由 Sarah Xiao 
具身智能的重心正在从”算法基准”转向”物理落地”。问题不再是模型能不能在视频里完成任务，而是这套系统能不能稳定跑一个班次——于是话题从模型转到了基础设施。
理解这套基础设施最好用的框架是一个 3×3 的格子：纵轴是计算、通信、控制，横轴是云、边、端。九个格子，每一格都是一类真实的工程问题。当 VLA 大模型要以百毫秒级周期驱动真实电机时，决定任务成败的是最弱的那一格，不是平均值。
这张表让什么变得可见
计算是显性的一格：模型能不能在移动机器人扛得动的功耗和散热预算内，跑出要求的帧率。
通信是最被低估的一格。云端推理 300 毫秒回包，对聊天机器人没问题，对一只必须接住滑落物体的手毫无意义。每一趟往返都得落在控制截止时间内，否则环就得留在本地。
控制是机器人行业本来就熟的：毫秒级实时闭合、确定性，以及失效时的安全。
把这三列和云边端交叉，故障就变得具体了。模型在端上、权重在云上、遥测走 Wi-Fi——坏掉的是”通信×端”这一格，而且它是在客户车间里坏，不是在实验室里坏。
分层解耦的开源栈
目前开源生态给出的答案不是一个更强的单点工具，而是一套分层、每层可替换的栈：
- 跨芯片统一适配——统一算子接口与异构调度，让同一个模型不必按每颗 SoC 重写一遍；
- 编译工具链——基于 MLIR 的图降级与代码生成；
- 量化与推理——W4A4 多格式，低延迟流式输出；
- 运动控制——毫秒级实时闭环；
- 片上安全与评测部署工具链。
设计约束是兼容——与现有算子库、编译栈和 ROS 2 兼容。一个靠”再建一个生态”来解决问题的栈，等于没解决问题。
量化的目标函数在这里不一样
对大语言模型，压缩的度量是词元精度。对具身模型，输出是连续动作序列，微小的数值偏差会随时序累积，直到任务失败。目标函数必须重写。
由此得到的框架是行为保持：动作保真度优先于词元准确率，时序稳定性与语义对齐同等权重，验收标准是闭环控制下的任务成功率。一个词元掉了 0.5%、抓取成功率掉了 3% 的模型，不是”0.5% 的问题”。
这也是为什么不该相信用困惑度（perplexity）报出来的压缩指标。要问的是：在你的任务上、在出货的那台设备上、量化之后，成功率是多少。
三层，各自该放什么
单机部署只是最小可行形态。任务一旦从单臂扩展到多机协同，架构就得重排：
端侧承载实时推理与控制闭环；边缘负责多模态感知流融合和确定性低时延传输；云端承担任务编排、弹性算力调度和数据回流。
价值不在算力叠加，而在数据的分级治理：高频低维的控制信号留在端侧，低频高维的学习信号上行。正是这个划分，让”感知—理解—预测—规划—行动”的循环在真实网络条件下保持闭合。
如果你是买方，六个问题
一场演示可以无限期地掩盖两百毫秒的网络依赖。六个问题能把架构照出来：
- 控制环周期，以及实测抖动。 不是标称频率，是在带载系统上跑一小时后的分布。
- 策略跑在端上，还是往返？ 如果是往返，链路劣化时环会怎样。
- 降级行为。 网络断掉后的 500 毫秒里机器人做什么——停、保持，还是走完当前动作，以及这在你的工位上是否安全。
- 量化后的任务成功率，在你的任务上。 在出货设备上测，不是在开发板上测。
- 升级与回滚。 模型是否 OTA 下发，坏版本能不能退回，车队规模下回滚要多久。
- 芯片与模组供应。 端侧推理芯片有自己的交期和配额。要问是哪颗 SoC、谁家的、二供是谁。
最后一个问题其实是采购问题而不是技术问题，但它该和机械部分放进同一份尽调。一台机器人的板载算力如果依赖某颗被配额限制的料，这个供应风险不会出现在任何基准测试里。
一个不激动的结论
这张表里每一格都是工程问题，没有一格能靠更强的模型解决。具身智能走向量产的约束不是智能，而是一个百毫秒级的环，要在一条成本受限的设备上，跨过一张没人能控制的网络，同样地闭合一万次。
这个结论没有刷新榜单那么好看。但决定一年后还有多少台机器人仍在运行的，是它。
数据来源：3×3 约束框架、分层开源栈、行为保持量化论证与云边端三级架构，依据 RadixRoot 生态开发者 2026 年 10 月 20 日公开文章。买方提问、降级行为关注点与芯片供应提醒为本刊编辑部内容。
相关阅读
- 机器人造机器人：从一天一台到一小时一台——这个行业的制造侧同样是系统问题。
- 灵巧手触觉传感三条路线对比——喂给控制环的那一层感知。
- 上半年卖了3.6万台人形机器人，真正进厂干活的只有3%——让这些基础设施问题变成商业问题的量。