如果说大语言模型的爆发得益于互联网上海量的文本，那么具身智能（Embodied AI）要迎来自己的"ImageNet时刻"，核心瓶颈则在于智能体在物理仿真环境中的交互效率。
由计算机视觉泰斗李飞飞教授 发起的 BEHAVIOR 基准，正是被整个行业寄予厚望的"具身 ImageNet"。它涵盖了上千种真实的家庭长程任务（如打扫卧室、做饭等），是训练真正能干家务的机器人的顶尖练兵场。然而，理想很丰满，现实却很"卡"------由于追求极高的物理与视觉逼真度，BEHAVIOR 仿真环境运行速度极慢。 在标准硬件上，跑一步（step）需要 1028 毫秒，且大量时间被复杂的观测渲染、图像语义分割等冗余的操作所占据。这种"蜗牛爬"的速度，严重阻碍了全球研究者在复杂长程任务上的模型开发。
为了打破这一僵局，我们对 BEHAVIOR 进行了极致的系统级性能优化 。通过功能裁剪、观测重构和高效流水线调度，成功将端到端延迟从 1028 ms/step 缩短至 41 ms/step ，实现了 25 倍的加速。
目前，这一成果已作为默认配置合入无问芯穹与清华大学联合研发的 RLinf 强化学习框架 ，并被 StanfordVL/BEHAVIOR-1K 官方上游仓库正式集成。我们正在用底层系统的颠覆性加速，亲手拉快具身智能"ImageNet时刻"的进度条。
GitHub链接：https://github.com/RLinf/RLinf
中文文档链接：https://rlinf.readthedocs.io/zh-cn/latest/rst_source/examples/embodied/behavior.html
英文文档链接：https://rlinf.readthedocs.io/en/latest/rst_source/examples/embodied/behavior.html
01 背景：为什么要优化 BEHAVIOR 仿真器
目前，具身行业的痛点问题已经从"机械臂能不能完成单步动作"逐渐转向**"智能体能否在真实世界里持续完成一整件事"**。这类任务通常被称为长程任务：不是一次抓取、一次物体摆放，而是由多个相互依赖的子步骤组成。例如"打扫卧室"这个看似简单的任务，背后就包括识别物品、判断它们分别应该被放回哪里、移动到对应位置抓取和放置、避开途中障碍物等诸多步骤。
也正因为任务链条更长、状态变化更复杂，训练和评测这类能力时，环境本身就成了关键基础设施。 由李飞飞教授发起的 BEHAVIOR 具身任务基准包含了一个有代表性的仿真环境：与 RoboTwin、LIBERO 等轻量环境相比，这套系统提供了更完整的物理仿真、更复杂真实的场景结构，并且包含了 1000 个家庭场景中的长程任务数据。
BEHAVIOR 仿真器，提供高保真长程任务环境
但其代价也同样明显，更高保真的渲染、更完整的任务和物理交互，都会直接反映到更高的训练开销上。 我们使用 AMD EPYC 7542 + NVIDIA RTX 4090D 24 GiB 的硬件配置，使用 BEHAVIOR 仿真器的默认配置训练一个典型的具身 3B 参数模型 OpenPI pi-05，发现端到端 rollout 耗时竟长达 1028 ms/step ，折合约 0.97 step/s 。相比之下，pi-05 在 rollout 阶段每个 step 的平均前向耗时只有 14-17 毫秒，这意味着真正主导训练吞吐的，已经不再是模型，而是环境本身。
除了慢，BEHAVIOR 还很"贵"。 在默认配置下，单环境大约会占用 10 个 CPU 核心 和 12 GiB 显存。更麻烦的是，这类环境并不是随便找一张 GPU 就能跑：由于它依赖完整的图形渲染链路，实际运行时无法部署在 A100 这类计算卡上，只能部署在 RTX 4090 这类图形卡上，而图形卡的显存又远小于计算卡。因此，我们无法简单地通过"多开几个环境"来提升并行数：CPU、显存和调度开销都会同步上升，很快就触达硬件上限。
RTX 4090 和 A100 渲染效果对比图
基于以上背景，本文希望回答三个问题：
第一，BEHAVIOR 到底慢在哪里：是物理引擎本身慢，还是渲染、观测、线程和并行结构共同造成了系统级瓶颈？
第二，哪些开销是真正必要的，哪些只是沿用了交互式仿真器的默认路径，因此在 RL rollout 阶段其实属于"无用功"？
第三，在不破坏仿真语义的前提下，我们能否重新组织 BEHAVIOR 的执行方式，把这个高保真环境真正变成一个可用于大规模训练的基础设施？
本节结论
BEHAVIOR 的问题不是"不能并行"，而是它默认为了单机单实例而设计，并不适合大规模 RL rollout。只要从 rollout 的真实数据流出发，重新审视哪些步骤必须保留、哪些步骤可以裁剪、哪些步骤可以重叠，就有机会在不牺牲环境价值的前提下，把系统吞吐显著提起来。
02 问题定位：BEHAVIOR 的慢本质上是源自系统性瓶颈
BEHAVIOR 是一个复杂的具身智能仿真环境，它的一次环境 step 会跨越多个系统组件。底层的 Isaac Sim 负责物理仿真、GPU 渲染以及 Omniverse 运行时；上层的 OmniGibson 则在此基础上封装场景、机器人、传感器、任务逻辑与评测接口。也就是说，对 BEHAVIOR 而言，一次 step 并不只是把状态从 推进到
，而是同时包含物理仿真、传感器渲染、观测打包，以及任务级别的 reward / 结束判定等完整链路；任何一个环节的额外开销，最终都会体现在端到端 rollout 吞吐上。
为了弄清楚 1028 ms 的 step 延迟到底耗在了哪里，我们使用 Tracy 对单步执行过程做了细粒度性能分析，时间线如图所示。一个非常直接的结论是：BEHAVIOR 的 step 时间被分散在渲染、观测生成、CPU 调度和环境组织方式等多个环节，并不是因为某一个物理仿真内核特别耗时。更重要的是，我们看到其中相当一部分开销，对于交互式仿真是合理的，但对于大规模强化学习 rollout 来说其实是冗余的。
BEHAVIOR 环境处理单个动作的时间线
第一类冗余，来自观测链路默认比模型实际需要的更重。BEHAVIOR / OmniGibson 支持丰富的多模态观测，包括 RGB、深度信息、语义分割、实例分割等；但在具体训练中，策略往往只消费其中的一小部分。例如，OpenPi pi-05 模型只需消费 RGB 图片加本体感觉状态，而无需消费上图中耗时占比72%的图像语义分割结果。
第二类冗余，来自离屏训练中仍然存在的图形界面展示路径。Isaac Sim 设计之初其实是针对交互式使用场景，因此对于机器人的每一个相机都配备了一个独立的视口（viewport）：开发者可以实时看到相机画面、调试场景、检查传感器输出。但在无人值守的 rollout 阶段，我们真正需要的是最终送入模型的观测，而不是屏幕上是否真的显示了一个窗口。性能分析和代码路径分析都表明，默认执行链路中仍然会为这条"显示路径"分配额外资源，这部分开销对训练本身并没有收益。
Isaac Sim GUI 界面，视口能让开发者直观看到每一个相机的实时画面
第三类冗余，来自观测生成频率和策略消费频率不匹配。主流的具身模型并不是每一个仿真 step 都重新读取图像并重新前向，而是按动作块获取观测输入并输出动作，例如一次输出 32 个动作。可在默认执行方式下，仿真器会每一步都完成渲染、拷贝并打包观测。对动作块中间那些根本不会进入模型前向的帧而言，这部分工作在严格意义上就是"做了但没人用"的无用功。
最后，还有一个容易被忽略的结构性事实：BEHAVIOR 的并行并不等于"天然高效并行"。它既可以通过多进程扩展吞吐，也可以在单进程内通过 VectorEnvironment 向量化环境接口同时管理多个环境，但这两种并行的收益特性并不相同。多进程可以带来接近线性的吞吐提升，但 CPU、显存和图形资源也会近似线性上涨；向量化环境更节省资源，但由于多个环境会共享同一次全局物理 / 渲染 step，关键路径中仍然存在明显的串行或半串行段，收益远低于理想线性。也就是说，问题并不只是"开多少环境"，而是这些环境到底以什么方式被组织和推进。
把这些性能分析结果放在一起看，问题就很清楚了：BEHAVIOR 慢，不是因为某个模块单点性能差，而是因为它的默认执行路径同时服务于交互、展示、调试和研究等多种场景，因此带上了大量对强化学习 rollout 并不友好的历史包袱。
本节结论
BEHAVIOR 的性能问题，本质上是渲染、观测、线程与并行结构共同作用下的系统瓶颈。
03 系统级优化思路与实现：先减少无用工作，再重叠必要工作
因此，我们的优化目标就不再是简单地"让每个环节都更快一点"，而是围绕 rollout 的真实数据流重新组织整个执行过程。整套优化其实可以概括为两句话：
第一，把无用功裁掉：如果某条执行路径只对交互式展示有意义、对训练没有收益，那它就不应该继续留在离屏 rollout 的关键路径里。
第二，把必要工作重叠起来：对于那些确实无法绕开的物理仿真、渲染和环境推进开销，关键不只是单独优化它们，而是要让它们与模型 rollout 更高效地流水化。
围绕这两个原则，我们最终形成了三条主线：功能瘦身、按需观测，以及混合切分的流水线并行。我们在 RLinf 中实现了对应的优化，默认开启，开箱即用。
3.1 直接有效的轻量优化：功能瘦身与按需观测
前两类优化的共同点是思路直接，而且都能自然地从第二节的性能分析结果中推出来。既然我们已经确认离屏 rollout 中仍然保留了图形界面展示路径、多余观测模态以及不适合多实例并发的默认线程策略，那么最直接的做法就是把这些"训练不需要、但系统默认会做"的事情裁掉。具体来说，我们关闭了离屏训练中无意义的 Omniverse 视口，只保留真正用于传感器输出的渲染链路；同时按照模型真实消费的输入，关闭深度图、语义分割等 rollout 不需要的多模态观测。此外，我们还限制了默认线程数，并启用了 numba 即时编译缓存等配套优化，让系统从一开始就成为一个面向高吞吐训练的环境，而不是一个面向单机交互调试的仿真器。
与功能瘦身类似，跳过动作块中间观测也是一个"顺着数据流去删冗余"的优化。我们的策略并不是每一个仿真 step 都重新读取图像并重新前向，而是按动作块输出动作，例如一次输出 32 个动作。换句话说，模型真正需要新观测的频率，本来就低于环境物理仿真的频率。如果此时仍然让仿真器在动作块内的每一步都执行渲染、获取观测和观测打包，那么动作块中间大量观测其实只是被生成出来，又立刻被丢掉。针对这一点，我们保留了动作块内每一步的物理仿真、reward 统计以及结束判定，但只在动作块末尾，即策略真正需要输入更新时才生成观测。这样做，我们让 观测生成频率能够和策略消费频率对齐，从而把一大块额外开销从关键路径里移除出去。
裁剪之后，BEHAVIOR 环境处理一个动作块的时间线。 最后一个动作需渲染，前面所有动作仅执行物理仿真
不过，前两类优化虽然重要，但它们更多是在做"减法"。它们能显著减少默认路径中的冗余，却不能彻底解决另一个更结构性的问题：**即便把无用功都裁掉了，BEHAVIOR 里依然存在大量必须执行的物理仿真、渲染和环境同步工作，而这些工作如果仍然与模型 rollout 串行排布，系统吞吐上限依旧不高。**也正因为如此，我们引入第三个优化：混合切分的流水线并行策略。
3.2 深度优化：混合切分的流水线并行策略
从系统角度看，一个很自然的想法是把模型 rollout 和环境 step 流水化：当一部分环境在执行当前动作块的 step 时，模型可以同时准备下一批 rollout。这个想法本身并不新鲜，但在 BEHAVIOR 里，真正的难点从来不是"要不要做流水线并行"，而是环境到底该怎么切分。
如果把 BEHAVIOR 当作一个普通的批量环境，最直接的做法当然是按进程分组：把若干个环境进程分给流水线阶段 A，再把另外一些进程分给流水线阶段 B，让不同阶段交替推进。问题在于，**这种切法在 BEHAVIOR 上并不高效。**原因是单个进程内部往往对应一个向量化环境，而向量化环境里的多个环境并不是彼此完全独立地推进；它们会共享同一次全局物理仿真 / 渲染 step，因此关键路径中天然带有明显的串行或半串行段。于是，哪怕我们在外面把进程分成了好几组，阶段内部仍然被这些共享的串行 step 卡住，最终导致环境无法使用所有计算资源，吞吐量直接减半。更糟糕的是，如果想靠继续增加进程数来缓解这个问题，CPU、显存和图形资源又会迅速线性上涨，回到第二节提到的"简单扩容不可持续"的老问题上。
BEHAVIOR 的两层并行结构示意图：进程级与向量化环境级
这也是为什么我们最后采用的不是"纯进程切分"，而是一种混合切分 策略：既利用进程级并行带来的吞吐扩展能力，又把切分边界进一步下沉到向量化环境内部的分片 / 切片粒度。换句话说，**我们不再把一个向量化环境看成不可再分的黑盒，而是把它视为可切分、可按需组织的结构。随后，再把属于同一个流水线阶段的环境切片，映射到所有子进程中对应的向量化环境上。**这样一来，单个阶段不再只"独占几个完整进程"，而是会跨所有子进程并行推进自己负责的那一部分向量化环境。
流水线切分方案对比，以两进程、每进程四个向量化环境为例
这种设计的关键好处在于，它更贴合 BEHAVIOR 自身的并行结构。由于每个阶段的工作都会分配到所有子进程上，阶段内部不再被某一个完整向量化环境的长串行段单独卡死，而是能够更均匀地利用各个子进程的并行能力。与此同时，模型 forward 与环境 step 的重叠也变得更充分：环境不再以"整个进程"为粒度等待，而是以更细的切片粒度和模型前向交错执行。你可以把它理解为：我们不是把几个"很重的环境盒子"简单排成两列轮流跑，而是先把盒子内部真正能并行的部分拆出来，再围绕这些部分去设计流水线。
但切得更细并不意味着可以随意改环境语义。对于 BEHAVIOR 这种高保真仿真器，训练吞吐很重要，但物理时间尺度和任务语义同样不能被破坏。因此，**在引入多流水线阶段后，我们还需要同步处理物理频率的一致性问题：**如果不同流水线阶段都会独立推进各自动作块内的 step，那么从系统角度看，有效物理仿真速度就会和流水线深度成正比。为了避免这一点，我们在阶段数增加时同步调整物理频率，使得整体的物理时间尺度仍然保持与原始配置一致。
从工程落地角度看，这套流水线并行也已经封装进 RLinf 配置中：用户无需手工拼接多进程逻辑，只要设置 pipeline_stage_num 参数，RLinf 就会在环境侧自动完成切片、调度和与 rollout 的协同。
本节结论
这次优化的关键，不是单独把某个模块做快，而是围绕强化学习 rollout 的真实数据流，先删掉默认路径中的无用功，再用更贴合 BEHAVIOR 结构的方式重排那些必须执行的工作。
04 性能评测：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 ms/step 到 41 ms/step
我们首先关心的是最直接的端到端指标：在同一套训练设置下，优化前后的端到端 rollout 每个 step 的延迟到底变化了多少。测量结果非常明确：优化前，rollout 每 step 平均耗时为 1028.7 ms/step ；完成整套优化之后，这一数字下降到了 41.2 ms/step ，总计获得了 25 倍的加速。如果单看 BEHAVIOR 仿真器的耗时，优化前平均执行速度约为 473.4 ms/step ；完成整套优化之后，这一数字下降到了 13.2 ms/step ，总计获得了 36 倍的加速。
这个结果的意义不只是"环境耗时缩短了"那么简单。对于具身强化学习而言，rollout 吞吐决定了训练系统能以多快的速度收集交互数据，也直接决定了模型更新的节奏、实验迭代效率以及单位时间内可覆盖的任务规模。经过我们的优化，训练系统的瓶颈也随之发生了根本变化：原本完全由环境主导的端到端时延，被大幅拉回到了一个模型、环境和调度都更均衡的区间。
各优化项的消融实验结果
左图代表每个 Rollout Epoch 的总时间开销，右图代表 BEHAVIOR 环境平均每 step 开销
4.2 分项消融：性能收益是如何逐步叠加出来的
为了回答"25 倍加速究竟来自哪里"，我们对三类优化做了分项消融。结果表明，这并不是某一个单独技巧带来的偶然收益，而是多层优化在同一条关键路径上逐步叠加的结果。
首先，关闭视口并裁掉多余模态 （图中的Slim）为端到端 rollout 性能带来了 4.8 倍 的加速。这个结果说明，第二节中识别出的图形界面展示路径和多模态观测冗余，确实是 rollout 阶段中非常真实的负担。对于交互式调试来说，这些功能当然有价值；但在离屏训练里，它们几乎只贡献成本，不贡献吞吐。
其次，跳过动作块中间观测 （SkipObs）带来了 3.3 倍 的进一步提升。这一项的收益甚至高于很多直觉上的"底层优化"，原因在于它直接命中了默认执行路径中一块很大的无用功：动作块中间那些根本不会进入模型前向的帧，如果仍然照常渲染、获取观测、打包观测，就等于把昂贵的视觉链路白白跑了一遍。把这部分工作删掉之后，step 延迟会立刻出现非常明显的下降。
最后，流水线并行和调度优化 （All）在前两类"减法"优化的基础上，又带来了 1.6 倍 的提升。这个数字虽然看起来不如前两项那样夸张，但它的意义同样重要：它说明在无用功被裁掉之后，系统剩余的主要瓶颈已经从"做了太多不该做的事"，转变为"必须做的事能否被更高效地组织起来"。也正因为如此，混合切分的流水线并行更像是在提升系统上限，而不是只做局部清理。
4.3 资源占用变化：不仅更快了，也更省了
除了 step 的耗时下降之外，资源占用的变化也同样重要。因为如果一个优化只是"更快"，但代价是吃掉更多 CPU、更多显存或者更多 GPU 时间，那么它对大规模训练的实际价值会大打折扣。幸运的是，我们看到的结果并不是"以资源换吞吐"，而是吞吐和资源效率同时改善。
最明显的变化发生在 CPU 侧。优化前，单环境平均需要占用 10 个 CPU 核心 ；优化后，这个数字下降到了 2.1 个核心。这意味着我们不仅把单步延迟降下来了，还大幅降低了并行扩展时的 CPU 成本。对于多环境、多实验并发的训练场景而言，这一点极其关键，因为它直接决定了系统能否在同样硬件预算下承载更多 rollout worker。
GPU 侧的变化则更能说明"删掉无用功"这件事确实奏效了。由于多余的视口和观测模态被裁掉，减少了与渲染、标注器和缓冲区相关的内存开销，单仿真器实例的显存消耗从平均 11.5 GiB 下降到了平均 8.2 GiB 。显存压力下降后，不仅单实例运行更轻，整个系统在多环境并发时的可扩展性也更好，OOM 发生频率显著下降。另外，模型 rollout 的 GPU 利用率上升了 69%，因为环境不再频繁阻塞模型前向，整个系统的流水化程度更高了。
4.4 一个开放的问题：最优资源布局
经过这轮优化之后，一个很有意思的问题开始浮现出来：当环境不再慢到压死一切之后，训练系统的最优配置其实变得更微妙了。环境和模型的资源画像并不相同：模型更偏向于稳定占用算力和显存，环境则同时依赖 CPU、图形渲染能力和 GPU 显存；而且这种画像还会随着模型大小、动作块长度、环境数量以及 CPU / GPU 比例的变化而变化。
这意味着，最优资源布局很可能不是一个固定答案，而是一类随配置变化的调度问题。例如，小模型配合大量环境时，也许环境侧资源更紧；而模型更大、动作块更长时，也许 rollout 侧反而重新成为瓶颈。类似地，不同流水线阶段数和不同的进程 / 向量化环境组合，也可能把系统推到完全不同的资源平衡点上。因此，从更长期的角度看，手工调参和静态资源布局只是第一步，后续非常值得探索的是自动资源布局 / 自动调优方案，让系统根据模型、环境和硬件配置自动找到更优的执行布局。
本节结论
性能收益并不是来自某一个 magic trick，而是来自多层优化的叠加与系统协同。
05 总结：高保真具身环境的启发
回过头看，我们从这次优化工作的获得了一个核心启发：高保真仿真器的默认执行路径，往往并不是为大规模强化学习 rollout 设计的。 像 BEHAVIOR 这样的系统，需要同时服务于交互、展示、调试、评测和研究等多种用途，因此默认会保留许多对开发者友好、但对训练吞吐并不友好的路径。真正要把它用于大规模训练，第一步不是盲目加机器、也不是急着去抠某个局部计算内核，而是先弄清楚：哪些工作是训练真正需要的，哪些只是历史上为了别的使用场景保留下来的"附加成本"。从这个角度看，本文的三类优化其实都围绕同一个原则展开：让执行路径服从真实数据流，而不是服从系统的默认组织方式。
另一个很重要的经验是，**环境优化不只是环境本身的优化，而是训练系统整体的优化。**在具身智能任务里，环境、模型、资源布局、流水线和资源调度之间的耦合程度远高于很多传统基准环境。环境再慢一点，模型就会被阻塞；模型再大一点，最优资源布局就会改变；流水线阶段的组织方式一变，环境的物理频率和切片映射也必须跟着调整。换句话说，我们最终要优化的对象，并不是某一个单独模块，而是"模型如何与环境协同工作"的整套系统。这也是为什么本文后面会把最优资源布局视作一个仍然开放的问题：当单一瓶颈被缓解之后，系统更高层次的协同调度问题才会真正浮现出来。除了自动资源布局以外，另一个方向则是把这套思路进一步扩展到更复杂的多机和异构资源场景中，验证它在更大规模实验中的稳定性与收益边界。
最后，我们已经将相关性能补丁合并到 RLinf 和 StanfordVL/BEHAVIOR-1K 上游仓库。对于想直接上手 BEHAVIOR 的开发者，RLinf 提供了一套不需要从零改环境就能使用的成熟方案。 同时，我们希望这项工作能不仅服务于我们自己的训练系统，还能为更广泛的具身智能社区提供一个参考：面对"高保真必伴随高开销"的固有认知，破局点并不是在环境真实感与训练吞吐量之间做妥协。拥有对强化学习的数据流向和底层系统框架的深刻理解之后，复杂的物理仿真世界也能蜕变为高效的算力基础设施，最终让智能体能够以更低的成本去试错、探索和掌握更广阔的真实世界。
GitHub链接：https://github.com/RLinf/RLinf
中文文档链接：https://rlinf.readthedocs.io/zh-cn/latest/rst_source/examples/embodied/behavior.html
英文文档链接：https://rlinf.readthedocs.io/en/latest/rst_source/examples/embodied/behavior.html
图片/视频素材：Physical Intelligence，BEHAVIOR-1K