Nimbus：一个统一的具身合成数据生成框架

Zeyu He¹, Yuchang Zhang¹, Yuanzhen Zhou¹, Miao Tao¹, Hengjie Li¹,²∗, Hui Wang¹, Yang Tian¹, Jia Zeng¹, Tai Wang¹, Wenzhe Cai¹, Yilun Chen¹, Ning Gao¹, Jiangmiao Pang¹摘要扩大数据规模和多样性对于泛化具身智能至关重要。虽然合成数据生成为昂贵的物理数据采集提供了可扩展的替代方案但现有的流水线仍然是碎片化的且针对特定任务。这种孤立导致显著的工程效率低下和系统不稳定无法支持基础模型训练所需的持续、高吞吐量数据生成。为应对这些挑战我们提出了 Nimbus一个统一的合成数据生成框架旨在整合异构的导航和操作流水线。Nimbus 引入了模块化四层架构采用解耦执行模型将轨迹规划、渲染和存储分离为异步阶段。通过实现动态流水线调度、全局负载均衡、分布式容错和后端特定渲染优化该系统最大化了 CPU、GPU 和 I/O 资源的利用率。我们的评估表明与未优化的基线相比Nimbus 实现了 2–3×的端到端吞吐量提升并确保在大规模分布式环境中稳健、长期的运行。该框架作为 InternData 套件的生产骨干实现无缝跨域数据合成。1 引言具身智能embodied intelligence的进步从根本上依赖于两项核心能力导航navigation和操作manipulation。这些基本能力使智能体agents能够在环境中自主移动并与物体进行物理交互从而成为人工通用智能Artificial General Intelligence, AGI的基本构建模块。现有工作表明进一步扩大数据规模和多样性可以加速模型能力的增长。然而这些努力大多依赖于真实世界的数据收集而数据获取成本仍然高得令人望而却步。具体而言硬件部署的高资本成本和收集器培训的时间开销使得物理流程无法满足现代基础模型训练的高容量、多模态需求。合成数据流程Synthetic data pipelines提供了一种可扩展的替代方案通过在虚拟环境中生成可控、多样的数据来绕过物理数据瓶颈。然而现有的合成数据流程缺乏统一框架这限制了当前解决方案只能专门针对导航或操作任务进行定制。这一缺陷引发了两个核心问题首先是效率低下表现为工程冗余以及优化和加速策略缺乏通用性其次是不稳定性由于缺乏标准化的集群调度cluster scheduling和容错fault tolerance机制阻碍了大规模数据集所需的持续、长周期数据生成。为弥合这一差距我们提出了 Nimbus这是一个统一的合成数据生成框架旨在整合异构的导航和操作流程。具体而言Nimbus 围绕分层设计和一组多层优化构建。在框架层面我们引入了一个四层架构清晰地分离了调度优化和容错Schedule Opt Layer、统一的 Load-Plan-Render-Store 生命周期运行器抽象Stage Runner Layer、面向接口的可复用导航和操作组件Components Layer以及集成基于 Ray的环境和不同模拟器及渲染器后端的高性能运行时Backend Opt Layer。这种模块化使得相同的调度和优化原语可以应用于异构流程例如 InternData-N1 导航和 InternData-A1/M1 操作而无需重写场景逻辑。在 Schedule Opt Layer我们实现了一个两级优化栈由 pipeline parallelism 和 distributed optimization 组成。在 pipeline parallelism 中我们将传统的单体 pipeline 解耦为异步执行模型。Trajectory planning (CPU-bound)、rendering (GPU-bound) 和 storage (I/O-bound) 在独立的 worker pools 中执行并采用动态 pipeline scheduling。这一设计减少了阻塞并最大化了 CPU、GPU 和 I/O 的利用率。在 distributed optimization 中我们致力于实现集群规模的高效率和高可用性。我们采用 global balancer 和 per-worker supervisors 来实现 load balancing、liveness monitoring 和 automatic recovery。最后在 Backend Opt Layer我们针对主要 backendsGaussian Splatting、Blender 和 Isaac Sim优化关键 rendering paths。通过应用 accelerated rasterization 和 batched/stacked rendering 等技术进一步提高了 per-process throughput。综合这些设计相比未优化的 baseline我们实现了 2-3 倍的 end-to-end throughput 提升并在分布式环境中实现了稳定、持续的数据生成。本文其余部分组织如下第2节详细介绍InternData系列数据集及其生成流程第3节分析导航、操作及相关框架的现有文献第4节描述Nimbus架构及其集成策略第5节介绍我们的优化技术包括阶段解耦、调度器设计和分布式容错第6节评估框架的性能第7节总结并展望未来方向。2 背景2.1 InternData-N1InternData-N1 一个用于视觉 - 语言导航VLN的大规模合成数据集涵盖超过 3,000 个室内场景包含 5,350 万张第一人称视角FPV图像和 80 万条语言指令约 4,840 公里的轨迹。它包含三个互补的子集VLN-N1/VLN-CE/VLN-PE分别用于支持通用导航预训练、细粒度指令跟随和 sim-to-real 迁移。图 1 展示了合成工作流程可概括如下场景库构建。整合六个开源室内场景库Replica、Matterport3D、Gibson、3D-Front、HSSD 和 HM3D以覆盖多样化的房间布局和场景类别。路径规划。通过三阶段流程生成无碰撞的平滑轨迹(i) 为每层构建欧几里得符号距离场ESDF并使用 A-star 在随机采样的起点 - 终点对之间规划初始全局路径(ii) 基于 ESDF 优化转向点以保持障碍物间距(iii) 应用 Bézier 平滑以确保连续运动。观测渲染。使用 Blender-Proc 逐帧渲染规划好的轨迹以获得 FPV RGB 图像和深度图。指令标注。从几何线索如急转弯或经过地标检测关键帧并将轨迹分割为子段使用多模态模型LLaVA-OneVision生成细粒度的步骤指令然后用语言模型Qwen3-72B重写并汇总子指令为单一的长程指令。数据过滤。使用地标密度和场景信息指标移除低质量样本。2.2 InternData-A1InternData-A1是一个高保真合成操作数据集用于预训练通用视觉 - 语言 - 动作VLA策略 。该数据集涵盖四种机器人形态Genie-1、Franka Panda、AgileX Split Aloha 和 ARX Lift-2包含 18 种技能跨越 227 个室内场景总计 7,433 小时的交互数据。如图2所示InternData-A1 通过一个完全解耦且可组合的流水线进行合成•环境构建Environment construction。给定任务模板从资产库中检索与任务相关的机器人、场景和物体机器人以经过验证的USD具身模型形式提供场景来源于GRUtopia GRScenes-100带有标注的操作区域物体包括刚性、关节式、可变形和流体类别均配备高保真物理模型例如刚性物体使用AnyGrasp生成的抓取姿态可变形物体和流体则使用专用模拟器。•技能组合Skill composition。通过从技能库中选择并组合原子技能来构建任务。每个技能都实现为脚本化策略将物体/机器人状态和约束映射到一系列末端执行器6D航点从而将高级逻辑与低级插值和控制解耦例如Pick、Place、Push、Goto-pose和Gripper-action。•域随机化Domain randomization。对外观和动力学进行系统性随机化以缩小仿真到现实的差距扰动相机外参主相机和腕部相机采样多样化的HDR环境贴图和光照参数在物体类别内交换实例随机化桌子/背景布局此外随机化初始机器人/物体姿态以及抓取/接触区域的随机性例如从最高置信度的AnyGrasp候选中采样。•轨迹生成与存储Trajectory generation and storage。给定航点序列使用CuRobo进行关节空间规划和密集插值记录多视角RGB观测数据包括相机参数、机器人状态和控制命令、物体元数据以及语言指令可选导出深度、定位标签和边界框。仅成功的rollout会被渲染并写入数据集最终转换为LeRobot格式。2.3 InternData-M1InternData-M1 是一个合成桌面操作数据集旨在实现长程推理和空间定位。它包含约 244,000 个仿真演示具有密集的动作和几何标注并整合了超过 80,000 个开放词汇对象以促进泛化能力。图3总结了LLM驱动的仿真工作流程具体步骤如下•仿真资产。在Isaac Sim中构建大型资产库包括超过14,000个带标签的物体、200张桌子和近1,700种纹理/光照配置以提供广泛的物理和视觉多样性。•物理仿真与任务合成。通过随机化物体布局和光照并利用特权信号如meshes和robot states计算抓取候选和运动规划来合成轨迹。每条轨迹都在闭环执行中进行验证并由scene-graph validator检查仅保留成功且物理一致的rollouts。•规划与视觉渲染解耦。通过先记录结构化规划轨迹如joint states和object poses然后在随机化的视角、材质和光照下重放将规划与渲染解耦。相机校准通过ArUco markers进行以使intrinsic/extrinsic参数与真实传感器对齐同时渲染器生成RGB图像和密集空间监督如2D boxes、end-effector traces和精确keypoints。•VLM/VLA数据打包。将中间表示转换为统一的visual question answering (VQA)格式用于VLM预训练。通过将动作与自然语言指令和空间标注配对该流程为affordance recognition、trajectory prediction和multi-step planning派生辅助监督桥接语义推理与具身执行。3 相关工作3.1 导航数据生成具身导航任务主要依赖于预先构建的 3D 环境和静态任务分布。虽然主流数据源利用了大规模室内扫描数据如 Matterport3D和 Habitat-Matterport 3D (HM3D)但其获取过程需要组织一个资源密集型的流程涉及专用硬件、物理布景以及复杂的后处理。在 VLN 领域主流方法是将静态环境资产与人工生成的标注相结合。诸如 R2R和 RxR等基准测试受限于有限的环境依赖劳动密集型众包流程为预定义路径生成指令。尽管后续工作如 CVDN和 REVERIE引入了多轮对话和指代表达式以增强语义复杂性但由于场景选择、轨迹采样和验证需要人工干预它们产生了显著的开销。因此扩展这些数据集的边际成本仍然高得令人望而却步。相反ObjectNav及相关目标驱动型任务需要严格的场景语义必须提供精确的对象列表、实例分割和类别标签以支持离线任务采样。虽然 Habitat 等平台通过对扫描资产如 HM3D应用基于规则的生成来自动化这一过程但其底层逻辑通常与特定代码库紧密耦合。由于缺乏针对任务模板、轨迹采样和元数据组织的统一抽象导致模块化程度不足严重阻碍了跨项目的可复用性。最终当代导航数据生成遵循的是混合现实世界扫描与模拟的工作流程。构建成本主要集中在物理扫描和后处理阶段而任务生成仍然受限于人工标注或脆弱、临时的脚本。因此数据集更新表现为离散的、静态的发布而非持续的、演进式的生产流程。3.2 操作数据生成与导航任务不同操作数据生成在过去三年中沿着三个不同的方向发展(1) 大规模物理遥操作代表传统的真实世界演示范式(2) 通用操作接口UMI风格的方法如 UMI、Fast-UMI将人类操作者与机器人形态解耦以在自然环境中捕捉类机器人轨迹(3) 合成数据生成通过演示增强或基于规则的批处理来编排仿真环境。物理遥操作与多机器人聚合。跨机构倡议如 Open X-Embodiment 汇聚了来自 34 个实验室和超过 60 个子数据集的数据构建了大规模的真实世界轨迹存储库。与此同时π0 和 RoboMIND 等系统在单一机构内执行统一的采集协议以生成标准化、多机器人的语料库。近期的工作包括 AgiBotWorld和 Galaxea将这一范式扩展到多样化的开放世界场景产生了高分辨率、长时域的轨迹数据。尽管这些工作显著扩展了真实世界数据的规模但它们面临着系统性的可扩展性瓶颈需要专用占用硬件资源、严重依赖专业遥操作员并在合规性、隐私和异构平台集成方面产生大量开销。为减少工程摩擦IRIS等沉浸式界面利用 XR 和点云渲染来统一跨平台的遥操作视图。与此同时工业界参与者如 Tesla、Figure AI协调大规模机队以收集专有行为数据。然而这些工业流水线仍然闭源掩盖了其内部编排逻辑使外部研究人员无法利用其系统抽象。UMI类接口与代理设备。第二种方法将操作员与机器人完全解耦。UMI、DexUMI和 DexCap 等方法采用代理设备来捕捉野外in-the-wild演示并将其离线映射到目标机器人形态。例如UMI 利用配备多模态传感器的低成本手持界面使非专家也能演示复杂的动态操作。Fast-UMI 进一步抽象了硬件依赖性采用商业追踪技术简化校准流程并利用专用工具链进行数据转换。虽然 UMI 类接口无需占用昂贵的机器人硬件即可保留真实世界的物理特性但它们仍线性受限于人类演示时间。此外从代理设备到机器人的转换带来了显著的工程复杂性需要进行严格的坐标映射、时空对齐以及统一控制接口的设计。合成数据增强与规则驱动生成。合成生成方法以物理真实性换取可扩展性大致可分为演示增强和规则驱动生成两类。MimicGen是增强方法的典型代表它通过子任务分割和场景扰动将少量人类演示种子集程序化扩展为数千条轨迹。RoboCasa及其后续版本 RoboCasa365 将这一逻辑集成到高保真家庭仿真平台中 effectively 作为演示工厂运作。相反规则驱动的数据生成如 InternData-M1 pipeline 和 InternData-A1 pipeline则从预定义的任务脚本和物理约束中生成大规模数据集。与 RLBench或 ManiSkill的固定基准不同这些工作强调将合成数据作为一种服务data as a service提供接口使研究者能够复用资产构建逻辑。仿真合成将数据生成的边际成本转化为计算开销。虽然这使得能够以极少的人工干预生成数百万条轨迹但也需要健壮的验证机制来过滤物理上不合理的数据并弥合 sim-to-real 差距。总结以数据集为中心的瓶颈三种主流范式揭示了一个关键的系统性差距。基于物理和UMI的方法受到硬件和人力的限制而仿真则将瓶颈转移到了资产和脚本构建上。关键在于当前的格局是以数据集为中心的一旦语料库确定底层的生成就实际上被固定了。研究人员只能使用静态数据集无法在不重新设计整个工作流程的情况下逐步扩展任务定义或传感器配置。这种缺乏可复用、可编排的系统架构的现状促使了Nimbus的设计。3.3 数据生成的系统框架从系统角度来看现有框架可分为三类任务专用生成工具、仿真平台和通用工作流引擎。第一类以 MimicGen 为代表将数据扩展形式化为可编程流水线但将控制限制在任务级规则修改。第二类包括 RoboCasa将资产和采集工具集成到统一平台中。虽然在其特定领域内有效但这些系统强制执行严格的边界其内部流水线与特定仿真后端紧密耦合阻碍了向新模态或任务的迁移。第三类包括 Apache Airflow 和 Prefect等通用编排器。虽然这些系统在工业 ETL 领域已相当成熟但它们将任务视为黑盒操作符缺乏针对机器人 - 环境 - 传感器拓扑的原生抽象。它们针对批处理进行了优化而非具身 AI 所需的实时、有状态控制循环。此外它们跟踪的是文件级元数据而非轨迹、场景状态和策略版本之间的语义关联。在分布式深度学习领域流水线并行训练调度如 Megatron-LM 的 1F1B和 Zero-Bubble Pipeline Parallelism通过在同步训练语义下优化跨层划分流水线阶段的微批次执行顺序来提高吞吐量旨在减少流水线气泡。这些方法围绕一组固定的流水线阶段进行设计具有明确的阶段间激活/梯度依赖关系以及正确梯度计算所需的一致性约束其气泡相关的最优性通常在阶段时间成本模型下进行分析而实际部署可能会受到执行时间变化和拖尾者的影响。相比之下数据采集会话涉及异步、事件驱动的编排具有动态参与、失败/重试和异构延迟等特点这需要与层/微批次级训练流水线不同的调度抽象和目标。因此目前仍缺乏一个能够跨越真实和仿真环境、统一采集和生成、并为具身任务提供原生编排的通用框架。我们的 Nimbus 通过引入专门为具身 AI 数据生命周期设计的系统级抽象来解决这一问题。4 架构Nimbus 采用模块化四层架构旨在统一异构合成数据流水线同时最大化资源效率。如图 4 所示该框架分为 Components Layer、Stage Runner Layer、Schedule Opt Layer 和 Backend Opt Layer。这种分层设计将高层编排与底层执行解耦使得在多样化的导航和操作任务中能够实现统一的调度和优化原语。4.1 Stage Runner LayerStage Runner Layer 定义了标准化的 Load-Plan-Render-Store 生命周期将生成工作流抽象为四个阶段。Load Stage 处理资产导入和域随机化以扩展数据多样性。Plan Stage 根据任务规范生成物理有效的运动序列或动作计划。Render Stage 将这些序列可视化为高保真多模态传感器观测数据RGB、Depth 等。最后Store Stage 管理数据序列化将异构输出聚合为统一的持久化格式。为了标准化每个阶段的执行我们定义了五个抽象基迭代器强制执行严格的输入/输出协议如表 1 所示。在 Load Stage我们提供 BaseLoader 和 BaseRandomizer 来共同构建场景。具体而言BaseLoader 导入配置以输出场景对象然后由 BaseRandomizer 处理以修改属性进行域随机化。对于其余阶段BasePlanner 接收场景以生成轨迹序列BaseRenderer 从这些序列合成观测数据BaseWriter 将序列和观测数据序列化到存储。通过链接这些迭代器Nimbus 以统一的方式编排端到端的合成数据生成流程。4.2 组件层组件层在 Stage Runner 定义的统一接口内实现导航和操作的具体逻辑。该设计通过强制执行严格的接口契约解决了现有流水线的碎片化问题从而实现代码复用和无缝集成。如图 5 所示Nimbus 通过灵活的组件组合集成了独立的 Navigation 和 Manipulation 工作流。4.2.1 导航组件与集成Navigation 组件将通用生命周期适配到 InternData-N1 流水线解决了基于 mesh 的资产与 Gaussian Splatting 资产之间的异构性问题。多功能组件套件。我们在整个生成生命周期中实现了一套全面的组件来处理多样化的数据格式。在加载阶段Load Stage我们提供 GSMeshLoader 用于处理与 GS 资产对齐的代理网格proxy meshesBProcObjLoader 用于标准 .obj 文件以及 BProc3DFrontLoader 用于解析来自 3D-FRONT 数据集的语义布局。为了扩展数据多样性BProc3DFrontRandomizer 应用特定领域的增强包括光照、纹理和姿态随机化。在规划阶段Plan StageNavPlanner 使用 A-star 路径查找生成无碰撞轨迹。这可以通过特定数据集的逻辑例如 BProc3DFrontPlanner进行扩展以在结构化环境中强制实施布局约束。对于渲染阶段Render Stage我们采用 SCGSRenderer 进行高保真 GS 光栅化以及 BlenderProcRenderer 进行照片级真实的网格渲染。最后在存储阶段Store StageNavWriter 聚合轨迹姿态、多模态观测和场景元数据将它们序列化为统一的 InternData-N1 格式。管道集成策略。为了协调 GS 和 Mesh 资产的不同特性我们采用差异化的组件组合策略如图 5 所示。对于 Mesh 资产管道可以根据格式复杂度进行配置。对于 GS 资产其提供更优越的渲染保真度但缺乏路径规划所需的几何信息我们实现了一个基于代理的管道GSMeshLoader → NavPlanner → SCGSRenderer → NavWriter。具体而言GSMeshLoader 摄入与 GS 坐标系对齐的代理网格使 NavPlanner 能够计算物理上有效的轨迹。随后使用 SCGSRenderer 渲染这些轨迹有效地将几何有效性与视觉保真度结合起来。4.2.2 操作组件与集成Manipulation 组件统一了 InternData-A1 pipeline 和 InternData-M1 pipeline 的异构工作流。与用于 navigation 的灵活组合方式不同我们采用 Unified Adapter Components 配合标准化的 Workflow API 来管理机器人仿真的复杂性。Unified Adapter Components。我们定义了一套 Env components例如 EnvLoader、EnvPlanner 等它们作为底层仿真器如 IsaacSim 和 Sapien的抽象封装层。这些 components 将 InternData-A1 和 InternData-M1 pipelines 的领域特定操作映射到标准化的 Nimbus 生命周期阶段。Workflow API。Unified Adapter Components 的实现基于标准化的 Workflow API该 API 提供三个核心能力•Encapsulation封装封装 pipeline 逻辑和仿真接口保护 component 层免受后端差异的影响。•Decoupling解耦通过定义 reset、randomization、generate seq、seq replay 和 save 等核心接口将详细的生成逻辑与框架的调度和优化机制严格分离。•Extensibility可扩展性开发者通过遵循这些接口实现特定的 workflows例如为 InternData-A1 pipeline 实现的 GenManipWorkflow 和为 InternData-M1 pipeline 实现的 SimBoxWorkflow。框架的 Env components 调用这些标准化方法无需关心底层实现细节。4.3 Schedule Opt LayerSchedule Opt Layer 作为控制平面control plane负责全局资源管理和容错fault tolerance。它采用四项关键优化来解决单体执行效率低下和集群不稳定的问题• Dynamic Pipeline Execution利用轨迹规划trajectory planning与渲染rendering的解耦特性我们实现了动态流水线dynamic pipelining机制。该设计消除了阶段间阻塞有效掩盖了计算延迟并最大化吞吐量。• Asynchronous Batch Storage为减轻 I/O 开销我们将数据持久化data persistence卸载到异步线程。通过批量处理写入操作该模块将存储延迟与关键计算路径隔离。• Load Balancing针对分布式环境中的资源倾斜问题负载均衡器load balancer动态调度任务以充分利用集群容量。该策略有效缓解了落后者效应straggler effect并确保资源的均匀利用。• Supervisor提供细粒度的容错能力supervisor 实时监控任务存活状态task liveness。它自动检测故障并触发恢复例程以保证系统的持续可用性。这些优化的详细实现在第 5 节中呈现。4.4 后端优化层Backend Opt Layer后端优化层提供高性能运行时环境。它集成了基于 Ray 的环境与优化后的渲染器后端。关键优化包括针对 Gaussian Splatting 的加速光栅化、针对 Blender 的 RT-cores 和 tensor-cores 优化以及针对 Isaac Sim 的批量渲染。这些特定于后端的增强功能与上层协同工作以充分发挥硬件性能。5 多层优化设计单体式合成数据流水线通常将轨迹规划trajectory planning和视觉渲染visual rendering耦合到一个同步执行单元中。虽然这种耦合便于原型设计prototyping但在大规模应用时会引入严重的低效问题。首先规划与渲染的紧密耦合会导致计算浪费规划阶段生成的无效轨迹仍会触发渲染不必要地消耗资源。其次两个阶段的资源特征存在显著差异规划是 CPU-bound而渲染是 GPU-bound。串行执行迫使一种资源类型在另一种资源活动时处于空闲状态导致硬件利用率严重不足。此外随着部署规模的扩大部分故障变得不可避免需要强大的容错机制fault tolerance来确保持续可用性continuous availability。为缓解这些瓶颈Nimbus 实现了第 4 节中定义的调度优化层Schedule Opt Layer和后端优化层Backend Opt Layer中提到的多层优化策略。图 6 展示了多层优化策略。上半部分展示了流水线并行Pipeline ParallelismSection 5.1和渲染器优化Renderer OptimizationSection 5.3它们将串行执行解耦为异步模型asynchronous model并加速渲染以最大化整体吞吐量aggregate throughput。下半部分展示了分布式优化Distributed OptimizationSection 5.2采用带有监督器supervisors的全局负载均衡global load balancing来确保集群级cluster-scale的效率和可用性。5.1 Schedule Opt LayerPipeline Parallelism通过将生成分解为异步阶段我们实现了Dynamic Pipeline Execution和Asynchronous Batch Storage。该设计采用细粒度的ComputeWorker封装和动态pipeline scheduling以掩盖计算延迟并最大化异构计算资源的利用率。5.1.1 Pipeline Parallel Execution传统的合成数据生成工作流主要依赖于单体架构其中planning和rendering在同步执行循环中紧密耦合。在这种范式下pipeline按顺序执行Load Stage加载场景Plan Stage生成trajectoriesRender Stage进行渲染然后Store Stage执行持久化。这种lockstep执行方式使硬件使用串行化GPU在CPU-bound planning期间空闲CPU在GPU-bound rendering期间停滞。Blocking storage I/O进一步放大了这些pipeline气泡阻碍了资源利用。为缓解这些瓶颈我们提出了一种Pipeline Parallel Execution优化方案将生成分解为三个异步阶段。如图7所示我们引入了中间buffers以切断各阶段之间的串行依赖关系。异步阶段解耦。我们使用高吞吐量消息队列来桥接解耦的各个阶段。planner 进程作为生产者将序列化的 simulation contexts 推送到队列中。renderer 进程作为消费者异步获取 contexts 用于可视化。该设计实现了 pipeline parallelism当 renderer 进程为出队的 contexts 执行 GPU-bound 可视化时planner 进程同时在 CPU 上为后续任务生成 simulation states。此外该架构支持多个 planner 和 renderer 进程的弹性部署elastic deployment使系统能够协调各阶段的整体处理速率尽管它们存在固有的延迟差异。I/O 延迟隐藏。为解决存储阶段的 I/O 瓶颈我们实现了异步批量存储Asynchronous Batch Storage机制。renderer 进程将数据持久化任务卸载到专用的 I/O 线程池而非执行同步写入。通过批量处理写入操作该设计有效地将高延迟磁盘 I/O 与关键渲染路径隔离。吞吐量最大化。该流水线架构有效屏蔽了各阶段的特定延迟。通过重叠 CPU、GPU 和 I/O 操作我们将稀疏的顺序执行时间线转换为密集的并行调度。这确保了异构硬件资源的同时饱和包括 CPU 核心、GPU 计算单元和磁盘带宽从而显著提升端到端生成吞吐量。5.1.2 动态流水线调度尽管流水线并行具有诸多优势但 Plan 阶段和 Render 阶段的延迟本质上仍不对称。虽然对 planner 和 renderer 进程进行静态划分在理论上可以平衡流水线但它在实际中面临显著局限性。首先它需要对各阶段延迟进行精确的事先剖析profiling而这些延迟在不同任务间差异很大。其次运行时的随机性例如规划失败导致无效轨迹被丢弃会破坏理想的计算重叠。因此Plan 阶段往往会提前完成其工作负载导致资源闲置而 Render 阶段则仍处于积压状态。为解决这些低效问题我们引入了一种以自适应资源回收为核心的动态流水线调度策略。该机制采用事件驱动方式当上游 planner 进程耗尽其任务流时它会发送一个终止信号促使全局 Scheduler 立即回收其资源。随后Scheduler 评估当前的队列积压情况并动态配置一个新的 renderer 进程该进程继承现有的消息队列连接并无缝加入 renderer 组。图 8 展示了这一过程该场景初始化为两个 planner 进程和一个 renderer 进程。随着 planner 进程退出其计算能力会自动重新分配以启动额外的 renderer 进程确保资源从规划到渲染流畅流动。这种对阶段并行度的动态调整有效缓解了静态配置中观察到的长尾延迟问题从而在端到端生成吞吐量方面取得了显著提升。5.2 调度优化层分布式优化为确保集群规模的效率和高可用性我们实现了一个分布式优化层包含全局负载均衡和容错机制。5.2.1 全局负载均衡在分布式环境中由于任务异构性和硬件性能差异即 stragglers静态任务分配常常导致严重的负载不均衡。为最大化集群利用率我们实现了一个基于 Master-Worker 架构的全局负载均衡器。如图 9 所示Master Node 作为中央协调器维护全局集群状态。它集成了 WorkerManager 来跟踪节点存活状态和资源可用性以及 TaskManager 来基于实时负载指标将待处理任务动态分配给最合适的 worker。Worker Node 托管 StateReporter 向 Master 推送心跳更新以及 TaskGetter 来获取任务分配。ComputeWorker 封装了特定领域的执行逻辑例如 Planning 或 Rendering。此外为减少调度开销和网络拥塞我们采用了惰性上下文初始化策略。dispatcher 仅发送轻量级任务元数据而非传输完整的数据负载。Worker 节点仅在任务初始化时从共享存储中惰性加载完整的执行上下文。5.2.2 通过 Supervisor 实现容错我们利用 Ray 来管理 ComputeWorker 的生命周期通过自动进程重启提供基本的可用性。然而大规模合成数据生成仍然容易受到不稳定性的影响尤其是在集成复杂的物理模拟器/渲染器例如 Isaac Sim时。这些组件经常出现非确定性的挂起或静默失败而不是立即崩溃导致执行停滞和资源泄漏。此外传统的进程内监控会受到 Python Global Interpreter Lock (GIL) 的影响因为主执行线程中的死锁经常会阻塞监控线程。为了保证运行时鲁棒性我们引入了一个带外 Supervisor实现为与 ComputeWorker 解耦的独立进程。关键在于Supervisor 本身由 Ray 管理确保其自身的高可用性。这一设计建立了一个健壮的故障检测循环。在操作上ComputeWorker 和 Supervisor 都维护各自的 Status Monitor 组件。ComputeWorker 定期更新其本地 Status Monitor 状态并通过心跳消息将此状态同步到 Supervisor 的 Status Monitor。Supervisor 持续轮询其自身的 Status Monitor 状态执行严格的超时策略以验证 worker 的活跃性。检测到超时时Supervisor 通过 SIGKILL 终止无响应的 ComputeWorker。这会触发 Ray 自动重新生成 worker 并恢复其执行上下文有效地将静默挂起转换为 fail-stop 错误并在无需人工干预的情况下维持集群稳定性。5.3 后端优化层渲染器优化为了充分利用底层基础设施的硬件能力后端优化层针对三个主要渲染器实施了针对性优化Blender、Isaac Sim 和 Gaussian Splatting。5.3.1 Blender硬件加速流水线Blender 是一个广泛使用的开源 3D 创作套件用于高保真度的基于物理的渲染。我们在 InternData-N1 Blender 基线流水线中识别出两个关键瓶颈由于传统执行路径导致专用 GPU 硬件利用率不足以及 GIL 施加的并发限制。我们通过异构计算卸载和多进程并行来解决这些问题。硬件感知内核映射。我们重新设计了渲染流水线以利用 NVIDIA RTX 架构的专用计算单元。如图 10 所示基线流水线在通用 CUDA 核心上存在资源争用问题并且由于基于 CPU 的去噪而产生高延迟这需要昂贵的 device-to-host 内存传输。为了缓解这一问题我们使用 OptiX 后端实现了完全驻留 GPU 的流水线。该设计将 ray-triangle intersection 内核映射到专用的 RT Cores并通过 OptiX AI Denoiser 将去噪任务委托给 Tensor Cores。通过将整个 render-denoise 循环限制在 GPU 上我们消除了 CPU 瓶颈并最大化异构硬件资源的并发利用率。多进程并行。为了进一步最大化单个 GPU 上的资源利用率我们在 Nimbus Blender Renderer 中实现了并行渲染调度机制启动多个并发渲染进程。这一设计的动机是需要绕过 Python GIL后者将标准 Blender 执行限制为单线程导致 GPU 资源利用率不足。在此架构中主进程充当全局资源管理器负责场景加载、参数配置、任务分配和最终数据聚合。它将渲染任务分发给一组独立的工作进程池其中每个工作进程独立执行完整的优化流水线初始化、渲染和后处理。这种进程级并行有效规避了 GIL使系统能够充分利用高端 GPU 的计算能力。5.3.2 Isaac Sim堆叠渲染NVIDIA Isaac Sim 是一款基于 Omniverse 平台构建的高保真机器人仿真与合成数据生成工具。它专为具身 AIembodied AI开发而设计在合成数据流水线中充当物理仿真和多模态数据生产的核心引擎。如图 11 所示合成操作数据生成通常需要记录物体的时序运动序列例如球体下落的连续过程。传统工作流采用串行状态回放即单个场景和相机随时间顺序渲染物体的不同运动状态t0、t1、t2。这种串行执行模式无法充分利用 RTX 流水线的并行能力造成了显著的效率瓶颈。为解决这一限制我们引入了堆叠渲染Stacked Rendering优化技术将多步时序状态例如球体下落的不同阶段映射到单个场景内的多个独立子区域中。通过部署多个相机并行捕获这些子区域我们实现了单次场景加载和一次渲染即可完成多步数据采集有效替代了传统的串行时序渲染方法。该技术最大化了渲染流水线的吞吐量。5.3.3 Gaussian Splatting内核融合3D Gaussian Splatting 是一种新颖的 3D 表示方法将场景建模为可学习的 3D 高斯基元的集合。每个基元封装了完整的几何属性位置、旋转、缩放和外观属性颜色、不透明度。渲染流水线通过 splatting 技术将这些 3D 高斯投影到图像平面上执行一系列投影、分块、排序和 alpha 混合操作以实现实时、高质量的场景合成。为解决大规模合成数据生成中的渲染效率瓶颈我们集成了 FlashGS 和 TC-GS 来优化光栅化内核。FlashGS 针对标准流水线的计算和内存开销进行了优化。它实现了冗余高斯过滤以剪枝无效或低贡献的基元并行化渲染调度并实施细粒度的 GPU 内核执行控制。此外我们利用 Tensor Cores 加速 alpha 混合操作——正如 TC-GS 所提出的该操作在渲染流水线中占据主导计算成本。这些技术显著提升了 Gaussian Splatting 的渲染吞吐量大幅提高了合成数据生成流水线的整体效率。6 评估我们在阿里云集群上对 Nimbus 进行评估配置详情如表 所示我们对四种数据生成管道进行了基准测试• Nav-GSInternData-N1 Gaussian Splatting Pipeline一个导航数据采集管道在坐标对齐的 mesh 模型和 3D Gaussian 模型上执行规划与渲染。场景为自定义室内环境每个模型约包含 300 万个 Gaussians。• Nav-MeshInternData-N1 Blender Pipeline一种传统管道从 3D-FRONT 数据集中采样端点。它执行 A-star 路径规划并利用 Blender 进行渲染。• GenManipInternData-M1 Pipeline在 Objaverse 数据集上执行物体抓取与放置任务。• SimBoxInternData-A1 Pipeline在 Objaverse 数据集上执行垃圾分类任务。6.1 性能评估我们在四个不同的管道上评估了 Nimbus 与未优化的 Baseline 的端到端性能Nav-GS 和 Nav-Mesh 用于导航任务GenManip 和 SimBox 用于操作任务。我们为 Nav-GS 生成了 150 条轨迹为 Nav-Mesh 生成了 450 条轨迹每个场景 150 条为 GenManip 和 SimBox 各生成了 200 条。鉴于任务复杂性和数据量存在固有的异质性我们关注每个管道内的相对加速比Baseline vs. Nimbus而非跨管道的绝对比较。6.1.1 端到端吞吐量分析图 12 展示了端到端延迟对比。Nimbus 在所有工作负载上均实现了显著的性能提升加速比范围从 2.1× 到 3.2×。为了识别这些提升的来源我们分解了关键阶段的延迟分布。如图 13 所示Baseline 以顺序模式运行规划与渲染紧密耦合。相比之下Nimbus图 14将这些阶段解耦。关键在于在我们的流水线并行和动态调度机制下端到端延迟不再是各阶段延迟的累加和而是由瓶颈阶段决定。在导航任务中规划阶段计算开销较轻而渲染阶段和存储阶段占主导地位。在此引入完全解耦的流水线会产生序列化开销和 IPC 开销从而抵消潜在的并发收益。因此Nimbus 对规划和渲染保持同步执行转而专注于两项针对性优化• I/O Masking我们解耦了存储阶段。通过将持久化操作卸载到异步写入器我们完全掩盖了约 56 ms/frame 的磁盘 I/O 延迟。• Renderer Optimization我们通过 Backend Opt Layer 优化关键渲染路径。例如Nav-Mesh 渲染延迟降低了 64%从 446.29 ms 降至 159.46 ms。对于 GenManip 和 SimBoxNimbus 利用了 CPU-bound 规划与 GPU-bound 渲染之间的结构分离• Pipeline Overlap通过将规划和渲染隔离到不同的 ComputeWorkers 中我们实现了它们的重叠执行。规划成本被有效地分摊到渲染窗口内。为了进一步减少瓶颈延迟我们通过多个 renderer ComputeWorkers 增加渲染并发性。• Dynamic Resource Reallocation为了减轻尾部延迟调度器动态地从已完成的 Planners 回收资源以生成额外的 Renderers。这种自适应重新分配确保计算资源保持饱和状态最小化渲染尾部期间的空闲时间。6.1.2 有效吞吐量的理论分析尽管 Nimbus 实现了 2×–3× 的加速但各阶段延迟Figure 14显示每帧总计算量Plan 和 Render与 Baseline 相比仍然相当。这表明性能提升源于架构效率而非操作数量的减少。我们通过有效阶段吞吐量对此进行形式化描述。吞吐量模型在解耦架构中阶段性能由每帧延迟 ℓs 和时间平均并发度 $$ N¯ s 1 T R T 0 Ns(t)dt.$$定义。有效吞吐量为$$µs N¯s / ℓs (frames/s)$$系统的稳态理论最大吞吐量为$$λtheory min(µplan, µrender)$$。与 Baseline 的退化流水线λbase ≈ (∑ ℓi)^-1不同Nimbus 通过提高$$ N¯s $$并利用重叠隐藏延迟从而最大化 $$ λtheory$$。Impact of dynamic pipeline scheduling在 ℓrender ≫ ℓplan 的操作任务中系统处于 GPU-bound 状态。Nimbus 初始化为平衡的 Planner:Renderer 比例以使队列饱和然后动态重新分配资源。随着 Planners 退出$$N¯ plan$$ 减少而 $$\bar{N}_{render$$ 增加恰好在瓶颈转移到尾部时提升 $$ µrender $$。Correlation Between Failure Rates and Latency在 GPU-bound 状态下存在一种反直觉的动态现象更高的规划成功率与更长的总执行时间相关联。设 $$X_i \in \{0, 1\$$ 为第 $$$$ 次尝试的成功指示器。总执行时间近似为$$T^{Nimbus}_{total} \approx \frac{\ell^{Nimbus}_{render}}{\bar{N}_{render}} \sum_{i1}^{M} X_i $$由于失败的规划在渲染前会被剪枝更高的失败率会降低总渲染负载。为了公平地评估效率我们定义Effective Successful Throughput$$λsucc (P Xi)/Ttotal$$。Nimbus 能够在不同的失败率下鲁棒地维持高 $$ λsucc $$因为动态流水线调度确保了成功样本的吞吐量接近$$ λtheory$$。6.2 可扩展性当将任务扩展到更大规模时需要额外的计算节点。这不可避免地带来了两个关键挑战全局负载均衡和复杂物理模拟器的故障恢复。这两个挑战都会显著影响框架的可扩展性。我们通过带有全局负载均衡器的 master-worker 架构来解决由任务异构性和硬件性能差异引起的负载不平衡问题并通过 Supervisor 机制确保运行时鲁棒性从而实现出色的可扩展性。我们通过在不同规模的集群上执行 24 小时数据生成任务来评估系统的可扩展性集群规模从 8 到 128 个 GPU 不等。值得注意的是对于 Nav-Mesh pipeline我们的评估包含 2,560 个不同的场景。我们还进行了对比实验分别启用和禁用动态负载均衡参数dynload其中启用 dynload 会激活全局负载均衡器。结果如图 15 所示。理论上吞吐量应与 GPU 数量呈线性增长。我们的实验结果表明当从 8 个 GPU 扩展到 128 个 GPU 时系统实现了约 86% 的线性扩展效率这表明可扩展性出色。在整个 24 小时的测试期间系统保持稳定运行没有出现节点故障或任务故障展现出卓越的鲁棒性。与完美线性扩展的偏差可归因于两个主要因素。首先任务执行存在固有的尾部效应tail effects。即使有负载均衡最后一批任务的完成时间也会影响整体吞吐量测量且随着节点数量增加这种效应变得更加明显。其次负载均衡器的调度效率受任务粒度影响。随着节点数量增加分配给每个节点的任务数量相应减少这降低了全局负载均衡器可用的调度灵活性。在我们的 128-GPU 配置中2,560 个场景被分配平均每 GPU 仅约 20 个场景。每个节点的这种相对较小的任务池不足以让负载均衡器充分发挥其动态调度能力并有效缓解不可避免的尾部效应从而限制了整体资源利用效率。值得注意的是尽管存在这些因素系统在大规模集群上仍保持高资源利用率这得益于我们的 master-worker 架构与 Supervisor 机制之间的有效协调。这一结果验证了我们的架构设计能够支持生产环境中的大规模数据生成需求。7 结论数据稀缺仍然是训练具身智能模型的主要瓶颈。虽然合成数据提供了一条可行的前进路径但现有的生成流程受到碎片化、低效率和不稳定性的困扰。在本文中我们提出了Nimbus这是一个通过系统化设计解决这些架构缺陷的统一框架。通过将导航和操作流程整合到单一框架中Nimbus成功协调了InternData数据集系列的大规模构建。我们的评估表明该系统通过动态流程调度和渲染优化实现了比基线2–3×的吞吐量提升。此外其容错设计确保在大规模GPU集群上稳健、持续地运行满足大规模数据活动的稳定性要求。通过使用标准化、高性能的基础设施取代临时脚本Nimbus规避了物理数据收集的过高成本。它提供了推进操作和导航模型所需的高容量、多模态数据流。展望未来我们计划从三个方向扩展该框架集成多样化的轨迹规划器以丰富行为变化纳入自动化场景生成以扩大环境兼容性以及实施自动化任务配置以进一步增强下游模型的泛化能力。