1. 从“能跑”到“跑得动”百万小时数据到底意味着什么过去两年具身智能圈子里最不缺的就是demo。今天这个机器人学会了开冰箱明天那个团队秀出叠衣服视频里动作流畅得像真人。但如果你真在实验室里盯着机器人跑过几百小时数据采集就会明白一件事视频里那几十秒的“高光片段”背后是海量数据的堆砌而海量数据一旦跨过某个量级最先崩掉的往往不是算法而是你脚下那套基础设施。我所说的“百万小时”不是某个营销话术而是一个实打实的数量级概念。假设一台机器人每天有效运行8小时一年也就3000小时上下。一百万小时意味着大约300多台机器人全年无休地跑或者一个中型团队用数千台设备高强度采集近一年。这个规模放在自动驾驶领域可能不算离谱但在具身智能行业绝大多数创业公司连这个数字的零头都摸不到。而当数据量真的逼近这个量级时问题就开始变得很有意思模型能不能收敛反而不是第一焦虑了第一焦虑变成了数据从哪来、怎么存、怎么标、怎么喂给训练集群、怎么在仿真和真机之间对齐。这套东西业内统称为AI Infra。很多人对AI Infra的理解还停留在“买几台GPU服务器、搭个分布式训练框架”的层面。放在纯语言模型时代这个理解勉强够用因为文本数据的采集、清洗、标注链路已经非常成熟。但具身智能的数据根本不是文本它天生就是多模态的高帧率视频、深度图、力觉传感器数据、关节角度编码器读数、机械臂末端的六维力力矩数据再加上自然语言指令和人为遥操作的动作轨迹。这些数据的时间对齐、空间坐标系对齐、传感器标定、异常帧剔除每一环都在给基础设施团队上强度。更要命的是具身智能的数据不是“拿来就能用”的静态资产。机器人学一个操作技能往往需要同一任务在几十种不同场景、不同光照、不同物体位姿下反复演示模型才能把“开冰箱”这个抽象概念和实际电机指令联系起来。这意味着一百万小时的数据里可能有相当比例是刻意设计的重复采集、域随机化变体、失败尝试记录。数据的价值密度远低于文本语料但数据的体积和复杂程度却远高于文本语料。基础设施如果按以前那套“只管吞吐、不管语义”的思路来做基本上会在数据清洗阶段就卡死整个项目。所以我说百万小时这个门槛本质上是在逼整个行业把AI Infra从“后台支撑”提升到“核心研发”的地位。谁能在单位算力下从海量多模态数据里榨出更多有效训练信号谁的模型就能更快收敛、泛化能力更强谁就能在下一轮融资或产品落地的竞争中跑在前面。这已经不是简单的工程优化问题而是决定具身智能能否从实验室demo走向规模化部署的战略问题。2. 具身智能的数据链路远比你想的复杂如果你去翻具身智能相关的招聘JD会发现“数据平台工程师”“数据采集系统负责人”这类岗位的薪资这两年涨得飞快。原因很简单这个环节的工作量被严重低估了而且市面上几乎没有成熟的开源方案可以直接套用。2.1 数据采集端真机、遥操作与传感器标定具身智能的数据采集通常有几种主流方式真人遥操作、自动化脚本采集、仿真环境生成。真人遥操作是目前最靠谱也最贵的方式操作员戴着动捕手套或者操作主手设备控制机器人完成一个个精细动作整个过程被多路传感器同步记录。一位熟练的操作员一天能产出多少有效数据坦白讲视任务复杂度不同可能只有几百到一千多条有效轨迹折算成时间可能就一两个小时。这也是为什么百万小时数据听上去很震撼但真正执行起来需要的成本会让人倒吸一口凉气。传感器标定是这中间最不起眼但最容易埋雷的环节。机器人身上的RGB相机、深度相机、IMU、关节编码器、力传感器每一个都有自己的采样频率、时间基准和坐标系定义。一个典型的问题是相机是30帧还是60帧力传感器是500Hz还是1kHz如果时间戳对齐做得不严谨神经网络学到的可能就是“动作和视觉之间存在几十毫秒的随机偏移”表现出来就是训练loss怎么都降不下去或者sim-to-real transfer的时候模型性能骤降。这个问题的隐蔽性极强很多时候你怀疑是网络结构不对、超参数没调好折腾一周后才发现是数据同步的锅。采集端还有一个容易被人忽略的软性问题数据质量的一致性。同一个任务A操作员习惯先看物体再缓慢移动B操作员动作快且果断这种人为差异会被模型当成数据分布的一部分学习进去最终让策略变得“神经质”——一会儿犹豫、一会儿激进。所以规模化的数据采集一定要有标准化的操作规范SOP和实时质量检测机制比如动作速度上下限、轨迹平滑度评分、力控超限报警。这些工具本身也是AI Infra的一部分而且是很考验工程经验的那部分。2.2 数据存储与预处理百万小时文件系统的挑战一百万小时的多模态传感器数据存储规模是多少我做了个粗略估算假设每路视频以1080p、30fps、H.264编码码率约4Mbps一小时约1.8GB再加上深度图、力觉数据、关节状态等其他数据流一小时数据总量做到3~5GB很正常。一百万小时就是3~5PB的原始数据。听着很多但真正棘手的不只是容量而是小文件数量。一个轨迹片段可能包含几十个文件每个文件几百KB到几十MB不等百万小时数据拆分下来可能是数亿甚至数十亿量级的小文件。传统的HDFS或者普通NAS在这种场景下会直接查到原地爆炸——NameNode内存告急、元数据操作延迟飙升、导出数据时目录遍历都要等半天。这个问题的解法思路其实和自动驾驶行业有些类似分层存储 文件聚合。热数据近期采集、频繁用于训练的片段放在高性能分布式存储上冷数据历史数据、很少访问的原始录像下沉到对象存储或者磁带库。同时把大量小文件按时间窗口、任务ID聚合成大文件比如一个任务的所有传感器数据打成tar包或自定义二进制格式减少元数据压力配合索引服务提供按语义检索的能力。预处理环节同样不容小觑。原始数据进来以后要做去重同一场景同一任务的重复片段、质量筛选剔除机器人摔倒、传感器断流、操作失败等无效数据、自动标注辅助用基础模型打粗标签人工精修。这一步我强烈建议做成流水线化的任务队列而不是靠脚本手动跑——因为数据量上来之后一次全量重新预处理可能要跑好几天没有任务编排系统会非常痛苦。2.3 仿真数据的角色域随机化与数据增强的平衡很多团队为了快速扩大数据规模会把很大一部分希望寄托在仿真环境上。用MuJoCo、Isaac Sim这类工具批量生成操作数据成本确实低一天百万条轨迹不是梦。但仿真数据的核心问题始终只有一个sim-to-real gap。仿真里完美平滑的力觉反馈、理想化的物理参数到了真实世界会因为摩擦力、形变、噪声而完全变样。所以我对仿真数据的态度是它是必要补充但不能作为绝对主力更不能让真机数据占比过低。一个相对健康的比例可能真机数据占70%~80%仿真数据占20%~30%仿真数据专门用来覆盖真实场景很难采集的长尾情形比如极端光照、多物体堆叠、非常规物体形状。域随机化domain randomization是让仿真数据能用的关键技巧——随机化物体的纹理、质量、摩擦系数、光照角度让模型不要死记硬背仿真环境的“长相”。但域随机化本身也有超参要调随机化范围太小则泛化不足范围太大则训练难度剧增又是一个工程和算法的交叉痛点。3. 训练侧的基础设施分布式训练、异构算力与数据管道数据链路理清楚了接下来就是真正“烧钱”的环节模型训练。具身智能的模型架构五花八门有端到端模仿学习的有大模型做任务规划的有VLA视觉-语言-动作模型的但无论哪种架构落到训练基础设施上都会面临几个共同的硬骨头。3.1 多模态数据加载IO才是真正的瓶颈很多团队第一次把具身数据搬到GPU训练集群上时都会经历一个幻灭时刻GPU利用率只有30%~40%显存占用倒是满了但SM流式多处理器大部分时间在干等数据。这就是典型的数据加载瓶颈。和NLP不同具身智能的每个训练step都要同时加载高分辨率图像、点云深度图、力觉序列和文本指令数据体积比token大几个数量级不做优化的话数据加载时间甚至会超过计算时间。解决这个问题我实操下来最有效的组合是这几招数据预取与缓存用内存映射文件mmap方式读取数据配合多进程预取队列让数据在GPU计算的同时提前加载到内存把IO等待时间藏起来。WebDataset/Tar包格式前面提到的文件聚合在这里直接受益把海量小文件打包成大文件顺序读取的吞吐量比随机小文件IO高一个数量级。GPU直通存储有条件的话上GPUDirect Storage让数据绕过CPU内存直接进GPU显存PCIe带宽那点延迟省下来意味着训练吞吐能提升20%~40%这笔账很划算。混合精度与梯度累积降低单次迭代的计算量减少对数据吞吐的压力变相缓解IO瓶颈。3.2 异构算力调度GPU、CPU、甚至NPU都要管具身智能训练的算力需求不像纯LLM那样单一。端到端策略网络可能要用大规模GPU集群跑Imitation Learning仿真数据生成主要吃CPU和轻量GPU而一些基于RL的fine-tuning场景可能还得同时跑数百个并行环境做rollout。这些负载的特性差异很大如果全部塞进同一个调度队列会出现严重的资源浪费——比如仿真环境占着满嘴CPUGPU却闲得发慌。更合理的方式是搭建一个支持异构资源感知的调度层。目前Kubernetes配合 Volcano 或 Kueue 这类批处理调度插件是比较主流的选择。它们能感知GPU型号、显存大小、CPU核数、内存容量还能做队列优先级和抢占策略让训练任务、仿真任务、数据预处理任务各取所需互不饿死。我们团队当时定的原则是训练任务优先级最高仿真任务次之数据预处理最低且可随时被打断。这套策略跑了一段时间后集群整体利用率从50%出头提升到了75%左右效果非常明显。3.3 训练稳定性的关键从Checkpoint到故障恢复百万小时数据规模的训练任务动辄在集群上跑几天甚至几周。这么大的训练任务最怕的就是中途故障。一个GPU卡死、一个网络抖动、一个节点被抢占都可能导致整个训练进程崩溃。而如果你天真地只靠PyTorch自带的torch.save来存checkpoint每存一次全量模型就要停顿几分钟训练效率大打折扣。实操经验是检查点机制必须单独做一套。核心思路是异步checkpoint模型权重在后台线程持续同步到分布式存储主训练进程不阻塞。每隔一定步数或者特定事件触发时保存一个“一致性快照”。模型并行维度较大时还要考虑分片保存策略每个rank只保存自己负责的那部分权重恢复时再拼接避免单个checkpoint文件过大导致写入耗时过长。除此之外训练过程中的监控告警也非常重要。我们当时在训练脚本里埋了不少自定义指标比如数据加载延迟的P99、梯度范数、loss的滑动平均值一旦出现异常模式比如loss突然飙升或梯度爆炸立刻自动保存现场并降级到安全学习率这套机制帮我们避免了好几次全军覆没的灾难。4. 模型部署与数据回流让基础设施形成闭环训练出模型只是第一步具身智能要真正落地模型要部署到机器人本体上实时推理然后机器人在实际环境中产生的交互数据还要回到训练集群参与下一轮迭代。这个“采集-训练-部署-再采集”的闭环才是具身智能AI Infra最有魅力的地方。4.1 端侧推理优化算力受限下的挣扎机器人本体的算力远不如云端GPU集群。一个移动机械臂上可能只有一块Orin或者更低功耗的嵌入式计算板要在上面实时跑视觉感知、任务规划、动作生成每毫秒都要精打细算。模型量化INT8/FP16、结构化剪枝、算子融合、蒸馏出小模型这些在云端不算特别迫切的技术到了端侧全变成救命稻草。这里我特别想提一点很多具身团队在模型部署阶段才发现训练框架和推理框架的割裂问题。训练时用的PyTorch模型转成TensorRT或者ONNX后某些自定义算子不支持某些动态shape处理不了导致部署周期比预期长得多。所以如果项目刚起步我建议在模型设计阶段就想着端侧部署——算子尽量用标准化的、shape尽量静态化、尽量避免自定义 CUDA kernel。这个意识能帮你在后期省下几周的适配时间。4.2 真机数据回流做好数据遗忘与重新标注的工程部署后的机器人每完成一次操作都会产生新的真实交互数据。理论上这些数据是最有价值的——它们代表了模型在实际场景中的真实表现和失败模式。但直接把这些数据全部塞回训练集会带来两个问题一是数据分布会逐渐偏移早期采集的数据可能和当前部署环境差别很大二是数据量持续膨胀训练集无限增长下去训练效率和存储成本都会失控。比较务实的做法是做数据生命周期管理设定一个滑动窗口比如只保留最近6个月的真实交互数据用于训练加上所有仿真数据和早期数据中挑选的“黄金样本”那些场景覆盖度极高、质量极好的数据。同时定期对历史数据做重标注和清洗把已经过时的、无效的、与当前任务无关的样本淘汰掉。数据并不是越多越好高质量数据的管理能力才是核心资产。4.3 让AI Infra成为具身智能的工程底座聊到这里你应该已经感觉到AI Infra在具身智能这个领域早已不是“IT部门该操心的事”而是和模型算法深度融合的研发主战场。它的技术栈横跨分布式系统、存储、调度、网络、数据工程、推理优化几乎是把传统互联网基础设施和MLOps的所有难点继承了一遍再叠加机器人特有的物理世界数据问题。也正因如此这个领域的工程师身价水涨船高——既懂机器人又懂大规模分布式系统的人市面上太少了。5. 实战中的那些坑百万小时数据项目的经验手册理论说再多不如踩坑经验来得直接。我把我印象最深的几个问题整理出来每个都是真金白银换来的教训希望能帮你避开同款事故。5.1 checkpoint白存问题我们早期做模型并行训练的时候每个rank各自存自己负责的那部分权重看起来没问题。但有一次故障恢复时发现不同rank之间checkpoint的保存时机不一致某个rank多存了几百步的模型恢复后各rank的模型状态对不上训练直接发散。从那以后我们改成以“全局步数”为基准的同步checkpoint机制——所有rank必须在同一个全局步数上保存才能在恢复时保证状态一致。5.2 数据时间戳同步的隐性陷阱前面提到传感器时间戳对齐的问题我再补一个真实的坑有一次我们发现模型在某个特定动作上效果特别差排查了很久最后发现是深度相机和关节编码器的时钟源不同——一个是基于系统时间的软件时钟一个是基于独立硬件的传感器时钟长期运行后两者漂移了几十毫秒。从那以后我们的数据采集系统统一改用PTP/PPS之类的硬件时间同步方案并且每天做一次时钟偏移校准。5.3 仿真数据的“训练快、真机崩”现象仿真数据训练的模型在验证集上loss很漂亮一上真机就各种诡异失败。我们当时归因了很久最后发现主要原因有两个一是仿真环境的物理参数太理想化摩擦系数、质心位置都和真实机器人相差很大二是仿真里的视觉噪声几乎为零模型过度依赖了某些在真实环境里根本不存在的视觉特征。解决方案也很朴素加大域随机化范围、在仿真图像里叠加真机采集的图像噪声以及最重要的——每次仿真模型训练完必须先用小批量真机数据做微调哪怕数据量很少再上真机测试。5.4 集群利用率焦虑的另一面很多技术负责人一看GPU利用率低就焦虑觉得钱白花了。但我想提醒一句对于具身智能这类多模态任务GPU利用率不可能像纯NLP那样做到98%以上因为数据加载、预处理、仿真rollout本身就要消耗大量CPU和IO资源。与其盲目追求GPU利用率不如关注有效训练吞吐——也就是每小时内真正完成的梯度更新次数。这个指标更能反映训练系统的真实效率。我们有个阶段GPU利用率只有60%但有效训练吞吐反而比之前90%利用率时高——因为之前大量时间浪费在了数据重复加载和无效rollout上。6. 给不同阶段团队的基础设施建议聊了这么多最后说说落地层面的建议。因为不同规模的团队面对百万小时数据时的路径选择完全不一样。6.1 早期团队数据量1万小时别做超前基建如果你的团队还处于验证算法阶段数据量几千小时那我劝你别急着搭大规模分布式存储和调度平台。这时候一套好用的单机开发环境、一个靠谱的数据标注工具、一个能跑的Pytorch训练脚本远比搞什么Kubernetes集群、千卡调度实在得多。过早做基建只会陷入“天天运维、没时间搞算法”的境地。你可以用云上的托管服务比如S3 云GPU实例先把流程跑通等模型验证成功、数据增速上来之后再逐步迁移。6.2 成长期团队数据量1万~50万小时开始体系化这个阶段你一定会感受到单机训练的极限也开始感受到数据存储和管理的痛点。建议优先做三件事把数据处理流程固化到工作流引擎里、把训练任务容器化并引入任务编排、把checkpoint机制和故障恢复做完善。不求规模大但求流程顺畅可复现。这些都是为下一步规模化打地基地基不牢后面都是还账。6.3 规模化团队数据量100万小时All in AI Infra走到这一步AI Infra就不再是“支持部门”了它就是你的核心竞争力。你要把团队结构、技术选型、流程规范全部围绕基础设施来制定。需要有专门负责数据平台的组、有专门负责训练平台和算力调度的组、有专门负责端侧部署和推理优化的组。这个时候基础设施团队的产出直接决定你模型的迭代速度而迭代速度就是具身智能公司最值钱的资产。我个人的体会是具身智能的数据规模跨过百万小时之后整个行业对AI Infra的认知会发生一次大洗牌。以前很多人觉得造机器人是硬件问题、是算法问题但走到规模化的临界点你会发现最大的瓶颈其实全在工程侧——数据的高效流转、算力的极致利用、模型的稳定训练、端云的协同闭环。谁能把这些基础设施打磨到极致谁就能在具身智能这个万亿赛道上真正跑起来。这条路没有捷径但每踩过一个坑都是在给整个行业趟出一条更稳的路。