把推理指标搬进机器人：为什么 TBT 是安全临界

基础篇的结尾我们说了：模型够聪明了、也瘦身好了，接下来要真正把它塞进机器人身体里跑。但动手之前，得先解决一件更根本的事——我们用来衡量 chatbot 快慢的那把"尺子"，到了机器人身上，还准吗？

这篇，具身篇开篇，我们先把尺子校准。

一、把 chatbot 的尺子，搬进机器人身体

还记得第 2 篇的"推理四件套"吗？Token、Prefill（读题）、Decode（逐字作答）、KV Cache（草稿纸）。当时我们全是在"聊天"的语境里讲它们。现在换个舞台——把它们一个个"搬"到一台机器人身上，你会发现每个零件都对得上号。

• 感知当前帧 = Prefill（读题）。chatbot 的"题"是你敲进去的那段文字；机器人的"题"是它的眼睛看到的这一帧画面——摄像头的图像、雷达的点云、关节自身的角度。机器人每"读"一次当前状态，就是一次 Prefill。读得越久（TTFT 越高），它对"现在世界什么样"的反应就越慢半拍。
• 生成动作序列 = Decode（逐字作答）。chatbot 一个字一个字往外蹦；机器人一个决策一个决策往外"蹦"——只不过它蹦出来的不是字，而是下一时刻该给各个关节多大的力矩、走什么轨迹。这一步的节奏，就是 TBT。在聊天里 TBT 高只是读着累；在机器人里，它意味着"动作与动作之间隔了多久"，这正是我们整篇要盯死的指标。
• KV Cache = "肌肉记忆"。第 2 篇说 KV Cache 是避免重算历史的草稿纸。机器人身上，它更像"肌肉记忆"：上一帧看到的障碍、上一时刻的姿态、刚才的手势，都被缓存下来，让连续决策前后连贯、不"断片"。没有它，机器人每一帧都像失忆，动作会一顿一顿。

你看，尺子还是那把尺子，只是刻度换了单位：从"字"换成了"动作"。

二、TBT，在这里不是"体验"而是"安全临界"

现在请把注意力只放在 TBT 上。

在 chatbot 世界里，TBT 是个"体验问题"。50 token/s，TBT 大约 20 毫秒，你几乎感觉不到停顿；掉到 10 token/s，TBT 涨到 100 毫秒，你顶多觉得它"吐字有点卡"。慢一点，无非你多等两秒，世界不会怎样。

但在机器人世界里，TBT 直接翻译成一句话：控制环路的闭环延迟。

什么意思？机器人不是"想好一次就动一次"，而是以几十赫兹的频率，一遍遍"看一眼、想一下、动一下"。每一圈的耗时里，藏着模型做决策的那段时间——也就是 TBT 的量级。TBT 一高，这一圈就转得慢，闭环刷新的节奏就跟不上物理世界的变化。

举个量级感受（以下均为示意，便于建立直觉，不代表精确实测）：chatbot 的 TBT 在几十毫秒到上百毫秒都"能忍"；而一个靠电池、要实时避障的机器人控制环路，闭环延迟通常得压到毫秒级——差出十倍甚至几十倍。因为机器人面对的是真实的速度和惯性：你往前走一步，0.1 秒后墙就到了。模型如果"想"了 100 毫秒才下令停下，这一步往往已经收不回来。

一句话钉死：chatbot 卡 200ms 只是体验差，机器人控制环路掉一帧就可能撞墙、或者抖动失控。 这就是 TBT 从"体验"升格为"安全临界"的真相。

三、控制环路 vs 对话环路：开环容忍，闭环必须刷新

为什么差别这么大？根子在"环"上。

人和 chatbot 的对话，本质是个开环：你发一句，它答一段，本轮回合结束，你读着等下一轮。慢一点，你顶多皱眉；它"卡顿"的那段时间，世界并不因为你停着而崩塌。你是容忍延迟的。

机器人的控制，本质是个闭环：它不仅要"作答"，还要把作答的结果通过传感器"读"回来，再决定下一步。它必须周期性地、不停歇地刷新自己的判断——一旦某个时刻没刷新，它就"不知道自己现在在哪、该往哪去"。

把两条链路画出来，区别一目了然：

左边那条，断了也无所谓，下一轮再接；右边那条，只要一停，机器人就"睁眼瞎"。这就是延迟在两种系统里分量天差地别的根本原因。

四、延迟—安全边界：有一条看不见的临界线

既然闭环必须刷新，那是不是"延迟越低越好"？

工程上更精确的说法是：存在一个临界延迟。低于它，系统稳稳当当；一旦超过，系统会从"可控"悄悄滑向"失控"。

可以想象一条曲线：横轴是延迟，纵轴是系统稳定性。延迟很小的时候，曲线高高在上——机器人灵活、听话；随着延迟增大，曲线缓缓下滑，进入一个"还能勉强维持"的灰色地带；再往上越过某条线，曲线陡然跌落——抖动出现了、振荡出现了、避障开始慢半拍，最后撞上障碍。那条陡然跌落的边界，就是"延迟—安全边界"。

这条边界不是固定的。它跟着任务变：低速巡线时边界宽松些，高速避障或和人协作时边界骤然收紧。但"越过边界就失控"这件事，是确定的。

所以工程师真正盯的不是"平均延迟漂亮不漂亮"，而是"最坏情况下会不会越过那道边界"。一次偶发的卡顿、一个掉队的帧，平时没事，碰上临界工况就可能出事。

五、当延迟超标：两个会"抖"的典型案例

光讲曲线有点虚，看两个工程里常见的"典型"画面（以下为示意性描述，非精确实测数据）：

案例一：端杯子时的高频抖动。 一台机械臂在抓取杯子，控制环路要求它每帧根据视觉微调指尖力度。某次因为模型 TBT 偏高、闭环刷新慢了，它"想"出来的修正指令总是滞后于真实姿态——指令和现实错开半拍，越修越歪，杯子在指尖高频颤动，最后脱手。这正是在临界线附近，微小延迟被闭环放大成振荡的典型表现。

案例二：移动机器人的"刹车来不及"。 一台轮式机器人在走廊避障，正常闭环延迟下它能从容减速。某次边缘设备负载升高，推理 TBT 从毫秒级涨到上百毫秒，闭环刷新慢了一截。等它"想"明白前方有人、下令刹车时，惯性和距离已经不够——要么急刹抖动、要么擦碰。延迟超标，直接把"可控刹车"变成了"来不及"。

两个案例里，模型都没"算错"，只是"算慢了"。而慢，在闭环里会被物理世界放大成事故。

六、指标搬过来了，下一篇我们真的动手

到这儿，具身篇的第一块拼图就齐了：推理指标能原样搬进机器人，TBT 从体验问题变成了必须压进毫秒级的安全临界，背后还悬着一条越过就失控的延迟—安全边界。

指标看清了，危险也看清了。下一篇，我们不再纸上谈兵——直接把瘦身好的模型，从云端搬到机器人本体或就近的边缘设备里，在功耗、散热、延迟的夹缝中，让它既聪明又听话。

那是真正的"搬箱子"实战。

读后小测

3 句话复述

1. chatbot 的推理指标能原样"搬"进机器人：感知当前帧 = Prefill（读题），生成动作序列 = Decode（作答，节奏即 TBT），KV Cache = 串联连续帧的"肌肉记忆"。 2. TBT 在机器人里是"安全临界"而非"体验问题"：它直接等于控制环路的闭环延迟，chatbot 卡 200ms 只是体验差，机器人掉一帧就可能撞墙或抖动失控，必须压到毫秒级。 3. 机器人是闭环、必须周期性刷新，对话是开环、人容忍延迟；存在一条"延迟—安全边界"，超过临界延迟系统就从可控滑向抖动、振荡、撞障。

1 件动手小事

今晚拿一个会"逐字来"的 AI，故意让它一次生成很长的回答，盯着屏幕数一数字与字之间是否均匀流畅；再想象一下，如果这串"字"变成机器人的一连串动作指令，每隔 100 毫秒才刷新一次，一个正在走路的机器人会怎样。把"延迟 = 动作刷新慢半拍"这个体感记牢，下一篇我们聊边缘部署、把模型真正塞进本体时，你会立刻懂为什么第一步就得死磕 TBT。