摘要：上一篇我们说清了"VLA 大模型救不了抖动"。这一篇回答一个更基础的问题：既然大模型和控制环的时间要求差了四个数量级，它们为什么还能装在同一个身体里？答案是人形机器人身上的"两个大脑"——不是备份、不是堆料，而是时间尺度逼出来的架构。本文把两个大脑的分工讲清楚，给出它们之间的延迟预算表、通信通道的四种取舍，以及双芯片、单 SoC 分区、异构 SoC 三种物理形态的工程账。

---

一、拆开一台人形机器人，你会看到两套计算

一个很直接的现象：如果你去看头部人形机器人公司公开的架构资料，会发现一个共同点——几乎没有谁用一套计算同时干"想"和"动"两件事。行业里管这个结构叫"两个大脑"。

更具体的例子：Figure 公开的 Helix 架构，直接就把两层命名为 System 2 和 System 1——System 2 是一个 70 亿参数级的视觉语言模型，以 7–9Hz 的频率理解场景、产生动作意图；System 1 是一个 8000 万参数级的策略网络，以 200Hz 的频率把意图变成具体动作指令。两个网络的规模差了近百倍，工作频率差了二十多倍，跑在同一个身体里。

我们在客户现场见到的剧本也类似。去年有个团队想"省一块板子"，用一颗 SoC 同时跑 VLA 推理和关节控制：推理一开跑，控制环的延迟从稳定 800µs 涨到偶尔 15ms，机器人手臂开始出现肉眼可见的抖动。他们试了调优先级、调批大小，最后改回"推理归推理、控制归控制"的分工，问题当天消失。

但分工只是开始。分开之后，新的问题马上出现：

• 两个大脑之间到底应该传什么数据？
• 传数据的通道，延迟和抖动预算怎么定？
• 是两个芯片，还是一颗芯片分区，还是同一颗芯片上的两个核？

这三个问题，就是这篇文章要算的账。

二、两个大脑不是"备份"，是两种时间观

2.1 快系统与慢系统：从认知科学借来的词

"两个大脑"的说法借用自认知科学里的双系统理论：System 2 是慢的、需要思考的（“我该走哪条路”），System 1 是快的、反射式的（“脚下有台阶，抬腿”）。机器人行业借用这个框架来描述两类计算：

	慢系统（大脑）	快系统（小脑）
职责	理解场景、理解指令、规划任务	轨迹生成、姿态控制、稳定反射
工作方式	一次推理产生一段时间的目标	固定周期闭环，每个周期都要出结果
频率	1–10Hz（公开的 Helix 是 7–9Hz）	100Hz–1kHz（Helix 是 200Hz）
时间要求	平均延迟可接受，抖动可被缓冲吸收	每一帧都必须守时，抖动直接进物理世界
失败模式	动作"不对"（语义错误）	动作"不稳"（抖动、失稳）

这两种计算的差别，本质上是时间观的差别：慢系统活在"平均时间"里——平均 200ms 出结果就行，偶尔跑到 300ms 也有人替它兜底；快系统活在"最坏时间"里——平均多快都没意义，每一帧都必须按时。

上一篇我们说过：平均值没有意义，尾部才有意义。这句话只对快系统成立。两个大脑的第一性原理就是：对时间要求差了四个数量级的计算，不应该放在同一个时间约束下管理。

2.2 为什么不能只留一个大脑？

每次讲这个架构，都会有人问：既然端到端大模型是趋势，为什么不让大模型直接输出力矩、一步到位？或者在同一个核上分时跑两件事不行吗？

这三个方案摊开看，答案很清楚：

方案 A：一个大模型干所有事。 大模型以 1kHz 为机器人输出关节力矩。抛开模型能力不谈，先看时间确定性：GPU 推理的时间分布是"平均 + 长尾"，批处理、显存分配、算子调度都不可控。要让一个 GPU 推理管线做到 1kHz、抖动 10µs，目前没有任何可行的技术路径。而且这条路还有一个安全问题：物理安全回路不能建立在"概率上通常没问题"的计算上。

方案 B：同一套计算分时跑。 就是上面那个客户案例：推理和控制同核。推理的长尾（一次 15ms）会直接暴露成控制环的 deadline miss。操作系统层面可以做到"优先保证控制线程"，但这只解决了"控制线程能跑"，没解决"控制线程跑得稳"——共享缓存、内存带宽、热降频、中断，都是分时方案躲不开的干扰源。同一个执行体里，弱约束的一方永远会被强约束的一方牵连，除非隔离做到物理边界。

方案 C：两个大脑分工，接口上重新连接。 慢系统以低频输出"意图"，快系统以高频执行"意图"，两者之间用一条明确定义了延迟预算的通道连接。工程上唯一可行的方案。

所以：两个大脑不是技术品味，是时间尺度逼出来的架构。 只要"思考"不可能做到"反射"的时间确定性，这个分工就会一直存在。

2.3 两个大脑之间应该传什么？

分工之后，第一件要定义清楚的事是接口。这里有一个很常见的错误：把底层量直接透传——大模型的输出直接变成关节角度、甚至力矩。

正确的做法是：两个大脑之间传的是意图，而且是"高频执行者愿意接受、且能兜底"的意图。接口应该满足三个特征：

1. 低频。 意图不需要以 1kHz 更新。10–50Hz 的意图刷新，配合快系统内部的插值与外推，足以支撑流畅运动。想清楚这一点，大脑的延迟预算一下就宽裕了——几百毫秒的推理延迟，对"意图"来说完全可以接受。
2. 高层语义。 意图是任务级、位姿级的：末端轨迹点、目标姿态序列、任务状态机迁移。不是关节角度，更不是力矩。力矩是"脊髓"层的事，跨两层去指挥，等于把低层的安全和实时责任拿走了。
3. 可缺失、可过期、可兜底。 这是最重要的一条：快系统必须假设"意图随时可能不来、可能来晚、可能来了但不合理"。所以意图通道上要有序号、时间戳和有效期；意图过期时，快系统要能自己稳住——零阶保持、降速、停在安全姿态，每一档都要预先定义。

用一句话概括这个接口的合同：大脑负责"去哪里"，小脑负责"怎么去、多快去、出问题时怎么安全"。 合同写不清楚，两个大脑就会互相甩锅——大脑怪小脑执行不到位，小脑怪大脑指令不可执行。

三、从 1 秒到 1 毫秒：预算与通道的工程账

3.1 一张完整的延迟预算表

把上一篇的链路分解换成预算视角，就是两个大脑的"分账表"：

环节	典型预算	由谁负责	超支的后果
感知采集	10–30ms	感知	意图滞后，不直接影响稳定
大脑推理	100–1000ms	慢系统	动作变"笨"，不直接影响稳定
意图传输	1–10ms	接口通道	意图滞后，触发兜底
轨迹生成与控制	1ms 周期	快系统	直接变成抖动
总线传输	微秒级抖动	通信	多轴不同步
伺服电流环	50–100µs	伺服	力矩纹波

这张表有一个反直觉的地方：从预算上看，慢系统占了大头（几百毫秒），快系统只占零头（毫秒级和微秒级）。但系统稳定性只由零头决定。 这也是为什么"优化了整个管线的平均延迟"经常没有效果——你优化的是大头，抖动住在零头里。

这张表还有一条使用纪律：预算要倒着分。 从最紧的 deadline（伺服环、总线）开始分，最后剩下的才是大脑的预算。反过来分（先给大脑留够、剩下的给控制）的结果，就是系统能跑，但不能用。

3.2 1kHz 周期里的 1 毫秒怎么花

快系统分配到 1ms 的控制周期，这 1ms 内部还要再分一次。以一个 1kHz 全身控制周期为例：

阶段	预算	说明
状态采样与同步	~100µs	关节编码器、IMU 读取，注意多源时间对齐
轨迹插值	~100µs	把意图插值成当前周期的目标
动力学/前馈计算	~300µs	全身控制（WBC）或 MPC 时更贵，必要时降频
输出与总线发送	~400µs	组包、EtherCAT 周期窗口
余量	~100µs	不允许为零

两条纪律：永远留余量（20% 起步，复杂负载下 30%）；动力学计算吃不下就降频或分层（比如全身控制跑 500Hz，关节伺服仍跑 1kHz）——预算是分配问题，不是"全都要"的问题。

3.3 两个大脑怎么"说话"：四种通道的取舍

意图通道的选择，决定了两个大脑"分开得有多彻底"。常见选项和它们的量级（常见配置下的经验值，实际取决于实现）：

通道方式	延迟量级	抖动量级	典型载体
进程间共享内存	1–10µs	微秒级	同一 SoC 内的两个进程
核间中断 + 共享内存	10–50µs	十微秒级	异构 SoC（CPU 核 ↔ MCU/DSP 核）
直连以太网（精简协议）	100–500µs	十微秒–百微秒	双板卡
通用协议栈（含 ROS 2/DDS 常见配置）	毫秒级	毫秒级抖动	双板卡、网络环境

怎么选？用两个问题就能框定：意图多久更新一次？失去意图后能安全运行多久？

• 如果快系统能在 100ms 内无意图安全运行，而意图以 10Hz 更新，那么通道延迟 10ms、抖动 5ms 都可以接受——抖动只要被"有效期 + 兜底"机制吸收掉，就不必追求微秒级。
• 反过来，如果意图通道设计成"每帧必须到、到了就要立刻执行"，那通道的抖动就会直接变成机器人的抖动——通道的实时性要求，取决于接口设计，而不是取决于通道本身。

给两条实战建议。第一，别把 ROS 2 当安全通道用：DDS 的常见配置是毫秒级延迟加毫秒级抖动，它适合调试、数据回放和模块解耦，不适合承载安全兜底的判断依据。第二，意图通道必须可观测：序号、时间戳、超时计数、丢帧计数，这些指标一天都不能没有——"机器人突然慢了半拍"这类问题，八成能在意图通道的统计里找到答案。

3.4 双芯片还是单 SoC：三种物理形态

"两个大脑"落在硬件上，有三种形态：

形态一：物理双芯片。 慢系统一块计算板（大算力，允许长尾），快系统一块实时板（小算力，要确定性），板间用直连通道。优点是故障域天然隔离——大脑崩了，小脑还能把机器人安全停下来；安全认证也容易做（实时部分可以单独取证）。代价是成本、体积、功耗都往上走。航天和工业安全场景基本都用这个形态。

形态二：单 SoC 分区。 一颗芯片，大核跑慢系统、隔离核跑快系统（或 GPU 跑推理、CPU 隔离核跑控制）。优点是成本低、通信快（共享内存就是微秒级）。代价是故障域共享，实时性完全依赖隔离质量：核隔离、内存带宽、缓存、热降频，任何一个环节没做好，两个大脑就"串味"。开篇那个 15ms 的案例就是这个形态没做隔离的结果——但隔离做扎实的话，它是成本最优解。

形态三：异构 SoC 折中。 SoC 内的应用核跑 Linux 侧（感知 + 慢系统），实时核/协处理器跑控制环，核间用中断加共享内存连接。介于前两者之间：成本接近单芯片，故障域部分隔离，通信在十微秒级。目前不少机器人的关节控制和总线主站就放在这类实时核上。

三种形态没有优劣，只有取舍。选择时问三个问题：安全要求到什么等级（要不要单独认证）？成本敏感度多高？团队能不能把隔离做扎实？ 三个问题的答案，基本就指向唯一合理的选择。

（编辑注：图 1 建议放"两个大脑三层时间尺度"架构图；图 2 建议放三种物理形态对比示意图，标注延迟与故障域差异。）

四、结论

把这篇压成一句话：

两个大脑不是"为了更强"，是"为了更稳"——时间尺度不同的系统必须在架构上分开，然后在接口上重新连接。

判断你的机器人要不要"分脑"，有一个简单的算法：把系统里所有计算按"最坏情况时间要求"排序，如果相邻两层的差距超过 100 倍（比如秒级的规划 vs 毫秒级的控制），它们之间就应该有一条显式的"意图接口"和一张分工明确的预算表；如果没有，抖动就会替你做出选择。

五、检查清单：你的两个大脑分工合格吗

八条，按优先级排序：

1. 意图接口的语义对吗？ 检查大脑输出的是不是"意图"（位姿序列/任务状态），而不是关节角或力矩。跨层指挥是抖动的温床。
2. 小脑有没有"无意图兜底"能力？ 断掉意图通道，快系统能不能零阶保持、降速、停在安全姿态？这是上电测试的第一项。
3. 意图通道可观测吗？ 序号、时间戳、超时计数、丢包计数，缺一不可。没有统计数据，通道故障只能靠"感觉"排查。
4. 通道延迟与刷新率匹配吗？ 用"意图更新周期 × 安全兜底时间"倒推通道预算，别拿 DDS 的常见配置当安全通道的底线。
5. 意图有效期定义了吗？ 每一条意图都应有明确的有效窗口，过期即触发兜底策略，而不是无限期沿用旧指令。
6. 单 SoC 形态：隔离做扎实了吗？ 核隔离、内存带宽限制、缓存干扰评估、热预算，一项一项验证，用压力测试说话，而不是"应该没问题"。
7. 双芯片形态：链路故障会降级吗？ 断线、丢包、时间不同步，每一种故障都要有明确的降级行为和告警，而不是靠人工发现。
8. 端到端指标和实时指标分开监控。 "指令→动作"几百毫秒的端到端延迟，和"控制环 1ms 守不守时"是两个看板，不要混在一张报表里。

六、留一个问题给你

回到标题那个问题：两个大脑，是过渡方案，还是终局？

• 站"过渡"的：等端到端模型足够快、算力足够便宜，一个大脑就够了；
• 站"终局"的：物理世界的时间约束是硬的，思考与反射的分层不会消失，只会换名字。

下一篇，我们把镜头拉远：特斯拉、宇树、Figure 这些头部公司，公开资料里到底用了什么操作系统、什么芯片、什么总线？我们试着把这张技术拼图拼出来。

---