从 LLM Infra 到具身智能 Infra:仿真集群、VLA 训练栈与数据管线全景解析

写给一位即将从大模型 Infra 转向具身智能 Infra 的工程师,也写给所有关注这个方向的人。

引言:一次心智模型的切换

过去三年做大模型 Infra 的人,心智模型基本是稳定的:海量文本 token 进、GPU 集群算、ckpt 出、推理服务化。但具身智能完全不同——它训练的不是"下一个 token",而是"机器人在物理世界里的下一步动作";它的数据不是从互联网爬来的,而是真机遥操作、仿真合成、人类视频多源混合出来的;它的基础设施不仅要支撑训练,还要支撑大规模并行仿真和真机数据回流这两个 LLM 时代从未存在过的环节。

如果你从 LLM Infra 背景切入这个领域,大约 60-70% 的工程经验可以直接平移,剩下 30-40% 需要新建心智模型。本文拆解其中三个最核心的新模块:仿真集群的算力形态、VLA 训练栈的真实结构、以及数据管线的工程全貌。

一、仿真集群:GPU 上的"平行世界"

1.1 它到底是什么

具身智能训练有一个大语言模型没有的根本性需求:机器人要在物理世界里"试错"才能学到东西。但真机试错成本极高——一台人形机器人几十万、摔一次就坏、数据采集速度受物理时间限制。行业的解法是把试错过程搬进仿真:在 GPU 上同时跑成百上千个虚拟场景,让虚拟机器人高频试错。

技术核心是 GPU 并行物理仿真。以 Isaac Lab 为例,它基于 Isaac Sim 构建,提供 GPU 向量化环境和 RL 接口(observation/action/reward),用于大规模并行策略优化。对运动控制类任务,单卡 L4 就能并行运行约 4096 个仿真环境,整体吞吐可达每秒数万步。所谓"一大群机器人在同一个世界里走路训练"的画面,本质是 GPU 把几千个独立环境的状态同时算出来,而不是一个个顺序模拟。

GPU 并行仿真把原本需要数天的 RL 策略搜索任务压缩到 GPU-hours 量级,这是仿真从"调试工具"升级为"训练基础设施"的关键原因。

1.2 主流仿真引擎对比

引擎	背景	并行能力	物理精度	适用场景
Isaac Lab	NVIDIA	单卡 4096 并行环境,GPU 物理+渲染一体化	中	大规模 RL、合成数据
MuJoCo MJX	Google	TPU 上百万级步/秒	高(接触动力学)	操作类任务
Genesis	社区	RTX 4090 上 43M FPS(刚体)	中	刚体/软体/流体
Newton	NVIDIA+DeepMind+Disney	GPU 加速、基于 Warp	高	Isaac Lab 下一代后端

值得关注的是 Newton 和 Isaac Lab 正在解耦 RTX 渲染依赖,让仿真可以跑在 L40s/H100/H200/B200 这类纯计算卡上,不再强制要求带光追的 RTX 卡。这会显著改变仿真集群的 GPU 选型策略。

1.3 在 K8s 中的形态

仿真集群完全跑在 K8s 上,但作为一类特殊的工作负载,它和训练任务的资源画像差异显著。一个典型形态如下:

┌─────────────────────────────────────────────────────────────┐
│                    K8s 控制面(同一个集群)                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ① 训练区(Megatron / FSDP)                               │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐                    │
│  │ Worker×8 │←─────────→│ Worker×8 │  ← InfiniBand/RDMA │
│  │  VLA训练  │ │  VLA训练  │                    │
│  └──────────┘ └──────────┘                    │
│        ↓ ckpt/checkpoint 仓库(对象存储+元数据)           │
│                                                             │
│  ② 仿真 Rollout 区(具身特有形态)                          │
│  ┌──────────────────────────────────────┐                  │
│  │  Isaac Lab Pod (1×H100)              │                  │
│  │   ├─ env_0   ├─ env_1   ├─ ...       │                  │
│  │   └─ env_4095  ← 单容器内并行         │                  │
│  └──────────────────────────────────────┘                  │
│  ┌──────────────────────────────────────┐                  │
│  │  Isaac Lab Pod (1×H100)  ×  N pods   │ ← 水平扩展      │
│  └──────────────────────────────────────┘                  │
│        ↓ 策略加载(每轮 rollout 从 ckpt 仓库拉)           │
│        ↑ 轨迹数据(episode 回报给数据湖)                  │
│                                                             │
│  ③ 真机回传网关                                             │
│  ┌──────────┐    gRPC/MQTT    ┌──────────┐                │
│  │ 机器人×N │ ───────────────→│ Ingest   │                │
│  │ (边缘侧) │                 │ Service  │                │
│  └──────────┘                 └──────────┘                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

1.4 和训练负载的调度差异

维度	LLM 训练任务	仿真 Rollout 任务
GPU 利用模式	长期占满、跨机通信	单 Pod 占 1 卡、容器内并行、短周期
Job 生命周期	数天到数周	分钟到小时级,海量并发提交
资源竞争	优先级+公平共享	与训练抢卡,需配额隔离
I/O 特征	大批量顺序读 ckpt	小批量高频随机读(策略权重+场景资产)
渲染依赖	无	部分场景需 RTX,正在解耦

对 LLM Infra 工程师而言,K8s、CNI、GPU 调度、资源超卖这些能力都可以直接复用,真正的新问题是:如何把仿真 GPU 和训练 GPU 做潮汐互补调度(训练晚上跑满、仿真白天做 rollout),以及如何在统一集群里隔离两类负载的 QoS。社区已有 Isaac Automator 这类工具支持把 Isaac Sim/Lab 一键部署到主流云平台,可以作为起点参考。

二、VLA 训练栈:模型怎么训、在哪训

2.1 先澄清一个常见误解

VLA 训练 100% 发生在云端 GPU 集群上,机器人本体不参与训练过程。 机器人在整个生命周期里只做两件事:

采集阶段:通过遥操作/动捕产生训练数据,回传云端
部署阶段:加载训好的模型权重做推理,产生新的部署数据

原因很朴素:一个 7B 的 VLA 模型全量训练需要几十张 H100,而机器人本体上的算力通常只有 200 TOPS 左右,连推理一个 7B 模型都吃力,更不可能做训练。谷歌最新发布的 Gemini Robotics On-Device 也是云端训练、端侧只做推理的分工。

所谓"机器人在训练",更准确的理解是:真机部署本身是训练飞轮的一环——机器人上线干活,产生失败数据,数据回流云端训练下一版,再部署下去。循环存在,但每一步的"训练"都发生在云端。

2.2 VLA 模型结构

VLA(Vision-Language-Action)本质是把一个 VLM 改造成能输出机器人动作的模型。以 π0 和 OpenVLA 为代表:

┌─────────────────────────────────────────────────────┐
│  VLA 模型结构(π0 / OpenVLA 为代表)                 │
├─────────────────────────────────────────────────────┤
│  输入                                                │
│   ├─ 图像(多视角相机,SigLIP/DINOv2 编码)         │
│   ├─ 语言指令("把杯子放到盘子里")                 │
│   └─ 本体感觉(关节角度、夹爪状态、IMU)            │
│         ↓                                           │
│  ┌────────────────────────────────────┐             │
│  │  VLM 主干(7B-70B)                │             │
│  │  PaliGemma / Llama / Qwen 底座     │             │
│  └────────────────────────────────────┘             │
│         ↓                                           │
│  ┌────────────────────────────────────┐             │
│  │  Action Head(三种范式选一)       │             │
│  │   ① 离散 token 自回归(RT-2/OpenVLA)│            │
│  │   ② Diffusion Policy               │             │
│  │   ③ Flow Matching + Action Chunking│             │
│  │      (π0 主流)                    │             │
│  └────────────────────────────────────┘             │
│         ↓                                           │
│  输出:未来 N 步连续动作序列(如 1 秒内的关节轨迹) │
└─────────────────────────────────────────────────────┘

以 OpenVLA-7B 为例:它基于 Llama-2 底座,视觉侧用 DINOv2 + SigLIP 双流融合,在 Open X-Embodiment 的 970K 条真实机器人操作轨迹上训练,用 64 张 A100 训练 15 天。相比闭源的 RT-2-X(55B),OpenVLA 以 7 倍少的参数在 29 个任务上取得 16.5% 的绝对成功率提升。

2.3 三种动作生成范式

这是 VLA 和 LLM 最本质的差异:动作是连续值,不是离散 token。

离散 token 自回归(RT-2、OpenVLA):把连续动作离散化成 token,按 LLM 的方式自回归生成。优点是复用 LLM 训练栈,缺点是精度损失。
Diffusion Policy:用扩散模型生成动作块,表达能力强但推理慢。
Flow Matching + Action Chunking(π0 主流):π0 通过独立的 action expert 用 flow matching 生成连续动作,一次输出未来多步动作。π0 系列的 chunk size 是 50 个动作对应约 1 秒真实时间。π0.5 引入 Knowledge Insulation 技术,解决加入 action expert 后损害 VLM 主干语义知识的问题。

Action chunking 的另一个价值在于掩盖推理延迟:机器人在执行上一个 chunk 的同时,模型在后台推理下一个 chunk,避免"执行-等待-执行"的停顿。

2.4 主流开源训练框架

框架	背景	特点	适合场景
openpi	Physical Intelligence	π0/π0-FAST/π0.5 全开源,base 模型在 10k+ 小时真机数据上预训练	工业界 SOTA 起点
openvla	伯克利	原生 PyTorch FSDP + Flash-Attention,支持 1B-34B,LoRA 和全量微调内置	学术+工程参考
LeRobot	HuggingFace	数据格式+训练+部署一条龙,π0 有官方实现	快速上手

上手路径:租一张 A100/H100,用 openpi 在 BridgeData V2 上微调一个 π0-small,跑通全流程。这一步做完,对"具身训练到底需要 infra 提供什么"就有了体感。

2.5 和 LLM 训练栈的对照

LLM 训练栈	VLA 训练栈	关键差异
Tokenizer	动作编码器(离散化或 flow matching)	动作是连续值
文本数据集	机器人轨迹 episode(多模态)	数据结构完全不同
Autoregressive loss	Flow matching / Diffusion loss	生成目标变成连续动作块
Dataloader 读 JSON/Parquet	Dataloader 读 RLDS/LeRobot/HDF5	格式生态不同
Megatron 3D 并行	PyTorch FSDP + Flash-Attention	通信抽象不同
ckpt 管理	ckpt 管理(几乎一样)	经验可平移
SFT/RLHF	预训练 + 微调 + 后训练	流程类似

对有 Megatron 经验的工程师:通信优化、并行策略、ckpt 管理这些心智可以平移,但代码要重写。openpi 和 openvla 都用 PyTorch FSDP 而不是 Megatron,两套在分布式通信抽象上完全不同。建议把 FSDP 当作第一优先上手。

三、数据管线:具身 Infra 的主战场

3.1 数据是最大瓶颈

具身智能的残酷事实是:全球高质量真机交互数据目前只有约 50 万小时,而训练一个可用的通用具身模型需要千万小时量级,缺口达 4-5 个数量级。这意味着:

每一小时真机数据都有真实成本(遥操作员+机器人+场景搭建)
数据管线不是"辅助工具",而是燃料系统
谁能把多源数据高效变成可训练格式,谁就掌握了飞轮咽喉

3.2 四种数据来源

来源	数据特点	成本	主要缺陷
真机遥操作	最高质量、最接近部署	极高	数量少、场景受限
人类视频	海量、易获取	低	缺精确动作标注
动捕/穿戴设备	精确人体动作轨迹	中	人-机重定向 gap
仿真合成	无限、自动标注	低	Sim-to-Real 鸿沟

四种来源在传感器配置、坐标系、采样频率、时间同步上完全不同,且真实采集还会受时间同步误差、设备老化、发热、环境变化影响。infra 要做的就是把四种泥沙俱下的数据,洗成训练能直接消费的统一格式。

3.3 五段式管线设计

┌──────────────────────────────────────────────────────────────┐
│  阶段1:采集接入(Ingestion)                                │
│   ├─ 真机遥操作:力反馈手柄→机器人→录制(30-60Hz)           │
│   ├─ 真机部署回流:失败样本、人工接管、边界case自动捕获      │
│   ├─ 仿真rollout轨迹:Isaac Lab 批量产生                     │
│   └─ 原始格式:MCAP/ROS bag                                  │
│                          ↓                                   │
│  阶段2:时间同步与对齐                                       │
│   ├─ 多传感器时间戳对齐(相机/IMU/关节/力觉)                │
│   ├─ 插值到统一频率(典型 30Hz)                             │
│   └─ 剔除时间戳漂移的坏样本                                  │
│                          ↓                                   │
│  阶段3:清洗与质量控制                                       │
│   ├─ 轨迹完整性校验(episode 是否被截断)                    │
│   ├─ 成功率过滤(遥操作失败的 episode 打标)                 │
│   ├─ 视觉质量检查(遮挡、模糊、标定漂移)                    │
│   └─ 跨来源去重                                             │
│                          ↓                                   │
│  阶段4:格式标准化(核心)                                   │
│   ├─ 转成 RLDS / LeRobot / HDF5 之一                        │
│   ├─ 多本体动作空间归一(不同机器人自由度不同)              │
│   ├─ 语言指令标注(人工 / LLM 自动生成)                     │
│   └─ 元数据登记(本体型号、场景、操作员、日期)              │
│                          ↓                                   │
│  阶段5:训练消费                                             │
│   ├─ Dataloader 流式加载(支持随机访问 episode)             │
│   ├─ 多模态解码 pipeline(视频 GPU 解码)                    │
│   ├─ 数据混合策略(按来源/本体/任务配比)                  │
│   └─ 训练侧反馈(哪些数据有效,回流到采集计划)              │
└──────────────────────────────────────────────────────────────┘

3.4 四种主流存储格式

社区共识是:录制用 MCAP,训练用 LeRobot/HDF5/RLDS 之一,多数团队组合使用。

格式	存储结构	随机访问	生态	适用场景
RLDS	TFRecord 分片	中	Open X-Embodiment 标准、Google DeepMind 推	读开源数据集
LeRobot	Parquet 元数据+每路相机独立 MP4+safetensors	好	HF 生态原生、openpi 默认	训练主力格式
HDF5	单文件层级结构	强	DROID 等学术框架	稠密数值轨迹
Robo-DM	EBML 二进制	极强	伯克利新出,顺序解码速度显著优于 LeRobot	大规模数据湖
MCAP	容器格式	好	ROS 生态、实时录制	采集侧标准

动手建议:写一个 Python 工具,把一个 HDF5 数据集(比如 ALOHA 的公开数据)转换成 RLDS 和 LeRobot 两种格式,跑通三个下游:OpenVLA 训练加载、LeRobot 可视化、Robo-DM 风格的随机访问查询。做完这个,对"具身数据到底长什么样"的理解就超过多数纯 infra 背景的工程师。

3.5 数据飞轮:管线是闭环,不是单向

评价一家具身 infra 成熟度的关键指标——真机部署产生的数据能不能自动回流到训练集:

     ┌─────────────────────────────────────┐
     ↓                                     │
[云端GPU训练]                          [新一轮训练]
     ↓                                     ↑
[ckpt发布]                                 │
     ↓                                     │
[真机/仿真部署]                            │
     ↓                                     │
[机器人实际作业]                           │
     ↓                                     │
[失败/接管/新场景捕获] ──→ [标注/清洗] ───┘

真机部署中的失败样本、人工接管、边界 case 是最有价值的训练数据——它们精确暴露模型的盲区。如何自动捕获、回流、标注、入训练集,是当前行业公认的飞轮瓶颈。斯坦福在图书馆部署的 Scanford 移动机器人就是这个范式的代表:机器人在实际运行中自主采集"多语言标签、视觉杂乱、标签退化"这类真机才能遇到的边缘 case,反哺模型迭代。

对 LLM Infra 工程师,这一块是最可能做出标杆项目的位置——MiniMax 时期做过的"模型管理 & 评测链路重构"和这套飞轮高度同构(都是全链路数据+自动化+元数据管理),把那套经验平移到具身场景,从零到一搭一个真机数据回流的 Ingestion + 清洗 + 标准化流水线,价值相当于无问芯穹时期做一个 EgressGateway。

四、三个模块如何串成一个闭环

这三块不是孤立的,而是一个完整的训练闭环:

仿真集群负责"规模化试错"——用 GPU 算力代替真机成本,同时产生合成数据和评测结果
VLA 训练栈负责"从数据到模型"——在 GPU 集群上用 FSDP 把数据变成可部署的权重
数据管线负责"飞轮传动"——把真机/仿真/遥操作的所有数据源变成训练能消化的格式,再把部署反馈流回来

已有的 K8s、GPU 调度、ckpt 管理、评测链路经验在这三个模块里都是基础设施层的复用,真正需要新建心智模型的只有两件事:

仿真是 GPU 上跑的特殊工作负载,和训练任务调度特征不同
动作是连续值而非离散 token,生成范式和 LLM 完全不同

把这两个转变完成,就能在具身 Infra 的战场上快速进入能打的状态。

五、LLM Infra 工程师转型路径

能力模块	LLM Infra 可复用度	需要新建
K8s 集群管理 / CNI / 网络流量	✅ 100%	具身场景下的混合负载调度策略
GPU 资源管理与超卖	✅ 90%	仿真 GPU + 训练 GPU 的潮汐调度
ckpt 全周期管理	✅ 90%	多模态 ckpt 分片差异
训练观测 / 全链路通知	✅ 100%	具身 metric 体系(成功率、轨迹平滑度)
评测链路重构	✅ 90%	真机+仿真评测结果相关性分析
分布式训练	⚠️ 心智平移,代码重写	PyTorch FSDP(替代 Megatron)
数据管道	⚠️ 部分平移	RLDS/LeRobot/HDF5 三格式
多模态解码 / 视频处理	❌ 新建	GPU 视频解码 pipeline
仿真系统	❌ 新建	Isaac Lab / MuJoCo MJX 概念
机器人学 / 控制理论	❌ 不必深入	概念级即可

避免踩的坑:

不要陷入机器人学教材(《机器人学导论》之类)——Infra 视角不需要控制理论
不要死磕 Megatron 在 VLA 场景的适配——FSDP 是新主力
不要再造数据格式——LeRobot + MCAP 已经是事实标准,参与生态比另起炉灶更有价值

结语

具身智能 infra 和 LLM infra 的关系,不是"推翻重来",而是"在熟悉的底座上,盖一层全新的楼"。仿真集群、VLA 训练栈、数据管线——这三块对应着物理世界的三个基本约束:试错需要代价、算力需要集中、数据需要闭环。

对从 LLM Infra 转过来的工程师,真正稀缺的不是 K8s 经验,而是理解具身场景特殊性、并把通用 Infra 能力针对性重构的能力。谁先把这两个转变完成,谁就能在这个赛道定型前占住身位。