百万小时数据规模下的具身智能AI Infra：存储、训练与数据飞轮

在跑VLA模型的多机训练时，我第一次意识到“具身智能”和“AI Infra”这两个词放在一起意味着什么，是在数据规模跨过百万小时之后。那段时间，模型结构早就调通了，真正卡住整个项目进度的反而是一堆看起来不该是瓶颈的东西：GPU利用率上不去、checkpoint保存一次就要卡几分钟、真机评测排期排到下个月、不同批次的数据格式对不上导致训练突然报错。

如果你也正在做具身智能的数据采集、训练或者基础设施，这篇内容是我这些年踩坑攒下来的一些经验，覆盖数据存储、加载、训练集群、仿真评测、数据飞轮设计和基础设施选型几个方向，希望能帮你少走点弯路。这个领域和纯NLP、纯CV最大的区别在于，数据规模一旦真的跨过百万小时，AI Infra就不再是“后台支持”，而是直接决定你每周能迭代几版模型的关键变量。

1. 百万小时是什么概念：具身智能数据管线的本质变化

1.1 这批数据不是“攒”出来的，而是“采”和“合成”出来的

当大家谈具身智能数据规模的时候，得先弄清楚一件事：这批数据和互联网文本、图像完全不是一个来源，不是爬虫能爬来的。具身智能数据主要靠三条路径产生：真机遥操作采集、半自动收集、仿真合成。

真机遥操作是最常见的方式。工程师戴着VR手套或者操控手柄，记录机械臂或者人形机器人的关节轨迹、力/力矩、视觉图像、语言指令。单条轨迹通常几十秒到几分钟，但多传感器是并行记录的，单小时的数据量非常可观。我见过不少团队一开始只用一台机械臂慢慢采，一旦第一个项目跑通，采集规模会突然加速度增长，设备从一台变五台十台，这时候数据基础设施的压力马上就会出现。

仿真合成是另一条线，在Isaac Sim、Genesis、MuJoCo这类环境里可以大规模并行生成数据。仿真数据的产能远远高于真机，几十张GPU跑一个晚上就能生成几千甚至上万小时的行为数据，但仿真数据和真机数据之间存在domain gap，材质、物理、光照、控制频率都不一样，后面要专门处理。

百万小时是什么量级？我们用保守方式估算一下：假设采样频率30Hz，每帧包含两路RGB图像、一路深度图、本体状态（关节角、关节速度、力矩、力传感器），单帧打包之后大概1到3MB。一小时采集量大约100到300GB。也就是说，一百万小时的原始数据，即使经过降采样、裁剪、压缩，也能轻松达到几十PB级别。这个量级下，数据不可能再像小规模实验那样塞进内存，或者挂在一个NFS共享目录里跑，它会逼着你重新设计存储、IO和训练管线。

1.2 为什么CV/NLP那套数据管线不能直接套用

不少团队的第一反应是“用现成的CV/LLM数据管线不就行了”。我试过之后发现，这里面有几个结构性的差异，不解决的话，后面全是大坑。

首先是数据形态。文本是一维离散token，图像是二维静态张量，而机器人数据是“多传感器+时间序列+动作语义”的混合体，一条轨迹前后帧高度相关，单独拎一帧出来几乎没有训练价值。采样频率、时间戳同步、传感器坐标系的差异，都会直接影响训练效果。其次是异构性，机器人本体、传感器型号、关节配置、执行器响应完全不同，在A型号机械臂上采的数据，放到B型号人形机器人上，如果不做本体感知和归一化处理，基本上就是噪声。第三是交互属性，机器人数据天然是“动作-观察-反馈”的三元组，数据里隐含着环境、任务、因果，整理这种数据的时候，需要有非常强的元数据管理意识。

每段轨迹属于什么任务、在哪种环境里采集、任务是否成功、机械臂是哪款、采集员是谁，这些信息后期做训练和评测几乎全都用得上。CV/NLP数据管线里，这类结构化信息通常不是第一优先级，但在具身智能里，没有元数据的数据基本等于废数据。我在团队里经常说一句话：采集的时候多花一分钟记元数据，训练的时候能省一天排查问题的时间。

2. 数据跨过百万小时后，最先崩掉的是这四个环节

2.1 存储与读取：海量小文件随机读会打穿数据加载器

数据刚上规模的时候，最常见的做法就是按“一个样本一个文件”存放，目录结构简单，调试方便。但到了百万小时量级，这种做法的瓶颈是致命的。

想象一个采集目录下有几百万个小文件，每个文件只有几十到几百KB，PyTorch的DataLoader每次随机取一批，本质上就是海量小文件随机读。文件系统在这种负载下，inode开销、目录遍历开销都极其恐怖，GPU卡到20%到30%几乎是必然的。很多团队以为是训练代码有问题，折腾了一周模型结构，结果把存储一换，训练速度原地起飞。

我比较推荐的做法是：把原始数据按轨迹或场景打包成大文件，再配合缓存层。具体来说有两种主流方案。一种是直接落地到WebDataset或HDF5这类大文件格式。WebDataset把多个样本打包成一个tar包，每个tar包几百MB到几GB，顺序读取，天然适配分布式训练。HDF5适合读固定维度的数据，但具身智能数据维度不固定，所以多模态轨迹数据我个人更倾向tar包。另一种是保留原始文件，但在训练集群前面挂一个NVMe缓存层或者高频对象存储网关，用Lustre或WEKA这类并行文件系统做底层，训练节点只需要访问热点数据。

不管你选哪种，关键原则是：训练时读取的必须是“大块、顺序、预取”的数据流，而不是“小块、随机、边读边看”的文件列表。这个原则一定要在数据链路设计的第一天就定下来，后面再改成本很高。

2.2 清洗、标注与质量筛选：人工流程跟不上数据产线节奏

第二个崩掉的环节，是数据标注和质量筛选。具身智能数据里，除了图像识别那种像素级标注外，还要做语言指令标注、轨迹质量评估、任务成功与否的判定。

语言指令标注就是典型瓶颈。百万小时数据里，如果每条轨迹都要人工写自然语言指令，哪怕外包团队效率很高，成本也完全失控。我们的做法是“模型预标注加人工抽检”，先让一个VLM或者LLM根据轨迹片段生成指令，再由标注员审核修改，大概能把人力压缩到原来的五分之一到十分之一。模型预标注的质量一开始肯定不如纯人工，但它可以随着模型迭代越来越准，人工抽检的比例也可以慢慢降下来。

质量筛选同样重要。真机采集的数据不是每条都有训练价值，有的轨迹里机械臂抖动严重，有的任务根本没完成，有的传感器某个时刻断了。如果不管三七二十一，把这些有问题的数据全部丢进训练集，模型会花大量容量去拟合噪声。所以质量筛选器是数据产线上不可缺少的一环，可以从轨迹平滑度、任务完成度、传感器状态可信度三个维度做自动化评分。评分低的轨迹进入人工复核池，评分正常才放行进训练集。

我见过一些团队把大量时间花在优化模型结构上，却忽视了数据质量问题，结果同样的模型结构，换一版质量更好的数据，效果直接翻倍。这类事情在具身智能里比CV更明显，因为数据本身就是动作语义，质量差的数据不只是“看不清”的问题，而是在教模型错误的动作。

2.3 训练侧：GPU利用率被拖到80%以下，模型在等数据

一旦数据进入百万小时量级，训练集群的问题也会逐渐暴露。最典型的现象是，nvidia-smi一打，GPU利用率在50%到70%之间抖动，但训练loss死活不降。定位到最后，大概率是数据加载、数据预取、数据增强成了瓶颈。

VLA这类模型训练任务有个特点：输入是多帧图像连在一起，模型forward和backward的计算量和显存占用比纯文本模型高很多。而数据的读取又需要解码图像、点云，做temporal sampling、resize、normalize。如果每个GPU吃的是同一个数据源，没有做并行预取，那么一次数据加载卡顿，整轮训练都要等。另外，checkpoint写入也是一个隐蔽的大坑。当模型规模到7B、13B、34B这个量级，一个full checkpoint动辄几十GB，如果不做异步保存，每次保存都会让整个训练job阻塞几分钟。多机并行时，如果所有rank都同时写同一份checkpoint到网络存储，网络带宽也会被打满。

解决办法没有秘密：数据读取走预取加多worker并行，数据增强部分能放到GPU上做的尽量放到GPU上，checkpoint写成异步、分片保存到对象存储。这些优化单项看起来提升不大，叠加起来往往能让GPU利用率从60%涨到90%以上，训练时间缩短至少三分之一。

2.4 评测与真机验证：整个闭环里最慢、最不可并行的一环

最后要说的，是评测环节。具身智能的训练迭代到一定阶段，不能只看loss，必须回到真实环境去验证。仿真评测可以大规模并行跑，但真机验证受硬件数量、场地面积、安全规范、操作员人力限制，一天能验证的任务数非常有限。

这里有一个很现实的问题：训练集群可以一夜之间跑几十个实验，但真机评测一天只能跑有限次。到了百万小时数据规模，模型迭代一周就能出一版，评测速度反过来变成了整个研发节奏的瓶颈。我的体会是，评测平台一定要提前自动化。仿真评测做回归，每个模型版本统一跑一批benchmark任务，带宽可以拉得很高。真机验证做抽样，每个版本抽固定的比例，跑到核心场景和长尾场景，以最低代价捕捉仿真和真机之间的gap。评测结果和训练日志、模型版本绑定，存进同一个实验追踪系统。

如果不做这套，你会发现团队的时间全耗在“这个模型到底行不行”的扯皮上，而不是在迭代。评测和标注一样，都属于看起来不起眼、但最后一定会反噬整个产线节奏的环节。

3. 训练基建实操：从单机调试到多机并行要补的课

3.1 数据加载器的必要优化：从tar打包到多worker预取

从单机debug到多机训练，第一步就是把数据加载器重写一遍。具体来说，我会按这个顺序排查问题。

第一，确认数据格式是否是大文件流式。如果不是，先打包成WebDataset或者tar。这一步没法省。第二，DataLoader的worker数和prefetch因子要调到与CPU核数和IO带宽匹配。实践中，单GPU通常要配8到16个worker，prefetch至少2到3个batch。第三，把shuffle的粒度从“样本级”改成“tar包级加包内轨迹级”，减少IO随机性，同时保证训练数据分布足够随机。第四，用支持流式读取的库直接访问远程存储，避免文件句柄随着并发上升而耗尽。

这里可以给一个比较常见的PyTorch DataLoader配置作为起点，具体数值还是要根据机器实测调整：

# PyTorch DataLoader 的常见配置示例 DataLoader( dataset=train_dataset, batch_size=256, num_workers=16, # 单GPU对应的worker数 prefetch_factor=4, # 提前预取的batch数 persistent_workers=True, # 避免每个epoch重新创建进程 pin_memory=True, )

写一个profile脚本实测一下：单独跑一个epoch的数据加载时间，对比总训练时间。理想状况下，数据加载时间应该占不到单epoch总时间的10%。如果超过30%，不用怀疑，先优化数据管线，再去调模型。很多团队遇到训练慢，第一反应就是扩卡，但如果是数据管线的问题，加卡只会让瓶颈更明显。

3.2 并行策略和checkpoint策略的选择逻辑

VLA模型的并行策略选择和纯LLM有很大区别。VLA通常由一个视觉编码器（比如SigLIP或者DINOv2）和LLM backbone组成，视觉编码器本身很重，而且输入是多帧图像，导致在模型前端的计算和显存压力非常大。

具体的选型逻辑可以这样理解：模型规模在7B以下，单机多卡FSDP通常够用，配合梯度checkpointing把中间激活打下来。到了13B到34B，就要考虑张量并行加流水线并行的组合，把大层切到多卡上。视觉编码器可以先冻结或者只做LoRA微调，降低显存压力。因为VLA的序列长度不高但多模态输入特征多，DP、TP、PP的比例需要实测调整，不能直接照抄LLM的配置。

checkpoint策略上，我强烈建议做分片保存，也就是sharded checkpoint。每个rank只保存自己负责的那部分参数，然后再集中合并到对象存储。保存过程走异步线程，训练不阻塞。发生故障时，只需要从最近一次分片checkpoint恢复，配合自动重启脚本，能做到几分钟内恢复训练。这里也提醒一句，checkpoint不要只存在本地磁盘，本地盘一坏就全没了，最好有一个对象存储或者远端文件系统作为落地位置。

3.3 故障恢复与集群调度：断点续训是必答题不是加分项

很多人第一次跑多机训练时，会明显感受到一台GPU坏了导致整个训练job灰飞烟灭的恐怖。更麻烦的是，如果没做周期保存，或者checkpoint只是保存在本地磁盘，一旦机器重启，前两天训练全是白干的。

集群规模越大，出故障的概率越高。8卡跑一个月可能碰不到一次，128卡基本每周都会遇到小概率事件。所以基础设施要提前做好几件事。周期性checkpoint必不可少，间隔要根据训练速度和故障频率平衡，一般15到30分钟一次比较合理，太频繁会浪费IO，太稀疏会丢进度。自动重启机制也很关键，用Kubernetes配合Volcano或Kueue这类调度器，或者Slurm的Job array，把失败任务自动拉起来，从最近checkpoint继续。训练日志、环境镜像、数据集版本在重启之后必须可复现，不能出现“昨天能跑今天报错”的魔幻问题。

我记得有一次半夜训练中断，第二天早上看日志才发现是存储连接超时。排查了半小时，最后发现是某个节点网卡驱动出问题，导致checkpoint写不进去。从那以后，我就要求所有集群必须做训练可观测性，GPU利用率、数据加载耗时、checkpoint耗时、网络吞吐全部记录下来，出现性能下降能快速定位。

4. 数据飞轮闭环设计：采集、训练、仿真、真机验证如何协同

4.1 数据回流与质量筛选：不是所有采集数据都值得进训练集

数据规模上来之后，最关键的设计决策之一就是“数据要不要全量进训练集”。我的答案很明确：一定不要。

真机采集的轨迹里，噪声数据、失败数据、歧义数据占比不低。把失败轨迹丢进模仿学习的数据集，模型会学到不该学习的动作。把碰撞、抖动严重的轨迹丢进去，模型的输出分布会变散。所以每个版本的数据集更新，都应该由质量筛选器把门。

我们实践中用三个自动化维度。第一是任务成功与否，可以靠VLM自动判断，或者人工标注。第二是轨迹平滑度，看关节角速度、力矩变化是否存在异常尖峰。第三是传感器健康，图像或深度图有没有丢帧、IMU有没有饱和。筛选器判断不了的中等质量数据，进入人工复核池，每周抽检一次。全量数据一流入训练集的做法，看起来是多快好省，实际是在给模型喂毒。

数据回流还有一个容易被忽视的点：新增数据对已有模型能力的影响。每次加入新一批数据，可能会导致模型在某些旧任务上的表现退化。这个现象在具身智能里相当常见，所以建议每次数据更新后，把全量评测任务都跑一遍，而不仅仅是看新任务的效果。

4.2 仿真数据和真机数据的配比，以及domain randomization的作用

仿真数据的产能远高于真机，在几十张GPU上跑Isaac Sim或者Genesis，一天可以生成几千小时的行为数据，而真机采集一天最多也就几百小时。问题是仿真数据和真机数据之间存在domain gap，材质、物理、光照、控制频率都不一样。如果仿真数据占比过高，模型在真实环境部署时会产生明显衰减。

我的做法是：训练时把仿真数据和真机数据分桶，控制比例。初期可以用10比1甚至20比1的仿真数据打底，让模型见过足够多样的场景。后期逐渐把真机数据比例提到1比1左右，主攻分布精度。同时用domain randomization让仿真数据覆盖更广的变化区间，减小sim-to-real gap，例如随机化光照、纹理、物理参数、传感器噪声。这个比例不是固定的，每个项目的最佳值都不一样，不要照抄别人的配比，要通过一组消融实验来确定。

还要注意一点，仿真数据虽然产能高，但如果只在同一套仿真环境里生成，数据多样性很快就会饱和。要让仿真数据真正有价值，需要不断扩展任务设置和环境变体，否则模型只是在一个更大的“模拟复读机”里打转。

4.3 元数据、版本管理与可复现性：数据规模越大越重要

最后一点，可能是最容易被忽视的：元数据和版本管理。百万小时数据不是一次到位的，而是持续采集累积的。每一批数据来自哪个采集批次、哪台机器人、什么时间、用了什么校准文件，这些信息如果不记录，后面训练出一个好模型却复盘不出为什么会好，这种情况会越来越多。

我建议每个团队尽早建立一套数据版本管理方案，至少包括：每个数据集有唯一ID和版本的语义化命名，每条轨迹关联其采集元数据（任务ID、机器人型号、传感器配置、操作员ID），训练实验记录里必须写明使用了哪个数据版本、仿真环境版本、模型代码commit，评测结果与实验记录绑定，持续积累。

有了这套东西，才能支撑良性的数据飞轮闭环。不然采集、清洗、训练、评测四个环节之间的衔接会不断出现“数据对不上”“环境跑不出来”的低级问题。而且数据版本管理越早建越好，因为数据量大了之后，你不可能回退到一个月之前去重新打标签。

5. 具身智能AI Infra选型清单与团队落地建议

5.1 存储、训练框架、调度三个层级的选型

聊完原理，给一份比较实际的选型清单。先说存储，这是最容易被低估的部分。

训练框架层面，目前VLA生态还没有完全统一的工具。常见做法是PyTorch加FSDP或DeepSpeed做训练，数据管线用WebDataset或Mosaic Streaming Dataset，实验追踪用W&B或MLflow。仿真侧可以用Isaac Sim、Genesis、ManiSkill，评测脚本尽量自己写一套，统一接口。调度层面，Slurm在传统超算和高校lab更常见，Kubernetes生态更适合容器化、动态调度、自动重启。如果团队规模不大，建议先把训练job封装成容器镜像，再上K8s或托管集群，否则后期换调度系统的成本很高。

我个人的建议是不要过度设计。很多小团队一开始就上全套k8s加并行文件系统，结果运维成本比训练成本还高。按当前数据规模选型，留出半年到一年的扩展空间就够了。

5.2 高校Lab、创业公司和大型团队的不同打法

不同规模的团队，对AI Infra的投入策略差别非常大。

高校Lab或者小团队，GPU资源通常有限，几十TB的数据就很多了。这时候重心应该放在让数据管线高效，而不是买更多硬件。用开源方案搭存储和调度，优先把数据格式、版本管理、评测自动化建起来，因为一旦这些不建，后期数据增长后会非常痛苦。我没少见过Lab里的同学把大量时间浪费在手动下载数据、手动改路径、手动拷贝模型上面，这些时间完全可以通过一个简单的数据集管理脚本省下来。

中型创业公司通常要解决模型迭代速度的问题。建议组建一个两到三人的Infra小组，专项负责数据管道和训练集群。存储、调度、数据版本管理这三件事最重要，仿真评测平台提前搭好。大型团队可以考虑自研部分基础设施，比如自建数据仓库、统一数据集注册表、大规模并行仿真平台、自动化真机评测场地。这个阶段，AI Infra已经不是support角色，而是公司的核心资产。

实际上，不管团队大小，有一条建议是通用的：不要等数据规模真的到了百万小时才开始重视AI Infra。地基要从第一天就开始打，哪怕只是一个小脚本、一套目录规范，也比之后再推倒重来强。

5.3 越早搭建越好的四个基础组件

最后分享几个我个人觉得越早搭建越好的组件。这些看起来简单，但收益巨大。

数据集注册表是最重要的。每个数据版本像软件版本一样管理，训练脚本通过ID引用，而不是到处传路径。统一评测脚本库也很关键，让所有模型版本跑同一套评测任务，结果自动汇总到看板。训练可观测性同样不可少，GPU利用率、数据加载耗时、checkpoint耗时、网络吞吐全部记录下来，出现性能下降能快速定位。最后是真机验证记录系统，每次真机实验的录像、传感器日志、任务结果都要归档，作为训练数据回流的入口。

这四个组件在两三个月内就能搭出一个最小可用版本，但省下的时间远远不止三四个月。尤其在数据规模跨过百万小时后，基本每个团队都会面临“GPU在等数据”“模型版本对不上评测结果”“训练中断后恢复困难”这类问题，提前把地基打好，后面就是越滚越快。我自己最深的体会是，基础设施不像模型结构那样能带来“惊喜式”的提升，但它的每一分投入，都会转化成训练迭代时的确定性。