具身智能不缺数据，缺的是一条产线

过去一年，几乎所有头部公司都在疯狂积累数据。真机采集、仿真合成、遥操作，数据规模从几百小时快速膨胀到几千甚至上万小时。行业会议上的话题也从"我们有多少数据"变成了"我们的数据工厂规模有多大"。谁的数据多，谁就更容易训出更强的模型，这几乎成了行业的共识。毕竟自动驾驶和大模型赛道都经历过同样的阶段：早期拼数据量，量上来以后拼的是谁能持续把新数据变成模型能力。

但具身智能比它们都复杂。自动驾驶的数据主要是图像和传感器信号，大模型的数据主要是文本，而具身智能要同时处理视频、点云、关节轨迹、力控信号，数据类型更多，链路更长，反馈闭环更难建立。一个悖论越来越明显：数据越堆越多，模型能力却没有同比例兑现。穹彻智能首席科学家吕峻在云栖大会上说了一句大实话："这么多数据能对应出来的模型能力没有兑现。"具身智能长远发展所需的数据至少还差两三个数量级，但眼下最卡的不是量，是从数据到能力的转化效率。

这不是某一家公司的问题。当机器人从实验室走向产线，当数据从几十小时走向几千小时，行业正在撞上一个比"数据不够"更本质的瓶颈：从原始采集到可训练数据集之间，缺少一条工业化的数据产线。

阿里云计算平台负责人汪军华在云栖大会上给出了一个数字：AI增长已经占了云增长的百分之六七十以上。在他看来，当AI成为云上最主要的WorkLoad，优化从数据到模型的全链路效率就不再是可选项，而是性价比最核心的指标。他还观察到，今年具身智能赛道的增长非常快，数据量、模型参数、迭代速度都在快速爬坡，短短几个月变化非常大。

赛道在加速，但基础设施的供给方式还没有跟上。

三堵墙的真正卡点

谈到具身智能的挑战，行业最常提到的是"三堵墙"：数据墙、算力墙、算法墙。但实际跑下来会发现，真正的卡点不在任何一堵墙上，而在墙与墙之间的衔接。

数据的问题最典型。具身数据和文本数据完全不在一个复杂度量级，视频加点云的数据量本身就很大，而从原始采集到进入模型训练，中间要经过十几甚至数十次大小数据的调用。任何一个环节堵住，整条链路就慢下来。一个数据版本的迭代花两到四周，模型实验的周期在此基础上继续延长。企业的研发节奏，直接卡在这条链路的吞吐上。

更麻烦的是，具身智能的研发仍处于早期，算法团队需要不断提出新的数据处理方法，快速验证、快速迭代。这意味着对CPU、GPU和模型资源的调度必须足够灵活。资源不够弹性的时候，即使单价降了，闲置成本反而更高。对初创公司来说，提前采购和部署大量计算资源既不现实也不经济。

算力和算法也是类似的逻辑。算力买得到不等于用得好，模型架构和硬件能力不匹配的时候，单点再强也白搭。算法迭代等数据喂不上来，数据采完又堆在那里进不了训练。三堵墙各自看都有解法，放在一起就是系统工程的问题。

数据在堆，模型在等，中间那条产线没通。这才是具身智能今天最大的瓶颈。

一条产线该怎么建

瓶颈明确了，解法也就不难推导：需要的不是在某个环节堆更多工具，而是一条覆盖数据全生命周期的完整产线。但这条产线到底该怎么建，行业还没有统一答案。

从今年云栖大会上的信息来看，阿里云在这个方向上走得比较远，思路也比较完整。他们的方法论可以拆成三层来看：数据处理、训推平台、数据底座。三层之间的协同程度，决定了产线的实际转速。

第一层：把原始数据变成可训练样本

这是整条产线中最容易被低估的环节。具身智能的原始数据包含第一视角视频、多视角画面、点云、机械臂轨迹、传感器日志、控制指令等多种模态，时间戳不同步、文件分散、没有统一结构，根本无法直接用于训练。

要从原始素材到可训练样本，至少要过五道关：时间同步对齐，让不同模态的数据在时间轴上精确对应；Episode分段，识别任务边界，把连续操作流切成独立训练片段；降采样与去冗余，提取关键帧减少无效数据；定制化大模型标注，给动作、物体、接触状态打标签；质量过滤与校验，去噪、完整性检查、达标准入。任何一道卡住，后面的训练就得等。

这套工序的复杂度决定了它不可能靠手工完成。MaxCompute MaxFrame承接PB级多模态数据处理，弹性扩展到十万核以上的计算资源；DataWorks把各道工序编排成自动化流水线，质检不通过的样本自动回流重新处理。标注环节则让大模型深度参与，推出了Qwen-Robot等Physical AI专属的定制优化模型，配合具身世界模型做数据增强和仿真生成。

一个有意思的变化是Data Agent的引入。阿里云推出了企业级的数据开发Agent，部署在云端全托管沙箱环境，7×24小时以自然语言驱动数据检索、问题定位和任务编排。这意味着管线的很多操作不再需要工程师写代码，而是用自然语言告诉Agent要做什么，Agent自己去调度底层引擎完成。数据管线从"人写脚本来跑"变成了"人说话Agent来干"，这对初创公司来说尤其有吸引力，因为他们往往没有足够的数据工程师来维护复杂的管线脚本。

第二层：让数据闭环和训练闭环同时转起来

前端数据处理速度提上来之后，后端训练系统必须同步承接。但具身智能的训练不是简单的"数据进去、模型出来"，它需要两个闭环同时运转。

一个是数据闭环：从采集、处理、测评到难例回流，确保数据侧持续供给高质量样本。另一个是训练闭环：从模型训练、仿真评测到失效场景回流，确保训练侧快速回收问题场景。两个闭环共享同一个数据底座，互为正向反馈。比如评测中发现的Corner Case会自动回流到数据管线重新处理，再进入下一轮训练，形成持续迭代的飞轮。

在这个框架下，三类具身模型需要在同一个平台上并行训练：世界模型（WMA）负责物理因果预测，视觉语言行动模型（VLA）做端到端控制，强化学习（RL）通过仿真采样和奖励塑形持续优化。三类模型共享数据和算力，互为正向反馈。阿里云内部把这叫"一份数据、多类模型、一站训练"。

这对底层训练平台的要求很高。具身智能的训练经常涉及大规模强化学习，需要训练和推理同时运行、权重实时同步、版本化管理。阿里云在PAI平台上设计了异步训推分离架构，训练与推理解耦，通过版本化缓冲和权重同步保障大规模RL训练的吞吐。底层支撑是数十万卡级的GPU集群、PPU超节点和高性能网络，配合断点续训和故障自愈能力，保障长任务不中断。

据阿里云方面披露，这套体系已经可以把具身智能企业的训练反馈迭代周期从周级压缩到日级。一周和一天的差距，对数据密集型研发来说意味着完全不同的进化速度。

第三层：统一的数据底座

前两层解决了数据处理和模型训练的效率问题，但如果底层数据管理是割裂的，效率提升也会被数据搬运和格式转换的开销吃掉。

具身智能的数据来源非常分散：真机遥操、仿真合成、视频流、视触觉传感器、工业现场，格式也各不相同。如果每种数据各自一套存储和管理系统，数据在不同引擎之间来回搬运，管线的吞吐就会被底层开销吃掉。

DLF就是为此而建的全模态数据湖，把结构化、半结构化、非结构化、向量和流式数据统一编目和管理，兼容Iceberg、Paimon等开放格式。来自不同采集源、不同格式的数据统一入湖后，可以被各种引擎直接访问。

更值得关注的是这个数据底座的演进方向：从人用数据变成Agent用数据。过去的数据湖，用户是人，通过产品界面和SQL来使用数据。阿里云正在推动的升级是让数据底座直接面向智能体，提供Agent接口和MCP协议，每个数据引擎也提供Agent可调用的Skill。用阿里云解决方案总监魏博文的话说，原来的数据湖都是大数据团队在用，现在业务人员也可以通过Agent直接使用数据，用户群体发生了根本性的变化。

配合这个方向，阿里云还推出了AI原生大数据服务，以主智能体与专业智能体协同的架构连接数据开发和分析产品，七大引擎同步Agentic化。这些变化指向一个趋势：整条数据管线不只是在工具层面变得更强，而是在交互范式上发生了一次根本转变。

产线跑起来的真实体感

理论再好，要看企业用起来是什么感觉。

穹彻智能是具身智能赛道最早跑通数据处理产线的公司之一。他们和阿里云合作，基于MaxCompute MaxFrame、DataWorks、Hologres和PAI搭了一套端到端的自动化数据处理产线，把原来依赖人工、单机跑批、容易中断的流程换成了稳定运行、弹性扩展的工业化生产线。对一家初创公司来说，这意味着不用在模型研发之外再养一支基础设施团队，研发资源可以更集中地投在模型本身。

变化最明显的是标注环节。穹彻已经基本抛弃了人工数据标注。模型标注的成本远低于人工，更关键的是灵活：要增加一种新的标注类型，不需要找供应商、招人、上量，拉起资源就能跑。版本迭代的时候可能只是改一句Prompt，而人工标注团队要让上百人理解A版和B版的区别，管理成本完全不同。这种灵活性反过来加速了数据处理方法论本身的迭代，标注方法和模型实验可以同步推进，不再互相等。

在算力侧，穹彻过去一年在平头哥PPU上做了大量实践，迁移成本和使用效率都比较有优势。对具身智能企业来说，国产芯片正在从"备选项"变成"可依赖的主力"，这在很大程度上缓解了算力紧张的问题。

另一条线来自AI for Science。科研领域有一个容易被忽略的瓶颈：不是缺模型，而是科学软件生态不成熟。无尽前延CTO张林峰在采访中指出了这个问题的本质：科学家不擅长写代码，大量科学软件效率很低，也没有被好好优化过。无尽前延用PAI平台支撑MoE科研基模、Coder代码模型、多模态模型三条模型线的并行研发，而在他们看来，Coding Agent未来有机会重构这些开源科学软件，甚至在这个过程中发现新的算法。

两家企业，一个做具身，一个做AI4S，技术路线完全不同，但遇到的底层问题高度相似：数据处理的工程能力跟不上研发迭代的速度。这已经不是个别公司的痛点，而是整个AI研发范式的共性问题。

更底层的前提：芯云模必须一起设计

产线跑通了，但故事还没有讲完。如果只在上层搭工具链，底层芯片、模型和云各自演进，产线的效率上限终究会被锁死。

这个教训已经被验证过。Qwen3.5刚发布的时候，算法团队做了一个不错的架构创新，结果到了推理适配环节发现和硬件能力对不上。硬件缓存只有256K，模型设计的结构和它不匹配，推理效率直接打了折扣。同样的模型，跑在不同的芯片上，性价比差了一截。推理尚且如此，训练和数据处理的链路只会更复杂。

用阿里云计算平台负责人汪军华的话说，模型、芯片、云如果各自独立演进，单点最优不等于系统最优。

这推动了一件事。平头哥、千问和阿里云之间成立了多个工作委员会，芯片往什么方向发展由模型和云共同给输入，反过来模型架构也要适配芯片的极致性能。超节点在MoE大模型上的ROI已经验证了这个方向的正确性，而超节点怎么大规模有效利用起来，就是云的能力。

底层打通之后，上层产线才能真正跑到极致。芯云模协同之后，客户可以直接用到芯片的极致性能，不用再花额外精力做适配和调优。

芯云模一体不是战略口号，是被业务逼出来的。具身智能的产线竞争已经开始了。数据规模只是存量，产线效率才是增量。谁能更快地把真实世界的数据变成下一轮模型的能力，谁就掌握了具身智能的下一个入场券。