CARE：给机器人推理加速发"体检合格证"，过不了就不许部署

VLA 是什么，它为什么慢到需要加速？

这篇文章要讲的是一条主线：CARE 如何给 VLA 加速发一张"部署合格证"。它把每一个能让 VLA 跑得更快的候选送进同一场体检，只有在配对轨迹上证明自己弄坏的任务没超过预算，才允许部署；拿不到证，就不许上岗。要理解这张证为什么非有不可，得先知道 VLA 是什么样的模型，它慢在哪儿，以及今天的加速方案都拿什么数字来证明自己安全。

2023 年，Google DeepMind 把一套互联网规模的视觉-语言模型直接接上了机械臂，系统取名 RT-2。它能靠从网络里学到的常识理解指令，比如你指着桌上一堆东西说"拿那个能提神的饮料"，它能推理出该抓能量饮料。同一篇论文也写下了代价：其中最大的 55B 参数版本，控制频率只有每秒 1 到 3 次。RT-2

1 到 3 Hz 意味着什么？机器人做一次灵巧操作，需要在很短的时间窗口里不断微调手指的位置和力道，做到跟手，得是每秒几十上百次的闭环反馈。1 到 3 Hz 则是每三分之一秒才重新看一眼、想一下、动一下，中间全靠惯性往前冲。RT-2 第一次证明了"用一个大模型直接控制机器人"可行，也顺手暴露了这条路离真正可用还差一个数量级的反应速度。

RT-2 留下的最有影响的一句话，是把动作当成另一种语言。它把机器人的每个动作也编码成文本 token，和网络上的图文数据塞进同一个模型一起微调。理解图片、读懂指令、输出动作这三件事由同一个视觉-语言模型完成，从网络知识往机器人控制迁移的能力就这样被继承下来。这一类模型后来被统称为 VLA，也就是视觉-语言-动作模型。

约一年后（2024 年），斯坦福等团队把这条路做成了开源的 7B 版本，取名 OpenVLA。它的结构可以拆成三段：一段视觉编码器把 DINOv2 和 SigLIP 两个特征拼起来，一个 projector 把视觉特征映射进语言模型的空间，最后交给 Llama 2 7B 输出 7 维机器人动作。OpenVLA

图注：OpenVLA 的模型结构。左侧是图像观测与语言指令两路输入，中间视觉编码器由 DinoV2 与 SigLIP 两条分支组成、汇合后经 Projector 映射，右侧是 Llama 2 7B 语言模型主干，最终输出 7 维机器人控制动作。OpenVLA

这张图也解释了它为什么慢。视觉编码、投影、7B 语言模型前向解码，全都要在每一个控制步里完整跑一遍，而最终输出的动作只有 7 维。机器人越灵巧，需要重算的频率越高，这套管线就越拖后腿。更要命的是这是闭环控制，动作一变，下一个观测就变，没有哪一步是可以跳过的。

加速的工作很快就来了，而且做得相当漂亮。OpenVLA-OFT 在输出侧同时做了四件事：用并行解码让一次前向同时吐出整组动作，不再自回归地一个一个生成；用 action chunking 让每一步规划后面若干步；把动作从离散 token 换成连续值；用 L1 回归代替分类目标。四个改动叠在一起，在 LIBERO 基准上把平均成功率从 OpenVLA 的 76.5% 推到 97.1%，吞吐提升 26 倍，动作分块加大到 25 步时能到 43 倍，还在双臂 ALOHA 真机上跑出了 25 Hz 的控制频率。OpenVLA-OFT

另一些方案选择了完全不同的发力点。VLA-Cache 不动模型也不重训，靠跨帧复用已经被算过的 KV，把 OpenVLA-OFT 的控制频率从 65.10 Hz 抬到 78.98 Hz。它的思路与输出侧改造互补，两者可以叠加。VLA-Cache

把这些方案放在一起看，你会发现候选加速器的种类很杂：有改动作表示与解码方式的，有剪视觉 token 的，有缓存特征的，有缩减流匹配步数的，甚至还有把几种组合起来的。它们各自都能让机器人更快，但报告结果时用的口径出奇地一致，也就是平均成功率和延迟（或控制频率）这两个数字。而问题恰恰出在这个口径上：平均成功率会把失败掩盖掉。参考策略能解出的任务里被加速版弄坏十个，加速版又碰巧"蒙对"十个参考策略本来就做不出的任务，一加一减，平均成功率几乎原地不动，可那十个被弄坏的任务是实打实的退化。平均成功率没掉，不等于没变差，这道沟比看起来深得多，也正是 CARE 那张合格证存在的理由。

这些方案彼此并不冲突，原理上甚至可以叠加，但它们几乎都会宣称自己是"无损"的，而"无损"这三个字背后的全部证据，往往只是平均成功率没掉。这就在选型时制造了一个真实的困境：它们的成功率数字挨得很近，延迟也都可接受，你到底该信哪一个？CARE 的处理方式很干脆，不预设哪种加速机制更优，把所有这些方案一律当成排队待检的候选，让配对轨迹上的数据来决定答案。

于是这张"合格证"要回答的就不再是"哪个加速器更快"，而是"这一档提速到底安不安全，能不能验收"。接下来要做的，就是先把平均成功率这道盲区摊开来看。

平均成功率没掉，就等于没变差吗？

先看一个最直观的场景。参考策略能解出的任务里，加速版弄坏了十个；可加速版又碰巧"蒙对"了十个参考策略本来就做不出的任务。一加一减，平均成功率几乎原地不动。可那被弄坏的十个，是实实在在的退化。这不是少见情形，而是闭环系统里非常自然的对称结果。

CARE 把这个现象单独定义出来，叫加速引发的失败，简写 AIF：在同一个条件下，参考策略成功、加速版失败。这里的"同一个条件"要求三件事完全固定，同一个任务、同一个初始场景、同一个随机种子，三者合起来构成一个 evaluation unit，记作 $U$。用公式写出来很干净：参考策略的成败记成 $Y_0(U)$，加速版的成败记成 $Y_\lambda(U)$，损失就是

$$L_\lambda(U)=Y_0(U)\bigl(1-Y_\lambda(U)\bigr)$$

只有当参考成功而加速失败时，它才等于 1，其余情况都是 0。"加速引发的失败率"就是它的期望，记作 $R(\lambda)$。CARE

关键在于，这个失败率没法从别的指标反推。论文给了一条 identification（可识别性）结论：无论是两个版本平均成功率的差，还是逐步的动作一致性、模型的置信度，都不能还原 AIF。原因不复杂。加速版每一步都用了更便宜的近似动作，这些动作会把机器人带到和参考策略不同的状态上去。偏差一旦产生就沿整条轨迹累积，最后以一种面目全非的方式爆掉，比如整条 episode 半途卡死或者把东西放错位置。它不会在某一小步上留下一个"我这里出错了"的标记。

举个能想象的具体画面。任务是"把黑色碗放到盘子上"，参考策略每次都稳稳完成。换上一个剪枝强度更大的加速版，绝大部分初始场景里它照样能完成，但在一小撮场景里，它恰好剪掉了定位那只碗所必需的视觉 token，机械臂于是抓了个空。整条 episode 从头到尾没有任何一刻"看起来要失败"，它只是最后没完成。平均成功率把这些零星报废平摊掉了，只有把它和同一场景下的参考轨迹并排放在一起，你才看得见差别。

这也解释了为什么局部层面的检查会失效。你可能盯着一帧一帧的动作一致性，看到两者输出差不多，就以为没问题；也可能看着每步的置信度都不低。但一条 episode 是由几百步串起来的，任何一步的微小偏离都可能在几十步之后才显形成任务失败。局部指标看不到这种延迟引爆。

图注：加速引发的失败随加速强度递增。三块面板用的是同一批 evaluation unit，每个格子里并排放着参考策略与加速版两条轨迹；左侧"轻"档几乎全部一致，中间"中"档开始出现参考成功而加速失败的格子，右侧"重"档这类分歧明显变多。每块面板下方那个代表平均成功率的横条却几乎保持水平。

图上那条几乎不动的平均成功率条，就是问题本身。想抓住这种失败，唯一的单位是把同一个初始场景下的两条 episode 成对完整跑完，也就是 paired rollout。少跑一条不行，只比逐步输出也不行。

这时候回看 VLA-Cache 这类方案就很清楚了。它诚实地报告了平均成功率和延迟，也在真机上验证了提速确实存在，但它的评估里既没有配对失败，也没有任何"退化不超过多少"的界。它有没有悄悄把某些任务弄坏，报告本身回答不了。CARE 把这类方案统称为"无保证的加速"，意思是它们在提速上的证据是充分的，在安全上的证据是缺位的。

成对跑把实验量直接翻倍，费用先放在一边，它还带来一个更根本的疑问。就算你一直跑下去，你也回答不了"跑够了没有"，更给不出一句可验证的话，比如"这档加速的退化率不超过 5%"。要回答这个，得换一套统计工具。

怎么把『别闯祸』变成一句能验证的保证？

先建立一个容易接受的画面。你想上一档更快的加速方案，诉求其实很朴素：它弄坏的任务别超过一个你能接受的比例，比如 5%。CARE 做的事情，可以理解成给每一档加速方案做一次体检。体检项目是它在配对轨迹上的失败率，合格线是你设的预算 $\alpha$，最后发一张合格证。拿不到合格证的方案，不许上岗。这个体检的比喻不是随便打的，它逐条对得上 CARE 的三件套，后面会一一落实。

整套流程分四步走。CARE

第一步，按延迟给候选排序。在一个单独的 profiling 集上测每个候选加速器的推理延迟，从最快排到最慢。这个顺序不改变每个候选能否通过认证，却规定了优先测试及在通过者中选择最快者的顺序。这相当于把排队的队伍按"谁最快"先站好。

第二步，在配对轨迹上估计失败率，并给出有限样本的上界，这是最需要解释的一环。朴素做法是把校准集上观测到的失败率当成真值，问题在于它只是"这批样本里恰好失败了这么多次"，它和真实失败率之间还隔着一层抽样误差，校准集越小误差越大。CARE 借用的语言来自 conformal risk control（共形风险控制）：要保证的从来不是"观测失败率低于 $\alpha$"，而是真实期望风险满足

$$\mathbb{E}\bigl[L(\widehat\lambda)\bigr]\le\alpha$$

经验均值必须加上一个随样本量收缩的校正项，才配得上"保证"这两个字。校准集越大，校正项越小，结论越紧；但无论多小，它都保证了一个有限样本下成立的界，而不是靠数据多来兜底。CRC

图注：MS COCO 多标签任务上的风险控制实测。上半部是若干预测示例，正确类别为黑、误报为蓝、漏报为红；下半部直方图统计 1000 次随机数据划分下的漏检率，均值约 0.0996，略低于灰色虚线标出的 α=0.1，两侧都有划分落在线的附近。它展示的是"期望风险 ≤ α"的经验形态，而不是覆盖率证明。CRC

这张图值得停一下。风险控制保证的是期望层面，直方图里的划分分布在虚线两侧，但整体均值压在线的下方。它不是要求每一个校准集都达标，而是要"长期看平均不超标"。理解了这一点，就能接受后面那句看起来别扭的保证：它从不说"这档加速一定安全"，只说"它以很高概率安全"。

第三步，候选不止一个，筛选时必须防住"多试几次总能撞上一个看着合格"的隐患。候选越多，凭运气蒙混过关的概率越大。CARE 把"每个候选是否满足预算"当成一组假设检验，用 family-wise 错误率来控制，让每个候选分到的容错概率加起来不超过总预算，实现上就是每个候选拿 $\delta$ 除以候选个数。这套做法有现成的方法学语言，叫 Learn-then-Test。CRC

这一条不是理论洁癖。论文给了一组很有说服力的对照：在一个 10 候选的受控模拟里，不做 family 校正的选择器有 46.0% 的概率把超预算的策略推上线；换成做了 family 校正的检验，这个比例被压到 0.15% 以下。同样一批数据，差别只在有没有把"试了很多次"这件事算进错误预算里。

第四步也是最实际的一步，成本控制。观察损失函数的形状就会发现一件事：只要加速版自己成功了，$L$ 必定是 0，参考策略那条轨迹跑了也白跑。所以完全不必每个 unit 都成对跑，只在加速版失败时，才去补跑一次参考策略，并把结果缓存下来给其它候选共用。这个技巧叫 failure-triggered reference evaluation。论文证明它和穷举成对评估给出完全相同的损失序列与认证决定，只是省掉了大量不必要的参考执行。

把四步拼起来，就得到 CARE 的核心保证：

$$\Pr\bigl(R(\widehat\lambda)\ge\alpha\bigr)\le\delta$$

读法是这样的：以至少 $1-\delta$ 的概率，你最终选中的那档加速器，它的加速引发失败率不会超过预算 $\alpha$。这句式子里藏了两个角色分工明确的参数。$\alpha$ 管的是"能容忍多少退化"，是业务上界；$\delta$ 管的是"这个结论自己出错的概率"，是统计置信。它们不能混为一谈，也不能互相替代。

这个保证覆盖的对象也很重要。它保证的是"你选中的那个策略"，而不是某一份校准报告。如果所有候选都没通过，系统就退回原始的参考策略 $\pi_0$。宁可维持原速，也不上没证的岗。

图注：CARE 的完整四阶段流程。Inputs 给出参考策略、候选族与 profile / calibration 数据集；Profile candidates 按延迟从快到慢排序；CARE offline certification 在任务平衡的轮次里做配对 rollout，配合序贯检验与 family-wise 错误率控制，并只在候选失败时执行参考策略；Select & deploy 返回第一个、因此最快的通过认证的候选，若全部不通过则保留参考策略 $\pi_0$。CARE

流程里还有两个细节值得点出。一是"任务平衡的轮次"：校准集按任务分组，每一轮里每个任务出的 episode 数相同。这一条是为了防止早停时只看了几个容易的任务就误以为通过，异质任务下这一点尤其关键。二是"序贯检验"：CARE 不用一次性收满固定数量的样本再看结果，而是边走边看，证据够了就停。让"边看边停"依然合法的，是 e-process（证据过程）这一工具，它保证无论你在哪个由数据决定的时刻停下来，误判概率都不会被偷走。Anytime-Valid

用更直白的话说，这像一场可以随时收手的赌局：你每看一批数据就更新一次"该不该停"的判断，而规则本身保证你不会因为多看了几眼就把错误率悄悄抬高。这条性质正是你能在"还能继续跑"和"证据已经够了"之间自由切换的原因。

到这里，CARE 的三件套齐了：候选按延迟排序、在配对轨迹上估计风险并认证、不通过就回退参考策略。剩下唯一的问题是，成对跑本身很贵，这套流程在工程上到底用不用得起？

要验证就得成对跑——这笔成本真用得起吗？

CARE 把主实验放在 LIBERO 上。这是一个语言条件下的机器人操作基准，130 个任务按语义切成四个 suite：Spatial、Object、Goal 各 10 个任务，分别考察空间关系、物体识别与目标理解；LIBERO-100 则有 100 个任务，把三个轴混在一起考。之所以用四个 suite 而不是一个，是因为异质任务下"平均掩盖失败"这件事尤其危险，某一类任务被弄坏，很容易被别的任务的提升盖过去。LIBERO

图注：LIBERO 的四个任务 suite 总览。上半部是各 suite 的代表任务环境截图与标题，Spatial、Object、Goal 各含 10 个任务，LIBERO-100 含 100 个任务；下半部列出该基准关注的研究主题。任务在空间布局、物体类别与目标语义上的切分，正是 CARE 主实验选取它们的原因。LIBERO

第一组结果是每个 suite 各自认证出的加速器。注意这里没有"一个通吃的万能加速器"，而是逐个候选过检，谁先通过就用谁，因此四个 suite 的结果可以完全不同：

Suite	选中的加速器	加速比	保留的参考成功任务下界
Goal	FastV-25	9.02×	93.5%
Spatial	FastV-75	10.08×	95.7%
Object	Plain	9.56×	92.2%
Long	VLA-Cache	10.81×	85.8%

四个 suite 选的东西各不相同，有的选了视觉 token 剪枝强度更高的版本，有的选了最朴素的配置，最难的 Long 反而选了输入侧的缓存方案。这说明 CARE 不是在替某个加速器站台，而是在跑一道选型工序，答案由数据决定。整体读数落在 9.0 到 10.8 倍加速，而在 95% 同时置信下，至少 85.8% 的参考策略能解出的任务被保留下来。这里"同时置信"的意思是四个 suite 的结果一起算，不是各算各的。CARE

四个 suite 给出不同答案这件事，本身就说明同一档加速在不同任务分布上的退化风险并不一样。某一档加速在某个 suite 上是安全的，换到另一个 suite 未必成立。正因为风险随任务而变，一个笼统的"平均最优"选择在具体场景上未必可靠，而逐候选过检、逐场景认证才是稳妥做法。

第二组结果更接近论文的真正主张。研究者在每个 suite 的 500 条 episode 上做了一万次重采样，模拟不同选择器在同一个预算下会不会超标。预算收紧到 $\alpha=2.0%$ 时结果很惨烈：只挑最快候选的、只看平均成功率的，有 75.0% 的 trial 超标；用验证集调参但不做多重假设校正的，超标率 36.8%；用非配对方法直接比成功率的，67.1%。而 CARE 是 0.0%。需要说明的是，这组数字来自选择器行为的模拟，不是 LIBERO 上逐条配对统计的直接实测。

CARE 守得住预算，靠的不是平均成功率更漂亮，而是那句"不通过就退回参考策略"。别的选择器一旦选定就没有退路，运气不好就会把没证的加速器推上线；CARE 给了一个安全的默认值，标准就是把没把握的方案挡在门外。

成本方面，论文给的两条节省数字要分开看，它们场景不同。在主要实验的 8 个候选族上，序贯停止加上 failure-triggered，把总 rollout 从 9,000 压到 1,997，减少了 77.8%，墙钟时间从 38.6 小时降到 7.0 小时。在更大的 24 个配置候选族上，对比穷举评估的 25,000 次 rollout，CARE 只用 5,263 次，节省 78.9%。一个是 8 候选族、一个是 24 候选族，两条都对，但引用时不能混用。CARE

这些节省具体来自哪里也值得看一眼。序贯停止让注定通不过的候选尽早出局，把候选那部分的 rollout 从 8,000 压到 1,950；failure-triggered 则让参考策略只在必要时登场，把参考轨迹从 1,000 次压到 47 次。两个机制各管一头，合起来才有那个 77.8% 的缩减。换句话说，CARE 的省钱不是靠少跑几次，而是靠把每一次 rollout 都花在还可能有信息量的地方。

论文还做了两组横向扩展，验证这套认证不只对某一个模型、某一个领域成立。在 π0.5 这种流匹配策略上，认证选出的流步数缩减按 suite 不同而不同：Spatial 和 Object 选 2 步，Goal 选 4 步，最难的 Long 干脆让全部候选提前停、保留 10 步的参考策略。在 Crafter 这样的开放世界环境里，用 Qwen3.5-9B 与 Llama-3.1-8B 两个 LLM agent，Wood 任务都认证出了 3/3 的种子，Drink 任务认证出 2/3。跨加速机制、跨模型、跨任务域，CARE 都认证出了加速器。Crafter

这些结果加在一起，传递的信息其实很朴素：CARE 的价值不在"平均指标更漂亮"，而在"预算守得住、失败看得见"，而且认证成本已经被压到能接受的范围。它证明的不是某一档加速多强，而是"选哪一档、敢不敢用"这个问题第一次有了可验收的答案。

这篇论文改变了什么，又在什么前提下才成立？

回到 CARE 流程的最后一步。它返回的是"第一个、因此最快的通过认证的候选"，全部不通过就保留参考策略 $\pi_0$。把这句话从流程图里拎出来看，CARE 交付的其实不是某个加速比，而是一条部署决策规则：候选按快慢排队，谁能拿出合格证谁上岗，拿不出来就退回原策略。

它改变的是"加速"这件事的性质。过去的加速工作交出一个延迟数字或一个吞吐倍数，读者只能自己猜这些数字背后有没有隐藏的退化；CARE 把它变成在预算约束下可以比较、选择、验收的工程动作。方法学上，它把 conformal risk control、Learn-then-Test 与 anytime-valid 检验这三件工具第一次落到成对闭环的 VLA rollout 上。CARE 并不取代 OpenVLA-OFT 或 VLA-Cache，它站在它们之上回答一个不同的问题：这么多加速器里选哪一个，选了敢不敢用。

但它的成立是有前提的，而且前提很清楚。

第一，校准和部署必须同分布。CARE 的合格证是在校准集上算出来的，它保证的是同一分布下的部署风险。真实场景一旦漂移，旧证书就不再作数，得在新的场景上重算。好在序贯程序让重算这件事没那么贵，但"需要重算"本身是一条要记住的工程约束。

第二，成对评估的成本。论文里的成本数据来自仿真和重采样，真机上成对跑要贵得多。failure-triggered 这类机制能省下大部分参考策略的调用，但能省到什么程度，取决于候选失败得有多频繁。如果某一档加速几乎不会失败，省下来的就多；如果频繁失败，就省不了多少。

第三，候选空间有限。同一条 episode 内部自适应调整计算的加速器，目前还很难被塞进这个候选族里，论文把它列为开放方向。长期 rollout 与分布外场景也还没有答案。

把这些前提摆在一起，CARE 的价值就看得更清楚了。它给"加速"装上了一枚可以验收的旋钮，让每一档提速都要先过体检。而这枚旋钮要转得动，前提是你愿意为验证付一次成对的成本，并且相信手里的场景和证书签发时是同一个世界。

这套思路的可迁移性也值得一提。在失败时才去补证据、用风险上界来约束部署决定，这套机制本身并不依赖 VLA 或机器人这个具体场景。只要你能定义清楚什么叫失败、能做配对评估、并且接受同分布的前提，同样的框架就能搬到别的闭环系统上去。CARE 更像是把一套通用方法论第一次钉进机器人策略部署这个具体位置。Anytime-Valid

想深入可以读原文：CARE: Certifying Acceleration for Vision-Language-Action Inference — arXiv:2610.08917