文章很长，干货超多，建议先Mark慢慢看~

作者：HZY、ZYC、ZYZ、TM和LHJ from HEICS Group@Shanghai AI Lab

TL;DR

在通往 AGI 的征途中，如果说模型是引擎，数据就是燃料。特别是对于具身智能而言，高质量、大规模、多样性的数据，是其从虚拟走向现实的唯一“船票”。

然而，在仿真合成数据（Synthetic Data）这一关键技术路径上，开发者们长期面临着“行业标准缺失”的困境：由于各套仿真方法实现上难以兼容，数据生产过程如同手工业式的“数据作坊”，普遍存在成本高昂、效率低下、且极不稳定的痛点。

为了打破这一僵局，我们系统性地推出了 Nimbus：仿真合成数据管线统一框架。该框架通过定义一套高效、通用的底层抽象，将碎片化的仿真流程标准化，开发者可借此充分发挥框架内置的各项性能优化特性，确保数据管线长期稳定高效运行，实现数据的持续可靠产出。

Nimbus 致力于将传统 “数据作坊” 升级为具备工业级稳定产出能力的 “智能数据工厂”。目前，该平台已成功支撑超大规模数据集矩阵 InternData 的生产建设，覆盖导航、操作等多个业务领域。相较于原有数据管线，Nimbus 将端到端性能提升 2–3 倍，并实现单条数据平均生成成本降至 0.006 元

---

Tech Report 地址：http://arxiv.org/abs/2601.21449

Nimbus: A Unified Embodied Synthetic Data Generation Framework

1. 背景：为何数据生产急需一场“工业革命”？

在深入 Nimbus 的设计之前，我们首先需要理解它所要应对的挑战有多复杂。让我们以 InternData 数据集系列中的三个典型代表为例，一窥现代合成数据管线的复杂性。

案例一：InternData-N1

论文地址：https://internrobotics.github.io/internvla-n1.github.io/static/pdfs/InternVLA_N1.pdf

这是一个面向视觉-语言导航（VLN）的大规模数据集，其生产流程如同一条精密的流水线，如图1所示：

1. 场景构建：聚合六大开源室内场景库（如 Matterport3D, 3D-Front 等）。

2. 路径规划：通过 A-Star 算法在三维场景中规划出数百万条无碰撞的平滑轨迹。

3. 观测渲染：利用 BlenderProc 渲染引擎，逐帧渲染轨迹上的第一人称 RGB 图像和深度图。

4. 指令生成：借助多模态大模型（LLaVA）和语言大模型（Qwen3-72B），为轨迹自动生成高质量、符合人类习惯的导航指令。

5. 数据筛选：最后通过一系列质量评估指标，筛除低质量样本。

图1 InternData-N1数据生成管线

案例二：InternData-A1

论文地址：https://arxiv.org/abs/2511.16651

这是一个高物理保真度的机器人操作数据集，其管线特点是“完全解耦”和“自由组合”：

1. 环境构建：根据任务模板，从资产库中检索指定的机器人、场景和交互物体。

2. 技能组合：通过组合原子技能（如 Pick, Place, Push）来定义一个完整的任务流程。

3. 领域随机化：对光照、纹理、相机内外参、物体的初始位姿等进行大规模随机化，以提升模型的泛化能力。

4. 轨迹生成：使用 CuRobo 进行高速的运动规划，生成密集的关节空间轨迹，并记录多视角观测数据。

图2 InternData-A1数据生成管线

案例三：InternData-M1

论文地址：https://arxiv.org/abs/2510.13778

这是一个由大语言模型驱动的、面向长序列推理的桌面操作数据集：

1. 资产构建：在 Isaac Sim 中构建了一个包含超过14,000个已标注物体的庞大资产库。

2. 物理仿真与任务合成：通过随机化场景布局和光照，并利用场景图等特权信息进行高效的抓取和运动规划。

3. 规划与渲染解耦：先记录下无视觉信息的“规划轨迹”（关节状态、物体位姿等），然后再在不同的视觉条件下（如不同相机、光照、材质）对轨迹进行“回放”和渲染。

图3 InternData-M1数据生成管线

从以上案例中，我们可以清晰地看到三大痛点：

• 碎片化：三个数据集的生成管线，虽然目标都是合成数据，但其实现细节、依赖的技术栈（Blender、 Isaac Sim）、执行逻辑都大相径庭，代码复用率极低。

• 低效率：所有流程都存在 规划-渲染-存储 的串行依赖，导致 CPU 和 GPU 、I/O 资源无法被同时充分利用。

• 不稳定：在大规模集群生产环境中，任何一个工作进程发生的非确定性挂起或故障，都会导致资源空转与任务执行出错，影响整体系统可用性。

这些问题，让我们明确了目标：必须结束“作坊”时代，建立一个统一、高效、稳定的“数据工厂”。

2. 现有工作分析：为何我们必须自研框架？

在自研之前，我们审视了业界现有的数据生成范式，主要分为三类：

• 物理遥操作 (Physical Teleoperation)：如 Open X-Embodiment 项目，通过聚合来自全球不同实验室的真实机器人操作数据，构建超大规模数据集。

  • 优点：数据保真度最高。

  • 缺点：成本极其高昂，严重依赖昂贵的硬件和专家操作员，且数据采集效率受限于物理时间和空间，无法大规模并行。

• UMI-like 接口 (Universal Manipulation Interface)：通过一个低成本的通用手持设备来采集人的操作意图，再离线映射到不同形态的机器人上。

  • 优点：解绑了对昂贵机器人的依赖，降低了采集门槛。

  • 缺点：本质上仍受限于人的操作时间，且从代理设备到真实机器人的运动学映射带来了巨大的工程复杂性。

• 合成数据生成 (Synthetic Data Generation)：分为演示增强和规则驱动生成。前者通过程序化扩展少量种子演示，后者利用模拟器从预定义脚本生成海量数据。

  • 优点：将数据生成的边际成本转化为计算开销，具有极高的可扩展性。

  • 缺点：需要强大的验证机制来过滤物理不可信的数据，并弥合 Sim-to-Real 差距。

从系统角度看，现有框架分为三类：特定任务生成工具、仿真平台以及通用工作流引擎。

• 特定任务生成工具（如 MimicGen）：将数据扩展形式化为可编程管线，但控制权局限于任务级规则修改。

• 仿真平台（如 RoboCasa）：将资产和收集工具集成到统一平台中。虽然在特定领域有效，但它们施加了僵化的限制：其内部管线与特定模拟后端紧密耦合，阻碍了向新模态或任务的迁移。

• 通用工作流引擎（如 Apache Airflow）：它们将任务视为黑盒算子，缺乏对“机器人-环境-传感器”拓扑的原生抽象。它们针对批处理进行了优化，而不是具身 AI 所需的实时、有状态控制循环。此外，它们跟踪文件级元数据，而不是轨迹、场景状态和策略版本之间的语义链接。

所以，目前的系统框架均无法充分满足具身数据生成的需求，因此我们需要一个全新的、专为具身仿真合成数据生产而生的系统级框架。 这就是 Nimbus 的由来。

3. 整体架构：专为数据生产设计的四层抽象

Nimbus 的基石是一个清晰的四层模块化架构，如图4，它自上而下将控制、执行、逻辑和后端完全解耦。

图4 Nimbus架构图

• 阶段执行层 (Stage Runner Layer)：定义了数据生产的标准化生命周期，即 加载 (Load) -> 规划 (Plan) -> 渲染 (Render) -> 存储 (Store)。它基于Iterator执行流定义了一套严格的抽象基类接口（见下表），统一了所有任务的工作流，确保了不同组件能够无缝协作。

抽象类	核心接口	功能职责
BaseLoader	load_asset(config)	资源加载与校验
BaseRandomizer	randomize(scene)	场景的域随机化
BasePlanner	gen_sequence(scene)	生成轨迹或动作序列
BaseRenderer	gen_obs(seq)	合成多模态可视化数据
BaseWriter	save_data(seq, obs)	序列化存储

• 功能组件层 (Components Layer)：这是具体业务逻辑的实现层。如图5，开发者可以像搭乐高一样，基于阶段执行层的接口，为特定任务（如导航、操作）开发可复用的组件。

  • 导航任务的灵活组合：针对导航任务中资源格式多样（如 Mesh 和 Gaussian Splatting）的特点，我们采用了灵活的组件组合策略。例如，对于缺乏几何信息的高斯泼溅（GS）资产，我们设计了“代理管线”：GSMeshLoader 加载一个与GS对齐的“代理”网格模型 -> NavPlanner 在代理模型上进行路径规划 -> SCGSRenderer 使用原始GS资产进行高保真渲染。

  • 操作任务的统一适配：针对机器人仿真（如 Isaac Sim）流程复杂、状态管理繁重的特点，我们设计了“统一适配器组件”。我们将 GenManip (InternData-M1 数据生成管线) 和 SimBox (InternData-A1 数据生成管线) 两种复杂的流程分别封装在 GenManipWorkflow 和 SimBoxWorkflow 中，并由 Env 系列组件作为统一适配层来调用。这使得上层调度器无需关心底层的模拟器是哪个、状态如何同步。

图5 不同数据生成管线组合示例

• 调度优化层 (Schedule Opt Layer)：系统的“大脑”，作为顶层控制层面，负责全局的任务调度、资源分配、动态扩缩容和故障恢复。所有核心的性能和稳定性优化都在这一层实现。

• 后端优化层 (Backend Opt Layer)：提供与硬件紧密结合的高性能运行时。它集成了 Ray 分布式计算框架，并包含了针对不同渲染后端（如 Blender, Isaac Sim, Gaussian Splatting）的深度优化实现。

这套分层架构，使得 Nimbus 能够用同一套顶层调度优化逻辑，去驱动完全异构的底层数据生成任务，实现了真正的“统一”。

4. 核心优化技术剖析

单体合成数据管线通常将轨迹规划和视觉渲染耦合为一个同步执行单元。虽然这种方式便于原型开发，但在大规模场景下会引入严重的效率问题。首先，规划和渲染的紧密耦合导致了计算浪费：规划阶段生成的无效轨迹仍然会触发渲染，从而不必要地消耗资源。其次，这两个阶段的资源特征显著不同：规划是 CPU 密集型的，而渲染是 GPU 密集型的。串行执行使得一种资源类型在另一种资源活跃时处于空闲状态。这导致了严重的硬件利用率不足。此外，随着部署规模的扩大，部分故障变得不可避免，这就需要强大的容错能力来确保持续的可用性。

为了缓解这些瓶颈，Nimbus 实现了第 3 节中定义的调度优化层（Schedule Opt Layer）和后端优化层（Backend Opt Layer）中提到的多层优化策略。

图6 Nimbus 框架的多层优化示意图

图6展示了多层优化策略的细节。上半部分描绘了 流水线并行 和 渲染器优化，它们将串行执行解耦为异步模型并加速渲染，以最大化整体吞吐量。下半部分展示了 分布式层的优化，利用带有监督器的全局负载均衡来确保集群规模的效率和可用性。

4.1 调度优化层：流水线并行

通过将生成生命周期解耦为异步阶段，我们实现了动态流水线执行和异步批量存储。该设计采用了细粒度的 ComputeWorker 封装和动态流水线调度，以掩盖计算延迟并最大化异构计算资源的利用率。

4.1.1 流水线并行执行

传统的合成数据生成工作流主要依赖于单体架构，其中规划和渲染紧密耦合在一个同步执行循环中。在这种范式下，管线按顺序执行：加载阶段（Load Stage）加载场景，规划阶段（Plan Stage）生成轨迹，渲染阶段（Render Stage）进行渲染，然后存储阶段（Store Stage）执行持久化。这种步调一致的执行使得硬件使用串行化：GPU 在 CPU 密集型规划期间空闲，而 CPU 在 GPU 密集型渲染期间停滞。阻塞式存储 I/O 进一步放大了这些流水线气泡，阻碍了资源利用。

为了缓解这些瓶颈，我们提出了流水线并行执行优化，将生成生命周期解耦为三个异步阶段。如图7所示，我们引入了中间缓冲区来切断阶段之间的串行依赖。

图7 规划与渲染解耦架构

异步阶段解耦。 我们使用高吞吐量的消息队列来连接解耦的阶段。规划器进程作为生产者，将序列化的模拟上下文推送到队列中。渲染器进程作为消费者，异步获取上下文进行可视化。这种设计实现了流水线并行：当渲染器进程为出队的上下文执行 GPU 密集型可视化时，规划器进程并发地在 CPU 上为后续任务生成模拟状态。此外，该架构支持多个规划器和渲染器进程的弹性部署，允许系统在阶段间存在固有延迟差异的情况下对齐聚合处理速率。

I/O 延迟隐藏。 为了解决存储阶段的 I/O 瓶颈，我们实现了异步批量存储机制。渲染器进程不是执行同步写入，而是通过专用的I/O线程池来进行数据持久化。通过批量处理写入操作，该设计有效地将高延迟的磁盘 I/O 从关键渲染路径中隔离出来。

吞吐量最大化。 这种流水线架构有效地掩盖了特定阶段的延迟。通过重叠 CPU、GPU 和 I/O 操作，我们将稀疏的串行执行时间线转变为密集的并行调度。这确保了异构硬件资源（包括 CPU 核心、GPU 计算单元和磁盘带宽）的同时饱和，从而显著放大了端到端生成吞吐量。

4.1.2 动态流水线调度

尽管流水线并行带来了好处，但规划和渲染阶段的延迟本质上仍然是不对称的。虽然静态划分规划器和渲染器进程理论上可以平衡流水线，但它面临着显著的实际限制。首先，它需要对阶段延迟进行精确的先验分析，而这在不同任务中差异很大。其次，运行时的随机性，例如无效轨迹以及失败的规划，会破坏理想的计算重叠。因此，规划阶段往往过早完成其工作负载，导致资源闲置，而渲染阶段仍然积压。

图8 动态pipeline调度机制

为了解决这些低效问题，我们引入了一种以自适应资源回收为中心的动态流水线调度策略。如图8所示，该机制是事件驱动的：当上游规划器进程耗尽其任务流时，它会发送一个终止信号，提示全局调度器立即回收其资源。然后，调度器评估当前的队列积压情况，并动态配置一个新的渲染器进程，该进程继承现有的消息队列连接并无缝加入渲染器组。上图展示了在初始化为两个规划器进程和一个渲染器进程的场景中的这一过程。随着规划器进程退出，它们的计算能力被自动重新分配以启动额外的渲染器进程，确保资源从规划流畅地流向渲染。这种对阶段并行度的动态调整有效地缓解了在静态配置中观察到的长尾延迟，从而大幅提高了端到端生成吞吐量。

4.2 调度优化层：分布式优化

为了确保集群规模的效率和高可用性，我们实施了一个分布式优化层，包括全局负载均衡和容错机制。

4.2.1 全局负载均衡

在分布式环境中，静态任务分配通常会由于任务异构性和硬件性能差异（即 stragglers，长尾节点）而导致严重的负载不平衡。为了最大化集群利用率，我们实现了一个基于 Master-Worker 架构的全局负载均衡器。

图9 全局负载均衡架构

如图9所示，Master 节点充当中央协调器，维护全局集群状态。它集成了一个 WorkerManager 来跟踪节点存活状态和资源可用性，以及一个 TaskManager 来根据实时负载指标将挂起的任务动态分配给最合适的 Worker。Worker 节点托管一个 StateReporter 向 Master 推送心跳更新，以及一个 TaskGetter 来拉取分配的任务。ComputeWorker 封装了特定领域的执行逻辑（例如，规划或渲染）。此外，为了减少调度开销和网络拥塞，我们采用了延迟上下文初始化策略。调度器不传输完整的数据负载，而是仅发送轻量级的任务元数据。Worker 节点仅在任务初始化时才从共享存储中延迟加载完整的执行上下文。

4.2.2 基于监督器 (Supervisor) 的容错

我们利用 Ray 来管理 ComputeWorker 的生命周期，通过自动进程重启提供基本的可用性。然而，大规模合成数据生成仍然容易出现不稳定，特别是在集成复杂的物理模拟器/渲染器（例如 Isaac Sim）时。这些组件通常会出现非确定性的挂起或静默失败，而不是立即崩溃，从而导致执行停滞和资源泄漏。此外，传统的进程内监控受到 Python 全局解释器锁 (GIL) 的影响，因为主执行线程中的死锁经常会阻塞监控线程。

为了保证运行时鲁棒性，我们引入了一个带外管理的 Supervisor，作为一个与 ComputeWorker 解耦的独立进程实现。至关重要的是，Supervisor 本身由 Ray 管理，确保了其自身的高可用性。这种设计建立了一个强大的故障检测循环。在操作上，ComputeWorker 和 Supervisor都维护着各自的 Status Monitor组件。ComputeWorker 会定期更新其本地 Status Monitor 的状态，并通过心跳消息将此状态同步到 Supervisor的 Status Monitor。Supervisor则持续轮询其自身 Status Monitor 的状态，执行严格的超时策略以验证工作节点的活跃度。一旦检测到超时，Supervisor 会通过 SIGKILL 终止无响应的 ComputeWorker。这会触发 Ray 自动重生该 worker 并恢复其执行上下文，有效地将静默挂起转换为故障停止 (fail-stop) 错误，并在无需人工干预的情况下保持集群稳定性。

4.3 后端优化层：渲染器优化

为了使底层基础设施的硬件能力饱和，后端优化层针对三种主要渲染器实现了针对性的优化：Blender、Isaac Sim 和 Gaussian Splatting。

图10 Blender 硬件加速渲染管线

4.3.1 Blender：硬件加速流水线

Blender 是一套开源 3D 创作套件，用于高保真物理渲染。我们确定了 InternData-N1 Blender 基线管线中的两个关键瓶颈：由于遗留执行路径导致专用 GPU 硬件利用率不足，以及 GIL 施加的并发限制。我们通过异构计算卸载和多进程并行来解决这些问题。

硬件感知内核映射。 我们重新设计了渲染管线，以利用 NVIDIA RTX 架构的专用计算单元。如图10所示，基线管线在通用 CUDA 核心上存在资源争用，并因基于 CPU 的降噪而产生高延迟，这需要昂贵的设备到主机内存传输。为了缓解这个问题，我们使用 OptiX 后端实现了一个完全驻留 GPU 的管线。该设计将光线-三角形求交内核映射到专用的 RT Core，并通过 OptiX AI 降噪器将降噪转移到 Tensor Core。通过将整个渲染-降噪循环限制在 GPU 上，我们消除了 CPU 瓶颈并最大化了异构硬件资源的并发利用率。

多进程并行。 为了进一步最大化单个 GPU 上的资源利用率，我们在 Nimbus Blender 渲染器中实现了一种并行渲染调度机制，该机制启动多个并发渲染进程。在该架构中，主进程充当全局资源管理器，负责场景加载、参数配置、任务分配和最终数据聚合。它将渲染任务分发给一组独立的 worker 进程，其中每个 worker 独立执行完整的优化管线（初始化、渲染和后处理）。这种进程级并行有效地绕过了 GIL，使系统能够使高端 GPU 的计算能力饱和。

4.3.2 Isaac Sim：堆叠式渲染 (Stacked Rendering)

NVIDIA Isaac Sim 是一个建立在 Omniverse 平台上的高保真机器人仿真和合成数据生成工具。它专为具身 AI 开发而设计，作为合成数据管线中物理模拟和多模态数据生产的核心引擎。如下图所示，合成操作数据生成通常需要记录物体的时序运动序列（例如，球落下的连续过程）。传统工作流采用串行状态回放模式，即单个场景和相机按时间顺序（$$t_0, t_1, t_$$）逐帧渲染物体的不同运动状态。这种串行执行模式未能利用 RTX 管线的并行能力，造成了显著的效率瓶颈。

图11 Isaac Sim堆叠渲染优化

为了解决这一限制，我们引入了 堆叠式渲染 (Stacked Rendering) 优化，它将多步时序状态（例如，落球的不同阶段）映射到单个场景内的多个独立子区域。通过部署多个相机并行捕捉这些子区域，我们能够通过单次场景加载和一次渲染实现多步数据采集，从而有效替代传统的串行时序渲染方法。该技术最大化了渲染管线的吞吐量。

4.3.3 Gaussian Splatting：算子融合 (Kernel Fusion)

3D Gaussian Splatting (3DGS) 是一种新颖的 3D 表示方法，它将场景建模为可学习的 3D 高斯基元的集合。每个基元封装了完整的几何（位置、旋转、缩放）和外观（颜色、不透明度）属性。渲染管线通过 splatting 将这些 3D 高斯投影到图像平面上，执行一系列投影、平铺、排序和 Alpha blending，以实现实时、高质量的场景合成。

为了解决大规模合成数据生成中的渲染效率瓶颈，我们集成了 FlashGS 和 TC-GS 来优化光栅化内核。FlashGS 针对标准管线的计算和内存开销，通过冗余高斯过滤以修剪无效或低贡献的基元，实现了并行化渲染调度，并强制执行细粒度的 GPU 内核执行控制。此外，我们还采用了 TC-GS 利用 Tensor Core 来加速 Alpha blending （这是渲染管线中计算成本最高的部分）的方案。这些技术显著增加了 3DGS 渲染吞吐量，大幅提高了合成数据生成管线的整体效率。

5. 实验分析

我们在阿里云集群上评估了 Nimbus，配置详情见下表。

组件	规格
OS	Ubuntu 22.04
GPU	NVIDIA RTX 4090
CPU	Intel(R) Xeon(R) Gold 6462C @ 3889.285 MHz

我们对四种数据生成管线进行了基准测试：

• Nav-GS (InternData-N1 Gaussian Splatting 管线)：一个导航数据收集管线，在坐标对齐的网格模型和 3D 高斯模型上执行规划和渲染。场景是自定义的室内环境，每个模型大约有 300 万个高斯点。

• Nav-Mesh (InternData-N1 Blender 管线)：一个传统的管线，从 3D-FRONT 数据集中采样端点。它执行 A-star 路径规划并利用 Blender 进行渲染。

• GenManip (InternData-M1 管线)：在 Objaverse 数据集上执行物体抓取和放置任务。

• SimBox (InternData-N1 管线)：在 Objaverse 数据集上执行垃圾分类任务。

5.1 性能评估

我们评估了 Nimbus 相对于未优化基线（Baseline）的端到端性能。我们的评估涵盖了四个不同的管线：用于导航的 Nav-GS 和 Nav-Mesh，以及用于操作的 GenManip 和 SimBox。我们为 Nav-GS 生成 150 条轨迹，为 Nav-Mesh 生成 450 条（每个场景 150 条），为 GenManip 和 SimBox 各生成 200 条。考虑到任务复杂性和数据量的内在异构性，我们关注每个管线内的相对加速比（Baseline vs. Nimbus），而不是绝对的跨管线比较。

5.1.1 端到端吞吐量分析

图12 端到端性能对比

为了找出这些收益的来源，我们分解了关键阶段的延迟分布。如图13所示，Baseline 在串行模式下运行，其中规划和渲染紧密耦合。相比之下，Nimbus（如图14）解耦了这些阶段。至关重要的是，在我们的流水线并行和动态调度下，端到端延迟不再是各个阶段延迟的累加和，而是由瓶颈阶段决定的。

图13 基准管线的延迟耗时分解

图14 Nimbus实现各管线的延迟耗时分解

在导航任务中，渲染阶段和存储阶段的开销占主导地位，在这里引入完全解耦的流水线会产生序列化和 IPC 开销，从而抵消潜在的并发收益。因此，Nimbus 保持规划和渲染的同步执行，转而专注于两个有针对性的优化：

对于 GenManip 和 SimBox，Nimbus 利用规划和渲染之间的解耦，实现了：

• 流水线重叠： 通过将规划和渲染隔离到不同的 ComputeWorker 中，我们重叠了它们的执行。规划成本有效地在渲染窗口内被摊销。为了进一步减少瓶颈延迟，我们通过多个渲染器 ComputeWorker 增加了渲染并发性。

• 动态资源重分配： 为了缓解尾部延迟，调度器从完成的规划器动态回收资源以生成额外的渲染器。这种自适应重分配确保计算资源保持饱和，最大限度地减少渲染尾部的空闲时间。

5.1.2 有效吞吐量的理论分析

5.2 可扩展性

当将任务扩展到更大的量级时，需要额外的计算节点，这不可避免地引入了两个关键挑战：全局负载不均和故障恢复。这两个挑战都严重影响了框架的可扩展性。

我们通过具有全局负载均衡器的 master-worker 架构解决了由任务异构性和硬件性能差异引起的负载不均问题，并通过 Supervisor 机制确保了运行时鲁棒性，从而实现了出色的可扩展性。

我们在 8 到 128 个 GPU 的集群上执行 24 小时的数据生成任务来评估系统的可扩展性。值得注意的是，对于 Nav-Mesh 管线，我们的评估包含 2,560 个不同的场景。我们还进行了启用和禁用动态负载均衡参数（dynload）的比较实验，其中启用 dynload 会激活全局负载均衡器。结果如图15所示。

图15 24小时数据生成量与扩展能力

理论上，吞吐量应随 GPU 数量线性扩展。我们的实验结果表明，当从 8 个 GPU 扩展到 128 个 GPU 时，系统实现了大约 86% 的线性扩展效率，表明了出色的可扩展性。在整个 24 小时的测试期间，系统保持稳定运行，没有节点故障或任务故障，证明了卓越的鲁棒性。

与完美线性扩展的偏差主要归因于两个因素。首先，任务执行表现出固有的长尾效应。即使有负载均衡，最后一批任务的完成时间也会影响整体吞吐量测量，并且随着节点数量的增加，这种效应变得更加明显。其次，负载均衡器的调度效率受任务粒度的影响。随着节点数量的增加，分配给每个节点的任务数量相应减少，这降低了全局负载均衡器可用的调度灵活性。在我们的 128 GPU 配置中，2,560 个场景平均每个 GPU 仅分配大约 20 个场景。这种情况下，每个节点在这种相对较小的任务池中，不足以让负载均衡器充分发挥其调度能力，从而限制了整体资源利用效率。

值得注意的是，尽管存在这些因素，该系统得益于 master-worker 架构与 Supervisor 机制之间的有效协调，在大规模集群上保持了高资源利用率。这一结果验证了我们的架构设计能够在生产环境中支持大规模数据生成需求。

6. 结语

Nimbus 精准直击具身仿真合成数据生产的“碎片化、低效率、不稳定”三大痛点，通过创新的四层模块化架构提供了系统级解决方案。其中，调度优化层实现统一的动态流水线并行调度与容错机制，阶段执行层定义合成管线全生命周期的标准化执行抽象，功能组件层完成多类管线组件的归一化封装，后端优化层则针对各类渲染器落地通用型性能优化。这种分层解耦的设计，让统一的调度与优化原语能够无缝适配异构数据生成管线，无需开发者重写底层场景逻辑。

实验数据验证了框架的价值：依托调度优化层的动态流水线并行能力，以及后端优化层的渲染器专项优化，管线端到端性能较优化前提升 2~3 倍；同时，其完善的容错设计保障了大规模 GPU 集群的稳健连续运行，充分满足超大规模数据生成的稳定性需求，支撑 InternData 系列数据集生成。

对比深度学习领域的流水并行方式，比如 1F1B 和 Zero-Bubble 等方案，其关于“气泡最优性”的分析通常基于阶段耗时成本模型，然而在实际部署中，系统往往会受到执行时间波动和掉队者（stragglers）的影响，并且数据生成涉及异步、事件驱动的编排，具有动态参与、故障重试以及异构延迟等特性。Nimbus 的动态流水并行和容错设计则是填补了这一缺失。

综上，我们从行业背景分析、顶层架构设计到底层技术优化多维度协同发力，成功将传统“作坊式”的合成数据管线，升级为一套可大规模部署、统一高效且稳定可靠的“智能数据工厂”。我们始终坚信，坚实的基础设施是驱动上层算法与模型创新的核心关键，而这一升级的核心价值，正是将研究者从繁琐低效、稳定性差的数据工程工作中彻底解放出来，使其能够聚焦于更具创造性的算法研究与模型迭代。