Zeyu He1, Yuchang Zhang1, Yuanzhen Zhou1, Miao Tao1, Hengjie Li1,2?, Hui Wang1, Yang Tian1, Jia Zeng1, Tai Wang1, Wenzhe Cai1, Yilun Chen1, Ning Gao1, Jiangmiao Pang1

摘要

擴(kuò)大數(shù)據(jù)規(guī)模和多樣性對(duì)于泛化具身智能至關(guān)重要。雖然合成數(shù)據(jù)生成為昂貴的物理數(shù)據(jù)采集提供了可擴(kuò)展的替代方案，但現(xiàn)有的流水線仍然是碎片化的且針對(duì)特定任務(wù)。這種孤立導(dǎo)致顯著的工程效率低下和系統(tǒng)不穩(wěn)定，無法支持基礎(chǔ)模型訓(xùn)練所需的持續(xù)、高吞吐量數(shù)據(jù)生成。為應(yīng)對(duì)這些挑戰(zhàn)，我們提出了 Nimbus，一個(gè)統(tǒng)一的合成數(shù)據(jù)生成框架，旨在整合異構(gòu)的導(dǎo)航和操作流水線。Nimbus 引入了模塊化四層架構(gòu)，采用解耦執(zhí)行模型，將軌跡規(guī)劃、渲染和存儲(chǔ)分離為異步階段。通過實(shí)現(xiàn)動(dòng)態(tài)流水線調(diào)度、全局負(fù)載均衡、分布式容錯(cuò)和后端特定渲染優(yōu)化，該系統(tǒng)最大化了 CPU、GPU 和 I/O 資源的利用率。我們的評(píng)估表明，與未優(yōu)化的基線相比，Nimbus 實(shí)現(xiàn)了 2–3×的端到端吞吐量提升，并確保在大規(guī)模分布式環(huán)境中穩(wěn)健、長(zhǎng)期的運(yùn)行。該框架作為 InternData 套件的生產(chǎn)骨干，實(shí)現(xiàn)無縫跨域數(shù)據(jù)合成。

1 引言

具身智能（embodied intelligence）的進(jìn)步從根本上依賴于兩項(xiàng)核心能力：導(dǎo)航（navigation）和操作（manipulation）。這些基本能力使智能體（agents）能夠在環(huán)境中自主移動(dòng)并與物體進(jìn)行物理交互，從而成為人工通用智能（Artificial General Intelligence, AGI）的基本構(gòu)建模塊?，F(xiàn)有工作表明，進(jìn)一步擴(kuò)大數(shù)據(jù)規(guī)模和多樣性可以加速模型能力的增長(zhǎng)。然而，這些努力大多依賴于真實(shí)世界的數(shù)據(jù)收集，而數(shù)據(jù)獲取成本仍然高得令人望而卻步。具體而言，硬件部署的高資本成本和收集器培訓(xùn)的時(shí)間開銷，使得物理流程無法滿足現(xiàn)代基礎(chǔ)模型訓(xùn)練的高容量、多模態(tài)需求。

合成數(shù)據(jù)流程（Synthetic data pipelines）提供了一種可擴(kuò)展的替代方案，通過在虛擬環(huán)境中生成可控、多樣的數(shù)據(jù)來繞過物理數(shù)據(jù)瓶頸。然而，現(xiàn)有的合成數(shù)據(jù)流程缺乏統(tǒng)一框架，這限制了當(dāng)前解決方案只能專門針對(duì)導(dǎo)航或操作任務(wù)進(jìn)行定制。這一缺陷引發(fā)了兩個(gè)核心問題：首先是效率低下，表現(xiàn)為工程冗余以及優(yōu)化和加速策略缺乏通用性；其次是不穩(wěn)定性，由于缺乏標(biāo)準(zhǔn)化的集群調(diào)度（cluster scheduling）和容錯(cuò)（fault tolerance）機(jī)制，阻礙了大規(guī)模數(shù)據(jù)集所需的持續(xù)、長(zhǎng)周期數(shù)據(jù)生成。

為彌合這一差距，我們提出了 Nimbus，這是一個(gè)統(tǒng)一的合成數(shù)據(jù)生成框架，旨在整合異構(gòu)的導(dǎo)航和操作流程。具體而言，Nimbus 圍繞分層設(shè)計(jì)和一組多層優(yōu)化構(gòu)建。在框架層面，我們引入了一個(gè)四層架構(gòu)，清晰地分離了：調(diào)度優(yōu)化和容錯(cuò)（Schedule Opt Layer）、統(tǒng)一的 Load-Plan-Render-Store 生命周期運(yùn)行器抽象（Stage Runner Layer）、面向接口的可復(fù)用導(dǎo)航和操作組件（Components Layer），以及集成基于 Ray的環(huán)境和不同模擬器及渲染器后端的高性能運(yùn)行時(shí)（Backend Opt Layer）。這種模塊化使得相同的調(diào)度和優(yōu)化原語可以應(yīng)用于異構(gòu)流程（例如 InternData-N1 導(dǎo)航和 InternData-A1/M1 操作），而無需重寫場(chǎng)景邏輯。

在 Schedule Opt Layer，我們實(shí)現(xiàn)了一個(gè)兩級(jí)優(yōu)化棧，由 pipeline parallelism 和 distributed optimization 組成。在 pipeline parallelism 中，我們將傳統(tǒng)的單體 pipeline 解耦為異步執(zhí)行模型。Trajectory planning (CPU-bound)、rendering (GPU-bound) 和 storage (I/O-bound) 在獨(dú)立的 worker pools 中執(zhí)行，并采用動(dòng)態(tài) pipeline scheduling。這一設(shè)計(jì)減少了阻塞，并最大化了 CPU、GPU 和 I/O 的利用率。在 distributed optimization 中，我們致力于實(shí)現(xiàn)集群規(guī)模的高效率和高可用性。我們采用 global balancer 和 per-worker supervisors 來實(shí)現(xiàn) load balancing、liveness monitoring 和 automatic recovery。最后，在 Backend Opt Layer，我們針對(duì)主要 backends（Gaussian Splatting、Blender 和 Isaac Sim）優(yōu)化關(guān)鍵 rendering paths。通過應(yīng)用 accelerated rasterization 和 batched/stacked rendering 等技術(shù)，進(jìn)一步提高了 per-process throughput。綜合這些設(shè)計(jì)，相比未優(yōu)化的 baseline，我們實(shí)現(xiàn)了 2-3 倍的 end-to-end throughput 提升，并在分布式環(huán)境中實(shí)現(xiàn)了穩(wěn)定、持續(xù)的數(shù)據(jù)生成。

本文其余部分組織如下：第2節(jié)詳細(xì)介紹InternData系列數(shù)據(jù)集及其生成流程；第3節(jié)分析導(dǎo)航、操作及相關(guān)框架的現(xiàn)有文獻(xiàn)；第4節(jié)描述Nimbus架構(gòu)及其集成策略；第5節(jié)介紹我們的優(yōu)化技術(shù)，包括階段解耦、調(diào)度器設(shè)計(jì)和分布式容錯(cuò)；第6節(jié)評(píng)估框架的性能；第7節(jié)總結(jié)并展望未來方向。

2 背景

2.1 InternData-N1

InternData-N1 一個(gè)用于視覺 - 語言導(dǎo)航（VLN）的大規(guī)模合成數(shù)據(jù)集，涵蓋超過 3,000 個(gè)室內(nèi)場(chǎng)景，包含 5,350 萬張第一人稱視角（FPV）圖像和 80 萬條語言指令（約 4,840 公里的軌跡）。它包含三個(gè)互補(bǔ)的子集（VLN-N1/VLN-CE/VLN-PE），分別用于支持通用導(dǎo)航預(yù)訓(xùn)練、細(xì)粒度指令跟隨和 sim-to-real 遷移。

圖 1 展示了合成工作流程，可概括如下：

場(chǎng)景庫(kù)構(gòu)建。整合六個(gè)開源室內(nèi)場(chǎng)景庫(kù)（Replica、Matterport3D、Gibson、3D-Front、HSSD 和 HM3D），以覆蓋多樣化的房間布局和場(chǎng)景類別。

路徑規(guī)劃。通過三階段流程生成無碰撞的平滑軌跡：(i) 為每層構(gòu)建歐幾里得符號(hào)距離場(chǎng)（ESDF），并使用 A-star 在隨機(jī)采樣的起點(diǎn) - 終點(diǎn)對(duì)之間規(guī)劃初始全局路徑；(ii) 基于 ESDF 優(yōu)化轉(zhuǎn)向點(diǎn)以保持障礙物間距；(iii) 應(yīng)用 Bézier 平滑以確保連續(xù)運(yùn)動(dòng)。

觀測(cè)渲染。使用 Blender-Proc 逐幀渲染規(guī)劃好的軌跡，以獲得 FPV RGB 圖像和深度圖。

指令標(biāo)注。從幾何線索（如急轉(zhuǎn)彎或經(jīng)過地標(biāo)）檢測(cè)關(guān)鍵幀，并將軌跡分割為子段；使用多模態(tài)模型（LLaVA-OneVision）生成細(xì)粒度的步驟指令；然后用語言模型（Qwen3-72B）重寫并匯總子指令為單一的長(zhǎng)程指令。

2.2 InternData-A1

InternData-A1是一個(gè)高保真合成操作數(shù)據(jù)集，用于預(yù)訓(xùn)練通用視覺 - 語言 - 動(dòng)作（VLA）策略 。該數(shù)據(jù)集涵蓋四種機(jī)器人形態(tài)（Genie-1、Franka Panda、AgileX Split Aloha 和 ARX Lift-2），包含 18 種技能，跨越 227 個(gè)室內(nèi)場(chǎng)景，總計(jì) 7,433 小時(shí)的交互數(shù)據(jù)。

如圖2所示，InternData-A1 通過一個(gè)完全解耦且可組合的流水線進(jìn)行合成：

??環(huán)境構(gòu)建（Environment construction）。給定任務(wù)模板，從資產(chǎn)庫(kù)中檢索與任務(wù)相關(guān)的機(jī)器人、場(chǎng)景和物體：機(jī)器人以經(jīng)過驗(yàn)證的USD具身模型形式提供；場(chǎng)景來源于GRUtopia GRScenes-100，帶有標(biāo)注的操作區(qū)域；物體包括剛性、關(guān)節(jié)式、可變形和流體類別，均配備高保真物理模型（例如，剛性物體使用AnyGrasp生成的抓取姿態(tài)，可變形物體和流體則使用專用模擬器）。

??技能組合（Skill composition）。通過從技能庫(kù)中選擇并組合原子技能來構(gòu)建任務(wù)。每個(gè)技能都實(shí)現(xiàn)為腳本化策略，將物體/機(jī)器人狀態(tài)和約束映射到一系列末端執(zhí)行器6D航點(diǎn)，從而將高級(jí)邏輯與低級(jí)插值和控制解耦（例如Pick、Place、Push、Goto-pose和Gripper-action）。

??域隨機(jī)化（Domain randomization）。對(duì)外觀和動(dòng)力學(xué)進(jìn)行系統(tǒng)性隨機(jī)化，以縮小仿真到現(xiàn)實(shí)的差距：擾動(dòng)相機(jī)外參（主相機(jī)和腕部相機(jī)），采樣多樣化的HDR環(huán)境貼圖和光照參數(shù)，在物體類別內(nèi)交換實(shí)例，隨機(jī)化桌子/背景布局；此外，隨機(jī)化初始機(jī)器人/物體姿態(tài)以及抓取/接觸區(qū)域的隨機(jī)性（例如，從最高置信度的AnyGrasp候選中采樣）。

??軌跡生成與存儲(chǔ)（Trajectory generation and storage）。給定航點(diǎn)序列，使用CuRobo進(jìn)行關(guān)節(jié)空間規(guī)劃和密集插值；記錄多視角RGB觀測(cè)數(shù)據(jù)，包括相機(jī)參數(shù)、機(jī)器人狀態(tài)和控制命令、物體元數(shù)據(jù)以及語言指令（可選導(dǎo)出深度、定位標(biāo)簽和邊界框）。僅成功的rollout會(huì)被渲染并寫入數(shù)據(jù)集，最終轉(zhuǎn)換為L(zhǎng)eRobot格式。

2.3 InternData-M1

InternData-M1 是一個(gè)合成桌面操作數(shù)據(jù)集，旨在實(shí)現(xiàn)長(zhǎng)程推理和空間定位。它包含約 244,000 個(gè)仿真演示，具有密集的動(dòng)作和幾何標(biāo)注，并整合了超過 80,000 個(gè)開放詞匯對(duì)象以促進(jìn)泛化能力。

圖3總結(jié)了LLM驅(qū)動(dòng)的仿真工作流程，具體步驟如下：

??仿真資產(chǎn)。在Isaac Sim中構(gòu)建大型資產(chǎn)庫(kù)，包括超過14,000個(gè)帶標(biāo)簽的物體、200張桌子和近1,700種紋理/光照配置，以提供廣泛的物理和視覺多樣性。

??物理仿真與任務(wù)合成。通過隨機(jī)化物體布局和光照，并利用特權(quán)信號(hào)（如meshes和robot states）計(jì)算抓取候選和運(yùn)動(dòng)規(guī)劃來合成軌跡。每條軌跡都在閉環(huán)執(zhí)行中進(jìn)行驗(yàn)證，并由scene-graph validator檢查；僅保留成功且物理一致的rollouts。

??規(guī)劃與視覺渲染解耦。通過先記錄結(jié)構(gòu)化規(guī)劃軌跡（如joint states和object poses），然后在隨機(jī)化的視角、材質(zhì)和光照下重放，將規(guī)劃與渲染解耦。相機(jī)校準(zhǔn)通過ArUco markers進(jìn)行，以使intrinsic/extrinsic參數(shù)與真實(shí)傳感器對(duì)齊，同時(shí)渲染器生成RGB圖像和密集空間監(jiān)督（如2D boxes、end-effector traces和精確keypoints）。

??VLM/VLA數(shù)據(jù)打包。將中間表示轉(zhuǎn)換為統(tǒng)一的visual question answering (VQA)格式，用于VLM預(yù)訓(xùn)練。通過將動(dòng)作與自然語言指令和空間標(biāo)注配對(duì)，該流程為affordance recognition、trajectory prediction和multi-step planning派生輔助監(jiān)督，橋接語義推理與具身執(zhí)行。

3 相關(guān)工作

3.1 導(dǎo)航數(shù)據(jù)生成

具身導(dǎo)航任務(wù)主要依賴于預(yù)先構(gòu)建的 3D 環(huán)境和靜態(tài)任務(wù)分布。雖然主流數(shù)據(jù)源利用了大規(guī)模室內(nèi)掃描數(shù)據(jù)，如 Matterport3D和 Habitat-Matterport 3D (HM3D)，但其獲取過程需要組織一個(gè)資源密集型的流程，涉及專用硬件、物理布景以及復(fù)雜的后處理。

在 VLN 領(lǐng)域，主流方法是將靜態(tài)環(huán)境資產(chǎn)與人工生成的標(biāo)注相結(jié)合。諸如 R2R和 RxR等基準(zhǔn)測(cè)試受限于有限的環(huán)境，依賴勞動(dòng)密集型眾包流程為預(yù)定義路徑生成指令。盡管后續(xù)工作如 CVDN和 REVERIE引入了多輪對(duì)話和指代表達(dá)式以增強(qiáng)語義復(fù)雜性，但由于場(chǎng)景選擇、軌跡采樣和驗(yàn)證需要人工干預(yù)，它們產(chǎn)生了顯著的開銷。因此，擴(kuò)展這些數(shù)據(jù)集的邊際成本仍然高得令人望而卻步。

相反，ObjectNav及相關(guān)目標(biāo)驅(qū)動(dòng)型任務(wù)需要嚴(yán)格的場(chǎng)景語義，必須提供精確的對(duì)象列表、實(shí)例分割和類別標(biāo)簽，以支持離線任務(wù)采樣。雖然 Habitat 等平臺(tái)通過對(duì)掃描資產(chǎn)（如 HM3D）應(yīng)用基于規(guī)則的生成來自動(dòng)化這一過程，但其底層邏輯通常與特定代碼庫(kù)緊密耦合。由于缺乏針對(duì)任務(wù)模板、軌跡采樣和元數(shù)據(jù)組織的統(tǒng)一抽象，導(dǎo)致模塊化程度不足，嚴(yán)重阻礙了跨項(xiàng)目的可復(fù)用性。

最終，當(dāng)代導(dǎo)航數(shù)據(jù)生成遵循的是混合現(xiàn)實(shí)世界掃描與模擬的工作流程。構(gòu)建成本主要集中在物理掃描和后處理階段，而任務(wù)生成仍然受限于人工標(biāo)注或脆弱、臨時(shí)的腳本。因此，數(shù)據(jù)集更新表現(xiàn)為離散的、靜態(tài)的發(fā)布，而非持續(xù)的、演進(jìn)式的生產(chǎn)流程。

3.2 操作數(shù)據(jù)生成

與導(dǎo)航任務(wù)不同，操作數(shù)據(jù)生成在過去三年中沿著三個(gè)不同的方向發(fā)展：(1) 大規(guī)模物理遙操作，代表傳統(tǒng)的真實(shí)世界演示范式；(2) 通用操作接口（UMI）風(fēng)格的方法（如 UMI、Fast-UMI），將人類操作者與機(jī)器人形態(tài)解耦，以在自然環(huán)境中捕捉類機(jī)器人軌跡；(3) 合成數(shù)據(jù)生成，通過演示增強(qiáng)或基于規(guī)則的批處理來編排仿真環(huán)境。

物理遙操作與多機(jī)器人聚合。?跨機(jī)構(gòu)倡議（如 Open X-Embodiment ）匯聚了來自 34 個(gè)實(shí)驗(yàn)室和超過 60 個(gè)子數(shù)據(jù)集的數(shù)據(jù)，構(gòu)建了大規(guī)模的真實(shí)世界軌跡存儲(chǔ)庫(kù)。與此同時(shí)，π0 和 RoboMIND 等系統(tǒng)在單一機(jī)構(gòu)內(nèi)執(zhí)行統(tǒng)一的采集協(xié)議，以生成標(biāo)準(zhǔn)化、多機(jī)器人的語料庫(kù)。近期的工作（包括 AgiBotWorld和 Galaxea）將這一范式擴(kuò)展到多樣化的開放世界場(chǎng)景，產(chǎn)生了高分辨率、長(zhǎng)時(shí)域的軌跡數(shù)據(jù)。盡管這些工作顯著擴(kuò)展了真實(shí)世界數(shù)據(jù)的規(guī)模，但它們面臨著系統(tǒng)性的可擴(kuò)展性瓶頸：需要專用占用硬件資源、嚴(yán)重依賴專業(yè)遙操作員，并在合規(guī)性、隱私和異構(gòu)平臺(tái)集成方面產(chǎn)生大量開銷。

為減少工程摩擦，IRIS等沉浸式界面利用 XR 和點(diǎn)云渲染來統(tǒng)一跨平臺(tái)的遙操作視圖。與此同時(shí)，工業(yè)界參與者（如 Tesla、Figure AI）協(xié)調(diào)大規(guī)模機(jī)隊(duì)以收集專有行為數(shù)據(jù)。然而，這些工業(yè)流水線仍然閉源，掩蓋了其內(nèi)部編排邏輯，使外部研究人員無法利用其系統(tǒng)抽象。

UMI類接口與代理設(shè)備。?第二種方法將操作員與機(jī)器人完全解耦。UMI、DexUMI和 DexCap 等方法采用代理設(shè)備來捕捉野外（in-the-wild）演示，并將其離線映射到目標(biāo)機(jī)器人形態(tài)。例如，UMI 利用配備多模態(tài)傳感器的低成本手持界面，使非專家也能演示復(fù)雜的動(dòng)態(tài)操作。Fast-UMI 進(jìn)一步抽象了硬件依賴性，采用商業(yè)追蹤技術(shù)簡(jiǎn)化校準(zhǔn)流程，并利用專用工具鏈進(jìn)行數(shù)據(jù)轉(zhuǎn)換。

雖然 UMI 類接口無需占用昂貴的機(jī)器人硬件即可保留真實(shí)世界的物理特性，但它們?nèi)跃€性受限于人類演示時(shí)間。此外，從代理設(shè)備到機(jī)器人的轉(zhuǎn)換帶來了顯著的工程復(fù)雜性，需要進(jìn)行嚴(yán)格的坐標(biāo)映射、時(shí)空對(duì)齊以及統(tǒng)一控制接口的設(shè)計(jì)。

合成數(shù)據(jù)：增強(qiáng)與規(guī)則驅(qū)動(dòng)生成。?合成生成方法以物理真實(shí)性換取可擴(kuò)展性，大致可分為演示增強(qiáng)和規(guī)則驅(qū)動(dòng)生成兩類。MimicGen是增強(qiáng)方法的典型代表，它通過子任務(wù)分割和場(chǎng)景擾動(dòng)，將少量人類演示種子集程序化擴(kuò)展為數(shù)千條軌跡。RoboCasa及其后續(xù)版本 RoboCasa365 將這一邏輯集成到高保真家庭仿真平臺(tái)中， effectively 作為演示工廠運(yùn)作。相反，規(guī)則驅(qū)動(dòng)的數(shù)據(jù)生成（如 InternData-M1 pipeline 和 InternData-A1 pipeline）則從預(yù)定義的任務(wù)腳本和物理約束中生成大規(guī)模數(shù)據(jù)集。與 RLBench或 ManiSkill的固定基準(zhǔn)不同，這些工作強(qiáng)調(diào)將合成數(shù)據(jù)作為一種服務(wù)（data as a service），提供接口使研究者能夠復(fù)用資產(chǎn)構(gòu)建邏輯。

仿真合成將數(shù)據(jù)生成的邊際成本轉(zhuǎn)化為計(jì)算開銷。雖然這使得能夠以極少的人工干預(yù)生成數(shù)百萬條軌跡，但也需要健壯的驗(yàn)證機(jī)制來過濾物理上不合理的數(shù)據(jù)，并彌合 sim-to-real 差距。

總結(jié)：以數(shù)據(jù)集為中心的瓶頸?三種主流范式揭示了一個(gè)關(guān)鍵的系統(tǒng)性差距?；谖锢砗蚒MI的方法受到硬件和人力的限制，而仿真則將瓶頸轉(zhuǎn)移到了資產(chǎn)和腳本構(gòu)建上。關(guān)鍵在于，當(dāng)前的格局是以數(shù)據(jù)集為中心的：一旦語料庫(kù)確定，底層的生成就實(shí)際上被固定了。研究人員只能使用靜態(tài)數(shù)據(jù)集，無法在不重新設(shè)計(jì)整個(gè)工作流程的情況下逐步擴(kuò)展任務(wù)定義或傳感器配置。這種缺乏可復(fù)用、可編排的系統(tǒng)架構(gòu)的現(xiàn)狀，促使了Nimbus的設(shè)計(jì)。

3.3 數(shù)據(jù)生成的系統(tǒng)框架

從系統(tǒng)角度來看，現(xiàn)有框架可分為三類：任務(wù)專用生成工具、仿真平臺(tái)和通用工作流引擎。

第一類以 MimicGen 為代表，將數(shù)據(jù)擴(kuò)展形式化為可編程流水線，但將控制限制在任務(wù)級(jí)規(guī)則修改。

第二類包括 RoboCasa，將資產(chǎn)和采集工具集成到統(tǒng)一平臺(tái)中。雖然在其特定領(lǐng)域內(nèi)有效，但這些系統(tǒng)強(qiáng)制執(zhí)行嚴(yán)格的邊界；其內(nèi)部流水線與特定仿真后端緊密耦合，阻礙了向新模態(tài)或任務(wù)的遷移。

第三類包括 Apache Airflow 和 Prefect等通用編排器。雖然這些系統(tǒng)在工業(yè) ETL 領(lǐng)域已相當(dāng)成熟，但它們將任務(wù)視為黑盒操作符，缺乏針對(duì)機(jī)器人 - 環(huán)境 - 傳感器拓?fù)涞脑橄?。它們針?duì)批處理進(jìn)行了優(yōu)化，而非具身 AI 所需的實(shí)時(shí)、有狀態(tài)控制循環(huán)。此外，它們跟蹤的是文件級(jí)元數(shù)據(jù)，而非軌跡、場(chǎng)景狀態(tài)和策略版本之間的語義關(guān)聯(lián)。

在分布式深度學(xué)習(xí)領(lǐng)域，流水線并行訓(xùn)練調(diào)度（如 Megatron-LM 的 1F1B和 Zero-Bubble Pipeline Parallelism）通過在同步訓(xùn)練語義下優(yōu)化跨層劃分流水線階段的微批次執(zhí)行順序來提高吞吐量，旨在減少流水線氣泡。

這些方法圍繞一組固定的流水線階段進(jìn)行設(shè)計(jì)，具有明確的階段間激活/梯度依賴關(guān)系以及正確梯度計(jì)算所需的一致性約束，其氣泡相關(guān)的最優(yōu)性通常在階段時(shí)間成本模型下進(jìn)行分析，而實(shí)際部署可能會(huì)受到執(zhí)行時(shí)間變化和拖尾者的影響。

相比之下，數(shù)據(jù)采集會(huì)話涉及異步、事件驅(qū)動(dòng)的編排，具有動(dòng)態(tài)參與、失敗/重試和異構(gòu)延遲等特點(diǎn)，這需要與層/微批次級(jí)訓(xùn)練流水線不同的調(diào)度抽象和目標(biāo)。

因此，目前仍缺乏一個(gè)能夠跨越真實(shí)和仿真環(huán)境、統(tǒng)一采集和生成、并為具身任務(wù)提供原生編排的通用框架。我們的 Nimbus 通過引入專門為具身 AI 數(shù)據(jù)生命周期設(shè)計(jì)的系統(tǒng)級(jí)抽象來解決這一問題。

4 架構(gòu)

Nimbus 采用模塊化四層架構(gòu)，旨在統(tǒng)一異構(gòu)合成數(shù)據(jù)流水線，同時(shí)最大化資源效率。如圖 4 所示，該框架分為 Components Layer、Stage Runner Layer、Schedule Opt Layer 和 Backend Opt Layer。這種分層設(shè)計(jì)將高層編排與底層執(zhí)行解耦，使得在多樣化的導(dǎo)航和操作任務(wù)中能夠?qū)崿F(xiàn)統(tǒng)一的調(diào)度和優(yōu)化原語。

4.1 Stage Runner Layer

Stage Runner Layer 定義了標(biāo)準(zhǔn)化的 Load-Plan-Render-Store 生命周期，將生成工作流抽象為四個(gè)階段。Load Stage 處理資產(chǎn)導(dǎo)入和域隨機(jī)化，以擴(kuò)展數(shù)據(jù)多樣性。Plan Stage 根據(jù)任務(wù)規(guī)范生成物理有效的運(yùn)動(dòng)序列或動(dòng)作計(jì)劃。Render Stage 將這些序列可視化為高保真多模態(tài)傳感器觀測(cè)數(shù)據(jù)（RGB、Depth 等）。最后，Store Stage 管理數(shù)據(jù)序列化，將異構(gòu)輸出聚合為統(tǒng)一的持久化格式。

為了標(biāo)準(zhǔn)化每個(gè)階段的執(zhí)行，我們定義了五個(gè)抽象基迭代器，強(qiáng)制執(zhí)行嚴(yán)格的輸入/輸出協(xié)議，如表 1 所示。在 Load Stage，我們提供 BaseLoader 和 BaseRandomizer 來共同構(gòu)建場(chǎng)景。具體而言，BaseLoader 導(dǎo)入配置以輸出場(chǎng)景對(duì)象，然后由 BaseRandomizer 處理以修改屬性進(jìn)行域隨機(jī)化。對(duì)于其余階段，BasePlanner 接收?qǐng)鼍耙陨绍壽E序列；BaseRenderer 從這些序列合成觀測(cè)數(shù)據(jù)；BaseWriter 將序列和觀測(cè)數(shù)據(jù)序列化到存儲(chǔ)。通過鏈接這些迭代器，Nimbus 以統(tǒng)一的方式編排端到端的合成數(shù)據(jù)生成流程。

4.2 組件層

組件層在 Stage Runner 定義的統(tǒng)一接口內(nèi)，實(shí)現(xiàn)導(dǎo)航和操作的具體邏輯。該設(shè)計(jì)通過強(qiáng)制執(zhí)行嚴(yán)格的接口契約，解決了現(xiàn)有流水線的碎片化問題，從而實(shí)現(xiàn)代碼復(fù)用和無縫集成。如圖 5 所示，Nimbus 通過靈活的組件組合，集成了獨(dú)立的 Navigation 和 Manipulation 工作流。

4.2.1 導(dǎo)航組件與集成

Navigation 組件將通用生命周期適配到 InternData-N1 流水線，解決了基于 mesh 的資產(chǎn)與 Gaussian Splatting 資產(chǎn)之間的異構(gòu)性問題。

多功能組件套件。我們?cè)谡麄€(gè)生成生命周期中實(shí)現(xiàn)了一套全面的組件來處理多樣化的數(shù)據(jù)格式。在加載階段（Load Stage），我們提供 GSMeshLoader 用于處理與 GS 資產(chǎn)對(duì)齊的代理網(wǎng)格（proxy meshes），BProcObjLoader 用于標(biāo)準(zhǔn) .obj 文件，以及 BProc3DFrontLoader 用于解析來自 3D-FRONT 數(shù)據(jù)集的語義布局。為了擴(kuò)展數(shù)據(jù)多樣性，BProc3DFrontRandomizer 應(yīng)用特定領(lǐng)域的增強(qiáng)，包括光照、紋理和姿態(tài)隨機(jī)化。在規(guī)劃階段（Plan Stage），NavPlanner 使用 A-star 路徑查找生成無碰撞軌跡。這可以通過特定數(shù)據(jù)集的邏輯（例如 BProc3DFrontPlanner）進(jìn)行擴(kuò)展，以在結(jié)構(gòu)化環(huán)境中強(qiáng)制實(shí)施布局約束。對(duì)于渲染階段（Render Stage），我們采用 SCGSRenderer 進(jìn)行高保真 GS 光柵化，以及 BlenderProcRenderer 進(jìn)行照片級(jí)真實(shí)的網(wǎng)格渲染。最后，在存儲(chǔ)階段（Store Stage），NavWriter 聚合軌跡姿態(tài)、多模態(tài)觀測(cè)和場(chǎng)景元數(shù)據(jù)，將它們序列化為統(tǒng)一的 InternData-N1 格式。

管道集成策略。為了協(xié)調(diào) GS 和 Mesh 資產(chǎn)的不同特性，我們采用差異化的組件組合策略，如圖 5 所示。對(duì)于 Mesh 資產(chǎn)，管道可以根據(jù)格式復(fù)雜度進(jìn)行配置。對(duì)于 GS 資產(chǎn)，其提供更優(yōu)越的渲染保真度但缺乏路徑規(guī)劃所需的幾何信息，我們實(shí)現(xiàn)了一個(gè)基于代理的管道：GSMeshLoader → NavPlanner → SCGSRenderer → NavWriter。具體而言，GSMeshLoader 攝入與 GS 坐標(biāo)系對(duì)齊的代理網(wǎng)格，使 NavPlanner 能夠計(jì)算物理上有效的軌跡。隨后使用 SCGSRenderer 渲染這些軌跡，有效地將幾何有效性與視覺保真度結(jié)合起來。

4.2.2 操作組件與集成

Manipulation 組件統(tǒng)一了 InternData-A1 pipeline 和 InternData-M1 pipeline 的異構(gòu)工作流。與用于 navigation 的靈活組合方式不同，我們采用 Unified Adapter Components 配合標(biāo)準(zhǔn)化的 Workflow API 來管理機(jī)器人仿真的復(fù)雜性。

Unified Adapter Components。?我們定義了一套 Env components（例如 EnvLoader、EnvPlanner 等），它們作為底層仿真器（如 IsaacSim 和 Sapien）的抽象封裝層。這些 components 將 InternData-A1 和 InternData-M1 pipelines 的領(lǐng)域特定操作映射到標(biāo)準(zhǔn)化的 Nimbus 生命周期階段。

Workflow API。?Unified Adapter Components 的實(shí)現(xiàn)基于標(biāo)準(zhǔn)化的 Workflow API，該 API 提供三個(gè)核心能力：

??Encapsulation（封裝）：?封裝 pipeline 邏輯和仿真接口，保護(hù) component 層免受后端差異的影響。

??Decoupling（解耦）：?通過定義 reset、randomization、generate seq、seq replay 和 save 等核心接口，將詳細(xì)的生成邏輯與框架的調(diào)度和優(yōu)化機(jī)制嚴(yán)格分離。

??Extensibility（可擴(kuò)展性）：?開發(fā)者通過遵循這些接口實(shí)現(xiàn)特定的 workflows，例如為 InternData-A1 pipeline 實(shí)現(xiàn)的 GenManipWorkflow 和為 InternData-M1 pipeline 實(shí)現(xiàn)的 SimBoxWorkflow。框架的 Env components 調(diào)用這些標(biāo)準(zhǔn)化方法，無需關(guān)心底層實(shí)現(xiàn)細(xì)節(jié)。

4.3 Schedule Opt Layer

Schedule Opt Layer 作為控制平面（control plane），負(fù)責(zé)全局資源管理和容錯(cuò)（fault tolerance）。它采用四項(xiàng)關(guān)鍵優(yōu)化來解決單體執(zhí)行效率低下和集群不穩(wěn)定的問題：

? Dynamic Pipeline Execution：利用軌跡規(guī)劃（trajectory planning）與渲染（rendering）的解耦特性，我們實(shí)現(xiàn)了動(dòng)態(tài)流水線（dynamic pipelining）機(jī)制。該設(shè)計(jì)消除了階段間阻塞，有效掩蓋了計(jì)算延遲并最大化吞吐量。

? Asynchronous Batch Storage：為減輕 I/O 開銷，我們將數(shù)據(jù)持久化（data persistence）卸載到異步線程。通過批量處理寫入操作，該模塊將存儲(chǔ)延遲與關(guān)鍵計(jì)算路徑隔離。

? Load Balancing：針對(duì)分布式環(huán)境中的資源傾斜問題，負(fù)載均衡器（load balancer）動(dòng)態(tài)調(diào)度任務(wù)以充分利用集群容量。該策略有效緩解了落后者效應(yīng)（straggler effect），并確保資源的均勻利用。

? Supervisor：提供細(xì)粒度的容錯(cuò)能力，supervisor 實(shí)時(shí)監(jiān)控任務(wù)存活狀態(tài)（task liveness）。它自動(dòng)檢測(cè)故障并觸發(fā)恢復(fù)例程，以保證系統(tǒng)的持續(xù)可用性。

這些優(yōu)化的詳細(xì)實(shí)現(xiàn)在第 5 節(jié)中呈現(xiàn)。

4.4 后端優(yōu)化層（Backend Opt Layer）

后端優(yōu)化層提供高性能運(yùn)行時(shí)環(huán)境。它集成了基于 Ray 的環(huán)境與優(yōu)化后的渲染器后端。關(guān)鍵優(yōu)化包括針對(duì) Gaussian Splatting 的加速光柵化、針對(duì) Blender 的 RT-cores 和 tensor-cores 優(yōu)化，以及針對(duì) Isaac Sim 的批量渲染。這些特定于后端的增強(qiáng)功能與上層協(xié)同工作，以充分發(fā)揮硬件性能。

5 多層優(yōu)化設(shè)計(jì)

單體式合成數(shù)據(jù)流水線通常將軌跡規(guī)劃（trajectory planning）和視覺渲染（visual rendering）耦合到一個(gè)同步執(zhí)行單元中。雖然這種耦合便于原型設(shè)計(jì)（prototyping），但在大規(guī)模應(yīng)用時(shí)會(huì)引入嚴(yán)重的低效問題。首先，規(guī)劃與渲染的緊密耦合會(huì)導(dǎo)致計(jì)算浪費(fèi)：規(guī)劃階段生成的無效軌跡仍會(huì)觸發(fā)渲染，不必要地消耗資源。其次，兩個(gè)階段的資源特征存在顯著差異：規(guī)劃是 CPU-bound，而渲染是 GPU-bound。串行執(zhí)行迫使一種資源類型在另一種資源活動(dòng)時(shí)處于空閑狀態(tài)，導(dǎo)致硬件利用率嚴(yán)重不足。此外，隨著部署規(guī)模的擴(kuò)大，部分故障變得不可避免，需要強(qiáng)大的容錯(cuò)機(jī)制（fault tolerance）來確保持續(xù)可用性（continuous availability）。

為緩解這些瓶頸，Nimbus 實(shí)現(xiàn)了第 4 節(jié)中定義的調(diào)度優(yōu)化層（Schedule Opt Layer）和后端優(yōu)化層（Backend Opt Layer）中提到的多層優(yōu)化策略。圖 6 展示了多層優(yōu)化策略。上半部分展示了流水線并行（Pipeline Parallelism，Section 5.1）和渲染器優(yōu)化（Renderer Optimization，Section 5.3），它們將串行執(zhí)行解耦為異步模型（asynchronous model），并加速渲染以最大化整體吞吐量（aggregate throughput）。下半部分展示了分布式優(yōu)化（Distributed Optimization，Section 5.2），采用帶有監(jiān)督器（supervisors）的全局負(fù)載均衡（global load balancing）來確保集群級(jí)（cluster-scale）的效率和可用性。

5.1 Schedule Opt Layer：Pipeline Parallelism

通過將生成分解為異步階段，我們實(shí)現(xiàn)了Dynamic Pipeline Execution和Asynchronous Batch Storage。該設(shè)計(jì)采用細(xì)粒度的ComputeWorker封裝和動(dòng)態(tài)pipeline scheduling，以掩蓋計(jì)算延遲并最大化異構(gòu)計(jì)算資源的利用率。

5.1.1 Pipeline Parallel Execution

傳統(tǒng)的合成數(shù)據(jù)生成工作流主要依賴于單體架構(gòu)，其中planning和rendering在同步執(zhí)行循環(huán)中緊密耦合。在這種范式下，pipeline按順序執(zhí)行：Load Stage加載場(chǎng)景，Plan Stage生成trajectories，Render Stage進(jìn)行渲染，然后Store Stage執(zhí)行持久化。這種lockstep執(zhí)行方式使硬件使用串行化：GPU在CPU-bound planning期間空閑，CPU在GPU-bound rendering期間停滯。Blocking storage I/O進(jìn)一步放大了這些pipeline氣泡，阻礙了資源利用。

為緩解這些瓶頸，我們提出了一種Pipeline Parallel Execution優(yōu)化方案，將生成分解為三個(gè)異步階段。如圖7所示，我們引入了中間buffers以切斷各階段之間的串行依賴關(guān)系。

異步階段解耦。?我們使用高吞吐量消息隊(duì)列來橋接解耦的各個(gè)階段。planner 進(jìn)程作為生產(chǎn)者，將序列化的 simulation contexts 推送到隊(duì)列中。renderer 進(jìn)程作為消費(fèi)者，異步獲取 contexts 用于可視化。該設(shè)計(jì)實(shí)現(xiàn)了 pipeline parallelism：當(dāng) renderer 進(jìn)程為出隊(duì)的 contexts 執(zhí)行 GPU-bound 可視化時(shí)，planner 進(jìn)程同時(shí)在 CPU 上為后續(xù)任務(wù)生成 simulation states。此外，該架構(gòu)支持多個(gè) planner 和 renderer 進(jìn)程的彈性部署（elastic deployment），使系統(tǒng)能夠協(xié)調(diào)各階段的整體處理速率，盡管它們存在固有的延遲差異。

I/O 延遲隱藏。?為解決存儲(chǔ)階段的 I/O 瓶頸，我們實(shí)現(xiàn)了異步批量存儲(chǔ)（Asynchronous Batch Storage）機(jī)制。renderer 進(jìn)程將數(shù)據(jù)持久化任務(wù)卸載到專用的 I/O 線程池，而非執(zhí)行同步寫入。通過批量處理寫入操作，該設(shè)計(jì)有效地將高延遲磁盤 I/O 與關(guān)鍵渲染路徑隔離。

吞吐量最大化。?該流水線架構(gòu)有效屏蔽了各階段的特定延遲。通過重疊 CPU、GPU 和 I/O 操作，我們將稀疏的順序執(zhí)行時(shí)間線轉(zhuǎn)換為密集的并行調(diào)度。這確保了異構(gòu)硬件資源的同時(shí)飽和，包括 CPU 核心、GPU 計(jì)算單元和磁盤帶寬，從而顯著提升端到端生成吞吐量。

5.1.2 動(dòng)態(tài)流水線調(diào)度

盡管流水線并行具有諸多優(yōu)勢(shì)，但 Plan 階段和 Render 階段的延遲本質(zhì)上仍不對(duì)稱。雖然對(duì) planner 和 renderer 進(jìn)程進(jìn)行靜態(tài)劃分在理論上可以平衡流水線，但它在實(shí)際中面臨顯著局限性。首先，它需要對(duì)各階段延遲進(jìn)行精確的事先剖析（profiling），而這些延遲在不同任務(wù)間差異很大。其次，運(yùn)行時(shí)的隨機(jī)性（例如規(guī)劃失敗導(dǎo)致無效軌跡被丟棄）會(huì)破壞理想的計(jì)算重疊。因此，Plan 階段往往會(huì)提前完成其工作負(fù)載，導(dǎo)致資源閑置，而 Render 階段則仍處于積壓狀態(tài)。

為解決這些低效問題，我們引入了一種以自適應(yīng)資源回收為核心的動(dòng)態(tài)流水線調(diào)度策略。該機(jī)制采用事件驅(qū)動(dòng)方式：當(dāng)上游 planner 進(jìn)程耗盡其任務(wù)流時(shí)，它會(huì)發(fā)送一個(gè)終止信號(hào)，促使全局 Scheduler 立即回收其資源。隨后，Scheduler 評(píng)估當(dāng)前的隊(duì)列積壓情況，并動(dòng)態(tài)配置一個(gè)新的 renderer 進(jìn)程，該進(jìn)程繼承現(xiàn)有的消息隊(duì)列連接，并無縫加入 renderer 組。圖 8 展示了這一過程，該場(chǎng)景初始化為兩個(gè) planner 進(jìn)程和一個(gè) renderer 進(jìn)程。隨著 planner 進(jìn)程退出，其計(jì)算能力會(huì)自動(dòng)重新分配以啟動(dòng)額外的 renderer 進(jìn)程，確保資源從規(guī)劃到渲染流暢流動(dòng)。這種對(duì)階段并行度的動(dòng)態(tài)調(diào)整有效緩解了靜態(tài)配置中觀察到的長(zhǎng)尾延遲問題，從而在端到端生成吞吐量方面取得了顯著提升。

5.2 調(diào)度優(yōu)化層：分布式優(yōu)化

為確保集群規(guī)模的效率和高可用性，我們實(shí)現(xiàn)了一個(gè)分布式優(yōu)化層，包含全局負(fù)載均衡和容錯(cuò)機(jī)制。

5.2.1 全局負(fù)載均衡

在分布式環(huán)境中，由于任務(wù)異構(gòu)性和硬件性能差異（即 stragglers），靜態(tài)任務(wù)分配常常導(dǎo)致嚴(yán)重的負(fù)載不均衡。為最大化集群利用率，我們實(shí)現(xiàn)了一個(gè)基于 Master-Worker 架構(gòu)的全局負(fù)載均衡器。

如圖 9 所示，Master Node 作為中央?yún)f(xié)調(diào)器，維護(hù)全局集群狀態(tài)。它集成了 WorkerManager 來跟蹤節(jié)點(diǎn)存活狀態(tài)和資源可用性，以及 TaskManager 來基于實(shí)時(shí)負(fù)載指標(biāo)將待處理任務(wù)動(dòng)態(tài)分配給最合適的 worker。Worker Node 托管 StateReporter 向 Master 推送心跳更新，以及 TaskGetter 來獲取任務(wù)分配。ComputeWorker 封裝了特定領(lǐng)域的執(zhí)行邏輯（例如 Planning 或 Rendering）。此外，為減少調(diào)度開銷和網(wǎng)絡(luò)擁塞，我們采用了惰性上下文初始化策略。dispatcher 僅發(fā)送輕量級(jí)任務(wù)元數(shù)據(jù)，而非傳輸完整的數(shù)據(jù)負(fù)載。Worker 節(jié)點(diǎn)僅在任務(wù)初始化時(shí)從共享存儲(chǔ)中惰性加載完整的執(zhí)行上下文。

5.2.2 通過 Supervisor 實(shí)現(xiàn)容錯(cuò)

我們利用 Ray 來管理 ComputeWorker 的生命周期，通過自動(dòng)進(jìn)程重啟提供基本的可用性。然而，大規(guī)模合成數(shù)據(jù)生成仍然容易受到不穩(wěn)定性的影響，尤其是在集成復(fù)雜的物理模擬器/渲染器（例如 Isaac Sim）時(shí)。這些組件經(jīng)常出現(xiàn)非確定性的掛起或靜默失敗，而不是立即崩潰，導(dǎo)致執(zhí)行停滯和資源泄漏。此外，傳統(tǒng)的進(jìn)程內(nèi)監(jiān)控會(huì)受到 Python Global Interpreter Lock (GIL) 的影響，因?yàn)橹鲌?zhí)行線程中的死鎖經(jīng)常會(huì)阻塞監(jiān)控線程。

為了保證運(yùn)行時(shí)魯棒性，我們引入了一個(gè)帶外 Supervisor，實(shí)現(xiàn)為與 ComputeWorker 解耦的獨(dú)立進(jìn)程。關(guān)鍵在于，Supervisor 本身由 Ray 管理，確保其自身的高可用性。這一設(shè)計(jì)建立了一個(gè)健壯的故障檢測(cè)循環(huán)。在操作上，ComputeWorker 和 Supervisor 都維護(hù)各自的 Status Monitor 組件。ComputeWorker 定期更新其本地 Status Monitor 狀態(tài)，并通過心跳消息將此狀態(tài)同步到 Supervisor 的 Status Monitor。Supervisor 持續(xù)輪詢其自身的 Status Monitor 狀態(tài)，執(zhí)行嚴(yán)格的超時(shí)策略以驗(yàn)證 worker 的活躍性。檢測(cè)到超時(shí)時(shí)，Supervisor 通過 SIGKILL 終止無響應(yīng)的 ComputeWorker。這會(huì)觸發(fā) Ray 自動(dòng)重新生成 worker 并恢復(fù)其執(zhí)行上下文，有效地將靜默掛起轉(zhuǎn)換為 fail-stop 錯(cuò)誤，并在無需人工干預(yù)的情況下維持集群穩(wěn)定性。

5.3 后端優(yōu)化層：渲染器優(yōu)化

為了充分利用底層基礎(chǔ)設(shè)施的硬件能力，后端優(yōu)化層針對(duì)三個(gè)主要渲染器實(shí)施了針對(duì)性優(yōu)化：Blender、Isaac Sim 和 Gaussian Splatting。

5.3.1 Blender：硬件加速流水線

Blender 是一個(gè)廣泛使用的開源 3D 創(chuàng)作套件，用于高保真度的基于物理的渲染。我們?cè)?InternData-N1 Blender 基線流水線中識(shí)別出兩個(gè)關(guān)鍵瓶頸：由于傳統(tǒng)執(zhí)行路徑導(dǎo)致專用 GPU 硬件利用率不足，以及 GIL 施加的并發(fā)限制。我們通過異構(gòu)計(jì)算卸載和多進(jìn)程并行來解決這些問題。

硬件感知內(nèi)核映射。我們重新設(shè)計(jì)了渲染流水線，以利用 NVIDIA RTX 架構(gòu)的專用計(jì)算單元。如圖 10 所示，基線流水線在通用 CUDA 核心上存在資源爭(zhēng)用問題，并且由于基于 CPU 的去噪而產(chǎn)生高延遲，這需要昂貴的 device-to-host 內(nèi)存?zhèn)鬏敗榱司徑膺@一問題，我們使用 OptiX 后端實(shí)現(xiàn)了完全駐留 GPU 的流水線。該設(shè)計(jì)將 ray-triangle intersection 內(nèi)核映射到專用的 RT Cores，并通過 OptiX AI Denoiser 將去噪任務(wù)委托給 Tensor Cores。通過將整個(gè) render-denoise 循環(huán)限制在 GPU 上，我們消除了 CPU 瓶頸，并最大化異構(gòu)硬件資源的并發(fā)利用率。

多進(jìn)程并行。為了進(jìn)一步最大化單個(gè) GPU 上的資源利用率，我們?cè)?Nimbus Blender Renderer 中實(shí)現(xiàn)了并行渲染調(diào)度機(jī)制，啟動(dòng)多個(gè)并發(fā)渲染進(jìn)程。這一設(shè)計(jì)的動(dòng)機(jī)是需要繞過 Python GIL，后者將標(biāo)準(zhǔn) Blender 執(zhí)行限制為單線程，導(dǎo)致 GPU 資源利用率不足。在此架構(gòu)中，主進(jìn)程充當(dāng)全局資源管理器，負(fù)責(zé)場(chǎng)景加載、參數(shù)配置、任務(wù)分配和最終數(shù)據(jù)聚合。它將渲染任務(wù)分發(fā)給一組獨(dú)立的工作進(jìn)程池，其中每個(gè)工作進(jìn)程獨(dú)立執(zhí)行完整的優(yōu)化流水線（初始化、渲染和后處理）。這種進(jìn)程級(jí)并行有效規(guī)避了 GIL，使系統(tǒng)能夠充分利用高端 GPU 的計(jì)算能力。

5.3.2 Isaac Sim：堆疊渲染

NVIDIA Isaac Sim 是一款基于 Omniverse 平臺(tái)構(gòu)建的高保真機(jī)器人仿真與合成數(shù)據(jù)生成工具。它專為具身 AI（embodied AI）開發(fā)而設(shè)計(jì)，在合成數(shù)據(jù)流水線中充當(dāng)物理仿真和多模態(tài)數(shù)據(jù)生產(chǎn)的核心引擎。如圖 11 所示，合成操作數(shù)據(jù)生成通常需要記錄物體的時(shí)序運(yùn)動(dòng)序列（例如球體下落的連續(xù)過程）。傳統(tǒng)工作流采用串行狀態(tài)回放，即單個(gè)場(chǎng)景和相機(jī)隨時(shí)間順序渲染物體的不同運(yùn)動(dòng)狀態(tài)（t0、t1、t2）。這種串行執(zhí)行模式無法充分利用 RTX 流水線的并行能力，造成了顯著的效率瓶頸。

為解決這一限制，我們引入了堆疊渲染（Stacked Rendering）優(yōu)化技術(shù)，將多步時(shí)序狀態(tài)（例如球體下落的不同階段）映射到單個(gè)場(chǎng)景內(nèi)的多個(gè)獨(dú)立子區(qū)域中。通過部署多個(gè)相機(jī)并行捕獲這些子區(qū)域，我們實(shí)現(xiàn)了單次場(chǎng)景加載和一次渲染即可完成多步數(shù)據(jù)采集，有效替代了傳統(tǒng)的串行時(shí)序渲染方法。該技術(shù)最大化了渲染流水線的吞吐量。

5.3.3 Gaussian Splatting：內(nèi)核融合

3D Gaussian Splatting 是一種新穎的 3D 表示方法，將場(chǎng)景建模為可學(xué)習(xí)的 3D 高斯基元的集合。每個(gè)基元封裝了完整的幾何屬性（位置、旋轉(zhuǎn)、縮放）和外觀屬性（顏色、不透明度）。渲染流水線通過 splatting 技術(shù)將這些 3D 高斯投影到圖像平面上，執(zhí)行一系列投影、分塊、排序和 alpha 混合操作，以實(shí)現(xiàn)實(shí)時(shí)、高質(zhì)量的場(chǎng)景合成。

為解決大規(guī)模合成數(shù)據(jù)生成中的渲染效率瓶頸，我們集成了 FlashGS 和 TC-GS 來優(yōu)化光柵化內(nèi)核。FlashGS 針對(duì)標(biāo)準(zhǔn)流水線的計(jì)算和內(nèi)存開銷進(jìn)行了優(yōu)化。它實(shí)現(xiàn)了冗余高斯過濾以剪枝無效或低貢獻(xiàn)的基元，并行化渲染調(diào)度，并實(shí)施細(xì)粒度的 GPU 內(nèi)核執(zhí)行控制。此外，我們利用 Tensor Cores 加速 alpha 混合操作——正如 TC-GS 所提出的，該操作在渲染流水線中占據(jù)主導(dǎo)計(jì)算成本。這些技術(shù)顯著提升了 Gaussian Splatting 的渲染吞吐量，大幅提高了合成數(shù)據(jù)生成流水線的整體效率。

6 評(píng)估

我們?cè)诎⒗镌萍荷蠈?duì) Nimbus 進(jìn)行評(píng)估，配置詳情如表 所示

我們對(duì)四種數(shù)據(jù)生成管道進(jìn)行了基準(zhǔn)測(cè)試：

? Nav-GS（InternData-N1 Gaussian Splatting Pipeline）：一個(gè)導(dǎo)航數(shù)據(jù)采集管道，在坐標(biāo)對(duì)齊的 mesh 模型和 3D Gaussian 模型上執(zhí)行規(guī)劃與渲染。場(chǎng)景為自定義室內(nèi)環(huán)境，每個(gè)模型約包含 300 萬個(gè) Gaussians。

? Nav-Mesh（InternData-N1 Blender Pipeline）：一種傳統(tǒng)管道，從 3D-FRONT 數(shù)據(jù)集中采樣端點(diǎn)。它執(zhí)行 A-star 路徑規(guī)劃，并利用 Blender 進(jìn)行渲染。

? GenManip（InternData-M1 Pipeline）：在 Objaverse 數(shù)據(jù)集上執(zhí)行物體抓取與放置任務(wù)。

? SimBox（InternData-A1 Pipeline）：在 Objaverse 數(shù)據(jù)集上執(zhí)行垃圾分類任務(wù)。

6.1 性能評(píng)估

我們?cè)谒膫€(gè)不同的管道上評(píng)估了 Nimbus 與未優(yōu)化的 Baseline 的端到端性能：Nav-GS 和 Nav-Mesh 用于導(dǎo)航任務(wù)，GenManip 和 SimBox 用于操作任務(wù)。我們?yōu)?Nav-GS 生成了 150 條軌跡，為 Nav-Mesh 生成了 450 條軌跡（每個(gè)場(chǎng)景 150 條），為 GenManip 和 SimBox 各生成了 200 條。鑒于任務(wù)復(fù)雜性和數(shù)據(jù)量存在固有的異質(zhì)性，我們關(guān)注每個(gè)管道內(nèi)的相對(duì)加速比（Baseline vs. Nimbus），而非跨管道的絕對(duì)比較。

6.1.1 端到端吞吐量分析

圖 12 展示了端到端延遲對(duì)比。Nimbus 在所有工作負(fù)載上均實(shí)現(xiàn)了顯著的性能提升，加速比范圍從 2.1× 到 3.2×。為了識(shí)別這些提升的來源，我們分解了關(guān)鍵階段的延遲分布。如圖 13 所示，Baseline 以順序模式運(yùn)行，規(guī)劃與渲染緊密耦合。相比之下，Nimbus（圖 14）將這些階段解耦。關(guān)鍵在于，在我們的流水線并行和動(dòng)態(tài)調(diào)度機(jī)制下，端到端延遲不再是各階段延遲的累加和，而是由瓶頸階段決定。

在導(dǎo)航任務(wù)中，規(guī)劃階段計(jì)算開銷較輕，而渲染階段和存儲(chǔ)階段占主導(dǎo)地位。在此引入完全解耦的流水線會(huì)產(chǎn)生序列化開銷和 IPC 開銷，從而抵消潛在的并發(fā)收益。因此，Nimbus 對(duì)規(guī)劃和渲染保持同步執(zhí)行，轉(zhuǎn)而專注于兩項(xiàng)針對(duì)性優(yōu)化：

? I/O Masking：我們解耦了存儲(chǔ)階段。通過將持久化操作卸載到異步寫入器，我們完全掩蓋了約 56 ms/frame 的磁盤 I/O 延遲。

? Renderer Optimization：我們通過 Backend Opt Layer 優(yōu)化關(guān)鍵渲染路徑。例如，Nav-Mesh 渲染延遲降低了 64%（從 446.29 ms 降至 159.46 ms）。

對(duì)于 GenManip 和 SimBox，Nimbus 利用了 CPU-bound 規(guī)劃與 GPU-bound 渲染之間的結(jié)構(gòu)分離：

? Pipeline Overlap：通過將規(guī)劃和渲染隔離到不同的 ComputeWorkers 中，我們實(shí)現(xiàn)了它們的重疊執(zhí)行。規(guī)劃成本被有效地分?jǐn)偟戒秩敬翱趦?nèi)。為了進(jìn)一步減少瓶頸延遲，我們通過多個(gè) renderer ComputeWorkers 增加渲染并發(fā)性。

? Dynamic Resource Reallocation：為了減輕尾部延遲，調(diào)度器動(dòng)態(tài)地從已完成的 Planners 回收資源以生成額外的 Renderers。這種自適應(yīng)重新分配確保計(jì)算資源保持飽和狀態(tài)，最小化渲染尾部期間的空閑時(shí)間。

6.1.2 有效吞吐量的理論分析

盡管 Nimbus 實(shí)現(xiàn)了 2×–3× 的加速，但各階段延遲（Figure 14）顯示，每幀總計(jì)算量（Plan 和 Render）與 Baseline 相比仍然相當(dāng)。這表明性能提升源于架構(gòu)效率，而非操作數(shù)量的減少。我們通過有效階段吞吐量對(duì)此進(jìn)行形式化描述。

吞吐量模型?在解耦架構(gòu)中，階段性能由每幀延遲 ?s 和時(shí)間平均并發(fā)度 $$ Nˉ s = 1 T R T 0 Ns(t)dt.$$定義。有效吞吐量為：

$$μs = Nˉs / ?s (frames/s)$$

系統(tǒng)的穩(wěn)態(tài)理論最大吞吐量為$$λtheory = min(μplan, μrender)$$。與 Baseline 的退化流水線（λbase ≈ (∑ ?i)^-1）不同，Nimbus 通過提高$$ Nˉs $$并利用重疊隱藏延遲，從而最大化 $$ λtheory$$。

Impact of dynamic pipeline scheduling?在 ?render ? ?plan 的操作任務(wù)中，系統(tǒng)處于 GPU-bound 狀態(tài)。Nimbus 初始化為平衡的 Planner:Renderer 比例以使隊(duì)列飽和，然后動(dòng)態(tài)重新分配資源。隨著 Planners 退出，$$Nˉ plan$$ 減少而 $$\bar{N}_{render$$ 增加，恰好在瓶頸轉(zhuǎn)移到尾部時(shí)提升 $$ μrender $$。

Correlation Between Failure Rates and Latency?在 GPU-bound 狀態(tài)下存在一種反直覺的動(dòng)態(tài)現(xiàn)象：更高的規(guī)劃成功率與更長(zhǎng)的總執(zhí)行時(shí)間相關(guān)聯(lián)。設(shè) $$X_i \in \{0, 1\$$ 為第 $$$$ 次嘗試的成功指示器?？倛?zhí)行時(shí)間近似為：

$$T^{Nimbus}_{total} \approx \frac{\ell^{Nimbus}_{render}}{\bar{N}_{render}} \sum_{i=1}^{M} X_i $$

由于失敗的規(guī)劃在渲染前會(huì)被剪枝，更高的失敗率會(huì)降低總渲染負(fù)載。為了公平地評(píng)估效率，我們定義Effective Successful Throughput?$$λsucc = (P Xi)/Ttotal$$。Nimbus 能夠在不同的失敗率下魯棒地維持高 $$ λsucc $$，因?yàn)閯?dòng)態(tài)流水線調(diào)度確保了成功樣本的吞吐量接近$$ λtheory$$。

6.2 可擴(kuò)展性

當(dāng)將任務(wù)擴(kuò)展到更大規(guī)模時(shí)，需要額外的計(jì)算節(jié)點(diǎn)。這不可避免地帶來了兩個(gè)關(guān)鍵挑戰(zhàn)：全局負(fù)載均衡和復(fù)雜物理模擬器的故障恢復(fù)。這兩個(gè)挑戰(zhàn)都會(huì)顯著影響框架的可擴(kuò)展性。

我們通過帶有全局負(fù)載均衡器的 master-worker 架構(gòu)來解決由任務(wù)異構(gòu)性和硬件性能差異引起的負(fù)載不平衡問題，并通過 Supervisor 機(jī)制確保運(yùn)行時(shí)魯棒性，從而實(shí)現(xiàn)出色的可擴(kuò)展性。

我們通過在不同規(guī)模的集群上執(zhí)行 24 小時(shí)數(shù)據(jù)生成任務(wù)來評(píng)估系統(tǒng)的可擴(kuò)展性，集群規(guī)模從 8 到 128 個(gè) GPU 不等。值得注意的是，對(duì)于 Nav-Mesh pipeline，我們的評(píng)估包含 2,560 個(gè)不同的場(chǎng)景。我們還進(jìn)行了對(duì)比實(shí)驗(yàn)，分別啟用和禁用動(dòng)態(tài)負(fù)載均衡參數(shù)（dynload），其中啟用 dynload 會(huì)激活全局負(fù)載均衡器。結(jié)果如圖 15 所示。

理論上，吞吐量應(yīng)與 GPU 數(shù)量呈線性增長(zhǎng)。我們的實(shí)驗(yàn)結(jié)果表明，當(dāng)從 8 個(gè) GPU 擴(kuò)展到 128 個(gè) GPU 時(shí)，系統(tǒng)實(shí)現(xiàn)了約 86% 的線性擴(kuò)展效率，這表明可擴(kuò)展性出色。在整個(gè) 24 小時(shí)的測(cè)試期間，系統(tǒng)保持穩(wěn)定運(yùn)行，沒有出現(xiàn)節(jié)點(diǎn)故障或任務(wù)故障，展現(xiàn)出卓越的魯棒性。

與完美線性擴(kuò)展的偏差可歸因于兩個(gè)主要因素。首先，任務(wù)執(zhí)行存在固有的尾部效應(yīng)（tail effects）。即使有負(fù)載均衡，最后一批任務(wù)的完成時(shí)間也會(huì)影響整體吞吐量測(cè)量，且隨著節(jié)點(diǎn)數(shù)量增加，這種效應(yīng)變得更加明顯。其次，負(fù)載均衡器的調(diào)度效率受任務(wù)粒度影響。隨著節(jié)點(diǎn)數(shù)量增加，分配給每個(gè)節(jié)點(diǎn)的任務(wù)數(shù)量相應(yīng)減少，這降低了全局負(fù)載均衡器可用的調(diào)度靈活性。在我們的 128-GPU 配置中，2,560 個(gè)場(chǎng)景被分配，平均每 GPU 僅約 20 個(gè)場(chǎng)景。每個(gè)節(jié)點(diǎn)的這種相對(duì)較小的任務(wù)池不足以讓負(fù)載均衡器充分發(fā)揮其動(dòng)態(tài)調(diào)度能力并有效緩解不可避免的尾部效應(yīng)，從而限制了整體資源利用效率。

值得注意的是，盡管存在這些因素，系統(tǒng)在大規(guī)模集群上仍保持高資源利用率，這得益于我們的 master-worker 架構(gòu)與 Supervisor 機(jī)制之間的有效協(xié)調(diào)。這一結(jié)果驗(yàn)證了我們的架構(gòu)設(shè)計(jì)能夠支持生產(chǎn)環(huán)境中的大規(guī)模數(shù)據(jù)生成需求。

7 結(jié)論

數(shù)據(jù)稀缺仍然是訓(xùn)練具身智能模型的主要瓶頸。雖然合成數(shù)據(jù)提供了一條可行的前進(jìn)路徑，但現(xiàn)有的生成流程受到碎片化、低效率和不穩(wěn)定性的困擾。在本文中，我們提出了Nimbus，這是一個(gè)通過系統(tǒng)化設(shè)計(jì)解決這些架構(gòu)缺陷的統(tǒng)一框架。通過將導(dǎo)航和操作流程整合到單一框架中，Nimbus成功協(xié)調(diào)了InternData數(shù)據(jù)集系列的大規(guī)模構(gòu)建。我們的評(píng)估表明，該系統(tǒng)通過動(dòng)態(tài)流程調(diào)度和渲染優(yōu)化，實(shí)現(xiàn)了比基線2–3×的吞吐量提升。此外，其容錯(cuò)設(shè)計(jì)確保在大規(guī)模GPU集群上穩(wěn)健、持續(xù)地運(yùn)行，滿足大規(guī)模數(shù)據(jù)活動(dòng)的穩(wěn)定性要求。

通過使用標(biāo)準(zhǔn)化、高性能的基礎(chǔ)設(shè)施取代臨時(shí)腳本，Nimbus規(guī)避了物理數(shù)據(jù)收集的過高成本。它提供了推進(jìn)操作和導(dǎo)航模型所需的高容量、多模態(tài)數(shù)據(jù)流。展望未來，我們計(jì)劃從三個(gè)方向擴(kuò)展該框架：集成多樣化的軌跡規(guī)劃器以豐富行為變化，納入自動(dòng)化場(chǎng)景生成以擴(kuò)大環(huán)境兼容性，以及實(shí)施自動(dòng)化任務(wù)配置以進(jìn)一步增強(qiáng)下游模型的泛化能力。