Horizon × depth (Euler steps vs execution horizon)¶
They said a robot that commits to long motion chunks can use 2 sampling steps instead of 10. On our arm's computer we measured how tightly 2 steps group the planned motions, and the time saved. Not proven: on 20 frames, 2 steps kept 0.78 of the 10-step spread (paper: 0.51) and saved 41 ms.
Papers tested · 21 of 22
Goal (the paper's): Show that, for frozen flow-matching VLAs, the effect of cutting Euler steps depends on how long the robot commits to a chunk: fewer steps hurt under frequent replanning and help under long open-loop commitment; shown on LIBERO, RoboTwin 2.0 and a real Franka.
Its hypotheses:
- Few Euler steps contract the sampled action cloud around an unchanged centroid. (Proposition 1; §III-D) not proven
- Under long open-loop commitment, two steps match or beat ten while cutting inference time. (Table I; Fig. 3; latency figures) reproduces
- Two steps avoid thermal throttling on edge GPUs. (§IV (end): 0.04 NFE per step; asserted, no thermal measurement) not tested here
Verdict: not proven · Claim tested: With long open-loop commitment, cutting a flow-matching VLA's Euler steps from 10 to 2 contracts the action cloud around an unchanged centroid, saves most of the inference time and avoids edge-GPU thermal throttling. · Bar: median R(2)/R(10) ≤ 0.70 with the centroid within 0.05 relative and 3°; N = 2 latency ≤ 0.85 × N = 10 on the Orin, N = 10 within 5 % of 238 ms. · n: 20 frames × 32 draws; 50 timed chunks per N; 2 × 10 min thermal per power mode
Theirs vs ours: R(2)/R(10) 0.51, centroid shift 3.2 %; 14.3 → 2.6 ms per step (A100); "eliminating edge GPU thermal throttling" vs R(2)/R(10) 0.78 (CI 0.73–0.81), centroid 0.018 and 2.35°; 196.1 vs 237.5 ms per chunk (0.83, vision 151 ms); no throttling at N = 10 on the Orin, at MAXN_SUPER or 25 W · Not proven: The contraction is between the bar and the fail line, so the arm gate (success at N = 2 vs 10) is not run; one policy, one task.
Paper: arXiv 2610.32102 · Code: no code link found
Claims:
- not proven two Euler steps below ten Euler steps on action-cloud radius — theirs R(2)/R(10) 0.51 · ours R(2)/R(10) 0.78 (paper Proposition 1; §III-D (R(2)/R(10) = 0.51 on π0))
- reproduces two Euler steps below ten Euler steps on ms per chunk on the Orin NX — theirs 14.3 → 2.6 ms per step · ours 196.1 vs 237.5 ms (paper Table I (14.3 → 2.6 ms per control step, A100))
Compute: External GPU: no. A1 on the Orin NX at 25 W (PyTorch); A2 and A4 at MAXN_SUPER + jetson_clocks and at 25 W (vla.cpp). Cost: $0; A2 and the MAXN half of A4 re-run once. · Reproduce: 2026-10-30-paper-vs-hardware-horizon-depth · First published: 2026-10-30 · Updated: 2026-10-30
Coupling Execution Horizon and Sampling Depth in Flow-Matching VLA Policies (Yang et al., arXiv 2610.32102) says that when a robot commits to a long chunk, two Euler steps are as good as ten and much cheaper. My SO-101 already runs SmolVLA with its whole 50-step chunk committed, so the claim lands on its default setting.
What the paper claims, and how it measures it¶
A flow-matching policy draws an action chunk by integrating from noise in N Euler steps. With few steps the samples cluster: the paper's Proposition 1 says the cloud contracts around an unchanged centroid, so under long open-loop commitment, where averaging out sample noise matters, N = 2 matches N = 10. On π0 the cloud's radius falls to 0.51 of N = 10's with a 3.2 % centroid shift, the per-step latency drops from 14.3 to 2.6 ms on an A100, and the authors add that N = 2 avoids thermal throttling on edge GPUs. Real-robot results are on a Franka Research 3.
What I ran¶
SmolVLA (10 Euler steps, H = 50, the checkpoint behind every vla.cpp number here) on 20 frames from the bowls episodes. Bars frozen before any number:
- A1, mechanism: median R(2)/R(10) ≤ 0.70, with the centroid within 0.05 relative and 3°; fail above 0.85.
- A2, latency on the Orin: N = 2 ≤ 0.85 × N = 10, with N = 10 within 5 % of the 238 ms reference.
- A4, thermal: 10 minutes at N = 10, 10 idle, 10 at N = 2, at full power and at 25 W; throttling = the GPU clock 5 % below its first minute for 10 s.
The arm test (success at N = 2 vs 10) runs only if A1 and A2 pass.
Their number, my number¶
| Paper | This rig | |
|---|---|---|
| cloud radius, N = 2 / N = 10 | 0.51 | 0.78 (CI 0.73–0.81) |
| centroid shift | 3.2 % | 1.8 %, 2.35° |
| inference saving with N = 2 | 14.3 → 2.6 ms per step (A100) | 237.5 → 196.1 ms per chunk (Orin NX) |
| thermal throttling at N = 10 | "eliminated" by N = 2 | none at full power or at 25 W |
A1 is not proven: two steps do contract the cloud around a nearly unchanged centroid, but by 22 %, not 49 %, and the confidence interval sits between the bar and the fail line. A2 passes, barely, and for a reason the paper's A100 hides: on the Orin a chunk is 151 ms of vision, 15 ms of prefill and 5.3 ms per denoise step, so cutting 8 of 10 steps saves 41 ms. A4 has nothing to act on: one chunk every 1.67 s never throttled the Orin, the GPU staying at 1,173 MHz and under 69 °C.
What the gap means¶
The mechanism is there but weaker on a 450M policy, and the cost it removes is a small slice of an edge chunk: the vision encoder dominates, so the denoising budget is not where the Orin's time goes. Because A1 did not pass, the arm test did not run and SmolVLA stays at ten steps.
Verdict: not proven.
What would change it: a policy whose denoising dominates the chunk (larger action expert, cheaper vision), or an arm test showing N = 2 keeps success, which the protocol only runs after A1 passes.
Compute. External GPU: no. A1 on the Orin NX at 25 W (PyTorch); A2 and A4 at MAXN_SUPER + jetson_clocks and at 25 W. Cost: $0. A2 and the full-power A4 were re-run once (a root-owned results folder; a tegrastats format without the GPU clock).
Reproduce this: 2026-10-30-paper-vs-hardware-horizon-depth
Papers tested, 21 of 22. ← Papers tested 20: PACT-VLA · Papers tested 22: REMORA →