端到端延迟拆解：摄像头→感知→决策→执行全链路

模型选好了、VLA 横评也做完了，但第 6 篇结尾抛出的那个问题还没回答：一个动作从"看见"到"做出来"，时间到底花在哪？

这篇就正式动手，做这场"时间解剖"。

一、先建一条"动作旅程"时间轴

把一个动作想成一次快递配送：你下单（看见画面、听懂指令）到货真送到手上（电机动起来），中间要过好几站——每一站都要时间，毫秒累加，最后才是你感受到的"反应快慢"。

机器人也一样。一个动作不是"啪"地一下完成的，它要穿过一连串环节，每环都吃毫秒：

摄像头采集 → 图像预处理 → 视觉编码器 → VLA 主干 → 动作头 → 执行器

把这六站画成一条链路，每站标注它"吃时间的来源"：

看清这条链路很关键：它正好把前几篇的"指标"翻译成了"机器人体感"。第 3 篇聊的 TTFT（首 token 延迟）对应这里的"从看见到出第一个动作"，第 3 篇聊的 TBT（token 间延迟）对应这里的"动作刷新的节奏"——只不过 chatbot 是吐字，机器人是出关节指令。

二、逐环拆解：每一站到底吃多少毫秒

⚠️ 说明：本专题目前没有真实自测数据，下面用清晰的量级示意口吻讲，便于建立直觉，非精确实测。

按链路顺序，逐站看它吃时间的来源和大致量级：

• 摄像头采集：画面不是"免费"的。一次曝光加传感器读出要时间，而且被帧率死死约束——30fps 就是约 33ms 一帧、60fps 就是约 16ms 一帧。这口"时间税"你躲不掉，帧率定下来它就在那。
• 图像预处理：把原始画面变成模型能吃的格式——resize、归一化、色彩空间转换（RGB→模型输入），有时还要先解码视频流。看着轻，但它常常发生在 GPU 之前，是被低估的"隐形税"。
• 视觉编码器（ViT 类）：把图像压成一串 token。这一步算力随分辨率、相机数量涨得飞快——一个相机、低分辨率还好；多相机、高分辨率一叠加，算力直接爆炸。
• VLA 主干 Prefill：对应基础篇"读题"——把过往几帧画面加语言指令一起读进去，形成上下文。这一步对应 chatbot 的 Prefill（第 2 篇的"读题"），上下文越长（看的帧越多）越慢。KV Cache 就是这里的"草稿纸"（第 2 篇）。
• 动作头 Decode / 迭代：对应基础篇 Decode / TBT，本篇是"出动作"，最吃实时性。离散路线是一点点往外吐动作 token（每步就是一次 TBT，第 3 篇）；连续路线是要迭代好多步把动作打磨出来（步数就是延迟，第 6 篇说它常被低估）。它必须压进第 4 篇讲的控制环路临界线以内，否则动作就"跟不上节奏"。
• 执行器：模型算出动作还没完，指令到电机还有通信延迟、实时总线（如 CAN / EtherCAT）的传输延迟。这口时间常常被遗忘，但它真实地躺在"出动作"和"真的动"之间。

把六站叠成一张时间瀑布（fig1），你会直观看到：不是每一站都贵，但贵的地方往往不在你以为的那站。

三、瓶颈到底在哪：真凶往往不是你盯着的那个

一个常见误区：大家挑模型时死盯"主干多大"——7B 还是 3B，好像主干越小就一定越快（第 5 篇的"瘦身三板斧"也是冲着主干去的）。

但真凶常常是下面三位：

1. 预处理这口"隐形税"：它经常跑在 CPU 上，发生在 GPU 之前。你 GPU 算得再快，前面 CPU 还在磨图像，整条链路就被前面的慢节点卡住——而这一步最常被人忽略。 2. 视觉编码器在"高分辨率 + 多相机"叠加时算力爆炸：单相机还好，一旦机器人装了多个摄像头、还要高分辨率看清细节，编码器的算力需求就非线性地涨上去，很容易变成全链路最肥的那块。 3. 动作头迭代步数：第 6 篇就提醒过"动作头被低估"。离散路线吐得慢、连续路线迭代多步，动作头常常是全链路里最吃实时性的那一截——可它偏偏最小、最不起眼。

结论先放这：瓶颈大概率不在主干，而在预处理、视觉编码器、动作头这三截"不起眼"的地方。 找到它，优化才有的放矢。

四、优化抓手清单：分环节"拆弹"

定位了瓶颈，就能按环节给抓手。下面这份清单分环节，给你可落地的方向：

• 预处理：把 resize / 解码搬到 GPU 或专用硬件（如 NVDEC 硬解码、ISP 图像信号处理）；降分辨率到"够用就好"；固定输入尺寸，省掉动态 shape 的开销。
• 视觉编码器：换更小的 ViT；做特征缓存——背景不变就不重算；多相机共享一次编码，别每路各算一遍。
• 主干：上量化（第 3 篇的 INT8 / INT4、第 5 篇的瘦身）；复用 KV Cache（第 2 篇的"草稿纸"），别每次都重读上下文；缓存指令前缀，语言指令不变就别重算。
• 动作头：减迭代步数（第 6 篇的硬招）；蒸馏一个更小的动作专家；在离散 vs 连续之间权衡——前者实现简单、后者动作丝滑，按你的实时预算选。
• 系统级：流水线化——让"前一帧的动作解码"和"后一帧的视觉编码"重叠进行，别串行等；用异步、确定性实时调度，把抖动压到最小。

把这份清单和第 4 篇的临界线对照看：每砍掉一截延迟，你就把动作往"压进临界线"推近一步。

五、拆完单步，下一个坑是"仿真太顺、现实掉帧"

我们已经把一个动作的耗时拆到了每一环，也给了分环节的优化抓手。但工程里有个经典反差：仿真里跑得顺顺当当，一上真机就掉帧、卡顿、过临界线。

为什么"纸上算得好好的延迟，落到现实就崩"？下一篇，我们聊这个让无数部署翻车的坑——《仿真到现实：sim-to-real 中的部署陷阱》。

读后小测

3 句话复述

1. 一个动作从看见到做出来要过六站——摄像头采集、图像预处理、视觉编码器、VLA 主干 Prefill、动作头 Decode/迭代、执行器，每站都吃毫秒、累加出你能感受到的"反应快慢"，类比一次快递从下单到送达的每一站。 2. 逐环看时间来源：帧率约束采集、预处理常跑在 CPU 上是隐形税、视觉编码器随分辨率和多相机非线性暴涨、VLA 主干 Prefill 对应"读题"、动作头对应 Decode/TBT 且必须压进第 4 篇的控制环路临界线、执行器还有通信总线延迟。 3. 瓶颈大概率不在主干，而在预处理、视觉编码器、动作头这三截不起眼的地方；优化要分环节下手——预处理搬硬件、编码器做缓存、主干量化加 KV Cache 复用、动作头减步数、系统级流水线化，把动作一步步推向压进临界线。

1 件动手小事

今晚拿手机拍一段自己伸手拿杯子的视频，看一眼录制参数里的帧率（30fps 还是 60fps），用 1000 除以帧率算出"每一帧间隔多少毫秒"——这就是链路第一站"摄像头采集"死死吃掉的那口时间税。再想象后面还有 resize、视觉编码、模型出动作、指令传电机五站，每一站都在这一帧的基础上继续累加；把这个"动作是一站站磨出来、每站都吃毫秒"的体感记牢，下一篇我们聊 sim-to-real 掉帧陷阱时，你会立刻懂为什么仿真里算得清的延迟、真机上却会崩。