为具身智能的“ImageNet 时刻”按下加速键：RLinf 为 BEHAVIOR 带来 25 倍系统优化#

最后更新：05/21/2026。

如果说大语言模型的爆发得益于互联网海量文本，那么具身智能（Embodied AI）要迎来自己的“ImageNet 时刻”，核心瓶颈则在于智能体在物理仿真环境中的交互效率。由李飞飞教授发起的 BEHAVIOR 基准涵盖上千种真实家庭长程任务，是训练通用家务机器人的重要练兵场；但在标准高保真配置下，它的环境交互链路非常沉重，默认端到端 rollout 延迟可达 1028.7 ms/step。

围绕强化学习 rollout 的真实数据流，我们对 BEHAVIOR / OmniGibson / Isaac Sim 的执行路径进行了系统级优化。通过功能瘦身、按需观测以及混合切分的流水线并行，我们最终将端到端延迟压缩到 41.2 ms/step，实现 25 倍 加速。相关优化已经作为默认配置合入 RLinf，并被 StanfordVL/BEHAVIOR-1K 上游仓库集成。

1. 背景：为什么要优化 BEHAVIOR 仿真器#

当前具身智能领域的难点，已经逐渐从“机械臂能不能完成单步动作”，转向“智能体能否在真实世界里持续完成一整件事”。这类任务通常是长程任务：它们不是一次抓取、一次放置，而是由多个相互依赖的子步骤构成。例如“打扫卧室”看似简单，背后却包含了物体识别、目标位置判断、导航、抓取、避障、放置等多个连续决策环节。

也正因为任务链条更长、状态变化更复杂，环境本身就成了训练系统中的关键基础设施。与 RoboTwin、LIBERO 等轻量环境相比， BEHAVIOR 提供了更完整的物理仿真、更复杂真实的场景结构，以及覆盖上千种家庭任务的数据规模，因此长期被视为具身智能领域极具代表性的“具身 ImageNet”。

图 1：BEHAVIOR 仿真器环境。

图 2：BEHAVIOR 仿真器场景。

BEHAVIOR 仿真器，提供高保真长程任务环境。

但高保真也带来了显著代价。我们在 AMD EPYC 7542 + NVIDIA RTX 4090D 24 GiB 的硬件配置上，以 OpenPI pi-05 为例进行分析，发现默认配置下：

端到端 rollout 平均耗时达到 1028.7 ms/step，约合 0.97 step/s；
模型 rollout 阶段 chunk step 的前向为 0.4-0.5 秒；若折算到单 step，则约为 12-16 ms，说明真正主导吞吐的仍然不是模型，而是环境；
单环境大约需要 10 个 CPU 核心 和 12 GiB 显存；
由于依赖完整图形渲染链路，BEHAVIOR 无法像纯计算任务那样轻松部署在 A100 这类计算卡上，通常需要 RTX 4090 这类图形卡。

图 3：RTX 4090 渲染效果示意图。

图 4：A100 渲染效果示意图。

RTX 4090 和 A100 渲染效果对比图。

这意味着我们不能简单地依靠“多开几个环境”来线性提升吞吐：CPU、显存和图形资源会同时上涨，很快触及硬件上限。因此，真正的问题不只是“环境慢”，而是默认执行路径并不是为大规模 RL rollout 设计的。

围绕这一点，我们试图回答三个问题：

BEHAVIOR 到底慢在哪里？ 是物理引擎本身慢，还是渲染、观测、线程与并行结构共同造成了系统瓶颈？
哪些开销是真正必要的？ 哪些只是延续了交互式仿真器的默认路径，在 RL rollout 中其实是无用功？
在不破坏仿真语义的前提下，能否重组 BEHAVIOR 的执行方式？ 让它真正成为可用于大规模训练的基础设施？

本节结论是：BEHAVIOR 的问题不是“不能并行”，而是它默认为单机交互式使用而设计，并不适合直接拿来做大规模强化学习 rollout。

2. 问题定位：BEHAVIOR 的慢本质上源自系统性瓶颈#

BEHAVIOR 的一次环境 step，并不是简单地把状态从 \(s_t\) 推进到 \(s_{t+1}\)。在底层，Isaac Sim 负责物理仿真、 GPU 渲染与 Omniverse 运行时；在上层，OmniGibson 封装了场景、机器人、传感器、任务逻辑与评测接口。因此，一次 step 实际上跨越了物理仿真、传感器渲染、观测打包、reward 计算和结束判定等完整链路。

我们使用 Tracy 对单步执行过程做了细粒度性能分析，发现端到端 1028 ms 的延迟并不是由某一个物理内核单点造成的，而是来自多个系统环节共同叠加。

图 5：BEHAVIOR 单动作处理时间线。

BEHAVIOR 环境处理单个动作的时间线。

2.1 观测链路过重#

BEHAVIOR / OmniGibson 默认支持丰富的多模态观测，例如 RGB、深度图、语义分割、实例分割等；但具体训练时，策略通常只消费其中一小部分。以 OpenPI pi-05 为例，模型真正需要的是 RGB 图像 + 本体感觉状态，而不是完整的图像标注链路。

换句话说，默认观测系统比模型的真实输入需求“重得多”。对 rollout 来说，大量观测生成工作都没有真正转化成训练收益。

2.2 离屏训练中仍保留了图形展示路径#

Isaac Sim 的设计初衷之一是支持交互式开发，因此会为机器人的每个相机保留独立视口（viewport），便于开发者实时查看画面、调试传感器和检查场景状态。但在无人值守的 rollout 阶段，我们真正需要的是模型输入，而不是屏幕上真的显示一个窗口。

性能分析和代码路径分析都表明，默认执行链路中仍然会为这条“显示路径”分配额外资源。它对训练几乎没有帮助，却会持续占用 GPU 显存与渲染时间。

图 6：Isaac Sim GUI 与 viewport 示意图。

Isaac Sim GUI 界面，视口能让开发者直观看到每一个相机的实时画面。

2.3 观测生成频率与策略消费频率不匹配#

主流具身模型并不一定在每一个仿真 step 都重新读取图像并前向一次。更常见的做法是按 action chunk 工作：模型一次生成多个连续动作，例如一次输出 32 个动作。

但在默认执行方式下，仿真器仍然会在动作块内的每一个 step 执行完整的渲染、拷贝与观测打包。对于这些根本不会进入模型前向的中间帧，这部分工作在本质上就是“做了但没人用”的无用功。

2.4 BEHAVIOR 的并行结构并不天然高效#

BEHAVIOR 既可以通过多进程扩展吞吐，也可以在单进程内部通过向量化环境同时管理多个环境实例；但这两种并行方式的收益特性并不相同：

多进程 可以带来接近线性的吞吐提升，但 CPU、显存与图形资源也会近似线性增长；
向量化环境 更省资源，但多个环境共享同一次全局物理 / 渲染 step，关键路径上仍存在明显串行或半串行段。

因此，问题不只是“开多少环境”，而是这些环境到底以什么粒度、什么方式被组织和推进。

本节结论是：BEHAVIOR 的性能问题，本质上是渲染、观测、线程与并行结构共同作用下的系统性瓶颈。

3. 系统级优化思路与实现：先减少无用工作，再重叠必要工作#

基于上面的分析，我们的优化目标不再是“让每个模块都更快一点”，而是围绕 rollout 的真实数据流去重排整个执行过程。整体思路可以概括为两句话：

把无用功裁掉：如果某条执行路径只对交互式展示有意义、对训练没有收益，就不应该继续留在离屏 rollout 的关键路径里；
把必要工作重叠起来：对于无法绕开的物理仿真、渲染和环境推进开销，不仅要优化其本身，还要让它与模型 rollout 更高效地流水化。

围绕这两个原则，我们最终形成了三条主线：功能瘦身、按需观测、混合切分的流水线并行。

3.1 直接有效的轻量优化：功能瘦身与按需观测#

前两类优化的共同特点是思路直接，而且都严格来自性能分析结果。

首先是 功能瘦身。既然离屏 rollout 仍然保留了图形展示路径、多余观测模态以及不适合多实例并发的默认线程策略，那么最直接的做法就是把这些训练不需要、但系统默认会做的事情裁掉。具体包括：

关闭离屏训练阶段无意义的 Omniverse 视口，只保留真正用于传感器输出的渲染链路；
按模型真实消费的输入，关闭深度图、语义分割等 rollout 不需要的多模态观测；
限制默认线程数，并启用 numba 即时编译缓存等配套优化，使系统从一开始就以“高吞吐训练环境”而不是“交互式调试仿真器”的方式运行。

其次是 按需观测。既然策略按动作块消费观测，那么动作块中间那些不会被模型使用的帧，就不应该继续触发完整的观测链路。因此我们保留了动作块内每一步的：

物理仿真；
reward 统计；
结束判定；

但只在动作块末尾、也就是策略真正需要新输入时才生成观测。这让观测生成频率与策略消费频率对齐，直接把一大块额外开销移出了关键路径。

图 7：按需观测后的动作块时间线。

裁剪之后，BEHAVIOR 环境处理一个动作块的时间线。最后一个动作需渲染，前面所有动作仅执行物理仿真。

前两类优化本质上都是“减法”：先删掉默认路径里的冗余，再谈更深层的执行重组。

3.2 深度优化：混合切分的流水线并行策略#

在做完“减法”之后，系统中依然存在大量必须执行的工作：物理仿真、渲染、环境同步等。如果这些工作与模型 rollout 仍然严格串行，整体吞吐上限依旧不会高。因此，我们进一步引入了 混合切分的流水线并行策略。

从系统视角出发，一个自然思路是让模型 rollout 与环境 step 流水化：当一部分环境正在执行当前动作块时，模型可以同时准备下一批 rollout。但真正的难点不是“要不要做流水线”，而是 BEHAVIOR 环境该怎么切分。

如果仅按进程切分，把若干环境进程分给阶段 A、另外一些分给阶段 B，表面上看很直接，但在 BEHAVIOR 中并不高效。原因在于：单个进程内部往往对应一个向量化环境，而向量化环境中的多个实例会共享同一次全局物理 / 渲染 step，因此关键路径依然存在明显的串行或半串行段。

图 8：BEHAVIOR 两层并行结构示意图。

BEHAVIOR 的两层并行结构示意图：进程级与向量化环境级。

这也是为什么我们最终采用的不是“纯进程切分”，而是一种 混合切分策略：

一方面利用 进程级并行 获得吞吐扩展能力；
另一方面将切分边界进一步下沉到 向量化环境内部的分片 / 切片粒度；
再把属于同一个流水线阶段的环境切片，映射到所有子进程中对应的向量化环境上。

这样一来，单个阶段不再“独占几个完整进程”，而是会跨所有子进程并行推进自己负责的那部分环境切片。其关键好处在于：

阶段内部不会再被某一个完整向量化环境的长串行段单独卡住；
环境资源的利用更均匀；
模型 forward 与环境 step 的重叠更加充分；
可以在不线性堆高资源成本的前提下，抬高系统吞吐上限。

图 9：流水线切分方案对比图。

流水线切分方案对比，以两进程、每进程四个向量化环境为例。

与此同时，切分更细并不意味着可以随意改变环境语义。对于 BEHAVIOR 这种高保真仿真器，物理时间尺度与任务语义必须保持一致。因此，在引入多个流水线阶段后，我们还会同步调整物理频率，使整体的物理时间尺度仍与原始配置保持一致，而不会因为阶段数增加而导致“仿真世界被加速”。

在 RLinf 中，这套策略已经封装为配置项，用户只需要设置：

env:
   pipeline_stage_num: 2

RLinf 就会自动在环境侧完成切片、调度以及与 rollout 的协同。

本节结论是：这次优化的关键，不是单独把某个模块做快，而是围绕强化学习 rollout 的真实数据流，先裁掉无用功，再用更贴合 BEHAVIOR 结构的方式重排必须执行的工作。

4. 性能评测：25 倍加速是怎么来的#

为了评估这套优化的实际效果，我们在一台配备 AMD EPYC 7542 32 核 CPU 和 4 × NVIDIA RTX 4090 D GPU 的服务器上进行了实验。模型选用当前在 BEHAVIOR 上表现优异的开放权重模型 OpenPI Comet 3B。由于 rollout 过程中仿真器耗时占比很高，我们采用分离式资源布局：

GPU 0 运行 OpenPI 模型；
GPU 1-3 各运行 2 个 BEHAVIOR 仿真器进程；
每个仿真器进程中运行 2 个向量化环境；
每个 rollout epoch 固定执行 2048 个 step。

4.1 端到端 rollout 耗时：从 1028.7 ms/step 到 41.2 ms/step#

我们首先关注最直接的指标：在同一套训练设置下，优化前后的端到端 rollout 延迟到底变化了多少。测量结果非常明确：优化前，rollout 每 step 平均耗时为 1028.7 ms/step；完成整套优化之后，这一数字下降到了 41.2 ms/step，总计获得了 25 倍 的加速。如果单看 BEHAVIOR 仿真器的耗时，优化前平均执行速度约为 473.4 ms/step；完成整套优化之后，这一数字下降到了 13.2 ms/step，总计获得了 36 倍 的加速。

这个结果的意义不只是“环境耗时缩短了”那么简单。对于具身强化学习而言，rollout 吞吐决定了训练系统能以多快的速度收集交互数据，也直接决定了模型更新的节奏、实验迭代效率以及单位时间内可覆盖的任务规模。经过我们的优化，训练系统的瓶颈也随之发生了根本变化：原本完全由环境主导的端到端时延，被大幅拉回到了一个模型、环境和调度都更均衡的区间。

图 10：各优化项消融结果（Rollout Epoch 总时间）。

图 11：各优化项消融结果（BEHAVIOR 平均 step 开销）。

各优化项的消融实验结果。左图代表每个 Rollout Epoch 的总时间开销，右图代表 BEHAVIOR 环境平均每 step 开销。

4.2 分项消融：性能收益是如何逐步叠加出来的#

为了回答“25 倍加速究竟来自哪里”，我们对三类优化做了分项消融。结果表明，这并不是某一个单独技巧带来的偶然收益，而是多层优化在同一条关键路径上逐步叠加的结果。

首先，关闭视口并裁掉多余模态（图中的 Slim）为端到端 rollout 性能带来了 4.8 倍 的加速。这个结果说明，第二节中识别出的图形界面展示路径和多模态观测冗余，确实是 rollout 阶段中非常真实的负担。对于交互式调试来说，这些功能当然有价值；但在离屏训练里，它们几乎只贡献成本，不贡献吞吐。

其次，跳过动作块中间观测（SkipObs）带来了 3.3 倍 的进一步提升。这一项的收益甚至高于很多直觉上的“底层优化”，原因在于它直接命中了默认执行路径中一块很大的无用功：动作块中间那些根本不会进入模型前向的帧，如果仍然照常渲染、获取观测、打包观测，就等于把昂贵的视觉链路白白跑了一遍。把这部分工作删掉之后，step 延迟会立刻出现非常明显的下降。

最后，流水线并行和调度优化（All）在前两类“减法”优化的基础上，又带来了 1.6 倍 的提升。这个数字虽然看起来不如前两项那样夸张，但它的意义同样重要：它说明在无用功被裁掉之后，系统剩余的主要瓶颈已经从“做了太多不该做的事”，转变为“必须做的事能否被更高效地组织起来”。也正因为如此，混合切分的流水线并行更像是在提升系统上限，而不是只做局部清理。

4.3 资源占用变化：不仅更快了，也更省了#

好的系统优化，不应该只是“用更多资源换更高吞吐”。幸运的是，我们看到的是吞吐与资源效率同时改善。

最明显的变化发生在 CPU 侧。优化前，单环境平均需要占用 10 个 CPU 核心；优化后，这个数字下降到了 2.1 个核心。这意味着我们不仅把单步延迟降下来了，还大幅降低了并行扩展时的 CPU 成本。对于多环境、多实验并发的训练场景而言，这一点极其关键，因为它直接决定了系统能否在同样硬件预算下承载更多 rollout worker。

GPU 侧的变化则更能说明“删掉无用功”这件事确实奏效了。由于多余的视口和观测模态被裁掉，减少了与渲染、标注器和缓冲区相关的内存开销，单仿真器实例的显存消耗从平均 11.5 GiB 下降到了平均 8.2 GiB。显存压力下降后，不仅单实例运行更轻，整个系统在多环境并发时的可扩展性也更好，OOM 发生频率显著下降。另外，模型 rollout 的 GPU 利用率上升了 69%，因为环境不再频繁阻塞模型前向，整个系统的流水化程度更高了。

4.4 一个开放的问题：最优资源布局#

在这轮优化之后，一个更有意思的问题开始浮现：当环境不再慢到“压死一切”之后，训练系统的最优配置其实变得更微妙了。

环境和模型的资源画像并不相同：

模型更偏向稳定占用 GPU 算力与显存；
环境同时依赖 CPU、图形渲染能力与 GPU 显存；
最优点会随着模型大小、动作块长度、环境数量，以及 CPU / GPU 比例变化而变化。

这意味着“最优资源布局”很可能不是一个固定答案，而是一类会随着配置变化的调度问题。例如：

小模型 + 大量环境时，环境侧资源可能更紧张；
模型变大、动作块变长之后，rollout 侧又可能重新成为瓶颈；
不同流水线阶段数、不同进程 / 向量化环境组合，也会把系统推到不同的平衡点。

从长期来看，这非常值得继续探索自动资源布局 / 自动调优方案，让系统根据模型、环境与硬件配置自动找到更优的执行布局。

5. 总结：高保真具身环境带来的启发#

这次优化工作的一个核心启发是：高保真仿真器的默认执行路径，往往并不是为大规模强化学习 rollout 设计的。 像 BEHAVIOR 这样的系统，需要同时服务于交互、展示、调试、评测与研究等多种用途，因此默认会保留许多对开发者友好、但对训练吞吐并不友好的路径。

真正要把它用于大规模训练，第一步不是盲目加机器，也不是急着去抠某个局部计算内核，而是先弄清楚：

哪些工作是训练真正需要的；
哪些只是历史上为了其他使用场景保留下来的附加成本；
哪些必要工作可以通过更贴合数据流的方式重排与重叠。

从这个角度看，本文的三类优化其实都围绕同一个原则展开：让执行路径服从真实数据流，而不是服从系统默认的组织方式。

另一个重要经验是，环境优化不只是环境本身的优化，而是训练系统整体的优化。在具身智能任务里，环境、模型、资源布局、流水线与调度之间的耦合程度，远高于许多传统基准。单一瓶颈缓解之后，更高层次的协同调度问题才会真正浮现出来。

目前，相关性能补丁已经合并到 RLinf 与 StanfordVL/BEHAVIOR-1K 上游仓库。对于希望直接上手 BEHAVIOR 的开发者， RLinf 已经提供了一套无需从零改环境即可使用的成熟方案。我们也希望这项工作不仅服务于自身训练系统，也能为更广泛的具身智能社区提供一个参考：在充分理解强化学习数据流与底层系统结构之后，复杂的物理仿真世界同样可以被重构为高效的算力基础设施。

图片素材：BEHAVIOR-1K。