百万小时这个数字放在具身智能圈子里已经不只是“多存几块硬盘”的问题了。过去两年大家聊具身智能讨论最多的是模型结构、是demo效果、是端到端控制策略怎么收敛但现在当数据集规模跨过百万小时训练流程里最让人头疼的反而变成了数据存储带宽不够、仿真环境跑不动、多机训练同步卡死这些基础设施问题。说白了模型的想象力再好数据管道堵住了一切都白搭。这篇文章我就从自己实际搭建和运维这套基础设施的经验出发聊聊百万小时数据规模下具身智能对AI Infra的真正考验在哪里以及应对这些考验时最值得注意的细节。这个内容不是写给只想看论文结论的人看的而是写给真正要自己搭数据管线、跑大规模仿真、训练大模型、做模型评测的工程师和研究员。如果你正准备把具身智能从单机demo推向规模化训练那这篇文章里的很多坑你大概率还没踩到但很快就会踩到。1. 数据规模过百万小时具身智能的“量变”如何引发“质变”1.1 百万小时不是拍脑袋定出来的门槛很多人第一次听到“百万小时数据”这个概念时第一反应是这不就是100万个小时的录像吗大不了多买几块硬盘、多挂几个任务队列就能解决。但如果你真的跑过具身智能数据管线就会知道事情远没有那么简单。我举个例子。一段真机采集的机械臂操作视频分辨率通常是1080P甚至更高帧率30fps单小时产生的原始数据量在20到40GB之间。多模态信息还不止图像机械臂的关节角度、力矩、末端速度、夹爪开合状态这些时序数据也要同步回传再加上语音指令或者遥控操作记录单条小时级数据按30GB算100万小时就是30000TB也就是30PB级别的存储需求。30PB看起来还不算离谱但数据管线不是只存一遍就完事——你要做抽帧、清洗、去重、标注、增强、版本回滚每一道工序都可能产生一到三倍的中间数据副本。这时候你会发现原来用单机硬盘跑数据加载的日子彻底结束了。数据在磁盘和GPU之间流动的带宽会成为比GPU算力更早出现的瓶颈。所以百万小时这个量级本质上是一个倒逼基础设施升级的门槛数据规模大到一定程度瓶颈一定会从“模型设计”转移到“数据进出效率”上。1.2 从“能跑通”到“稳定跑量产”的转变我见过太多团队在展示demo的时候非常惊艳但真正开始全量训练时反而崩溃了。为什么因为demo阶段的数据集往往只有几千条单机可以随便折腾但百万小时规模的数据意味着你的训练任务要连续跑几天甚至几周中间任何一个环节出问题整个任务就白跑了。举几个真实发生的情况数据读取进程因为内存溢出被kill掉训练提前终止某个仿真节点因为任务分配不均匀被拖垮导致整个数据生成集群出现“木桶效应”多机训练时因为一台机器的网络抖动卡在梯度同步的all-reduce阶段损失惨重。这些问题的共同点在于它们不是模型能力的问题而是基础设施不够健壮的问题。所以在百万小时这个阶段“能跑通”已不再值得骄傲“稳定跑完整个训练周期”才算合格。这也是我在后面几个章节里反复强调稳定性和可观测性的原因。数据规模上了一个量级所有原来可以凑合的事情都变得不可凑合了。2. 数据管线是具身智能落地中绕不开的“硬骨头”2.1 数据来源多元化真机采集、仿真合成、公开数据集各有各的坑具身智能的数据来源目前大致可以分成三大类真机数据、仿真数据、公开的互联网视频或多模态数据。这三类数据在百万小时规模下的处理方式和坑点完全不同。真机数据质量高、语义真实但采集成本极高。你让一个操作员通过示教器或者遥控设备完成任务一小时可能只能采到几段高质量操作样本。而且遥控设备的操作熟练度会直接影响数据质量新手操作员采出来的数据机械臂抖动、轨迹不合理、夹爪开合时机不对这些都是家常便饭。更麻烦的是真机数据天然不平衡简单任务容易采集复杂长程任务往往需要十几倍的时间才能凑够样本量。仿真数据解决了成本问题你可以在虚拟环境里并行开几千个环境疯狂生成数据一天下来数据量轻轻松松到几十万小时。但仿真数据最大的麻烦在于“真实性”和“域差”问题。仿真器里的物理引擎再精细和真实世界的接触力、摩擦、光线、传感器噪声还是有区别。我在实操中发现当训练数据里仿真数据占比超过一定比例时模型在真实环境里会出现明显的“仿真依赖”——它在仿真里表现得完美一到现实就失灵。公开的互联网视频数据是最容易获取的互联网上确实有海量的人类操作视频。但问题是这些视频的相机位姿五花八门、任务语义不明确、操作过程中往往有遮挡。要把这些数据变成可用的机器人操作监督信号需要做大量预处理和标注投入的人力成本不容忽视。我的建议是百万小时规模的数据管线尽量以“仿真数据作为规模底座 真机数据作为质量校准 公开视频作为语义补充”的混合策略来搭建。单一数据源很难在成本、规模、质量三个维度上同时满足要求。2.2 清洗、去重、对齐决定模型上限的“脏活累活”很多团队把精力全放在模型结构上觉得数据清洗是“脏活累活”随便跑几个脚本就算完事。但以我自己的实操经验看数据清洗质量对最终模型效果的影响往往比模型结构改动大得多。具身智能数据清洗有几个特别容易被忽视的环节。第一是时间戳对齐。真机上采集的数据视觉信号、关节状态、指令信号往往来自不同的传感器每一路的时间基准可能有几百毫秒的偏差。如果不做时间戳对齐模型学到的输入输出映射就是歪的——明明视觉传感器已经看到物体被抓住了关节数据却还停留在抓取之前的状态。这个问题在单条数据上几乎看不出来但训练量一大模型就会学出“延迟响应”或者“预判错误”这类奇怪行为。第二是去重。百万小时的原始数据里真正互不相似的样本可能只有几万小时。如果不去重模型会被大量高度相似的样本“刷屏”对稀疏场景和边缘情况的泛化能力会越来越差。去重不能只做视频层面的帧级Hash还要结合任务语义做场景级的聚类去重。比如同一张桌子上、同一位置、同一姿势的抓取动作尽管每帧图像有微小差异但在语义上是同一种样本应该按比例降采样。第三是标注规范统一。数据标注的好坏直接决定模型的上限。标注规范要提前定义好任务描述、物体类别、动作标签、轨迹关键点每个字段都要有明确的格式和取值范围。否则多个人或者多个批次标出来的数据尺度和粒度不一致模型很容易被搞糊涂。2.3 数据格式统一与版本管理基础设施里的“隐形地雷”数据格式混乱带来的麻烦越到后期越明显。早期各算法工程师各存各的有人存MP4视频JSON标签有人存HDF5有人直接用Pickle。等数据量上来之后你要做分布式采样、跨模态对齐、多机并行训练格式不统一意味着每个环节都要写一层格式转换代码慢还不说还特别容易出bug。目前行业内相对主流的做法是统一使用开源的标准化具身数据集格式比如HDF5或者Zarr这一类支持大规模并行读写的存储格式把所有传感器模态都放进同一个容器里再配上结构化的meta信息。Zarr的优势在于它天然支持chunk压缩和分布式并行读取在数据规模大的时候性能优势特别明显。我建议你在搭建数据管线第一天就统一格式中途切换格式的代价极其昂贵。版本管理同样重要。具身智能数据集是持续迭代的你今天新增了2000小时避障数据明天修正了一批错误标注后天又把旧版本的真实数据重新校准了。整个过程如果没用数据版本管理工具记录下来训练结果根本没法复现。你可以用DVC或者LakeFS这类工具对数据集做版本管理让每次训练都能精确对应到某一版数据快照。这不仅是工程规范问题也是研究可复现性的基础。3. 训练基础设施算力再强系统调度乱了也白搭3.1 训练框架选型不是越高级越好稳定和生态才最重要具身智能大模型训练当前的主流路线是视觉-语言-动作模型也就是VLA模型。VLA模型通常基于预训练的视觉-语言主干在上面接一个动作输出头用百万小时级别的机器人操作轨迹做训练。在框架选型上很多团队一开始会纠结用哪个分布式训练框架。我的经验是不要盲目追逐最新颖的框架要选择生态成熟、踩坑资料多、团队最熟悉的方案。工程稳定性的优先级永远高于性能上限。你框架性能再高出了问题排查三天查不出来整个训练周期就废了。另外既然选了框架就尽量把“断点续训”这种能力从一开始就建设好。百万小时规模的训练任务不可能一次跑完分布式训练中节点故障是常态没有断点续训的话一次故障就可能让几天算力白费。3.2 数据加载与预处理流程的优化最容易忽略的“隐形瓶颈”训练任务跑不起来很多人第一反应是加GPU但很多时候瓶颈根本不在GPU而在数据的加载和预处理上。百万小时的数据量下数据读取、解码、增强、传输这些本来在demo阶段毫不起眼的操作会突然变成整个训练流程里最慢的一环。我给你算笔账假设你训练VLA模型时的数据加载是单进程逐条读取每条样本解码出来需要3秒那么100万条样本一轮epoch就需要将近35天。你觉得离谱吗实际上在很多团队里这种事情就是真实发生的。训练一跑起来GPU利用率只有20%到30%原因就是数据根本喂不进来。我自己的解决方案是四层流水线架构第一层用数据分片和大块连续读取来优化磁盘IO第二层用多个worker进程并行做数据解码和增强第三层在内存里维护一个高容量的预取缓存队列第四层直接用GPU显存缓存一部分热数据。这套设计能保证绝大多数样本在GPU计算完成之前就已经在队列里等好了GPU利用率可以稳定拉到85%以上。3.3 仿真平台的并行化大规模合成数据必须走分布式仿真数据在百万小时数据规模里承担了“数量担当”的角色。要想在合理时间内生成几十万小时的仿真数据单机开几个Unity或Isaac Sim实例是完全不够的必须搭起一套分布式仿真集群。以Isaac Sim为例你可以通过容器化技术把仿真环境打包成镜像然后在Kubernetes集群上同时拉起成百上千个仿真任务实例每个实例各自独立运行一套仿真环境持续产生轨迹数据再定时把数据推送回统一的数据存储。这种架构下数据生成速度和集群规模成正比理论上只要你容器能拉起来多少个数据产量就能翻多少倍。但多实例并行仿真会带来两个新麻烦。第一是仿真初始条件的多样性问题如果每个实例都用同一套初始场景生成出来的数据就会高度同质化我一般会为每个仿真实例分配不同的随机种子、不同的物体摆放策略和不同的任务难度系数保证数据分布的广度。第二是异常检测和自动重启机制仿真任务在长时间运行后经常出现物理穿透、任务卡死这类异常采集到的数据质量会大幅下降你要设计一个健康检查策略自动杀掉并重启异常实例同时丢弃该实例产生的异常数据。4. 评估与回流规模越大越需要一套可靠的“质检体系”4.1 仿真评估与自动化回归保护训练效果的最后一道防线模型训练完之后效果到底怎么样这是每个团队都必须回答的问题。在小规模数据时代肉眼看一眼demo就大致有数了但到了百万小时规模模型动辄几亿甚至几十亿参数人工评估慢且主观根本无法支撑高频迭代的需求。所以你必须建立一套自动化的评测基准。常用的思路是建立一套不同难度的标准任务集把模型放到仿真环境里自动跑测试。评测任务要覆盖抓取、推搡、堆叠、长程操作等不同类型的技能每个任务还要区分简单、中等、困难三档难度。评测过程全部自动化模型每训练一个checkpoint就自动跑一轮评测把成功率、平均完成时间、轨迹平滑度这些指标记录下来。有了这套自动化评测体系你就能在训练过程中实时监控模型能力的上升和回退。有时候你会看到某个checkpoint在训练loss上下降了但在评测任务上的成功率反而暴跌——这就是典型的“过拟合到训练分布”的信号。没有评测体系的话这种问题可能要过好几轮迭代才能发现浪费大量算力。4.2 真实环境验证仿真评测再准也替代不了真机测试仿真评测虽然效率高、成本低但它和真实世界之间始终存在一个“最后一公里”的差距。仿真器里的视觉渲染再逼真和真实相机的噪点、动态范围还是有区别仿真器里的物理引擎再强大也难以精确模拟真实世界里的线缆缠绕、关节摩擦、物体滑动这类复杂物理现象。所以我的做法是在仿真评测通过之后还必须安排一个真机环境的小批量验证环节。真机验证不一定需要覆盖所有任务选择不同技能类别里最有代表性的若干任务各跑几十次就足够了。重点看两个指标一个是成功率另一个是任务完成过程中的“故障分布”——模型是经常在初始抓取阶段失败还是经常在长程任务的中段迷失方向这两类问题的修复思路完全不同。真实环境验证环节需要投入不少人力但它也是数据回流的重要来源。真机验证中暴露出来的失败案例经过人工分析标注后要重新注入数据管线。这个“仿真生成-训练-仿真评估-真机验证-失败案例回流”的闭环是百万小时数据规模下提升模型能力最可靠的方法论。4.3 评测体系与数据反馈闭环让失败的case反过来滋养数据管线很多团队做评测只是停留在“得出个成功率数字”的阶段这是远远不够的。评测的最大价值在于它能指出你的数据在哪里存在短板。我习惯把每次评测失败的任务按失败阶段、失败原因和涉及场景做细分统计然后把统计结果直接反馈到数据采集和数据生成环节。举个例子如果你发现模型在“抽屉拉开后抓取内容物”这个复合任务上成功率特别低那大概率是训练数据里这个场景的样本量太少了。这时候你就应该在仿真环境里针对性地增加抽屉相关任务的生成概率同时安排真机采集团队补充一部分抽屉操作的真实数据。这样每轮评测不仅能告诉你“模型目前不行”还能告诉你“下一轮数据应该往哪里使劲”。5. 百万小时数据工程中的常见故障速查与处置经验5.1 训练时GPU利用率低首先排查数据链路现象GPU利用率长期低于50%训练步数跑得很慢但GPU算力没被打满。排查顺序看数据加载曲线是否有周期性“断崖”如果有说明预取队列空了数据加载速度跟不上GPU消费速度。检查是否存在大量小文件随机读。如果是这种情况尽快把数据重新打包成Zarr或者HDF5这类大文件格式。检查解码和图像增强是否跑在CPU主线程上。把这类重操作迁移到独立worker进程里能大幅提升吞吐。最后再检查网络传输瓶颈分布式训练中频繁拉取远程数据也会导致GPU空转。5.2 训练loss正常但评测效果差大概率是数据分布问题现象训练loss稳步下降看起来一切正常但一到评测环境任务成功率就没有提升。这种情况我遇到过好几次根因通常是训练数据分布和评测任务分布不匹配。比如训练数据里90%都是“物体在桌面中心”的样本评测任务却要求模型处理“物体在桌面边缘”的情况模型自然就懵了。解决办法把训练数据和评测任务的场景条件分布做个可视化对比重点看物体位置、光照、背景、任务起始状态这些维度。差距暴露出来后针对不足的场景重新生成数据或降低其他冗余场景的采样权重。5.3 真机测试与仿真结果偏差大优先怀疑“域差”现象仿真评测成功率85%真机测试只有40%。第一优先怀疑物理引擎参数和真实世界的差距尤其是接触力、摩擦系数、阻尼这些参数。你可以收集一小批真机轨迹在仿真里回放对比看轨迹在哪个阶段出现明显偏差。第二要检查传感器仿真噪声模型是否设置过低。真实相机有噪声、真实关节有延迟你在仿真里把传感器设置成“理想状态”模型到了现实就等于蒙着眼睛干活。要给传感器加噪声、加延迟、加随机扰动增强模型的鲁棒性。5.4 训练意外中断后恢复困难断点续训要设计好现象训练跑到一半某个节点宕机重启后要从头开始。如果你从一开始就做对了断点续训这只是一个“损失几十步训练进度”的小事如果没做对可能几天的算力直接清零。关键点有三个模型权重和优化器状态要定时同步保存数据加载器要支持从最近epoch的断点位置恢复训练日志和指标曲线要和checkpoint配套记录方便恢复后确认训练状态。关于checkpoint保存频率我建议早期训练阶段可以稍微放宽间隔后期接近收敛时缩短保存间隔这样既不会频繁写磁盘又能最大限度避免损失训练进度。6. 你自己的具身智能学习路线从基础设施入手反而更快前面聊了这么多基础设施层面的内容可能有人会觉得这些离“算法模型”太远。但实际上对一个想入行具身智能的新人来说从数据管线和训练基础设施入手反而是一条更平滑、更高效的学习路线。原因很简单纯搞模型结构你需要深厚的数学和深度学习基础而且SOTA模型往往被大厂牢牢把持很难插上手但数据管线和训练基础设施这块行业里却极度缺人。每一家做具身智能的公司都在为数据发愁都在为训练效率发愁这些岗位的需求量极大。学习路线上我建议按这个顺序递进先从解决“单机数据处理与模型训练”开始学熟练掌握一个主流深度学习框架跑通一个机器人数据集上的小规模训练然后扩展学习“分布式数据管线”搭建一个微型仿真数据生成集群再去接触“评测闭环”建立自己的自动评估和模型迭代流程最后逐步深入大模型自身的结构设计和部署优化。如果要去面试具身智能相关岗位除了基础的深度学习知识把这套数据量和训练效率的问题聊透绝对是一个巨大的加分项。很多候选人一上来就背模型结构但问到“数据规模上来了之后你怎么解决训练效率问题”就语塞了——这个问题的回答质量几乎可以直接反映一个人有没有真正做过大规模具身智能训练。按我个人的经验具身智能这个行业目前最缺的不是“能跑通demo的人”而是“能在海量数据环境下稳定跑完训练、高效迭代模型的人”。数据规模跨过百万小时以后AI Infra的能力直接决定了团队的迭代速度和上限。谁能把数据管线和训练系统打磨得更稳、更快、更省钱谁就能在具身智能这场竞赛里跑得更远。