Where Does a Robot Think — On-Device vs Datacenter Inference

迄今为止，AI 主要活在屏幕后面。聊天机器人回答问题，随后 agent 开始驱动软件、自主完成多步骤任务。下一步就是能在物理世界中行动的 AI，而其中最大的一块就是机器人。现在还处于早期阶段。无论是硬件、模型还是商业模式，都还没有定论。

具身问题

在 LLM 领域，硬件要迁就模型。训练时尽可能多地投入数据和算力，然后再想办法部署训练出来的模型。模型第一，硬件第二。而机器人领域正好相反，原因在于两个约束。

第一个约束是时间。机器人要运行实时控制回路，不能错过任何时限。LLM 慢一点并不影响最终输出，但机器人一旦变慢，周围的世界就已经变了，等它要执行动作时，这个动作已经过时了。

第二个约束是成本。使用 LLM 时，模型运行在用户自带的屏幕后面；而在机器人领域，制造商必须同时构建计算硬件和机器人本体，并且要在每一台设备上提前支付这笔费用，资本开支可能非常庞大。一旦形成规模化，这笔前期投入可能达到数十亿美元；如果最终真能造出十亿台机器人，甚至可能高达数万亿美元。

受这两个约束影响，机器人领域的情况是：机器人本体上的硬件是固定的，模型要围绕我们能合理量产的硬件来设计。前沿的模型能力将受限于我们能在 affordable 的实时硬件上运行什么，智能变成了一种要在延迟和单机经济性之间精打细算的资源。

机器人模型目前还很小……

正因如此，前沿机器人模型的规模仍远小于前沿 LLM——后者已经迈入万亿参数级别。如今的通用机器人模型都在十亿到百亿参数级别：Physical Intelligence 的 π0 系列约 30 亿参数，π0.7 为 50 亿，ByteDance 的 GR-3 为 40 亿，Generalist 的模型约 100 亿，NVIDIA 的 DreamZero 为 140 亿。不过，这些参数量的含义不如 LLM 那样明确。LLM 实验室是在训练预算和推理成本之间权衡质量来选择模型规模；机器人实验室则是根据数据能支撑多大规模、以及什么模型能在延迟预算内塞进一块 Jetson 或 H100 来选择规模。机器人模型的参数量告诉你约束在哪里，而不是规模最终会稳定在哪里。

在大语言模型（LLM）领域，规模法则（scaling law）一直成立，扩展模型规模持续扩大了单个模型所能解决的问题范围。Generalist 和 Dyna 等公司的早期结果表明，机器人领域也遵循同样的规律。问题不在于规模扩展是否有效，而在于输入能否跟上。数据是第一个约束：目前不存在互联网规模的机器人经验语料库，而真实世界的交互数据生成起来既缓慢又昂贵——这正是具身人类数据采集和世界模型兴起的原因。网络是第二个约束。前沿模型的规模已经超出了机器人本身的承载能力（π0.7 需要在机器人外部的 H100 上运行；DreamZero 需要两块 GB200）。一旦模型部署在数据中心，延迟和抖动就会成为问题。

机器人模型的规模最终会落在什么水平，目前尚不明确。趋势线是向上的，但效率提升在不断把它往回拉，这个领域还没有收敛。NVIDIA 的 DreamZero 是一个 140 亿参数的「世界动作模型」，基于视频扩散（video-diffusion）骨干网络构建，仅为了实时运行就需要在机器人外部使用两块 GB200 GPU。但算力需求变化很快：在 DreamZero 发布数月之后，NVIDIA 的 RoboTTT 做出了相反的押注，它采用一个 30 亿参数的策略模型，通过测试时训练（test time training）持续更新自身权重，而不是生成对未来的视频预测。其结果是一个拥有数分钟可用上下文、且小到可以在机载运行的模型。

无论模型规模最终落在哪里，我们的观点是：多种方法的级联是不可避免的。一些机器人会在机载上完整运行认知计算，另一些则会将其中一部分卸载到数据中心的 GPU 上。不过，对于需要真正智能的通用机器人而言，我们认为机载外计算（off-robot compute）具有诸多优势，从摆脱机器人自身的算力和功耗预算，到在整个机群中共享推理资源。它确实带来网络方面的挑战（我们将在后续章节讨论），但它正日益成为一个可行的选择。

机器人模型入门

在探讨机载外计算这个概念之前，先简单介绍一下机器人模型的工作原理，以及我们讨论的是哪些模型。

经典的机器人控制——运动学、规划轨迹加上反馈控制器——几十年来一直在工厂里依靠小型嵌入式芯片运行。许多范围狭窄的学习型策略也能装进机载芯片。但这两者都不是本文讨论的重点。我们关注的是通用机器人：能够遵循开放式指令、应对从未见过的场景、并能承担多种不同工作的机器人。

机器人模型的层次结构

最上层是规划层。它负责解读指令和场景，决定机器人下一步该做什么，并可能生成子任务、目标位置、抓取位姿或足步规划。其下是动作层（或运动层）。它将这些输出转换为短促的动作序列、身体姿态或速度指令。最底层是伺服与安全回路。它们负责估计机器人状态、响应接触和打滑、维持平衡，并最终向执行器下达指令。

频率决定了哪些层必须在机器人本体上运行。动作层和伺服层的运行频率高达数百 Hz：一个 100 Hz 的循环必须每 10 毫秒就产出一个输出。而一次典型的无线往返本身就要耗费 10 到 50 毫秒，即便是精心优化的链路也需要将近 10 毫秒。因此对于这些循环来说，网络带来的不只是延迟，它几乎在模型开始计算之前就把整个时间预算消耗殆尽。这就是为什么任何高于大约 100 Hz 的环节都不能离开机器人本体。

在大约 20 Hz 以下，也就是规划层所在的频率范围，情况就不同了。一个以 5 Hz 运行的规划器每次决策有 200 毫秒的时间，因此即便是 10 到 50 毫秒的往返也绰绰有余，还有不少余量。这样的余量足以把规划层完全从机器人上移出去，而且一个调校良好的网络协议栈甚至可以把可卸载的边界推到 20 Hz 以上。不过，更大的问题在于抖动而非延迟。固定的延迟是可以提前规划的：系统大致知道机器人和周围环境在这段时间内会移动多远，从而提前做一点规划。抖动则更难处理，因为指令到达的间隔不规律，机器人永远无法确切知道下一次更新何时到来。可以按最坏情况进行缓冲，把可变的延迟转化为可预测的延迟，但这样一来每个动作都要付出最坏情况的代价。真正解锁规划层卸载的，是把抖动控制住。

规划层同时也是计算需求最重的层，而且随着泛化能力的提升，这些需求还会不断攀升。开放式的任务需要真正的推理能力，而推理模型都很庞大。这正是一些公司开始考虑数据中心算力的原因。Jetson Thor 是目前能买到的最好的机器人计算平台，但它提供的 FLOPs 仍只有 GB200 的大约 1/10，内存带宽更是只有后者的约 1/30。

供应链的现实

供应链同样是为数据中心芯片而非机器人芯片服务的，扩大机器人芯片的产能并不容易，尤其是在前端产能和 DRAM 本就已紧张的情况下。Nvidia 自身的产出就说明了这一点。

Nvidia 的加速器产出几乎全是数据中心芯片：Hopper 在 2023 年和 2024 年经历了漫长的产能爬坡，随后交接给 Blackwell，后者在 2025 年和 2026 年急剧放量并主导产品组合。而用于机器人的 Jetson 产品线，只是图表底部一条细细的红色窄条，即便到 2026 年也几乎看不见。这是因为机器人市场尚处于萌芽阶段，真正的放量还要等上好几年，而且眼下几乎没有可以规模构建的应用场景。

利润率也呈现出类似的局面。需求尚未到来，但一旦到来，价格就会上涨，Jetson 的利润率也将随之扭转。但目前，一块 Blackwell 数据中心 GPU 的毛利率远高于一个 Jetson 模块，前者约为 75%～80% 的中高水平，后者约为 65% 左右。因此，NVIDIA 完全有动力把稀缺的先进制程晶圆产能优先分配给数据中心，而在机器人市场仍然很小的时候，几乎没有理由去扩大边缘芯片的生产。

更糟的是，机器人芯片正在向数据中心争夺的那些制程节点收敛。Nvidia 的 Jetson 产品线过去是有隔离的：上一代 Orin 采用的是 Samsung 的 SF8 工艺。而当前的 Thor 一代已经转到了 TSMC N4，缩小了这一差距。随着机器人运行越来越强大的模型，其芯片必须保持在先进制程上：Thor 的下一代很可能与 Rubin 一起迁移到 N3，之后再到 N2 与 Feynman 同行——而这些正是整个 AI 加速器路线图都在争夺的节点。因此，出货量低、利润率也较低的 Jetson，在先进制程晶圆的争夺中将永远排在队伍末尾。

但机器人带来的晶圆需求并不是压力所在。2030 年若有 100 万颗 Jetson 级别的芯片，每颗约 400mm²，全年也只需要约一万片晶圆——相对于数据中心 GPU 的放量而言只是个零头的零头。原因在于 Thor 的芯片面积只有接近 reticle 尺寸芯片的一半左右，而且目前机器人的数量本来就不多。只有当机器人每年需要数千万颗芯片时，供应才会真正紧张，而那已远远超出 2030 年。所以真正的问题不在于机器人能否拿到晶圆，而在于硅片效率：对于给定规模的机器人集群，哪种方案消耗的先进制程硅片更少？是在每台机器人里装一颗芯片，还是用共享的数据中心 GPU 来提供它们的认知能力。

如果以每台机器人消耗的晶圆数来衡量硅片效率，板载芯片与共享数据中心 GPU 的交叉点大约在每颗 GPU 服务 7 台机器人处。超过这个数之后，通过共享 GPU 提供认知能力，在每台机器人上消耗的硅片反而比在每台机器里装一颗芯片更少。这一点才是关键所在：因为当晶圆厂供应紧缺时，每台机器人消耗硅片更少的方案才能规模化。

另一个主要瓶颈是内存。每一代 Jetson 搭载的 DRAM 都比上一代更多：Jetson Xavier 是 32GB，AGX Orin 是 64GB，而 Jetson Thor 现在用上了 128GB 的 LPDDR5X，未来几代还会继续攀升。尽管 DRAM 总晶圆产能仍在增长，但大部分新增产能都被 AI 加速器的 HBM 吸收了。这就使得机器人大脑所依赖的普通 DRAM 和 LPDDR 供应，只能在一个不断萎缩的非 HBM 晶圆池中竞争。同样地，当 DRAM 成为稀缺资源时，每台机器人消耗 DRAM 更少的方案才能规模化。

内存也呈现出类似的局面：板载芯片与共享数据中心 GPU 的交叉点大约在每颗 GPU 服务 5 台机器人处。超过这个数之后，通过共享 GPU 提供认知能力，在每台机器人上消耗的 DRAM 反而比在每台机器里装一颗芯片更少。

TCO 结论：B300 vs. RTX 6000 PRO vs. Jetson Thor

晶圆和 DRAM 告诉我们哪种方案可以扩展，但它们无法说明哪种方案的运行成本更低。因此，下一个问题就是成本。如果你要为同一批机器人车队提供服务，分别采用数据中心中的 B300 服务器、数据中心中的 RTX 6000 Pro 服务器，或者在每台机器人上配备 Jetson Thor，各需要付出什么代价？

我们使用 NVIDIA 的 RoboTTT。由于它没有公开的代码或权重，我们构建了一个在耗时上具有代表性的复现版本来进行基准测试：使用真实的 GR00T N1.7 检查点，并在动作头（action head）中插入测试时训练（TTT）模块，使其计算和内存特征与论文一致，而不是追求精度上的对齐。

为了忠实还原，有三个细节需要说明。GR00T 的 DiT 按索引交错使用 cross-attention 和 self-attention 模块，如果简单采用固定步长，所有 TTT 模块都会落在同一种模块类型上；因此我们以（偶数、奇数）成对的方式插入 16 个模块，在 32 个模块中，8 个紧跟在 cross-attention 之后，8 个紧跟在 self-attention 之后。我们前置了 16 个可学习的 register token，构成论文中的 57 token 序列（16 个 register + 1 个状态 + 40 个动作），所有 attention 和 TTT 模块都在该序列上运行。每个模块在每轮去噪中执行一步内部梯度更新，每台机器人携带 151 MB 的 fast-weight 状态，在每次批量调用前汇总（gather）、调用后写回（scatter），这是共享权重的 VLA 无需承担的多机器人服务成本。

因此，这条 TTT 路径付出了完整的 FLOPs、内存流量和状态交换开销，却完全不改变输出的动作。未训练的 fast weight 会发散并产生垃圾输出，而我们衡量的是服务成本而非任务成功率。这些数字说明的是 RoboTTT 形态的推理在服务层面有多昂贵。

在此基础上，一块 B300 在 500 ms 的 chunk 截止时间内可以支撑 12 台机器人，而一块 RTX PRO 6000 可以支撑 4 台。

据此，我们构建了三种场景。对于卸载（offload）场景，我们假设一台 Blackwell 级的 B300 服务器，每块 GPU 可以服务多达 12 台机器人；以及一台 RTX 6000 Pro Server Edition，每块 GPU 可以服务多达 4 台机器人。对于端侧（on-device）场景，每台机器人自带一块 Jetson Thor。

在所有三种场景中，各场景间通用的部分（即机械部件、机器人外壳）不计入 BOM 成本计算。

B300 卸载场景

第一种卸载场景是一台 B300 服务器，加上 96 块无线板卡用于将机器人以无线方式连接到 GPU 服务器（每台机器人一块，按基准测试的 p99 标准，每块 GPU 服务 12 台机器人）。这使得总资本支出约为 55.4 万美元；再算上托管（colocation）和电力等运营成本，卸载场景的综合总持有成本（TCO）为每小时 18.63 美元。这里采用的是自持自营的经济模型，而非云服务租赁报价。

RTX 6000 Pro 卸载场景

第二种卸载方案使用 RTX 6000 Pro Server Edition。为了进行公平的同类对比，96 台机器人需要三台 8-GPU 服务器，因为在基准测试的 p99 标准下，每块 RTX 6000 Pro 可服务四台机器人。总体而言，这些服务器的全包含资本支出为 43.6 万美元，折算成全包含的总 TCO 为每小时 15.61 美元。

机载 Jetson Thor 方案

机器人本地方案采用 96 块 Jetson Thor 模块，单价 3500 美元，每块模块还需配套底板、存储、散热、额外电池以及板载无线连接，总成本约 39.4 万美元。将上述成本与 Thor 模块的电费一并计入后，这 96 芯片部署的 TCO 为每小时 14.97 美元。

我们假设机载 Jetson Thor 的使用寿命为四年，短于数据中心 GPU，原因在于其工作环境。机架中的 GPU 从不移动，而机器人上的 Jetson 则安装在一个持续振动的底盘上，偶尔还会遭受剧烈撞击。视具体工作而定，它可能被摔落、被泼溅，或整天在非结构化环境中作业。这种机械应力会加速硬件损耗。我们访谈的一些运营方认为其寿命不到四年，但我们认为四年是一个合理的假设。

可以说，机载部署的资本成本（WACC）也可能更高，尤其是对股权融资的新兴机器人公司而言；相比之下，neocloud 大多依靠债务融资，而自建服务器的企业资本也更为雄厚。不过，由于我们在基准情形中已经考虑了机载计算更短的经济使用寿命，为保守起见，我们决定在全部三种方案中采用相同的 WACC。

TCO 对比

在考虑利用率之前，三种方案的每 FP4 dense FLOPs TCO 各不相同：B300 为每小时每 PFLOP 0.15 美元，Jetson Thor 为每小时每 PFLOP 0.16 美元，RTX 6000 Pro 为每小时每 PFLOP 0.39 美元。

由此可以立刻得出的结论是：无论按单位 TCO 的 FLOPs 还是按单位资本支出的 FLOPs 来衡量，RTX 6000 Pro 的性价比都不突出。因此，我们接下来重点分析 B300 卸载方案和 Jetson Thor 机载方案。

利用率是 TCO 中的关键变量。机器人及其背后的 GPU 几乎完全是固定资本，无论资产是运行还是闲置，账单都一样，因此每有效工作小时的成本与其工作量成反比。

如今，机器人本体芯片的利用率高度依赖具体部署场景。在家庭场景中，一家已大规模部署机器人的公司告诉我们，其机器人每天仅运行 1-2 小时，只占时钟时间的 4-8%，因为家务任务是突发性的，而且当前模型的能力仍限制了无人监督下可运行的任务。随着能力提升和新功能推动用户使用，这一数字正呈上升趋势，朝每天 4-5 小时（17-21%）迈进。但家庭场景存在一个硬性上限：家务活终究是有限的。工业需求则是持续性的，理应达到更高的水平。Figure 在 BMW 的部署是我们掌握的一个锚点：在约 11 个月的工作日班次中累计运行约 1,250 小时，每天工作约 10 小时，利用率为 40%。随着模型能力的提升，工业场景的利用率应该会大幅超越这一水平。

共享 GPU 服务器的运行方式则往往相反，因为其计算资源在整个机队之间共享，全天候处于忙碌状态。鉴于上述场景中一块 B300 GPU 可以在 p99 延迟预算内服务 12 台机器人，我们将其建模为 GPU 服务器约 90% 的利用率。

对于机器人本体芯片利用率，我们将约 40% 作为基准情形，并已计入下表中。扣除利用率因素后，B300 的卸载方案每 FP4 dense FLOPs 的 TCO 为 $0.17/hr/PFLOP，而 Jetson Thor 的本体运行方案每 FP4 dense FLOPs 的 TCO 为 $0.37/hr/PFLOP。在此情形下，卸载方案的 TCO 仅为本体运行方案的约 46%。

在下方敏感性分析的右上角区域，GPU 服务器利用率高、端侧芯片利用率低的组合，使每 PFLOP 的 TCO 大幅倾向卸载方案。对于当前的工业部署，卸载方案的每 PFLOP TCO 约为本体运行方案的 46%，而在家庭部署中甚至低至约 12%。

只有在靠近右下角的若干情形中，即 B300 云服务器利用率长期低迷而端侧利用率长期高企时，每 PFLOP 的 TCO 才会转向有利于端侧推理。

一个自然浮现的问题是：需要将多少台机器人组成批次，每 PFLOP TCO 的节省才能使天平倾向卸载方案？通过改变下方的批次假设，对于标准的工业部署，我们发现只要每块 B300 GPU 服务 5 台及以上机器人，每 PFLOP 的 TCO 就会转向有利于卸载方案。

总体而言，我们发现将推理卸载到云端的 B300 服务器是一个颇具说服力的方案，除非是极小规模的机器人部署——此时一台本地服务器大部分时间处于闲置状态。不过即便如此，也可以论证按需租用算力，而非专门购置一整台服务器来服务少数几台机器人。

部署之争的主战场

从纸面上看，非本体计算在 TCO（总拥有成本）上占优。但实际上，还没有哪家公司实现大规模量产，因此 TCO 目前并不是决定问题的关键。真正在出货的公司分成了两大阵营：一类把计算保留在机器人本体上，另一类把部分计算放在本体之外。决定它们归属哪一阵营的因素是：机器人需要多大的通用性、无线网络有多糟，以及客户允许它们改造多少现场。一旦车队规模扩大，TCO 就会变得重要。目前，下面是各家公司各自的立场及其原因。

Boston Dynamics

Boston Dynamics 打造了三款机器人：Spot 沿着巡检路线行走，Stretch 负责卸载拖车和集装箱，而人形机器人 Atlas 今年已投入生产。这里的“生产”是指批量制造用于大规模数据采集和应用试点的开发单元，而非大规模量产。对 Boston Dynamics 来说，最重要的是能力，也就是机器人能否为客户解决实际问题，并产生经济价值和节约成本。

通用型 vs 专用型

这些难题大多要求通用性。汽车工厂里充满难以自动化的任务：从排序、配套（kitting）、把零件运送到产线旁，到像给车轮上螺栓这样的装配工作。一辆整车有上万个零件，一条产线可能同时生产 5 到 10 种车型、十几种甚至更多颜色，而且这种组合每年都会更新换代。在这种规模下，为每一个步骤部署定制化的专用方案，既不快速也不经济。正是这种多变性限制了传统自动化，也是工厂作业需要通用型机器人、而不是成千上万台专用机器的原因。

Boston Dynamics 瞄准的这类通用工作——把机器人直接投放进汽车工厂或仓库——需要前沿模型，原因很简单：通用性就是智能。多模态进一步加剧了这个问题：由于这些机器在物理世界中运行，System 2 必须处理图像并基于图像进行推理，而擅长此事的模型天然就是庞大的。Boston Dynamics 没有给出确切的参数量，而是指向 Gemini Robotics ER——DeepMind 基于 Gemini 3.5 Flash 构建的具身推理模型——作为正确的参考。Google 从不公布参数量，但我们估计 System 2 的参数量可能在数千亿级别，甚至达到 1T。

大到无法随身携带的大脑

这种规模的模型无法装在机器人上，因此 Boston Dynamics 把整个技术栈拆分到网络两侧。System 1，即驱动机器的视觉运动策略（visuomotor policy），在本体上运行——在 Atlas 上这意味着一块 NVIDIA Jetson Thor。System 2，即推理层，在机器人之外运行，通过该公司的车队软件 Orbit 访问，目前借助与 DeepMind 的合作在 Google TPU 上提供服务。在我们采访的公司中，Boston Dynamics 是少数刻意把高层推理放在无线链路另一端的公司之一。

在一个完美的世界里，根本不需要这种拆分。理想情况下，System 2 应该直接运行在机器人本体上，中间不经过任何无线链路。但目前还没有足够小、能装载到机器人上的模型可以在工厂工作中实现足够好的推理能力，而公司宁愿现在就交付一个可用的智能方案，也不愿等待。未来，随着更强大的嵌入式芯片的出现，或者小模型学会更好地推理，这一差距可能会缩小。就目前而言，离端运行才是可行的方案。

Boston Dynamics 如何定义 System 1 和 System 2 至关重要，因此有必要说清楚。System 2 是规划器。它从制造执行系统（MES）接收工单，比如“执行作业 345 并将结果放入库存料箱 5”，然后将其拆解为足够简单、可以直接执行的步骤。System 1 则是 VLA，也就是实际驱动机器人运动的模型：它接收摄像头画面加上一条简短指令，比如“捡起罐子，放进带绿点的料箱”，然后将其转化为电机动作。它在本体上运行，因为运动控制有严格的延迟和确定性要求。注意这两层之间发生了什么。

工厂里的“库存料箱 5”对 VLA 来说毫无意义，因此 System 2 在机器人视野中的正确料箱上标记了一个绿点。这种从混乱的现实世界到 System 1 能理解的语言的转换，是 System 2 职责的核心部分，而绿点只是其用来引导 System 1 行动的一整套相当深入的技巧库中的一种。System 2 还负责监督：它在工作执行过程中持续观察，捕捉 System 1 的异常行为，并跟踪任务进度。正是因为这种监督，System 2 的调用频率远超人们的预期：基本假设是每几秒到每十秒查询一次，某些情况下甚至会达到每秒一到两次。

System 2 无法放在机器人上的另一个原因是，它所需的硬件是数据中心级硬件。这种规模的模型需要机架式、液冷的 Blackwell 级 GPU，每颗芯片功耗达 1.2 到 1.4 kW。而人形机器人携带的电池大约只有 2 kWh，正常运动时的功耗为几百瓦，把所有设备都算上也只有峰值一两千瓦。这也解释了为什么机器人本体上的 GPU 通常只是一块 40 到 130 W 的 Jetson Thor。如果强行把数据中心 GPU 装到机器人上，光这一颗芯片的功耗就会超过整台机器人，还会带来机器人根本无法承载的散热需求，几分钟内就能把电池耗尽。

尾部延迟问题

将 System 2 卸载到远端后可以使用前沿模型，但代价在网络层面，主要是可靠性和抖动。平均延迟并不是大问题，真正的问题在于尾部：偶尔出现的一秒级延迟尖峰会让机器人在任务中途卡住。一旦推理位于无线链路的另一端，网络就成了机器人领域最突出的问题，Boston Dynamics 为此专门成立了多个团队，负责机器人上的射频协议栈、客户的基础设施、频谱以及协议设计。我们将在下一节详细讨论网络部分。

数据属于谁

通过无线链路将 System 2 卸载到云端的另一个考量是数据安全。每台机器人实际上都在导出某个客户工厂车间的视频流，而客户理所当然会附加条件：不得用他们的数据训练模型，不得与其他客户的数据混用，按需删除。合规要求也是碎片化的，每个司法管辖区在数据保护法上都有各自的特殊规定。还有一些客户，比如核电站或军事运营商，无论给出何种保证，都不会允许数据离开现场。

Boston Dynamics 的应对方案是分层的，沿数据管道逐级向上。第一层在机器人本体上，客户可以精细控制哪些数据可以被共享。离开机器人的数据会进入 Orbit——机器人上报的云平台。该平台通过了 SOC 2 Type 2 认证，并由一个内部数据委员会负责监管数据处理。最后一跳是 Google：System 2 通过与 DeepMind 的合作运行在 Google 的基础设施上，因此机器人发送上去用于推理的每一张图像也会经过 Google 一侧。这部分由 Gemini Enterprise Agent Platform 提供服务，它是 Google Cloud 的企业级智能体基础设施，已被数据标准极为严苛的客户所接受。这家公司的判断是，只要你能有力证明数据得到了妥善处理，客户就会接受数据离站——这与那些敏感企业愿意在无训练保证的条款下向 Anthropic 发送查询是同样的逻辑。

Agility Robotics

Agility Robotics 面向仓库和工厂车间场景进行构建。其双足人形机器人 Digit 可以搬运料箱、看管机器并进行码垛。它的客户包括 GXO、Schaeffler、Amazon、Toyota Motor Manufacturing Canada 和 Mercado Libre。Agility 并不从零训练基础模型，而是选用一个性能优秀的第三方基础模型，再在其上进行后训练。由于语言和动作条件化来自 Agility 自己的语料库，就没有理由从零训练一个视觉模型。所有这些都可以在机器人本体的 NVIDIA Jetson 级加速器上运行。

即使推理在本体上完成，Agility 仍会将部分功能卸载到云端。车队编排、工作流分配、场地建图和空中更新（OTA）都在 Agility Arc 中运行，遥操作和训练数据上传也走同一链路。这种切分之所以可行，是因为编排层可以容忍延迟抖动，而控制层不能。机器人可以十秒钟收不到下一个工作流分片，因为它面前已排有三十到六十秒的排队任务，所以把这一层放在云端是合理的。

在其他所有方面，Agility 都坚定地站在“GPU 装在机器人上”这一阵营。网络可靠性和延迟是实实在在的顾虑，而工厂对无线连接来说更是尤为恶劣的环境：移动的金属、重型机械、多径干扰，还有一台每次经过货架都会丢失视距的机器人——它穿过车间时还要在不同接入点之间漫游。这些问题当然都可以通过工程手段解决，从而获得一个足够可靠、可以卸载计算的网络。但那意味着要改造客户的网络和边缘基础设施，而 Agility 希望 Digit 能以尽可能少的改动直接融入现有场地。

网络并不是让计算留在机器人上的唯一因素，安全同样推动着这个方向。在安全领域，Agility 打造了一套工业级的方案，这是许多其他人形机器人竞争对手所欠缺的。目前，Digit 只在设有物理围栏的工作单元内运行，因为尚无任何动态平衡机器人获得过近距离与人类协作的安全认证。双足平衡机器人需要主动控制才能保持直立，一旦断电就可能倾倒，因此在受 OSHA 监管的环境中，必须对 Digit 与人类工人进行物理隔离。Digit 的传感器套件通过摄像头和 LiDAR 提供 360 度感知，使其能够检测人员并实时停止或调整行进路径。下一代产品更进一步，加入了专门的人类检测系统，旨在识别靠近的人、停下，并在可能发生接触之前降落到地面，从而扫清 Digit 最终走出围栏工作的障碍。Digit 还具备其他工业安全特性，例如在减速过程中保持执行器供电的停止功能，使机器在断电前平稳、安全地停下。

所有这些防护措施都建立在计算完全在机的前提下。如果把安全决策移出机器人，会带来一个更根本的问题：网络链路本身就成了一种故障模式。如果机器人与机外安全模型失去连接，它无法判断是否出了问题，因此唯一的选择就是盲目地执行最坏情况的失效保护。这就是为什么复杂的安全决策必须始终留在机器人上。

Verne Robotics

Verne Robotics 主要在仓库和轻工业制造环境中部署其机器人。它的机器人 Nemo 是一款双臂移动操作机器人，由安装在轮式底座上的双臂上身组成，可选臂展 700 mm 或 1,000 mm 的机械臂。Nemo 已部署在马萨诸塞州和加利福尼亚州的物流公司，包括生命科学试剂公司 AbClonal——在那里，它负责自动化冷链工作流，如取放、包装和搬运化学试剂与冰袋。Verne 还在向轻工业制造领域扩展部署，那里的利用率可能会更高。

值得注意的是，Verne 并不完全依赖遥操作，而是使用员工和承包商穿戴的专有带摄像头数据采集服，直接在客户现场采集具身数据。公司自主开发端到端策略模型，参数量可能在几十亿级别，完全运行在 Jetson 级或 RTX 50 系列 GPU 上。由于仓库操作和轻型制造任务（如拣选、打包和组装）不需要广泛的开放世界推理能力，Verne 无需依赖大型云端托管的基础模型即可实现很高的任务成功率。整套从感知到执行的流程都在机器人本地运行，执行过程中完全不需要离板推理或数据中心连接。

Sunday Robotics

Sunday Robotics 面向家庭场景打造机器人。Memo 是一台轮式机器人，躯干可以升降，能够触达从地板到高处的橱柜，配备三指夹爪而非人形双手。Sunday 也训练自己的基础模型。他们不采用遥操作，而是通过 Skill Capture Glove（技能采集手套）收集训练数据——这是一种与 Memo 夹爪几何形状相匹配的可穿戴设备，由在家中做日常家务的人佩戴。这些手套数据与视频等其他通用数据相结合，预训练出一个端到端策略，再通过后训练（post-training）加以打磨。

在过去 12 个月里，Sunday 发布了两个模型，每一个都让 Sunday 更接近打造出能在任何家庭完成任何任务的系统。2025 年 11 月发布的 ACT-1 侧重于能力的广度。它使 Memo 能够完成一项长达 15 分钟的长时程任务——清理餐桌并将所有餐具放入洗碗机，同时还展示了叠袜子和制作意式浓缩咖啡等高灵巧度技能，并能泛化到从未见过的家庭环境。

今年 7 月预览的 ACT-2 则将这种广度转化为可靠性：在机器人从未见过的家庭中，跨九种衣物的零样本（zero-shot）叠衣成功率达到 99.1%。Sunday 最关注的发现是：扩大预训练规模正是让后训练实现泛化的关键，效果之显著，以至于一次演示就能教会一个可迁移的新行为。图表清楚地展示了这一点。域内（in-domain）指 Sunday 自己的实验室，即后训练数据的来源；域外（out-of-domain）指保留的未见过的家庭和物体。没有预训练时，模型在实验室达到 96%，但在未见过的家庭中仅有 14%，是教科书式的过拟合。而使用完整的预训练语料后，这一差距消失了：两边都达到 100%。

通用性来自预训练规模，而预训练规模需要一个足够大的模型来吸收它。能在陌生人洗衣房里正常工作的策略不会是小模型。因此 Sunday 一开始就假定使用云端推理。在实验室里，这很合理：算力更充足、调试更方便，而且与研究人员已有的工作环境一致。然而在真实家庭中测试 ACT-2 两天后，他们改变了方向。家庭 WiFi 原来是一团糟：到处是信号死角、邻居干扰、配置不当的 Mesh 路由器，还有上下行不对称的链路。延迟问题不大，抖动才是问题所在。一个要在数小时内维持 99% 成功率的机器人，无法像视频通话那样对偶尔的卡顿无动于衷。替代方案也不管用。Starlink 的卫星几分钟就划过天空，只要天线 100 度视场内有任何树木或屋顶，每次过境都会断链；而 5G 路由器也会以同样的方式掉线。

Sunday 面临一个根本性的权衡：模型越大，泛化能力越强，但依赖云端会让机器人受制于网络连接。Sunday 选择彻底把推理搬到设备端来解决这个矛盾。模型现在直接运行在机器人内部的 GPU 上，将云端从关键路径中移除，让 Memo 可以不依赖网络独立运行。

Weave Robotics

Weave Robotics 同样面向家庭场景。它的第一台已部署机器人 Isaac 0 坐在桌边，为你送来的衣物进行折叠。今秋推出的 Isaac 1 保留了这些功能，并增加了轮式底座和可伸缩躯干，可以自己去找脏衣服、把叠好的衣物归位、整理床铺，还能把玩具和鞋子放回原处。Weave 自研 VLA 模型，同时也使用 Physical Intelligence 的模型。自研是为了尽可能贴近技术前沿，但只要能带来更好的客户体验，他们不介意用任何模型——所以这既不是一个套壳 Pi 的产品，也不是一个封闭体系。两个模型大概率都在几十亿参数级别，小到足以装进机器人，我们预计推理是在本地运行的。

即使推理在机器人本地运行，Weave 也离不开网络。WiFi 链路负责回传本体感知数据，视觉数据则作为训练数据上传；当机器人遇到困难时，还会有远程操作员介入接管。两者都会随链路质量下降而受影响，连接差到一定程度时，双向流量都会中断。在家庭环境中，墙壁和其他障碍物会造成信号弱区和死角，而普通路由器本来就不是为无缝切换设计的。网络条件通常不错，但拥塞是一个因素：家庭通常使用共享光纤，邻居家和公寓会拖累链路，而且恰好在家庭机器人最可能工作的时间段。

面对这些环境条件，Weave 不要求对家庭环境做任何改动：不需要新路由器，也不需要额外的接入点。这将全部适应工作都推给了机器人。

翻越网络之墙

如今许多部署方案仍将推理保留在机器人本体上，几乎所有公司给出的理由都一样：网络问题。那些确实采用离端（off-device）部署的公司，是通过组建多个专职团队、专门解决这一问题才实现的。我们认为这些网络问题是可解的，而且随着它们被逐一解决，会有更多部署从机器人本体迁移到云端。

什么是网络墙（Network Wall）？

在机器人本体之外运行模型极其困难（见下图）。有三个层面的问题使得离端策略充满挑战。

本体问题（Embodiment）。在物理层，你要求一台金属材质、不断移动的机器具备良好的网络条件，而它的电机和电子器件恰好在你要传输的频段上产生噪声。机身会阻挡并反射自身信号，姿态变化会改变天线位置，每次传输之间的射频条件都是动态变化的。

网络问题。WiFi 和 5G 的底层基础设施在设计时并未考虑机器人场景。它们在家庭中表现出色——一两台设备，你坐在沙发上看着 Netflix。但机器人恰恰相反：你依然有一路 Netflix 规模的视频流，却是往数据中心上传，而且一边移动一边上传。这就是上行链路（uplink）问题：现有基础设施全部是围绕下行链路（downlink）设计的。

对 Netflix 来说，偶尔丢包或延迟飙升无关紧要，但对机器人来说这就是随时可能发生的事故。现有的接入点、芯片组和算法根本没有为此而设计：优先级是颠倒的，上行 MIMO 很少被支持，没有让 UDP 流变得可靠的冗余机制，接入点之间没有低延迟切换，上行调度只是事后补上的一环，而一切本该是确定性保障的地方却只做统计性保证。再加上共享光纤——你的邻居在你的人形机器人工作时打开 Netflix，真的可能造成致命后果。

环境问题。这是核心挑战，它决定了离端方案能用在哪儿、不能用在哪儿。自动驾驶是必须在端侧运行的典型例子：覆盖区域巨大，运营商几乎无法控制射频条件，车辆高速移动，导致延迟预算近乎为零，并且被迫频繁切换接入点。再加上驾驶本身就是比人形机器人劳动更简单的学习问题，模型可以直接装进车里，结论便顺理成章：计算放在车端，离端部分收缩为车队管理——一个缓慢的、低频的控制回路。

端外计算的环境前提，是一个结构化程度足以实现射频控制的小型到中型空间。自动驾驶不具备这一点；而家庭和工厂具备。但这并不意味着问题简单——环境问题依然非常棘手。墙壁、金属和其他电子设备都会影响射频条件。在家里打开洗碗机，射频环境就会改变。在工厂启动重型机械，旁边可能出现信号盲区。接入点的摆放位置至关重要，而且必须预判环境随时间的变化。在接入点之间移动意味着切换，典型的路由器在一次切换期间会中断 100 毫秒到几秒钟不等。这可能发生在操作过程中，导致策略失效或远程操作卡顿。恢复可能还需要几秒钟，而到那时人形机器人可能已经倒在地上了。

家庭中信号遮挡物和反射物的摆放不可预测；每栋房子都是一个不同的射频难题。工厂更有结构，但与你作对的因素也多得多：密集的金属货架会反射和遮挡信号；电机和机器在整个频谱上喷洒干扰；库存和设备每天都在移动，盲区和弱信号区也随之移动；还有几十台机器人在争抢同一份上行链路空口时间。

我们该如何翻越这堵墙？

为端外推理准备模型是一个微妙的问题。这取决于模型是分层式还是单体式、需要多少计算量、要执行哪些任务、动作空间是什么，以及它驱动的是什么样的具身形态。目前失效的环节中，有一部分可以通过常规工程手段修复。以传输层为例，它通常是改造过的 WebRTC：基于 UDP、不做重传、通过多天线上的重复发送来保证可靠性、在应用层感知数据包的重要性，并把新鲜度放在首位。团队已经在构建这类方案，相关知识已经商品化。

但网络之墙并不是传输层，也不是一系列常规的工程挑战。网络之墙的根源在于现有硬件的问题。我们认为有四个既困难又高杠杆的问题，解决它们合在一起，可以让端外模型在现有基础设施之上实现可靠运行。

首先修复环境，而不是机器人。杠杆率最高的修复点是接入点。机器人场景中的接入点，需要做的恰恰与消费级和企业级接入点为下行密集型静止客户端所做的相反。这包括：

部署位置与硬件同样重要。它需要被测量和优化，而不是靠猜：沿着机器人的任务路径做射频勘测，绘制信号盲区地图，并根据机器人的典型高度和朝向来选择天线方向。

WiFi 将主导家庭和大部分工厂车间，因为它速度快、承载能力强。但它无法覆盖一切。5G，无论是私有还是公有的，可以填补室外路径、更大的场地以及无法控制 WiFi 拥堵的位置。两者应该共存于同一个调度器之下，机器人能够在两者之间快速切换。在依赖运营商的场地上，最后一步是与网络提供商合作，实现上行优先级保障以及通往 GPU 集群的专用光纤，这样被规划的传输路径就不会终止于接入点。

缩减负载。网络带宽是有限的。翻越这堵墙的另一半，是减少必须穿过它的数据量。图像传感器占机器人上行流量的绝大部分，所以在成为网络问题之前，这是一个感知问题。

最大化上行链路。机器人技术颠倒了每种无线芯片组最初设计的流量模式，主板必须为此而打造。采用 4x4 上行 MIMO，而不是消费级模块所配备的一到两个数据流；选择以上行吞吐量而非下行为优先的芯片组；使用专为无线通信构建的操作系统；以及一个参与接入点调度而非与之竞争的射频模块：它知道自己的时隙，按节奏填充时隙，并在时隙之外保持静默。保持这种节奏才能让调度具有确定性，而这只有主板与接入点协同设计才能实现。任何一方都无法单独对链路强加秩序。

一切运行在同一时钟上。随着批量效率的提升，数据中心 GPU 在成本上胜过了设备端计算，而批处理要求来自多台机器人的观测数据时间对齐地到达，才能满足合理的延迟预算。所有环节必须运行在同一时钟上。借助主板上的高质量晶振以及整个机群的无线时间同步，可以实现亚毫秒级的同步，使站点上的每台机器人都在同一节拍上采集、编码和传输。GPU 编排则围绕这一节拍构建：调度器知道下一帧观测数据何时到达，提前为其预留算力，并在该帧完整时就立即运行。迟到的观测数据进入下一个批次，而不是排队，这样延迟预算就花在推理上而不是等待上。将这些组合起来——一个保持调度的主板、执行调度的接入点、以及减轻负载的感知栈——你就能得到一个在大规模下进行批处理而不增加延迟的系统，而这正是在设备外运行模型的全部经济理由。