不在伺服环里

Figure 的 Helix 页面，日期 2025 年 2 月 20 日，为同一台机器人公布了两个速率："System 2 (S2): An onboard internet-pretrained VLM operating at 7-9 Hz"（系统 2（S2）：一个在互联网数据上预训练、运行在机上的 VLM，以 7-9 Hz 运行），以及 "System 1 (S1): A fast reactive visuomotor policy… at 200 Hz."（系统 1（S1）：一个快速响应的视觉运动策略……以 200 Hz 运行。）一套权重——S2 是 7B，S1 是 80M——协调一个 35 自由度的动作空间。

7 到 9 Hz，是我们查过的这组部署方案里已公布的最快语义层；对面是 200 Hz 的控制，以及我们自己公布的 500 到 1,000 Hz 伺服环区间——后者是设计目标，不是测量。没有哪个可信的人提议把语言模型放进伺服环。机器人领域也没有哪场严肃的争论取决于该不该这么做。

真正悬而未决的问题是：语义层坐在环之上的哪一层，又被允许多久回到环里一次。在 Jetson Thor 上，这由一条内存总线决定。这块模组的招牌数字是 2,070 TFLOPS。决定架构的数字是 273 GB/s。

我们没有 Thor，这些数字一个也不是我们测的。这句话正以我们自己的口吻，写在我们自己的大脑页上，也是这篇文章能够写出来的唯一理由：直到 9 月 11 日，我们有两个页面把别人在 Thor 上的测量当作自己的发布出去；当天上线的更正又带进了第二个错误；而在这篇文章背后的研究里，我们断言没有人测过两个大模型在一块 Thor 上并发运行。有人测过，在 3 月，在一台真实的人形机器人上。

决定一切的那个数字

NVIDIA 的 Jetson Thor 页面，2026 年 9 月 11 日抓取，把两块模组并排列出。T5000：2070 TFLOPS (FP4—Sparse)，一颗 2560 核的 Blackwell GPU，128 GB 256-bit LPDDR5X，273 GB/s，40 到 130 W。T4000：1200 TFLOPS (FP4—Sparse)，1536 核，64 GB，同样 273 GB/s，40 到 70 W。内存减半，TFLOPS 是前者的 58% [推断，1200 ÷ 2070]，总线一模一样。

这为什么要紧，要看 NVIDIA Research 在 2 月发表的东西。VLA-Perf——Jiang、Clemons、Sankaralingam 与 Kozyrakis，四位作者全部来自 NVIDIA Research，arXiv 2602.18397v1，2026 年 2 月 20 日——用论文自己的话说，是 "an analytical performance model"（一个解析式性能模型）。它的作者们没有在任何一块 Thor 上跑过东西。它唯一的硬件验证，是别人在一块 RTX 4090 上的调优实现，那里 "an optimized system can achieve 73.3∼82.6% of the theoretical roofline reported by VLA-Perf"（一个经过优化的系统能达到 VLA-Perf 所报理论 roofline 的 73.3∼82.6%）；论文也说了它为什么偏乐观："VLA-Perf assumes that the maximum theoretical compute capability and memory bandwidth are attainable for every operator executed."（VLA-Perf 假定每一个被执行的算子都能达到理论上的最大算力与内存带宽。）它里面每一个 Thor 数字，都是建模出来的上界。

这个 roofline 找到的是机制。Takeaway 2，原文："Action prediction is memory-bound across hardware, while vision and VLM inference are compute-bound on most GPUs except from Jetson Thor."（动作预测在所有硬件上都受内存带宽限制，而视觉与 VLM 推理在多数 GPU 上受算力限制，Jetson Thor 除外。）原因就在同一页上。Thor "relies on LPDDR memory… (270 GB/s) than GDDR on RTX 4090 (1 TB/s) and HBM on B100 (8 TB/s). As a result, even the vision encoder and VLM backbone become memory-bound on Jetson Thor."（依赖 LPDDR 内存……（270 GB/s），相比 RTX 4090 上的 GDDR（1 TB/s）与 B100 上的 HBM（8 TB/s）。结果是，在 Jetson Thor 上连视觉编码器与 VLM 主干也变成受内存带宽限制。）背后的算子运算强度是：视觉编码器每字节 321.4 FLOPs，VLM 主干 542.8，动作专家 54.0 [建模值]。VLA-Perf 自己给总线的数字是 270 GB/s，比 NVIDIA 公布的 273 少 3；两个数字在本文里都出现，谁也不被平均掉。

接下来是速率。它们分三种，而我们自己的语料此前一直把三种压成一种。

NVIDIA 在一块 AGX Thor 上测了 GR00T N1.7，一个 3B 的策略：PyTorch eager 下 8.9 Hz，TensorRT 下 12.4 Hz——附带一条我们从未转载过的限定："4 denoising steps, 1 camera"（4 步去噪，1 路相机）。

NVIDIA 也测了 π₀.₅，在它的 Jetson AI Lab 教程里，而这一级是任何人能拿到的、条件交代得最完整的一级：pi05_libero 检查点，动作时域（action horizon）10，运行在一台装有 JetPack 7.2 的 Jetson AGX Thor 开发者套件上。PyTorch BF16 加 torch.compile、MAXN 模式下 132.00 ± 0.89 ms，即 7.6 Hz；TensorRT FP8 + NVFP4、MAXN 模式下 48.84 ± 0.16 ms，即 20.5 Hz [推断，由毫秒数换算]。BF16 与 4 位之间在真实芯片上差 2.7 倍，精度代价也写明了：单用 FP8 约 53 ms，"Most stable accuracy (cosine ≈ 0.9995)"（精度最稳定，余弦相似度 ≈ 0.9995），而 FP8+NVFP4 约为 0.99。

VLA-Perf 为 π₀——一个 2.7B 的模型，不是 3B——建模出 52.57 ms，即 19.0 Hz，条件是 BF16、动作块长度 50、10 步去噪 [建模值]。它更大的几级不是产品：π₀-L、π₀-XL 与 π₀-XXL，用论文自己的话说，是 "hypothetical larger VLA models"（假想的更大 VLA 模型），由作者们把 SigLIP-Giant 与 Llama2 系列换进去构造而成；π₀-XL 是 SigLIP-Giant 1.1B 加 Llama2-13B 加一个 2.9B 的动作专家。Physical Intelligence 没有做这个模型，它的建模速率不是任何人的产品性能。

还有一位独立开发者，在一块 AGX Thor 上测得 π₀.₅ 为 44 ms（23 Hz）、π₀ 为 46 ms（22 Hz）[单一来源]：一个发帖人，7thuniversels，一条 2026 年 5 月 2 日的帖子，精度与功耗模式始终没有说明，数字是他在自己的推理引擎里用 "hand-written CUDA kernels"（手写 CUDA 内核）达到的，此前用 MLIR-TRT 构建只做到约 70 ms——一位 NVIDIA 版主在帖子里回了话，没有核实其中任何一项，只是指向了 NVIDIA 自己的教程。

把这张表从上往下读，纪律就显出来了。那位论坛开发者测得的 22 到 23 Hz，高于 VLA-Perf 对同一类模型建模出的 19.0 Hz roofline，也高于 NVIDIA 自己测得的 20.5 Hz。动作块长度、去噪步数与精度各不相同：这些梯级不在同一把尺上，而我们公布的 10 到 25 Hz 策略区间，只是把其中经过优化的几级包了进去，仅此而已。它不包含两个未优化的梯级，而那两个都是 NVIDIA 自己的：PyTorch eager 下 GR00T N1.7 的 8.9 Hz，BF16 下 π₀.₅ 的 7.6 Hz。

500–1,000 Hz——伺服环[设计目标] Tidewell，发布于大脑平台页。不是对任何东西的测量；我们没有 Thor。

200 Hz——Helix System 1[实测，厂商] Figure，2025 年 2 月 20 日。一个 80M 的视觉运动策略驱动整个 35 自由度的上半身，运行在自己专属的嵌入式 GPU 上——Figure 给 S1 与 S2 各配一块 GPU，而不是把一块切开。

100 Hz——安全监控[设计目标] Tidewell，发布于大脑平台页。未测。

10–25 Hz——操作策略[设计目标] Tidewell，发布于大脑平台页。只是把下方经过优化的几级包了进去，仅此而已；NVIDIA 自己两个未优化的梯级，8.9 Hz 与 7.6 Hz，落在它下面。未测。

23 Hz 与 22 Hz——π₀.₅ 44 ms、π₀ 46 ms，AGX Thor[单一来源] 一位独立开发者 7thuniversels，一条 2026 年 5 月 2 日的论坛帖子。在他自己的推理引擎里用手写 CUDA 内核达到；精度与功耗模式始终没有说明；一位 NVIDIA 版主回了帖，没有核实其中任何一项。在写那些内核之前，他的 MLIR-TRT 构建约为 70 ms，约 14 Hz。

20.5 Hz——π₀.₅，AGX Thor[实测，厂商] NVIDIA Jetson AI Lab 教程：TensorRT FP8 + NVFP4、MAXN 模式下 48.84 ± 0.16 ms。这把梯子上条件交代得最完整的一级。

19.0 Hz——π₀（2.7B），Jetson Thor[建模值——非实测] VLA-Perf，NVIDIA Research，2026 年 2 月 20 日：BF16、动作块长度 50、10 步去噪下 52.57 ms，出自一个解析式 roofline 模型，其作者没有在任何一块 Thor 上跑过东西。论文自己写明：一个调优过的真实系统达到其 roofline 的 73.3–82.6%，且模型假定每个算子都能达到理论最大算力与带宽。

12.4 Hz——GR00T N1.7（3B），AGX Thor[实测，厂商] NVIDIA，TensorRT，4 步去噪、1 路相机。

7–9 Hz——Helix System 2[实测，厂商] Figure，2025 年 2 月 20 日。一个 7B、在互联网数据上预训练的 VLM 运行在机上，用自己专属的嵌入式 GPU。

8.9 Hz——GR00T N1.7（3B），AGX Thor[实测，厂商] NVIDIA，PyTorch eager，同样是 4 步去噪、1 路相机。

7.6 Hz——π₀.₅，AGX Thor[实测，厂商] NVIDIA Jetson AI Lab：PyTorch BF16 加 torch.compile、MAXN 模式下 132.00 ± 0.89 ms。这一级与上方 20.5 Hz 那一级相差 2.7 倍，不同的只有精度与运行时。

每秒 40–80 token——本地规划器[设计目标] Tidewell，发布于大脑平台页。每秒 token 数不是赫兹；这一级之所以在梯子上，是因为这一层在，不是因为单位能换算。未测。

0.5–3 秒——任务规划器与校验器[设计目标] Tidewell，发布于大脑平台页。在任务边界与异常时调用，从不进入控制环。未测。

• Tidewell 的设计目标——已公布，在任何东西上都没测过
• 由所标厂商在所标硬件上测得
• 不是对这块芯片的测量：一个 roofline 模型，或一条未经核实的论坛帖子

厂商自己的门槛，按其真实范围读

载有那张 GR00T 表格的文档，同时载有三道充分性门槛。我们此前一直引用其中一道，却把结尾切掉了。三道全文：

"10+ Hz — recommended minimum (Thor, Spark with TRT; most dGPUs with torch.compile): sufficient inference rate for typical manipulation tasks (paired with action chunking to reach ~30 FPS execution)."

"30+ Hz — high-frequency (H100, RTX Pro 6000 with TensorRT): headroom for reactive, low-latency closed-loop control where sub-30 ms per-step latency matters."

"< 10 Hz (Orin with TensorRT): only suitable for slow, non-reactive tasks."

即：10 Hz 及以上——推荐下限（Thor、带 TRT 的 Spark；多数带 torch.compile 的独立 GPU）：对典型操作任务足够的推理速率（配合动作分块达到约 30 FPS 的执行速率）。30 Hz 及以上——高频（H100、带 TensorRT 的 RTX Pro 6000）：为响应式、低时延的闭环控制留出余量，适用于单步时延必须低于 30 ms 的场合。10 Hz 以下（带 TensorRT 的 Orin）：只适合缓慢、非响应式的任务。

同一页上还有一段话，限定了整个读法："Because each inference returns a multi-step action chunk, a ~10 Hz inference rate can sustain ~30 FPS execution via action chunking + asynchronous inference — you do not need 30 Hz inference to execute at 30 FPS."（因为每次推理返回一个多步动作块，约 10 Hz 的推理速率经动作分块加异步推理可以维持约 30 FPS 的执行——要以 30 FPS 执行，并不需要 30 Hz 的推理。）VLA-Perf 独立地说了同一件事。

那种直白的读法——NVIDIA 把自家的机器人模组放在自家的推荐下限上，把响应式那一档留给不是机器人模组的芯片——在一个范围内成立，在另一个范围内不成立。就逐步响应性而言它是对的：单步 30 ms 以内，正是 30 Hz 那道门槛所指的东西，而 NVIDIA 自己在 Thor 上测得的最快数字，是 TensorRT FP8 + NVFP4、MAXN 模式下每次推理 48.84 ± 0.16 ms。若把它读成「Thor 上的策略驱动不了 30 FPS 的机器人」，它就是错的，因为 NVIDIA 说动作分块从约 10 Hz 起就能给出 30 FPS。我们的大脑页在 9 月 11 日之前载的是宽的那个版本，现在载的是窄的。

百分之七十二，以及这是谁的数字

这个论证倚得最重的那个数字，出自 NVIDIA 2026 年 8 月 19 日 Cosmos 3 Edge 博客里的一句话，而紧接着的下一句，正是我们此前丢下的那一句：

"On an NVIDIA Jetson AGX Thor T5000, it generates each action chunk in about 1.53 seconds (running at 640×540 resolution and 15 Hz), while a single chunk covers roughly 2.13 seconds of robot motion. Because the next chunk is ready before the current one finishes, the arm moves continuously, with no data-center GPU in the loop."

即：在一块 NVIDIA Jetson AGX Thor T5000 上，它生成每个动作块约需 1.53 秒（以 640×540 分辨率、15 Hz 运行），而单个动作块覆盖约 2.13 秒的机器人运动。因为下一块在当前这块用完之前就已备好，机械臂连续运动，环路里没有数据中心 GPU。

1.53 ÷ 2.13 是 0.7183 [推断，算术]。动作块的形状在同一页上可以互证：15 Hz 下 32 个动作，是 2.133 秒。

四件事随这个数字一起走。两个数字在同一页的同一句话里，所以这不是跨来源的拼接。它是推理层的墙钟时间占用，不是 GPU 利用率、内存占用或带宽。它是一个模型在一种分辨率、一种速率下的数字，把分辨率降下来它就变了。而且 NVIDIA 报告的是一次成功：那句讲连续运动的话，才是整段的要点。把同一道算术读成天花板——2.13 秒的运动减去 1.53 秒的计算，每个周期给其他一切留下约十分之六秒 [推断，算术]——是我们的读法，不是 NVIDIA 的，而这篇文章是在与产出这个数字的来源本身唱反调。一篇用了这个数字却不带那句框定语的文章，是在以省略的方式误引。

再有一个观察，需要小心处理。同一页往下，NVIDIA 自己的部署代码片段是同步的，而且只执行半块——result["action"][:16]，注释为 "first 16 of 32, then replan"（32 个中的前 16 个，然后重新规划），配的正文是 "Executing only a prefix and replanning is standard practice."（只执行一个前缀然后重新规划，是标准做法。）15 Hz 下 16 个动作是 1.067 秒的运动，对面是产出下一块所需的 1.53 秒 [推断，由同一页上的两处陈述算出]；于是，连续运动的说法依赖于把整块消耗完，而推荐做法只消耗半块，页面从头到尾没有说 1.53 秒该落在两者中的哪一个里面。

• Cosmos 3 Edge，AGX Thor T5000 — 1.53–2.13 秒 — 15 Hz 下 32 个动作，640×540
• 代码片段：32 个中的前 16 个 — 1.067 秒 — NVIDIA 在半块之后重新规划
• 产出下一块需 1.53 秒 — 1.53 秒
• NVIDIA 的测量
• 半块前缀
• 一块所覆盖的运动
• 到下一块的时间

反对意见，按其最强形式

最强的反对意见于 2026 年 6 月 1 日发布。NVIDIA 的 JetPack 7.2 公告："JetPack 7.2 on Jetson Thor introduces support for MIG, allowing the integrated NVIDIA Blackwell GPU to be partitioned into two isolated GPU instances with dedicated compute, cache, and memory bandwidth."（Jetson Thor 上的 JetPack 7.2 引入 MIG 支持，允许把集成的 NVIDIA Blackwell GPU 划分为两个相互隔离的 GPU 实例，各有专属的算力、缓存与内存带宽。）一个较大的分区，"12 SMs, 1536 CUDA cores"（12 个 SM，1536 个 CUDA 核），给 AI 与图形；以及 "A second isolated compute partition for robotics, control, perception, or safety-critical workloads (8 SMs, 1024 CUDA cores)"（第二个隔离的计算分区，给机器人、控制、感知或安全关键工作负载（8 个 SM，1024 个 CUDA 核））。它给出的理由，正是写给本文读者看的："control loops, AI perception, and generative AI reasoning must reliably coexist on a single embedded platform."（控制环、AI 感知与生成式 AI 推理必须可靠地并存于单一嵌入式平台。）

按最强形式接下它：分区是真的，已经发布，「专属……内存带宽」是 NVIDIA 自己的措辞。如果 MIG 给每个租户各配一条总线，上面的论证就到此为止了。可是那篇博客没有带任何基准测试。一个数字也没有，任何工作负载都没有，Thor 上或别处都没有。

带宽这个问题，NVIDIA 自己在 MIG 用户指南的 Thor 一节里给了答案；该页最后更新于 2026 年 9 月 11 日，9 月 12 日重读：

"The Thor iGPU uses unified system memory shared with the CPU. There is no dedicated video memory, so all profiles report 0 GB. Memory bandwidth is proportional to the instance size. At most two MIG instances can coexist simultaneously: one compute instance and one graphics (+gfx) instance. The full 3g.0gb profile cannot coexist with any other instance."

即：Thor 的集成 GPU 使用与 CPU 共享的统一系统内存。没有专属显存，所以所有配置档（profile）都报 0 GB。内存带宽与实例大小成正比。最多两个 MIG 实例可以同时存在：一个计算实例和一个图形（+gfx）实例。完整的 3g.0gb 配置档不能与任何其他实例并存。

旁边的配置档表用一列说了同一件事。H100 各行的 Fraction of Memory（内存份额）给出 1/8、1/4、2/8、4/8 与 Full，而 Thor 的每一个配置档都报 Fraction of Memory = N/A，对应的 Fraction of SMs（SM 份额）大约是三分之一或三分之二。指南的机制一节解释了为什么这两者是同一个问题："A GPU memory slice is roughly one eighth of the total GPU memory resources, including both capacity and bandwidth"（一个 GPU 内存切片大约是 GPU 全部内存资源的八分之一，容量与带宽都包括在内），以及 "Partitioning of the GPU happens using memory slices."（GPU 的分区就是按内存切片进行的。）

所以 MIG 保证的是服务质量。它把一套现成的内存系统切成相互隔离的份额，让一个租户不能把另一个饿死；在 Thor 上，这大约是一条 273 GB/s 总线的 91 GB/s 与 182 GB/s [推断，按「与实例大小成正比」算出]。MIG 让并存变得确定，也让它确定地更慢。它给总线定量配给。它不把总线加宽。

随之而来的还有两条约束。文档写明的两实例上限，是一个计算实例加一个图形实例，不是两个对等的计算分区——尽管 +gfx 实例确实能跑 CUDA，Jetson Linux 开发者指南里的示例就是这么做的。而且，NVIDIA 的博客与 NVIDIA 发布的工具，在第二个分区的大小上说法不一：博客说 12 个 SM 加 8 个 SM，正好是 T5000 的全部 20 个 SM；开发者指南则贴出了从一块 Thor 上取得的真实 nvidia-smi mig -lgip 输出，列出的 SM 数是 6、12 与 20，没有 8 个 SM 的配置档，并建议把 12 SM 的配置档与 6 SM 的配对，20 个里用 18 个。设备输出比公告更接近源头。我们不裁决，两个都印出来。

然后是那个根本不算论证的回答。Figure 在自己的机器人上运行两层架构，Helix 页面说了怎么做的："each equipped with dual low-power-consumption embedded GPUs. The inference pipeline splits across S2… and S1…, each running on dedicated GPUs."（每台都配有两块低功耗嵌入式 GPU。推理流水线分到 S2……与 S1……上，各自运行在专属的 GPU 上。）唯一一家公布过 7B 语义模型在机上与 200 Hz 控制器并肩运行的公司，没有去切一块模组。它给每一层各配了一块。

这就撤回了我们的一句话，而我们宁愿在这里自己撤回，也不愿等别人替我们撤。它的一般形式——没有第二个大模型能在 Thor 上与策略并存——按原话从来就不成立，在 MIG 之后更不成立，现在又被一项已发表的测量反驳。留下来的是更窄的那句，我们的大脑页已经这么写了：一个 30 至 70B 的任务规划器与校验器无法在机器人上与策略并存，而任何比本地规划器更大的东西都会与策略争抢 Thor 的内存总线。第二个模型放得下。问题是它让第一个付出什么，而这笔代价以带宽支付。

一块 Jetson Thor T5000 集成 GPU——2,560 个 Blackwell 核、20 个 SM——最多划成两个实例，一个计算、一个图形

较大实例——12 个 SM、1,536 个 CUDA 核，约三分之二NVIDIA 的博客把它分给 AI 与图形。Jetson Linux 开发者指南里的设备输出把它列为 2g 配置档，它也是博客与发布工具唯一一致的数字。

较小实例——约三分之一；按博客是 8 个 SM / 1,024 核，按设备输出是 6 个 SMNVIDIA 的博客把它分给"机器人、控制、感知或安全关键工作负载"，8 个 SM、1,024 个 CUDA 核 [单一来源，存在矛盾]。发布的 nvidia-smi 输出把 1g 列为 6 个 SM，根本没有 8 SM 的配置档，指南建议 12 与 6 配对——20 个里用 18 个。未决。

一条 273 GB/s 的 LPDDR5X 总线，与 CPU 共享——被切分，不被复制"Memory bandwidth is proportional to the instance size."（内存带宽与实例大小成正比。）Thor 的每一个 MIG 配置档都报 0 GB 专属内存、Fraction of Memory 为 N/A，对应的 Fraction of SMs 约为三分之一或三分之二——所以 SM 的切分就是带宽的切分：一条 273 GB/s 总线的约 182 GB/s 与约 91 GB/s [推断，按 NVIDIA 自己那句话算出]。T4000 上也是同一条 273 GB/s 总线，内存减半，TFLOPS 为 58%。

完整的 20 SM 配置档不能与任何其他实例并存，所以分区是选择让两个租户都跑得更小，不是让两个租户都跑满。

• 一个 MIG 实例——对算力的一次普通分区
• 两个实例共同取用的那一条内存总线，MIG 给它定量配给，而不是加宽
• 两个实例所在的那一块模组

我们说没有人测过的那件事

我们写过：不存在任何关于两个大模型在一块 Jetson Thor 上并发运行的已发表测量——没有论文，没有厂商基准，没有论坛帖子。我们错了。它已经存在了六个月，下一轮检索在第二次搜索就找到了。

OxyGen——Li、Tang、Ding、Wang、Cao 与 Liu，arXiv 2603.14371，v1 2026 年 3 月 15 日，v2 2026 年 5 月 18 日，一份未声明经过同行评审的预印本——为 π₀.₅ 实现了多任务推理，在一块 RTX 4090 与一块 Jetson AGX Thor 上评测，并 "further validate the gains on a real humanoid robot with on-board Jetson AGX Thor."（进一步在一台机载 Jetson AGX Thor 的真实人形机器人上验证了收益。）语言生成与动作生成并发，两个速率都已发表。

先说让步，因为这是更有用的一半。OxyGen 作为基线测量的，正是本文论证所预言的配置：两条推理路径在一块模组上，用论文的话说，每一条 "runs independently and sequentially within each frame"（在每一帧内独立且顺序地运行）——所以下面这个 1030 ms 是两次前向的加总，不是争抢的数字。在机器人上，3 路 224×224 的 RGB 观测、动作时域 10、10 步去噪、30 步解码且每帧 5 步——"baseline on-device inference (1030 ms) far exceeds the 333 ms action-execution window and blocks the next control cycle."（基线的机上推理（1030 ms）远超 333 ms 的动作执行窗口，阻塞了下一个控制周期。）超预算 3.1 倍 [推断，算术]——由 OxyGen 的作者们测出，就在这块芯片上，在一台真实的人形机器人上。

他们的第二个基线是那个朴素的修法，也很接近任何人读完 MIG 公告后会伸手去拿的那一个——接近，不相同，因为 MPS 是共享一块不切分的 GPU，而不是把它分区，而且没有人在 MIG 下跑过这个："each task runs on an individual process in parallel, sharing one GPU. We implement this for openpi via CUDA Multi-Process Service (MPS). Results show that this naive parallelization provides very limited speedup from the main baseline."（每个任务在各自的进程里并行运行，共享一块 GPU。我们通过 CUDA 多进程服务（MPS）为 openpi 实现了这一点。结果显示，这种朴素的并行化相对主基线只带来非常有限的加速。）

他们点出机制，然后测了它："Naive parallelization, in contrast, nearly doubles peak memory and even increases energy per request by 3% because of redundant computation and memory bandwidth contention."（相比之下，朴素并行化让峰值内存几乎翻倍，甚至因为冗余计算与内存带宽争抢，让每次请求的能耗增加 3%。）资源争抢是这篇论文要消除的两个缺陷中的第二个，而它在自己的消融实验里给这个缺陷记下了 2.6 倍的减速。这两个都不是 Thor 上的数字：2.6 倍论文明写是 RTX 4090 的，其基线随解码步数增加从 49.9 Hz 跌到 19.1 Hz；内存与能耗那张表没有标明硬件，但它的功耗远超一块 40 到 130 W 模组所能达到的范围 [推断]。这就是我们的论证，由并不打算做这个论证的人测了出来——在一块桌面级 GPU 上，它的总线比本文所讲的这块更宽。

现在是结果，按其最强形式，因为它指向另一边。有了 OxyGen 的统一 KV 缓存，两个任务确实在一块模组上并存了：在一块 Jetson AGX Thor 上，每秒 200 token 以上的语言吞吐，同时 27 Hz 的动作频率。这两个速率来自 LIBERO 配置；论文标题级的「比隔离执行最高快 3.7 倍」，是它在三种配置、两块 GPU 上取的最大值，不是 Thor 的数字；随之而来的质量声明是一个仿真结果——用 π₀.₅-LIBERO 检查点，该系统把 openpi 报告的成功率复现到 ±0.8% 以内，这是论文用来证明加速不损失什么的证据，不是机器人上的成功率。

在机器人上，总推理时间从 1030 ms 降到 393 ms，其中动作关键的预填充与去噪阶段占 198 ms，落在执行窗口之内；剩下 195 ms 的语言生成在其后运行，藏在运动的后面。

读一读是什么起了作用，因为这就是整个能否迁移的问题。OxyGen 不是两个大模型共享一块模组。它是一个 Mixture-of-Transformers 结构的 VLA，语言专家与动作专家共用一个主干，收益来自消除这种分离：一次预填充分发给两个专家，一份 KV 缓存，语言解码被刻意推迟到动作之后。这里行得通的架构，恰恰是「在第一个模型旁边再跑第二个」的反面。我们借不来这个结果：我们的语义层是另一个模型、另一套权重、做另一件事，没有可以分发出去的共享预填充。

取代我们那句话的否定命题更窄，而且两头都指。2026 年 9 月 11 日，在 NVIDIA 的 MIG 用户指南与 Jetson Linux 开发者指南 r39.2、developer.nvidia.com/blog、NVIDIA 开发者论坛的 JSON API、arXiv 以及四次网络搜索里检索：不存在任何人在一块 MIG 分区的 Jetson Thor 上对任何工作负载做过的、带有数字的已发表测量；也不存在一个 30 至 70B 的推理模型与控制策略在一块 Thor 上并发运行的已发表测量，不论分区与否。在这个问题上，没有东西支持我们的结论，也没有东西反驳它。

先撑不住的那张规格表

我们的大脑页公布了一个 7 至 8B 的本地规划器，每秒 40 至 80 token，作为设计目标。批量为 1 的自回归解码，每生成一个 token 都要把全部权重读一遍，所以上限就是总线带宽除以每个权重的字节数。按 273 GB/s，7B 在 BF16、FP8、FP4 下分别是每秒 19.5、39.0 与 78.0 token，8B 则是 17.1、34.1 与 68.2 [推断，算术]——这是一个上界，它忽略了注意力、KV 缓存、激活值、CPU 在同一块统一内存里的份额，以及每一个并存的工作负载。

而且还要打一个折扣。2025 年 10 月 29 日，一位开发者用一个只做内存拷贝、别的什么都不做的内核，在一块 Thor 上测得约 200 GB/s——那是 JetPack 7.2 之前八个月，没有人在之后的软件上重跑过——一位 NVIDIA 版主回了帖，没有提出异议 [单一来源]。按 200 GB/s，同一道算术给出 7B 的 14.3、28.6 与 57.1，8B 的 12.5、25.0 与 50.0。

所以我们自己公布的区间，只有在 4 位权重下、只有独占整条总线时才够得着，而页面给了速率，却没有说它假定的精度。在 BF16 下，我们区间的上沿是总线所能给的四倍。唯一让人安心的部分是，4 位是工作点而不是取巧：NVIDIA 自己的教程在同一块模组上把 132 ms 压到 49 ms，靠的就是 FP8 加 NVFP4，代价记在余弦相似度上。

任何要决定语义层放在哪里的人，从这里能得到三个问题，都关乎出处而不是赫兹。这个数字是测出来的还是建模出来的，在什么硬件上。如果是测的，什么精度，哪种功耗模式。第二个模型是不是真的第二个模型，还是一个与第一个共用主干的专家——因为 1030 ms 与 393 ms，是同一块芯片上的同样两个任务。

我们自己的放法——规划器与校验器放在现场服务器上，在任务边界或异常时调用——是一个从带宽推理得出的设计决定。它由我们来辩护，不靠文献来支撑。两天里我们有两句话需要更正：9 月 11 日的「在 Thor 上实测」，9 月 12 日的「VLA-Perf 测得」——后者是一次为消除一个错误而写的更正，在替换的那个从句里带进了一个更小的错误。这是本文里我们最希望能够略去的部分。我们会拥有一块 Thor，把策略与规划器一起跑在上面，并按十条规则公布两个速率。没有日期；在有数字之前，没有数字。