穹彻智能 × MaxCompute：具身智能 UMI 数据产线的全模态计算实践

在 2026 云栖大会大数据论坛上，穹彻智能 AI 科学家吕峻以 UMI 数据产线为例，介绍了团队如何在 MaxCompute 上批量处理视频和动作轨迹，把真实场景中的操作记录整理成可供模型训练的数据集。

从近十万小时真实世界操作数据说起：场景与挑战

穹彻智能成立于 2023 年，专注于具身智能预训练模型研发。团队用自研设备记录人在真实场景中操作物体的过程，通过数据平台将视频和动作轨迹整理成训练样本，并在机器人上验证模型能否完成相应任务。

2026 年 8 月，穹彻智能发布了具身世界模型 Noe-0 的研究预览。团队用自研的 RoboPocket 设备采集操作数据，在预训练和后训练阶段都使用无本体数据，以保留人类示范动作的连续性。据当期 Noe-0 Research Preview 披露，累计采集时长 97,387.7 小时 ，覆盖 47 个城市、18 个省级行政区，平台累计支持 2,000 余名采集人员。最新数据，穹彻智能已累计采集30万小时数据，覆盖70个城市。

穹彻智能的数据方案称为无本体众包采集。采集人员把便携设备带到家庭、门店等真实场景，无需在现场遥操作机械臂。以 UMI（Universal Manipulation Interface，通用操作接口）为例，采集人员手持夹爪演示抓取和放置，设备记录操作过程中的图像和运动轨迹。

现场展示的一集操作记录包含头部和左右腕的三路视频，需要在解码后按时间戳对齐；深度与位姿，各自保持原始采集帧率，与视频不同频；手部状态和 SLAM（同步定位与建图）输出的信号也按各自的频率记录。加工时还要关联任务、场景、设备号和质检结果等元数据。

据现场分享，日均写入数据湖的原始数据约 10 TB，单日峰值为 50 TB。按日均量折算，年增量约为 3.6 PB。这些视频和轨迹在交付训练前，还要经过解码、时间戳对齐、重新编码、质检、元数据抽取等环节。一旦处理规则变化，同一批数据还可能需要再加工。

数据产线面临的三项工程挑战

面对多源不同频的传感器数据，团队先把不同传感器帧之间的对应关系存进数据表，让下游应用可以直接复用。

穹彻智能按采集片段（episode）组织数据，用 Lance 列式格式保存记录。相机表按对齐后的时间线逐帧成行，其余表（深度、位姿、元数据）保留原始采集帧，跨表通过原始帧号关联。采用这一结构后，新增元数据字段只写新列文件，无需重写已有列；新增一路传感器即新增一张表，旧数据集仍可读取。训练、标注、可视化和批处理都可以复用同一套帧映射。

数据表结构设计完成后，穹彻智能在数据处理中还面临三个核心工程挑战，均无法通过简单扩展算力解决。

首先是算力需求的脉冲特性。团队在迭代中会调整对齐规则、编码参数和质检阈值。若改动影响已有数据，就需要重算受影响的部分；有时范围会扩大到整个数据集。平时计算负载较低，集中重处理时则可能需要数万核并行。按峰值采购容易造成设备闲置，按平时的需求采购又会拉长重处理时间。

其次是加工流程对 Python 生态的深度依赖。解帧、H.264 与 AV1 编解码、点云处理、质检、预标注模型推理，会用到 pandas、OpenCV、PyTorch 等工具。仅用常规 SQL 很难复用这些处理逻辑，把大批数据拉回本地也不现实。团队还在部分质检和预标注环节调用大模型。

第三是容错机制的必要性。单集数据可达 GB 级，一个工作进程（worker）处理一集可能需要数十分钟。批量处理数万集时，文件损坏、超时或格式异常都可能使个别任务失败。系统需要按集记录失败原因，让其余任务继续运行，重试时再补算失败的部分。

对初创团队而言，自建大数据基础设施涉及三方面成本。其一是硬件与机房：机柜、电力、制冷、跨机房专线，还要权衡服务器容量、闲置成本和设备更换。其二是软件与运维：调度、存储、计算引擎的选型与集成，版本升级、补丁、容量规划，监控告警、值班与故障响应，权限、审计、数据安全合规。其三是人力：需要有人持续承担平台运维和数据安全工作，并支持算法工程师调试分布式作业。

穹彻智能选择用 MaxCompute 承担这条数据产线的批量计算，无需为重处理时峰值算力需求单独采购服务器。团队自行维护加工规则和算子，把更多精力用于数据和算法研发。

面向 PB 级数据的批处理实践

针对脉冲式算力需求，团队采用 MaxCompute 的 Serverless 弹性计算。据现场演示材料，MaxCompute 当时为穹彻智能这条产线开通的弹性 CPU 配额上限为 10 万核。

例如，团队调整多路视频的对齐规则后，需要重新生成受影响片段的帧映射。把这些片段分批并行处理，可以缩短集中重算的时间。采用 Serverless 模式后，团队可在批量作业开始时按需申请算力，作业完成后释放相应资源，不必长期保有一套按峰值配置的集群。

数据链路中的需求不只是 CPU。本例中，视频解码与时间对齐主要在 CPU 上运行。需要模型推理时，团队可用 GPU 运行自有模型做特征提取，也可在质检和预标注环节调用通义千问等模型服务。

在 MaxCompute 的 MaxFrame 作业里，CPU 算子使用计算单元（CU），GPU 算子使用 GPU 计算单元（GU）。作业还可以通过 API 调用阿里云百炼的模型服务，Token 是模型调用量的计量单位。前段用 CPU 完成解码与对齐，后段直接接入模型推理进行预标注，数据加工和模型调用可以编排在同一条流程里。

穹彻智能自研的数据管理平台 DM3 负责数据治理与交付，这里介绍的批量加工作业则运行在 MaxCompute 上。算法工程师使用 MaxFrame 的 pandas 风格接口编写算子，平台负责切分和调度作业，把处理逻辑分发到多个 worker 执行。

具体落地中，穹彻智能维护三套 DPE 自定义镜像——通用加工镜像、模型镜像、Lance 格式专用镜像，分别装入相应算子所需的软件依赖。团队以一集数据为处理单位，通过 apply_chunk  将 Python 算子分发给 worker。配置访问权限后，源桶和目标桶均通过 ossfs2 挂载到 worker，算子可通过本地路径读写 OSS，无需在代码里保存密钥。分片与配平方面，团队按当天的有效集数设置并行度，再按单集数据量排序、轮转分配，尽量把较大的片段分散到不同的worker中。

在失败恢复层面，穹彻智能构建了六段加工链路——预处理入湖、格式转换、解帧与重编码、质检、元数据抽取、数据集冻结——并配套两套保障机制。一是按天分区并覆盖写入：某天的数据出错，可以只重跑对应的 dt=<日期> 分区，避免重试时重复追加记录。二是按集维护审计表，记录处理结果、耗时、产物地址和错误信息。同一批任务重试时可复用已成功的结果，只补算失败的集；如果输入或处理规则已变，则要重算受影响的部分。沿审计表还可以查到一集数据经过了哪些环节。

MaxCompute 与自建集群的工程分工

在这条产线上，穹彻智能使用云端算力完成集中重处理，自行维护数据处理逻辑和失败恢复机制。表中比较的是团队采用托管计算与自建集群时各自需要承担的工作。实际费用取决于作业负载、资源配置和计费方式。

对穹彻智能这条 UMI 数据产线而言，云端批处理降低了启动门槛：团队无需先搭建峰值集群，就能开始编写和运行加工作业。当对齐规则变化时，团队可以集中算力重算受影响的数据；如果只是个别片段失败，就按审计记录定向重试。

郑重声明：此文内容为本网站转载企业宣传资讯，目的在于传播更多信息，与本站立场无关。仅供读者参考，并请自行核实相关内容。