Proprio · physical AI inference
The policy you validated. Bit for bit, faster.
Proprio runs an unmodified vision-language-action policy faster and proves, tick by tick, that the actions it produces are identical to the policy's own eager execution. If they are not identical, it refuses to deploy. Every run ships a Bitwise Certificate.
Technical preview · LeRobot checkpoints, unmodified · RTX 4090 · every figure measured
The same 450M-parameter policy, the same inputs, the same noise. The compiler is faster and changes the robot's actions; Proprio is 6.4× faster and changes nothing.
How
Faster, then proven identical.
The usual ways to make a policy faster, compilers, lower precision and autotuning, change its arithmetic, so the robot's actions change too. Proprio makes the same policy faster without changing a single action, and proves it on every run.
The unmodified policy
Proprio loads the checkpoint as LeRobot does, with no source edits, and prepares a faster run of the same policy.
Bit for bit, on held-out inputs
Proprio's actions are compared with eager actions on held-out inputs, with fixed noise and seeds. Not close: identical, every byte of every action chunk.
Refuse what is not identical
A tick that cannot be proven identical is not deployed; Proprio falls back to the original path and says why. A non-identical tier is reported with its measured error, never as "exact".
A Bitwise Certificate per run
Actions, identity count, error bounds, latency, device, driver, clocks, power state, seeds and a digest, signed. The document a safety review or a customer can check with a public key.
Single robot
Three policy families, three exact certificates.
One robot, one GPU, the policy as its authors shipped it. Latency is the median wall time of a full control tick including the host-side pre- and post-processing; identity is counted per tick against eager with the same inputs and noise.
| Policy | Parameters | Eager p50 | Proprio p50 | Speedup | Bit-identical ticks | Evidence |
|---|---|---|---|---|---|---|
| SmolVLA | 450M, fp32 under autocast | 241–246 ms | 36–39 ms | 6.2–6.5× | 100 / 100; identical across 6 fresh processes and 3 clock states | measured |
| pi0.5 | 3.3B, bf16 | 266 ms | 98 ms | 2.7× | 100 / 100 | measured |
| GR00T N1.7 | 3B, bf16, whole tick | 170–178 ms | 64–66 ms | 2.7× | 32 / 32 | measured |
measured RTX 4090, torch 2.11, LeRobot 0.6 checkpoints (lerobot/smolvla_base, lerobot/pi05_base, nvidia/GR00T-N1.7-3B). Eager is LeRobot's own inference path with no changes. Ranges span several certificate runs on different days; identity never varied.
Speed versus drift
Every free speedup moves the robot.
The accelerations teams reach for first, measured on the same 100 ticks with the same inputs and noise, next to the exact tier. Action error is the largest change in any normalised action value of the chunk; 0.07 to 0.1 is the size of the step between two consecutive actions.
| Policy | Mode | p50 | Speedup | Rows identical | Max action error | Warm-up |
|---|---|---|---|---|---|---|
| SmolVLA | eager (reference) | 246.1 ms | 1× | reference | 3.1 s | |
| SmolVLA | Proprio exact | 38.7 ms | 6.36× | 100% | 0 | 2.5 s |
| SmolVLA | torch.compile, cudagraphs | 49.5 ms | 4.97× | 0% | 0.083 | 58.0 s |
| SmolVLA | torch.compile, max-autotune | 26.6 ms | 9.24× | 0% | 0.068 | 36.2 s |
| SmolVLA | TF32 matmul | 239.7 ms | 1.03× | 0% | 0.012 | 3.1 s |
| SmolVLA | cuDNN benchmark | 242.5 ms | 1.01× | 0% | 0.100 | 3.0 s |
| pi0.5 fp32 | eager (reference) | 330.5 ms | 1× | reference | 3.6 s | |
| pi0.5 fp32 | Proprio exact | 209.7 ms | 1.58× | 100% | 0 | 3.5 s |
| pi0.5 fp32 | torch.compile, max-autotune | 173.4 ms | 1.91× | 0% | 1.1e-05 | 560.8 s |
| pi0.5 fp32 | TF32 matmul | 280.9 ms | 1.18× | 0% | 0.0071 | 3.1 s |
| pi0.5 fp32 | cuDNN benchmark | 330.3 ms | 1.00× | 100% | 0 | 4.3 s |
| pi0.5 fp32 | bf16 weights | 272.2 ms | 1.21× | 0% | 0.305 | 3.4 s |
measured 100 ticks, 4 mixed instructions, fixed noise. On SmolVLA, cuDNN autotuning alone buys nothing and still moves actions by 0.1. The fastest row, max-autotune at 9.2×, drifts 0.068 and needs 36 s of warm-up against 2.5 s. A drift of any size means the deployed policy is not the one that was validated.
Many robots per tick
Batch the fleet, keep every robot's answer.
Serving several robots or simulated environments per tick is the utilisation lever, but stock GPU kernels change their arithmetic with the batch size, so row i of a batched result is not what robot i gets alone. Proprio offers two tiers and certifies each row against that robot's own single-robot run.
Identical to the original policy
Every row is bit-identical to the original eager policy run for that robot alone. 12.5× per robot on SmolVLA at 16 robots.
Identical to its own single-robot run
Every row is bit-identical to the tier's single-robot run; its measured difference to stock eager is declared on the certificate. 14.8× per robot on SmolVLA.
96% GPU busy at 16 robots
One eager SmolVLA process keeps the GPU 17% busy; a single exact run 83%; the batched tick 96% in both tiers (Nsight, RTX 4090). 55 to 67 robots per second on one card.
| Policy | Robots / tick | Tier | Rows identical | Eager, one robot | Proprio, per robot | Speedup | Declared diff vs eager |
|---|---|---|---|---|---|---|---|
| SmolVLA | 16 | exact | 64 / 64 | 240.5 ms | 19.3 ms | 12.5× | 0 |
| SmolVLA | 16 | invariant | 64 / 64 | 227.2 ms | 15.3 ms | 14.8× | 0.090 |
| pi0.5 fp32 | 8 | exact | 64 / 64 | 314.9 ms | 174.7 ms | 1.8× | 0 |
| pi0.5 fp32 | 8 | invariant | 64 / 64 | 314.2 ms | 109.6 ms | 2.9× | 0.041 |
| GR00T N1.7 | 8 | invariant | 64 / 64 | 179.1 ms | 119.9 ms | 1.5× | 0.209 |
| GR00T N1.7 | 4 | invariant | 32 / 32 | 175.5 ms | 149.1 ms | 1.2× | 0.209 |
| GR00T N1.7 | 4 | exact | 32 / 32 | 176.7 ms | 237.1 ms | 0.75× | 0 |
measured Rows compared against each robot's own single-robot run with its own observation, noise and seed. Both tiers are correct floating-point implementations; the certificate declares the invariant tier's measured difference to eager and names which implementation was validated. A 3B-parameter model is already compute-bound at one robot on this GPU, so GR00T's headline stays the 64 ms exact single-robot tick; the exact tier's per-robot execution costs more than the batch saves there.
Bitwise Certificate
What every number here stands on.
Each table row above comes from one certificate, a JSON document the engine writes after a run. The hosted certification service signs it with an Ed25519 key; anyone can verify a signed certificate with the public key.
Identity and error
Per-tick eager and engine actions, the count of bit-identical ticks or rows, max and mean absolute error, the reference used (original eager or same-tier single-robot) and, for a non-exact tier, the declared difference to eager.
Latency and split
p50 and p99 of both paths, the host pre- and post-processing share, per-robot cost and batch size for rollout runs.
What it ran on
GPU, driver, torch build, clocks, power state and active throttle reasons at the time of the run, thread count, seeds and noise seed, weight-precision manifest, licence tier, digest and signature.
Status
Where Proprio stands today.
In plain language, for teams deciding whether to try it.
Exact single-robot tick
SmolVLA, pi0.5 and GR00T N1.7 certified bit-identical on an RTX 4090, 2.7 to 6.5× faster than LeRobot eager, including the host side of the tick.
Exact multi-robot rollout
Two certified tiers at 4 to 16 robots per GPU on all three policy families, 96% GPU busy on SmolVLA.
Design partners
Evaluation licences for teams running LeRobot policies on NVIDIA GPUs: a certificate on your checkpoint and your inputs within a day of access.
Jetson and other GPUs
Jetson Thor and data-centre cards; the method does not depend on the card, only the speedups do.
Your policy
Send a checkpoint, get a certificate.
Tell us the policy, the GPU and the control rate you need. We return a Bitwise Certificate on your checkpoint and your observations: the speedup, and the proof that nothing else changed.
hello@zenedgex.in