6小时前 机器人为什么正在被算力、功耗和时延卡住 ——具身智能落地的隐藏瓶颈：端侧计算

作者：智域基石研究组     出品：智域基石

过去两年，机器人行业最吸引眼球的，是模型能力的跃迁。

系统更会理解语言了，更会识别场景了，也更像是拥有某种“高层智能”了。于是，一个很自然的判断开始出现：模型既然已经越来越强，那么剩下的问题是不是只是部署问题？

现实通常恰恰相反。

在机器人行业里，部署从来不是训练完成后的附属环节，很多时候，它本身就是最硬的门槛之一。因为机器人不是把一个模型跑通就结束了，而是要把模型装进一个有电池、有散热限制、有实时闭环要求、还要过安全和成本约束的身体里。

更准确地说：

具身智能的难点，不只是把模型训出来，而是让模型在端侧、在有限功耗和有限时延下，持续、稳定、可控地运行起来。

这就是“模型上身”真正难的地方。

一、为什么机器人里的“部署问题”，比互联网更难

互联网产品里的很多推理任务，本质上是一次性服务请求。

用户提一个问题，模型在云端算出一个结果，哪怕慢几秒，很多时候也可以接受。系统更关心的是吞吐、成本和响应体验。

机器人完全不是这样。

机器人面对的是一个持续运行的闭环系统。它需要同时完成：

感知环境

理解任务

规划动作

发送控制

接收反馈

修正下一步

这个循环不是一分钟跑一次，而是持续不断地跑。
而且，不同环节对时延的要求完全不同：

高层语言和任务理解可以低频一些

局部规划和视觉跟踪需要更快

力控、阻抗控制和伺服闭环则往往必须足够高频

这意味着，机器人并不只是“能把模型跑起来”就够了，而是必须回答两个更难的问题：

1. 算得动吗？

模型、感知、规划和安全监控能否同时运行。

2. 算得稳吗？

长时间运行后，是否还保持稳定时延、稳定帧率和稳定温度。

这也是为什么，很多在实验室里能跑通的系统，一旦走到真实现场，性能就会迅速恶化。
因为实验室验证的往往是“可运行”，而交付现场要求的是“可持续运行”。

二、机器人缺的不是峰值算力，而是稳态算力

行业里讨论边缘芯片时，最容易被误导的一个指标，就是峰值算力。

例如，某个平台标称多少 TOPS、多少 TFLOPS，听起来非常直观，也很容易拿来做横向比较。但放到机器人系统里，这个数字往往只是一个粗略起点，而不是答案本身。

机器人真正关心的，通常不是“峰值能跑多快”，而是：

多任务并发时是否会抖动

长时间运行后是否会降频

显存和内存是否足够

数据搬运是否成为瓶颈

尾时延是否可控

算法部署后是否还能保持精度和稳定性

换句话说：

机器人需要的不是 benchmark 上的峰值算力，而是现实系统中的稳态算力。

这两者差别很大。

一个模型离线单独跑，可能表现很好；
一旦和多路相机、点云处理、定位、规划、安全监测、日志回传一起运行，系统资源占用会立刻变得完全不同。

这也是为什么，很多团队在芯片选型时最容易踩的坑，就是只看算力数字，不看真实系统负载。

三、机器人不是跑一个模型，而是同时跑一堆模型

互联网里讨论大模型部署，很多时候默认的是“一个主模型”的问题。
机器人不是。

一个真实运行的机器人，往往要同时处理一整组任务栈：

相机解码与预处理

目标检测、分割与跟踪

深度或点云感知

SLAM / 定位建图

局部避障与路径规划

抓取或操作策略

高层 VLM / VLA 推理

语音理解与交互

安全监测

日志记录与数据上传

如果是移动双臂或人形机器人，还可能再叠加：

底盘状态估计

平衡与步态

双臂协同

全身动作规划

多模态人机交互

这意味着，机器人端侧计算的核心，不是“某个模型跑得动吗”，而是：

整套系统在并发状态下，是否还能保持可控。

而一旦进入并发状态，问题就不再只是模型精度，而会迅速变成系统工程问题：

CPU、GPU、NPU 如何分工

哪些任务占用内存带宽

哪些任务会抢实时资源

推理和控制是否相互干扰

相机数据流是否会堵塞

操作系统调度是否影响控制线程

这也是为什么，机器人里的端侧算力问题，本质上不是单纯的 AI 问题，而是 AI + 嵌入式 + 实时系统 + 工业控制 的交叉问题。

四、为什么 TOPS 不是答案：真正卡住的是四重约束

如果把“模型上身”的难点概括一下，最关键的通常不是单一变量，而是四重约束同时存在。

1. 算力约束：模型越强，部署越重

这一点最直观。

模型越大，多模态输入越多，推理链路越复杂，对计算、显存、缓存和带宽的要求就越高。
而机器人系统又很难只跑一个模型，因此算力需求往往是叠加的。

问题在于，机器人要的不是“偶尔跑一下”，而是长时间持续运行。
这会让很多在离线环境下还能接受的模型，在端侧部署时变得不再现实。

2. 功耗约束：每一瓦都在吃掉续航

固定机械臂尚且可以依赖稳定供电，移动机器人和人形机器人则必须直接面对电池约束。

对这类系统来说，端侧算力并不是一个独立变量，而是和续航直接绑定的。

算力更强，功耗通常更高；
功耗更高，续航通常更短；
续航更短，就意味着运行时间下降、充电频率上升、运营效率下降。

这会直接影响机器人作为生产系统的价值。

所以，端侧算力的真实问题从来不是“有没有更大的芯片”，而是：

这份算力，值不值得消耗掉这么多电。

3. 散热约束：能跑不代表能一直跑

这是机器人部署里经常被低估的一层。

很多系统在冷启动和短时间测试里看起来没有问题，一旦连续运行一个小时、几个小时甚至更久，温度上升就会引发：

降频

帧率波动

推理时延变长

控制响应抖动

稳定性下降

而机器人又通常不能像服务器一样，用大体积风冷或机房级散热来解决问题。
它受制于：

机身空间重量

噪声防尘防水要求

外壳设计电源预算

所以在机器人行业里，热设计不是“后期优化项”，而是芯片选型和系统架构设计的一部分。

4. 时延约束：机器人要的不是吞吐，而是确定性

大模型行业常讨论每秒生成多少 token、每秒处理多少请求。
机器人更关心的是另一件事：最坏情况下到底会不会慢。

这就是时延问题。

在机器人系统里，最危险的往往不是平均性能，而是抖动性能。
因为一旦出现尾时延飙升，就可能影响：

目标跟踪

动作修正

避碰判断

视觉伺服

接触控制

急停响应

这意味着，机器人端侧计算最重要的指标之一，不是平均吞吐，而是：

系统在高负载和长时间运行下，是否还能维持稳定、可预测的时延。

五、端侧算力为什么在人形和移动操作上更难

端侧计算问题，在不同机器人形态上，严重程度差异很大。

1. 固定机械臂：相对最容易

固定机械臂通常有几个天然优势：

稳定供电

可接外部工控机

散热条件更好

环境更结构化

通信链路更稳定

所以它的计算瓶颈虽然存在，但通常不会成为第一约束。
在这类场景里，更大的问题往往还是节拍、良率、工艺稳定性和系统集成。

2. 移动操作：开始进入高压区

移动双臂机器人就不同了。

它一边要做移动定位和避障，一边要做操作感知和抓取，还要处理多传感器融合和高层决策。这让它的计算需求明显高于固定机械臂。

但与此同时，它又必须背着电池、带着机载算力、控制整机热设计。
这就形成一种典型矛盾：

任务复杂度已经接近“自动驾驶 + 机械臂操作”

但可用电力和可用空间远没有这么充裕

这也是为什么，移动操作常常是端侧算力最容易出问题的赛道之一。

3. 人形机器人：把矛盾推到极致

人形机器人几乎把所有约束叠满了：

多路视觉

全身状态估计

步态与平衡

双臂操作

多模态交互

安全约束

电池和热管理

体积和重量限制

这意味着，人形机器人对端侧算力的要求，不只是“更高”，而是“更综合”：

算力要够

功耗要低

时延要稳

体积要小

散热要控

软件栈还要可维护

所以，从产业成熟度看，人形机器人真正大规模落地之前，端侧计算平台大概率会先经历一轮明显升级。

六、云端不能替代端侧，端云协同才是现实路线

只要谈到端侧算力瓶颈，很容易有人提出一个简单方案：
既然本地难算，能不能把更多东西放到云上？

这个思路当然有价值，但边界也非常明确。

云端适合承担的通常是：

模型训练

数据管理

日志回放

大规模评估

低频策略优化

跨设备知识汇总

但真正依赖云端来做关键动作闭环，问题会立刻出现：

网络时延不可控

断网和弱网无法避免

上行带宽成本很高

安全关键动作不能依赖远端

数据隐私和合规会带来额外限制

所以，机器人行业更现实的路线，不是“云替代端”，而是：

必须在端上完成的闭环，坚决放在端上；可以异步优化和回流的部分，再交给云。

这就要求系统做更精细的分层：

端上负责感知、动作、安全和基本自治

云上负责训练、分析、回放和慢速优化

谁能把这条边界划得更合理，谁的系统就更容易稳定，也更容易算清成本。

七、芯片问题不只是技术问题，还是成本和供应链问题

端侧算力之所以重要，还有一个经常被忽略的原因：
它不仅影响性能，还直接影响机器人整机的商业化路径。

因为芯片选择会牵动很多现实问题：

整机 BOM 成本

电源设计复杂度

散热结构成本

供货稳定性

备件管理

生命周期管理

后续升级兼容性

很多 demo 之所以能做出来，是因为可以临时堆高配工控机、堆更强 GPU、堆更宽松的散热。
但一旦进入产品化和规模交付，这些方案往往会迅速失去经济性。

这也是为什么，机器人行业对芯片的真正诉求并不是“永远更强”，而是：

在可接受的成本、功耗和供应稳定性下，提供足够可用的边缘智能。

换句话说，端侧算力不仅是技术栈的一层，也是一张商业报表上的一层。

八、今天最容易被忽略的，不是芯片本身，而是软件栈

很多人讨论“模型上身”，注意力都放在硬件上。
但真正让部署变难的，往往并不只是芯片，而是软件栈成熟度。

训练侧和部署侧之间，经常隔着一整条鸿沟：

模型能否稳定导出

算子是否被支持

量化后是否掉点

编译优化是否引入精度偏移

多传感器输入是否能稳定接入

异构计算是否有统一调度

线上升级和回滚是否方便

日志和故障定位是否可用

这些问题不出现在论文标题里，但它们经常决定一家公司到底能不能做产品。

尤其在机器人领域，很多关键模块并不只是神经网络：

点云和几何处理

轨迹规划

运动学与动力学

实时控制

安全诊断

设备通信

这意味着，机器人端侧部署不是单纯的 AI 推理优化，而是整个机器人软件系统的重新组织。

九、什么样的架构，才更接近现实可用

在今天这个阶段，最现实的机器人计算架构，通常不是“一个大芯片包打天下”，而是异构分层。

比较典型的分法是：

1. MCU / 实时控制器

负责底层伺服、驱动、急停、限位、安全相关实时任务。

2. CPU

负责系统调度、通信、中间件、部分规划和逻辑控制。

3. GPU / NPU

负责视觉、多模态模型、感知推理、高层策略。

4. 独立安全单元

负责安全监测、冗余判断和异常隔离。

5. 云端

负责训练、数据管理、离线分析和策略迭代。

这类架构的核心思想很简单：

把必须稳定的东西隔离出来，把必须实时的东西优先保障，把必须高算力的东西集中处理。

这不一定是最“优雅”的技术叙事，但通常是最接近交付现实的做法。

十、怎么判断一个机器人的端侧算力到底够不够

真正评估机器人计算平台，不能只问“有多少 TOPS”，而应该问更具体的问题：

多路传感器同时打开后，系统帧率是多少

高负载下的 P95 / P99 时延是多少

连续运行 8 小时后是否会热降频

控制线程是否会被高层推理抢占

模型量化后成功率下降多少

显存和内存是否有余量

断网之后还能保留哪些核心功能

线上升级和回滚是否容易

芯片成本占整机 BOM 的比例有多高

同一平台能否支撑未来一到两代模型升级

这些问题，比“芯片参数看起来够不够大”更接近真实答案。

十一、写在最后

具身智能的很多问题，表面上看是模型问题，往下拆往往会发现，它们最终都要落到部署问题上。

因为机器人的“大脑”不是放在云里的抽象能力，而是必须装进一个真实存在的身体：

它有电池

它会发热

它要实时闭环

它不能乱动

它还要算账

这也是为什么，端侧算力和芯片部署虽然不像大模型那样容易制造想象力，却很可能是接下来两三年里最现实的行业瓶颈之一。

真正决定一个机器人系统是否能从 demo 走向交付的，很多时候不是它最强时有多聪明，而是它在现实约束下是否依然稳定。

如果要把这篇文章的核心判断浓缩成一句话，那就是：

机器人真正难的，不仅是把模型训练出来，更是把模型装进一个受功耗、散热、时延、安全和成本共同约束的身体里。

这才是“模型上身”四个字背后，真正沉重的部分。