pi05-base-bh-galaxy

This repo runs Physical Intelligence's pi-0.5 vision-language-action policy on one Tenstorrent Blackhole Galaxy (32 Blackhole chips in 4 trays of 8) as an openpi websocket policy server. The model is SigLIP + Gemma-2B VLM + a Gemma-300M flow-matching action expert. Every serving mode uses the multi-config megakernel package of changh95/pi05-base-p150 (mode 1: its action-expert megakernel behind a TP8 prefix; modes 2 and 3: the package's single-chip model on every chip), which serves any robot type: 1-4 cameras, prompt bucket 32-224 tokens, horizon 1-64, 1-16 denoising steps. One entry point, serve.sh --profile, selects one of three serving modes:

The old profile names in parentheses stay accepted as aliases (same plan); the release directories profiles/<name>/ and results/<name>/ keep them. The v1 / v2 servers stay selectable in every mode as --cell final (the v1 TP8 cell, the v2 batched per-chip server, the v2 disagg engine), with their v1 / v2 numbers. What changed is listed in CHANGELOG.md.

Performance summary

The serving defaults, measured on the Galaxy with lerobot/pi05_libero. [측정] = measured, [추정] = estimate. Capacity is N_max: the largest number of robots, each sending one request every 250 ms (4 Hz), for which p99 latency (pooled and of the worst robot) stays ≤ 200 ms with 0 misses, on 3 of 3 random-phase seeds, every answer bit-exact against the class reference. Every row below is [측정]; artifacts in RESULTS.md §R.

Mix A = every robot c2 L32 H10 N10 (LIBERO); mix B = uniform over the camera / prompt / action-row presets and N 1-12; mix C = heavy (3-4 cameras, long prompts, H 50, N 10-12); mix D = light (1-2 cameras, L32, H 10, N 1-5). The mixed-fleet B / C / D values are those of the default host path PI05_MC_HOSTPREP=pre (2026-10-13, bit-identical answers); mix A, the 1 h soaks, LIBERO and the release-layout smoke ran on the legacy host path before it (below). Other robot types of uniform-fleet on 32 chips: c1 183, c3 74, c4 64 robots (admitted 183 / 74 / 64) [측정, 32-chip window; status WINDOW: no 32-chip soak]. LIBERO 2000 = 4 suites x 10 tasks x 50 initial states; the one-chip v1 baseline is 1941 / 2000 and every mode is within it (Fisher p > 0.05).

Single-chip reference: changh95/pi05-base-p150 (the same multi-config megakernel on one p150a card) reports 47.16 ms device time at cam2 and 77.63 ms at cam4 (its own card, @ 3bec9278ae1d; not re-measured here, tt-metal c718b5df9b9).

What the numbers were measured with: every accuracy and speed number in this repo uses the LIBERO fine-tune lerobot/pi05_libero @ a217bfd3 (--model libero, the default). The robot types other than the LIBERO shape (c2 L32 H10 N10) are payload classes for capacity and exactness; their gates are numerics gates against references, not task success. base_model names lerobot/pi05_base because the architecture, the port and the p150 package all come from it. --model base (H = 50, 224 tokens) is not gated on any Galaxy mode: the single-robot cell at c<C>_l224_s64 H50 N10 has an (a′) reference (smoke-tested); every other base form is untested, and uniform-fleet / mixed-fleet have no base class. serve.sh starts it and prints that status as a note.

Weights: lerobot/pi05_libero · lerobot/pi05_base · Paper: arXiv:2504.16054 · Upstream: Physical-Intelligence/openpi · Single-chip package: changh95/pi05-base-p150 · Port: changh95/tt-pi-0.5

Demo videos

Four videos in demo/ of this Hugging Face repo (not part of the serving tree or files.txt). Both runs used the host paths of 2026-10-12, before the perf1 / perf2 host-path changes (uniform-fleet lean MC host path, mixed-fleet legacy chip host path).

• Uniform fleet, 128 LIBERO robots on 32 chips (libero128_grid.mp4, all 128 robots, 29 s; libero128_zoom.mp4, 8 robots up close, 21.7 s). 128 closed-loop MuJoCo LIBERO episodes (32 per suite), every policy call served live by the 32-chip fleet, 4 robots per chip: 125 / 128 succeeded, and all 4047 action chunks are bit-identical to the same episodes of the one-chip LIBERO 2000 run [측정]. Playback is simulation time (20 fps = the 20 Hz control rate): the host has no GPU, so the sims rendered on the CPU and ran ~74x slower than real time. The real-time capacity on screen (128 robots at 4 Hz, worst-robot p99 179 / 155 / 160 ms) is the separate open-loop N_max walk, not this run.

• Mixed fleet, robots with 1 / 2 / 3 / 4 cameras on 32 chips (mixed_fleet_main.mp4, 102 robot tiles, 75 s; mixed_fleet_zoom.mp4, one robot per camera count, 20 s). serve.sh --profile mixed-fleet in real time with the 102 robot types of the mix-B N = 102 soak (30 one-camera Bridge V2, 27 two-camera LIBERO, 25 three-camera DROID, 20 four-camera ALOHA), each streaming recorded episodes at 4 Hz. Over a 600 s window: 102 / 102 robots within the gate (each robot p99 ≤ 200 ms), 0 misses, fleet p50 / p99 75.7 / 129.2 ms, worst robot p99 149.8 ms (4 cameras, H 50), 408 answers/s [측정]. This is open-loop replay: the predicted actions are never executed, and every robot type runs pi05_libero, which was not trained on Bridge / DROID / ALOHA. It is a serving-load demo, not a policy-quality claim.

Datasets in the videos: LIBERO (Liu et al., NeurIPS 2023 D&B; sims for the uniform-fleet video, recorded episodes from lerobot/libero, apache-2.0 card, for the mixed one); BridgeData V2 (Walke et al., CoRL 2023), CC BY 4.0 upstream, used via IPEC-COMMUNITY/bridge_orig_lerobot; DROID (Khazatsky et al., 2024) via lerobot/droid_100 (mit card); ALOHA (Zhao et al., RSS 2023) via lerobot/aloha_static_cups_open (mit card) and lerobot/aloha_static_battery (apache-2.0 card). Run details: RESULTS.md §R.6.

Uniform fleet (uniform-fleet, mode 2, 32 chips)

One MC-MK server per chip at batch 1 serves one robot type, chosen at start: --preset c<cameras 1-4>_l<prompt bucket 32/64/128/224>_s<action rows 32/64> [--horizon H] [--steps N] (default c<--cams>_l32_s32, H 10, N 10 = the LIBERO shape; prompts longer than the bucket are refused). A robot asks the router once (GET /assign?robot=R) and then talks the openpi websocket protocol to its chip. The router admits at most min(k_adm x chips, cap): k_adm is the measured robots per chip of mc_cost.json, the cap the measured N_max of mc_nmax.json.

• Soak on the default deployment [측정]: 128 robots, 1 h, 1,843,200 requests, all served and bit-exact, p50 / p99 / max 67.7 / 144.0 / 173.4 ms, worst robot p99 163.1 ms, 0 misses.
• Closed-loop LIBERO on 32 chips [측정]: 128 simulated LIBERO episodes (32 per suite) ran at once through the router, 4 robots on each chip: 125 / 128 succeeded, and every observation and action chunk was bit-identical to the same episodes served by one chip (the LIBERO 2000 run, 1949 / 2000).
• Gates on T1: gate (a) PASS, (a′) identity exact on all 8 T1 chips for all 13 classes with a reference, gate (b) 98 / 100 [측정].
• 32 chips hold more than 4 x the 8-chip N_max for c1 / c2 because the 8-chip deployments had a slower server host path (CPU partition shared with other work); see RESULTS.md §R.2.1.

Mixed fleet (mixed-fleet, mode 3, 32 chips)

Every request names its own robot type, and one URL serves all of them. A request is an openpi observation; the optional fields are prompt_bucket (32 / 64 / 128 / 224, else the smallest that holds the prompt), action_horizon (H 1-64), num_steps (N in 1-12 or 16), noise_seed and deadline_ms (default 200 ms). The camera count is the number of images sent (1-4). A request without these fields is the LIBERO shape: 2 cameras, L32, H 10, N 10. Each of a tray's 8 chips is a UniversalHost that holds every robot type's programs. It runs one request at a time, prefix then action expert, taking the earliest deadline first. Before READY, every chip's answers to the start-up self-check requests must equal the shipped reference (profiles/pa-disagg/mode3/refs/refs_selfcheck.npz). The default runs all 4 trays behind the front router (ws://127.0.0.1:8330, per-request join-shortest-queue). Mode 3 has no admission cap: every robot is routed, so plan by the measured N_max.

Host path. The default host path of engine mc is PI05_MC_HOSTPREP=pre (2026-10-13): the server's preprocessing threads build each request's device inputs as host tensors (the bf16 im2col straight from the uint8 pixels through a 256-entry table of the served conversion, cached mask / RoPE tensors), so a chip worker only copies, replays the two traces and reads back. Its answers are bit-identical to the legacy chip path's (every level above was checked against the legacy path's references) [측정], and a request's GIL re-acquisitions on the host path drop from 50-63 to 5-11 [측정, host bench]. The B / C / D values above are on this path; mix A, the soaks, the gates, LIBERO and the release-layout smoke ran on the legacy path and were not re-run (no soak on the new path at the new N yet). The 8-chip "legacy host path" values for B and D come from a same-runner A/B (chip vs pre, same commit and boot procedure); C 21 is from an earlier run.

At 32 chips the host CPU is still the limit [추정]: at the B / C edge each tray server keeps 12.2-12.7 of its 13 hardware threads busy (the chip workers spin on their completion events), and 32 chips reach 92 % (B) / 96 % (C) of 4 x the 8-chip value [측정]. The default uses the measured CPU plan (tray servers on 13 threads each, the front on CPU 23; your clients get the rest). Colo was chosen over the split layout 6p2a by measured capacity (mix B 28 vs 22, mix C 21 vs 17 on T2, legacy host path); 6p2a was removed (RULINGS R6.12). Mix definitions: RESULTS.md §R.3 (pre-registered in the development repo's plan/prereg_M3.md, not shipped).

The level-start slowdown is fixed on 8 chips. On the legacy path, more first requests than chips (>= 10 within ~50 ms) reaching an idle tray server could start a GIL hand-off convoy (host preparation 5-8x slower for 0.5-18 s), which bounded the light mix D run to run and made it report-only. With the pre host path no level of ~60 searched on T2 showed it, and the discriminating level (D N = 34, seed 2001) passed 3 / 3 repeats (worst robot p99 59.4 / 58.2 / 59.2 ms) where the legacy path on the same runner failed 2 of 3 (1555 / PASS 77.5 / 3517 ms) [측정]; mix D now has a gateable 8-chip N_max (48, 3/3 seeds). Mix D on 32 chips is not measured yet.

Single robot (single-robot, mode 1): the mc cell

mc is the TP8 cell (prefix tensor-parallel on the 8 chips of T0) with the action expert replaced by the multi-config expert megakernel, plus five prefix and host-path levers. One process serves one preset, chosen at start: --preset c<cameras 1-4>_l<prompt bucket 32/64/128/224>_s<action-row bucket 32/64> [--horizon H] [--steps N] (N 1-16; default c<--cams>_l32_s32, H 10, N 10). Every knob is set by the cell, never by hand:

Measured [측정, T0]: c2 L32 p50 / p99 31.76-32.18 / 32.05-32.51 ms (3 boots), c1 L32 28.28 / 28.59, c3 L32 37.51 / 37.77, c4 L32 41.24 / 41.69, c2 L224 35.98 / 36.47 ms; gate (b) 98 / 100; LIBERO 2000 1936 / 2000; 1 h soak at 6 robots PASS. Other presets are DEVELOPMENT (each has a frozen (a′) reference; soak and LIBERO ran at c2 L32). serve.sh gives the cell TT_METAL_OPERATION_TIMEOUT_SECONDS=60 when your environment has none. v2's cam2-only cell final_mk2 (30.51 ms p50 in the same chain) was removed in favour of mc, which serves every preset at +1.4 ms (RULINGS R6.10); its v2 results stay in RESULTS.md §10.

Host regime. On this host each server boot, and sometimes blocks of ~100-500 calls inside a boot, run in a fast or a slow host-CPU state. The state moves the client p50 by about 1.2 ms on T0 for every cell alike, and its cause is not attributed. A sub-millisecond p50 difference between boots is therefore not a code effect.

Accuracy

• The multi-config megakernel changes the numerics, so its answers are not bit-identical to the v1 / v2 servers'. Each mode passed its gates on its own references: gate (a) (PCC vs the fp32 golden; modes 1 and 2), gate (a′) (bit-identical repeats and chip identity; mode 3: its start-up self-checks and S2 / S3 gates), gate (b) (LIBERO 100: 98 / 100 in every mode) and LIBERO 2000 (1936, 1949, 1949 / 2000; two-sided Fisher p 0.714 / 0.499 / 0.499 vs the one-chip 1941) [측정].
• Modes 2 and 3 serve the LIBERO shape bit-identically: LIBERO 2000 through mode 3 equalled mode 2's run call for call (64,426 / 64,426) and episode for episode, and the 128-robot run on 32 chips equalled the one-chip run.
• Every capacity level and soak checked every answer against its class reference: all exact.

Stall fixes (on by default)

The 32-chip soaks of 2026-10-02 failed on short stalls that hit every server at once: Python's full garbage collection about 70-84 min after READY (100-120 ms with the GIL held) and 0.3-2 s write stalls of the host's root disk on serving threads. serve.sh therefore turns on PI05_GC_FREEZE=1 (all modes: the boot heap is frozen at READY, so later full collections take a few ms) and PI05_LOG_QUEUE=1 (single-robot, mixed-fleet: every log record goes through one writer thread). Both are host-level settings with no device or numerics effect; every 32-chip 1 h soak passed with them on. --no-stall-fix turns them off. Details in RESULTS.md §6.0.

Quickstart

Requirements:

• A 32-chip Blackhole Galaxy with KMD and firmware installed. The measurements used firmware 19.13.1 and KMD 2.10 (RESULTS.md §0).
• A source build of tenstorrent/tt-metal @ 668c2907575 with its python_env.
• In that python_env: openpi_client (openpi @ fdc03f5, packages/openpi-client), plus websockets and sentencepiece. See requirements.lock.
• git, flock, curl, taskset and ss; hf (huggingface_hub) or git-lfs to download this repo.

hf download changh95/pi05-base-bh-galaxy --local-dir pi05-base-bh-galaxy   # or git clone with git-lfs installed
cd pi05-base-bh-galaxy
export TT_METAL_HOME=/path/to/tt-metal                 # built @ 668c290757550588d0ce46b180c344a462a2aaf5
bash serve.sh --fetch-assets                            # tokenizer + norm stats (sha256-checked) + pi05_libero weights into the HF cache
bash serve.sh --profile uniform-fleet --dry-run         # print the plan, its status and the exact launcher command; touches nothing
bash serve.sh --profile uniform-fleet                   # 32 chips, 128 LIBERO robots: router http://127.0.0.1:8200
bash serve.sh --profile mixed-fleet                     # 32 chips, a robot type per request: ws://127.0.0.1:8330 (front)
bash serve.sh                                           # single-robot: T0, ws://127.0.0.1:8110, the mc cell
bash serve.sh --profile uniform-fleet --trays T1        # 8 chips (T1) instead of 32
bash serve.sh --profile mixed-fleet --trays T2          # one tray (T2): ws://127.0.0.1:8310

Ctrl-C (or SIGTERM to serve.sh) stops a deployment; nothing here ever resets a chip. The first start of each mode compiles its kernels into the runtime root's cache, so it takes longer than the warm boot times in SERVING.md. The 32-chip modes take every chip lock of the host (exclusive).

Client (openpi's own client, unchanged; LIBERO keys, uint8 HWC 224 x 224 images):

from openpi_client import websocket_client_policy
policy = websocket_client_policy.WebsocketClientPolicy("127.0.0.1", 8110)   # metadata arrives on connect
out = policy.infer({"observation/image": img, "observation/wrist_image": wrist,
                    "observation/state": state8, "prompt": "put the bowl on the plate"})
out["actions"]   # (10, 7) LIBERO actions, already unnormalised with openpi's pi05_libero norm stats

For uniform-fleet, first ask the router for your chip (GET http://127.0.0.1:8200/assign?robot=R returns its url) and connect to that; for mixed-fleet, connect to the front (8330) and optionally add the robot-type fields to each request. SERVING.md covers per-mode hardware, chips, ports, the router and front APIs, metadata, the stall-fix knobs, stop and failure behaviour, and the serve.sh options.

Caveats

• Galaxy only, as measured. The chip views (the 1D ring order of T0, the 2D (2,4) grids of T0-T3), the PCIe x8 chips and the tray map from idx to /dev/tenstorrent were measured on one host and are checked at start-up. A Galaxy whose views differ is refused rather than mis-served.
• Which configurations are MEASURED. uniform-fleet c2 L32 @ 4 Hz on 32 chips and on T1; mixed-fleet engine mc on 32 chips and on T2; single-robot mc at c2 L32 H10 N10 on T0. serve.sh --dry-run prints the status of any other plan (WINDOW, DEVELOPMENT, SMOKE-TESTED or UNTESTED) with its reason; every plan starts.
• 32-chip mixed fleets are host-CPU bound on a 64-thread host (above). Leave the CPUs outside the measured plan to your clients.
• One spare chip on T1 is headroom, not an idle chip. --trays T1 admits k_adm x 7 robots (capped at the measured 25 for c2), but the router places robots on all 8 chips.
• --model base is not gated anywhere (above).
• CPU pinning uses the measuring host's partition (cores n and n + 32 are SMT siblings). On another CPU layout, use --no-pin (single-robot, mixed-fleet) or edit the deploy_*.json maps (uniform-fleet).
• localhost only. Servers bind 127.0.0.1. Use an SSH tunnel or a proxy for remote robots.
• Device hangs. A device hang or op timeout latches the server: every later request gets an error, /healthz answers 503, the chips get quarantine markers, nothing is closed, and the server exits with a hang code at the stop without touching the device. A quarantined chip or tray is refused at the next start until the operator clears the markers (SERVING.md).
• Shared tools. The chip lease / run-dir / identity tools (tools/lease.sh, inrun.sh, rundir.sh, quiet.sh) run unchanged under serve.sh, keyed to the runtime root ($TTPI05_HOME/root, default ~/.cache/pi05-bh-galaxy/root). Their locks protect chips only from other users of the same runtime root, not from unrelated TT software.
• Outputs. The actions are LIBERO actions: openpi's pi05_libero unnormalisation, the first 7 dimensions. They are not usable on another robot without that robot's fine-tune and norm stats.
• Packaging. No tt-model container image is published, and tt-model-manager does not manage these multi-process deployments. tt-model.yaml keeps the p150 manifest layout as documentation; serve.sh is the entry point (SERVING.md).

Earlier servers (--cell final): v1 / v2 results

The v1 / v2 servers are kept, with their numbers from 2026-10-02 to 2026-10-05 (another host; not re-measured in R6). They use the v1 port without the multi-config megakernel and are not bit-identical to it. All [측정]; details and artifacts in RESULTS.md §2-§10.

Note that the v1 / v2 capacity rows used the 4-Hz class L_max 250 ms (p99 ≤ 245 ms), not the R6 gate class p99 ≤ 200 ms of the tables above. Not shipped: the whole-model megakernel class cam2mk (one chip hung in its 1 h soak; RESULTS.md §10.4).

Licensing

• Weights. lerobot/pi05_libero and lerobot/pi05_base are under the Gemma Terms of Use. They are not redistributed here; serve.sh --fetch-assets puts them in your HF cache.

• Tokenizer. The PaliGemma sentencepiece model (paligemma_tokenizer.model, identical to google/paligemma-3b-pt-224's) is under the same terms. It is fetched by checksum from openpi's public bucket, not shipped.

• Norm stats. openpi's pi05_libero norm stats are fetched, not shipped.

• Data. data/obs.npz holds 24 LIBERO observations from the MuJoCo simulator (LIBERO: MIT), used as payloads by the client tools. The reference actions in data/, profiles/dp-throughput/mode2/refs/ and profiles/pa-disagg/mode3/refs/ are outputs of the model above. Their meta field keeps the measuring host's run-dir paths as provenance.

• Demo videos (demo/, not part of the serving tree). They show frames of LIBERO (simulated and from lerobot/libero), BridgeData V2 (CC BY 4.0 upstream, Walke et al., CoRL 2023), DROID (lerobot/droid_100, Khazatsky et al., 2024) and ALOHA (lerobot/aloha_static_cups_open, lerobot/aloha_static_battery, Zhao et al., RSS 2023) episodes under their own licenses; see "Demo videos" above.

• Code.

  • code/ is the port (models/experimental/pi0_5, Apache-2.0 headers) and the vendored multi-config megakernel package (models/experimental/pi0).
  • profiles/, tools/ and eval/ hold the Galaxy serving code.
  • serve.sh is the release entry point.

  All code is distributed under the same Gemma terms as the p150 package.

Provenance