面向工业操作的具身机器人
尽管任务目标各不相同，这些应用却有着共同的执行模式：机器人在固定工作站上反复执行相似任务，变化主要来自目标物体及其位置。此类场景也对策略的响应速度与可靠性提出了严格要求。
VLA 中的双阶段推理
我们聚焦于将视觉语言模型（VLM）与扩散动作专家结合的 VLA 模型，这是近期多数 VLA 模型采用的架构。
视觉 Transformer（ViT）嵌入阶段会将观测和语言指令转换为输入嵌入。视觉观测通常由机器人摄像头拍摄的图像组成。随后，推理进入两个占据大部分延迟的核心阶段。
首先，VLM 对 ViT 嵌入执行预填充（prefill），计算用于生成动作的视觉特征。其次，动作专家从一个带噪动作样本出发，通过多次去噪迭代对其进行细化，最终生成一个动作块。
去噪步跳过及其在 VLA 中的局限
然而，这些方法并不适合直接迁移到具身模型推理中，因为两种复用方式都以去噪步为粒度。整步复用依赖相邻步骤产生几乎相同的输出；对于文本到图像和文本到视频模型而言，这种情况较为常见，因为它们通常运行 20–50 步。
VLA 模型使用的步数要少得多。例如，GR00T 仅使用四步。因此，每一步都会显著改变动作块；跳过任何一步都会丢失后续步骤无法弥补的细化过程。
具身工作负载特征分析
为了寻找加速具身推理的机会，我们从执行和模型两个角度分析 VLA 工作负载。首先，我们定位 VLM 预填充和动作去噪中的性能瓶颈；随后考察不同执行之间的观测与轨迹相似性；最后研究这种相似性如何延伸到模型内部状态，具体包括 VLM 状态以及去噪过程中的神经元贡献。
重复任务中的轨迹相似性
在工业装配线场景中，机器人会在相对稳定的工作空间内，使用有限的一组物体反复执行同一任务。然而，光照、桌面纹理和物体姿态的变化，可能同时改变观测结果和所需动作。因此，我们考察在这些变化存在时，动作轨迹是否仍能在不同执行之间保持相似。
动作轨迹是 VLA 可观察到的输出：它是按时间排列的一系列机器人动作，在三维空间中描绘出连续路径。为检验环境变化下有用的重复性是否仍然存在，我们在仿真中对这些因素进行建模。在代表性任务中，双臂机器人抓起两只饮料瓶，并将其移动到桌面上方指定的位置。我们在不同执行之间改变瓶子的初始位置和光照条件，然后将当前执行与同一任务的一次参考执行进行比较。
当前执行和参考执行都在四步推理后成功且稳定地到达目标位置。尽管瓶子的初始位置和光照不同，两条机械臂的末端执行器轨迹以及摄像头视角仍高度一致，路径余弦相似度分别达到左臂 0.995 和右臂 0.994。
VLM 状态相似性与视觉 Token 覆盖率
我们在 VLM 的每一层比较当前执行和参考执行的 MLP 输入与输出，发现输入的余弦相似度最高可达 98.5%，输出最高可达 81.0%。这种相似性促使我们进一步考察剩余输出变化如何分布在视觉 Token 上，并研究 MLP 输入差异能否识别出造成大部分变化的 Token。
瓶子移动任务中，被选中的区域表明，重要图像块主要集中在瓶子、夹爪和机械臂周围；背景区域中也有少量图像块，用于编码场景上下文。随着操作推进，这些区域的位置会在不同动作块之间发生变化，因此需要在每次策略调用时重新选择，而不能使用固定的空间掩码。
去噪神经元贡献与重叠
当前执行与参考执行具有相似轨迹，这促使我们考察它们的动作去噪过程是否也具有相似的内部激活。延续对 VLM 状态的分析，我们首先比较动作去噪的输入和输出。尽管在相同随机种子下初始噪声相同，生成的动作块相似度却只有 69%。
这一差异促使我们探索去噪过程中的细粒度复用，而不是直接复用参考动作。因此，我们考察每个去噪 FFN 内部的神经元贡献如何分布，以及当前执行与参考执行之间的贡献模式是否相似。
对于每个去噪步骤 t 和层 l，我们使用贡献分数来量化每个神经元对 FFN 输出的贡献。
贡献分数衡量在给定去噪步骤和层中，每个神经元对 FFN 输出的影响程度。
保留选定比例的神经元即可覆盖总贡献分数的 84.4%。
设计
rMuscle 结合了两种互补机制：用于选择性重计算的双阶段缓存，以及用于低开销访问和存储的缓存管理。
双阶段缓存使用 Context Cache 加速计算密集型的 VLM 预填充，使用 Action Cache 加速内存密集型的动作去噪。Context Cache 会复用相似视觉 Token 的 FFN 输出，并重新计算输入发生显著变化的 Token。在动作去噪期间，相似执行往往会激活重叠的重要神经元集合。Action Cache 利用这些参考激活模式，选择需要计算的神经元以及需要加载的权重。
缓存管理从共享库中向双阶段缓存提供参考 FFN 输入、输出和神经元掩码。为降低内存开销，该库只保留紧凑的参考输入和神经元掩码，仅在某个参考很可能被检索时才重建扩展后的 FFN 状态。参考项依据视觉上下文和机器人状态历史进行选择。系统还使用滑动式 GPU 工作集限制驻留内存，并结合重建预算限制重建工作量。
缓存管理
缓存管理在限制 GPU 驻留量和重建工作量的同时，为双阶段缓存提供相关参考数据。它结合异步在线重建、上下文感知检索，以及由时间局部性引导的滑动窗口预取。
对于所有任务中的每个参考项，扩展后的 VLM 状态过于庞大，无法全部存储。以三视角输入为例，17 个 FFN 层中的每一层都保留一对 BF16 输入和输出张量，每次策略调用约占 107 MB。一个包含 40 次策略调用的回合因此需要约 4.28 GB 的中间状态。只存储紧凑输入可以避免这种膨胀，但同步重建状态会将密集 VLM 计算重新置于推理关键路径上。
rMuscle 转而在机器人执行物理动作期间重建参考项。存储库保留参考模型输入和离线生成的神经元掩码。在一次执行窗口内，GPU 获取即将到来的候选位置的输入，并密集运行 VLM 预填充，以准备其 FFN 状态。由于神经元掩码已离线计算，重建过程无需再次运行动作去噪。
只有活动工作集会在 GPU 上保存扩展后的 FFN 状态。这种组织方式减少了持久化的主机和磁盘存储，但不会降低单个重建条目的 GPU 占用。候选位置由下文所述的预取策略确定。
实现
本节介绍 rMuscle 如何离线构建缓存，以及如何准备和检索缓存参考项来加速在线推理。
评估
我们通过三个主要问题评估 rMuscle：
- 它能带来多大加速？每项优化分别贡献多少？
- 在不同任务中，它能否保持任务成功率？缓存配置会产生怎样的影响？
- 它会带来多少额外内存开销？
推理性能
与去噪步跳过方法相比，rMuscle 同时加速 VLM 预填充和动作去噪，从而实现推理加速。尽管步跳过方法可以通过激进地跳过去噪步骤，在去噪阶段取得更高加速比，但代价是任务成功率下降。
内存开销
我们量化 rMuscle 的 CPU 缓存占用，并将其 GPU 内存使用量与原始执行进行比较。为体现更困难任务所需参考数据的增加，我们将每个任务的缓存容量从 8 个参考回合中的 200 个条目增加到 32 个参考回合中的 800 个条目，同时将候选窗口从较小的初始窗口扩大到较大的最终窗口。
在 RTX 4090 上，CPU 缓存占用 32 GB 主机内存的 3.7–14.9%。GPU 内存从原始执行的 8.4 GB 增加到 9.4–11.4 GB，占用率增幅不到 13%。
在 CPU 和 GPU 共享 128 GB 统一内存的 Jetson Thor 上，占用率从 6.6% 增加到 8.3–12.6%。总体而言，rMuscle 支持最多 800 个缓存推理条目；在 RTX 4090 上仅需额外不到 3 GB GPU 内存，在 Jetson Thor 上统一内存占用率最多额外增加 6.0 个百分点。
消融实验
我们在 RoboTwin 上使用所评估的 VLA 模型配置，评估缓存贡献以及质量与延迟之间的权衡。
缓存贡献
我们在 RTX 4090 和 Jetson Thor 上比较 FlashRT、仅使用 Context Cache、仅使用 Action Cache，以及完整系统，以分离各缓存对延迟的贡献。
参考存储库
不使用 Cache Repository 的 rMuscle 变体，会使用同一回合中的上一次策略调用作为参考，而不是从存储库中检索参考项。在延迟相近的情况下，默认配置的成功率为 35.2%，而不使用参考存储库时为 25.9%。
这些结果凸显了来自先前执行的参考项对于保持策略质量的价值；同时，相近的延迟表明缓存管理几乎不会给关键路径增加额外开销。
质量—性能权衡
我们调整 rMuscle 的视觉 Token 重计算比例和神经元比例。在 RTX 4090 上，我们比较 Fast、Default 和 Slow 配置，以及 Vanilla、DP-Cache、NIRVANA 和上述存储库消融版本。
与 Fast 相比，Default 将成功率从 23.0% 提高到 35.2%，额外延迟为 4.9 ms。Default 达到与 Vanilla 相同的成功率，而 Slow 的成功率略高。相较 Vanilla，它们的延迟分别降低 10.5 ms 和 4.5 ms。
这些结果实现了我们的设计目标：在降低推理延迟的同时保持策略质量。与性能分析结果一致，Default 在不牺牲成功率的前提下提供了最低延迟。
相关工作
VLA-Perf 从分析角度探讨架构、硬件部署位置和服务方式如何影响推理延迟；一项跨 XPU 研究则测量异构加速器上的能耗与延迟，并在 LIBERO 和实体 Franka 机器人上验证 DP-Cache。
讨论
策略延迟是一个动作块的最后一个动作与下一个动作块的第一个动作之间的间隔，而动作块内部的动作以 20–30 Hz 的频率执行。随着策略调用频率接近执行频率，动作块之间的衔接会更加平滑，机器人也能更频繁地重新观测环境并做出反应。
因此，更低的推理延迟能够提升响应速度、运动平滑性和任务吞吐量。由于每个回合需要 4–40 次策略调用，降低单次调用延迟可以缩短整体任务周期，使固定工作站上的机器人在相同硬件上每小时完成更多任务。
常见问题
什么是 rMuscle？ rMuscle 是一种缓存系统，用于加速重复具身机器人任务中的视觉—语言—动作模型推理。
rMuscle 的两个主要组件是什么？ 它使用 Context Cache 加速 VLM 预填充，使用 Action Cache 加速动作去噪。
rMuscle 如何保持任务质量？ 它只重新计算发生变化的视觉 Token 和重要的去噪神经元，同时从先前执行中检索参考项。
rMuscle 会带来多少内存开销？ 在 RTX 4090 上，它额外使用不到 3 GB GPU 内存；在所评估的缓存容量下，还会占用 32 GB 主机内存的 3.7–14.9%。