机器人的“大脑”该放在哪：端侧算力的三道硬约束

不是把服务器塞进机身，而是同时满足实时、功耗与温度

今年最忙的两个词，一个是“大模型”，一个是“具身智能”。前者负责想，后者负责动。可两者真正结合时会撞上一个很现实的问题：机器人的身体里，放得下那颗会思考的“大脑”吗？

云端当然能算。但机器狗跑进变电站、无人车开进隧道、机械臂上产线，网络不一定在，时延不一定给。于是算力必须往设备里塞——而且要小、要省电、要抗造。

▲ 掌上级具身控制器：全铝鳍片机身，天线与接口集中在后侧

01 先把算力分三层

讨论端侧算力之前，值得先把“算力放哪儿”这件事拆开。工程上通常分三层：

· 云：训练、长尾场景、复杂规划，追求上限，不计较毫秒

· 边缘：多机协同、局部地图、区域调度，兼顾带宽与响应

· 本体：实时控制、避障、视觉跟随，只认确定性和稳定性

越靠近本体，约束越硬。云端可以靠堆卡解决性能问题，本体不行——它的天花板由体积、功耗、散热和实时性共同决定。

02 第一道约束：实时性不是“快”，是“准点”

做过运动控制的人都知道，控制周期是毫秒级的。一个 1kHz 的伺服环路，每 1 毫秒就要算一次；晚到 5 毫秒，轨迹就已经偏了。

问题在于，通用 Linux 不是实时系统。调度抖动、中断延迟、内存回收，任何一项都可能让一帧控制指令迟到几十毫秒。工程上的标准解法是分层：Linux 负责规划、视觉、人机交互，实时任务下沉到独立 MCU，再加一颗硬件看门狗兜底。这也是为什么很多控制器的主板上，除了主 SoC，还会单独放一颗单片机——它不是冗余，是必需。

总线同样关键。CAN 在 1Mbps 下每帧只有几十字节有效载荷，挂十几个关节就开始吃紧；CAN-FD 把数据段提到 5Mbps 以上，帧长也放大到 64 字节，才谈得上带多关节、高刷新。再往上走是 EtherCAT 一类的实时以太网，但对走线和从站成本要求更高。

03 第二道约束：几十瓦的预算，怎么花

移动机器人大多靠电池。整机功率预算往往只有一两百瓦，要分给驱动、计算、传感器和通信。留给控制器的，通常就是几十瓦——45W 是一个常见的量级。

这个量级有个尴尬之处：纯被动散热压不住，加风扇又怕进灰、怕噪音、怕寿命。于是常见方案是铝挤鳍片加一颗涡轮风扇，靠风道设计把热量从侧面带走，同时把整机做成无孔或少孔结构，兼顾防护。

温度指标也反映了使用场景。消费电子标 0~40℃，工业与车载设备通常要 -20~60℃ 起步，还要过静电与电源浪涌的摸底测试。这些参数不出现在宣传页上，但决定了设备能不能真的装到户外设备舱里。

04 第三道约束：接口决定它能不能“接上身体”

具身设备最容易被低估的，是接口。工业现场没有“插个 USB 就行”这回事：

· 视觉：车载级 GMSL 摄像头一根线缆同时传视频、供电和控制，抗干扰强、线束短，但需要专门的解串芯片

· 运动：CAN、CAN-FD、RS485、RS232 各有各的生态，转换板越多，故障点越多

· 感知：IMU 要 6 轴加速度计加陀螺，再加地磁做航向；精度和零偏稳定性比量程更重要

· 定位：多模 GNSS 在室外够用，进室内就要靠视觉或激光

· 网络：多网口做内外网隔离，在工业现场几乎是硬需求

比接口数量更难的，是时间同步。多传感器融合要求摄像头、IMU、轮速的时间戳对齐，差几毫秒，标定就会漂。所以真正成熟的控制器，会在硬件层做触发与授时，而不是让软件去打补丁。

05 一种被验证过的形态

把上面三道约束叠在一起，会得到一个很窄的设计空间。这两年市面上陆续出现了一些掌上大小的具身控制器：体积不到 1.5 升，整机功耗 45W 量级，主控用八核 ARM 平台，算力通过可插拔模块扩展，实时总线从侧面的排母引出。

▲ 六视图尺寸图纸：机身主体长约 141.7mm，宽 90mm，高 48.6mm

这种设计思路值得关注的地方不在参数，而在两件事：

一是算力与结构解耦。同一套机械结构和软件栈，低配做视觉检测，高配跑多模态模型，整机厂不必为每一档算力重新开模。在模型一年一迭代的当下，这一点比多几 TOPS 更有意义。

二是把系统边界划清楚。主 SoC 管通用计算，独立 MCU 管实时控制，看门狗兜底——这套分工看起来保守，却是工业设备能长期稳定运行的前提。

06 算力档位到底怎么选

如果把端侧负载粗分三档，选型逻辑其实不复杂：

· 轻量视觉：目标检测、瑕疵识别、二维码与姿态，20 TOPS 级别够用

· 多路视频解析：4~8 路 1080p 同时解码加推理，叠加 OCR，70 TOPS 级别更稳

· 大模型交互：30B~70B 级别的语言或多模态模型，需要 160 TOPS 级别算力，且内存要在 24GB 以上

需要提醒的是，“能跑”和“实时跑”是两件事。同一个模型，量化精度、上下文长度、并发路数一变，帧率能掉一个数量级。规格书上的算力是上限，实际体验要看实测。

07 三个常见误区

第一，把 TOPS 当唯一指标。算力是峰值，访存带宽和算子效率才决定实际吞吐。同样标称算力，不同架构跑同一个模型，速度可以差好几倍。

第二，忽略软件生态的迁移成本。ROS 2 支持比参数表重要得多——它意味着现有算法能迁过来，而不是从零重写。国产算力平台的软件栈迭代很快，算子覆盖和框架适配要预留时间。

第三，把消费级方案直接搬到工业现场。风扇寿命、宽温、静电、振动，这四项在实验室里测不出来，到了现场就是批量故障。

08 结语：这是一道组合题

“具身智能”听起来是算法的事，落到工程上其实是接口、功耗、尺寸、温度的组合题。谁能把这几件事同时做到，谁才谈得上让机器真正“长脑子”。

至于大脑放在身上还是放在云端，我的看法是分层：本体负责确定性和实时，云端负责上限和长尾。两者不是替代关系，是分工关系。

你觉得机器人该把大脑放在身上，还是放在云端？如果给你一台这样的控制器，你会先让它干什么？评论区聊聊。

（本文为技术观察，不构成采购建议；参数与性能以厂商公开资料为准，文中配图为产品渲染图与结构图纸。）