pi05-b1k-base-pytorch-sft

pi05_base_pytorch_sft

The PyTorch-converted π0.5 base used as pytorch_weight_path by every BEHAVIOR-1K skill adapter in this collection (pi05-b1k-nav-move-to-lora, pi05-b1k-pick-up-from-lora, pi05-b1k-place-in-on-lora). Converted 2026-08-01; published 2026-08-25.

Why this is published separately

A trained step-N/ checkpoint in the adapter repos is self-contained — 1,390 tensors, fp32, base weights and LoRA together — so evaluating a trained policy does not need this file. It is needed to (a) START a training run, since train_pytorch.py loads pytorch_weight_path before wrapping the model with PEFT, and (b) serve as the init (pre-LoRA) arm in attribution work, which is the only way to say what the adapter changed.

It lived only on the two hosts that used it, copied box-to-box, until 2026-08-25.

It must have AdaRMS

π0.5 in openpi depends on a transformers_replace patch that injects AdaRMS into gemma. Convert the JAX base inside a venv without that patch and you get a 6.52 GiB file with plain RMSNorm that silently loads and then fails on every checkpoint:

Missing key(s):    ...gemma_expert.model.layers.0.input_layernorm.dense.weight
Unexpected key(s): ...gemma_expert.model.layers.0.input_layernorm.weight

The 0.22 GiB difference between the two builds is exactly those 72 layernorm.dense layers. This file is the patched build: it has all 72.

What is NOT recorded

The JAX checkpoint this was converted FROM is not identified anywhere, and no copy of it survives on the training host. The conversion tool is openpi's examples/convert_jax_model_to_pytorch.py, but the input is unknown. So this file is currently the only artifact of its own provenance — which is the reason it is on the Hub rather than on two disks.

Note that madokalif/pi05-b1k-sft50k-merged is not a substitute despite a similar size and an identical 812-key layout: its vision tower matches byte-for-byte but its action expert does not. That repo is a merged LoRA at step 50,000, a different artifact.