强 … https://dyna.co/research/dyna-2-infrastructure… https://dyna.co/dyna-2

以百万小时规模可重复地训练 Dyna-2 —— DYNA

来源：https://www.dyna.co/research/dyna-2-infrastructure [ 研究 ]

以百万小时规模可重复地训练 Dyna-2

1. 01引言 (https://www.dyna.co/research/dyna-2-infrastructure#introduction)
2. 02扩展性挑战 (https://www.dyna.co/research/dyna-2-infrastructure#scaling-challenges)1. 02.1场景容器：MCAP 与话题组分块 (https://www.dyna.co/research/dyna-2-infrastructure#episode-container-mcap-and-topic-group-chunking) 2. 02.2数据摄取：DAG 分解、错峰启动与装箱批次 (https://www.dyna.co/research/dyna-2-infrastructure#ingestion-dag-decomposition-staggered-starts-and-bin-packed-batches) 3. 02.3数据整理：数仓查询与内存映射表 (https://www.dyna.co/research/dyna-2-infrastructure#curation-warehouse-queries-and-memory-mapped-tables) 4. 02.4数据传递：基于节点 NVMe 的集群本地缓存 (https://www.dyna.co/research/dyna-2-infrastructure#delivery-cluster-local-cache-on-node-nvme) 5. 02.5训练：拓扑感知的优化器分片 (https://www.dyna.co/research/dyna-2-infrastructure#training-topology-aware-optimizer-sharding) 6. 02.6作业容错：预检门控与自动重启 (https://www.dyna.co/research/dyna-2-infrastructure#job-resilience-preflight-gating-and-auto-restart)
3. 03展望未来 (https://www.dyna.co/research/dyna-2-infrastructure#looking-forward)
4. 04参考文献 (https://www.dyna.co/research/dyna-2-infrastructure#references)

机器人或供应商收集落地桶对象存储训练就绪数据MCAP 场景训练清单列式存储 + 内存映射GPU 集群训练上传摄取整理加载

**图 1：**数据生命周期流程图

从在 GPU 集群上收集数据到训练，机器人数据经历四个阶段：收集到落地桶、摄取为训练就绪的场景、整理为特定实验的数据集，以及加载到训练批次。这种高层范式在行业中很常见。但区别在于，现有基础设施无法满足大规模机器人训练的具体要求，每个阶段都以自己的方式出现问题。我们将按此顺序探讨，并以 GPU 集群本身作为结束，在那里同样出现了规模依赖的瓶颈。

场景容器：MCAP 与话题组分块

对于同时预测视频和动作的 Dyna-2，每个训练样本需要少量解码的视频帧，但需要长得多的本体感觉状态序列，其长度与动作分块相匹配。这种不对称性并非 Dyna-2 独有：机器人数据本质上是多模态的，任何数据收集方法通常都配备一套传感器，所有传感器以不同的速率和结构持续产生数据，因此读取模式本身成为了一个因模态而异的训练超参数。这些 I/O 模式迫使我们在存储格式上进行直接权衡。独立的、逐帧访问使得任意偏移读取非常简单，但存储和流式传输的成本要高得多，对于逐帧 JPEG，每个摄像头每分钟大约需要一百兆字节，具体取决于分辨率和帧率。帧间视频压缩（使用 GOP 的 H.264）显著减小了体积，但压缩帧只能从其 GOP 的关键帧开始解码，这与随机访问任意时间戳相矛盾。扩展规模意味着我们需要一种既高效存储又易于检查的格式。我们早期的存储方式（H5 保存逐帧 JPEG）在两点上都不足：

**未针对视频优化：**帧是独立存储的，没有帧间压缩，继承了与 JPEG 基线相同的成本。

**没有原生可视化功能：**检查一个场景意味着将其转换为某种查看器可以直接读取的格式。

我们完全转向了 MCAP (https://mcap.dev/)，它在自动驾驶领域被广泛使用，并因其随机访问和灵活的分块功能而脱颖而出。然而，MCAP 并不能开箱即用地满足我们的训练要求，主要是因为其默认的分块模式并未针对视频-动作训练进行优化。我们针对自身的访问模式，对其压缩、视频编码和分块进行了深度调优。其中两个选择最为关键：

**采用更大 GOP 的 H.264 编码：**图像组（GOP）提供了压缩率和随机访问之间的典型权衡，因为定位到任意帧需要从前面的关键帧开始解码。VLA 训练采样的是短而稀疏的窗口，因此每次采样都要付出这个定位代价。世界-动作模型读取的是长的连续序列，一个关键帧可以平摊到许多帧上，因此我们可以使用更大的 GOP。

**话题组分块：**MCAP 的默认写入器为每个话题提供自己的分块，因此组装一个样本需要为每个话题读取一次。我们改为将具有相同读取模式的话题分组，并以时间为主序写入每个组：摄像头交织在一个流中，本体感觉和动作在另一个流中。两者从不共享一个分块，因为一个样本需要几帧解码帧，但需要一个长而密集的状态窗口。这样，一次获取操作每组只需要一次读取，而不是每个话题一次，因此增加摄像头或状态话题不再增加往返次数。

组装一个在时间 t1 的训练样本 摄像头在 t1 和 t3 采样，状态每步采样——实心单元格是样本 默认：每个话题一个分块 每个话题一个分块，包含其整个窗口 所有话题 分块 1 camA 1 camA 3 分块 2 camB 1 camB 3 分块 3 prop 1 prop 2 prop 3 分块 4 act 1 act 2 act 3 4 次读取 话题组分块：两个流，每个流时间为主序 每个读取模式一个分块流 视频 分块 1 camA 1 camB 1 camA 3 camB 3 2 次读取 每组一次读取，而非每个话题一次 状态 分块 1 prop 1 act 1 prop 2 act 2 prop 3 act 3

**图 2。**默认情况下，MCAP 按顺序写入每个话题的整个窗口，因此一个训练样本需要为每个话题读取一次。我们改为将具有相同读取模式的话题分组——摄像头与摄像头一起，状态与状态一起——并以时间为主序写入每个组。这样，无论有多少个话题，一个样本只需要两次读取，每组一次。为清晰起见，该图使用了两个不同速率的四个话题。真实场景包含更多的话题，因此下面的实测节省量更大。

在真实的遥操作场景上，与逐帧 JPEG 基线相比，压缩将存储大小减少了约 68%。话题分块进一步减少了 I/O 往返次数，每个样本的分块获取次数减少约 3.4 倍，在相同读取器下读取速度比默认分块快约 2.9 倍：

1. 存储占用空间（兆字节/摄像头-分钟） 0 20 40 60 80 80.3 JPEG（逐帧） 25.1 MCAP + H.264（按话题） 25.1 我们的方案（话题分块）

2. 每个样本的读取延迟（毫秒） 0 10 20 30 27.0 MCAP + H.264（按话题） 9.4 我们的方案（话题分块）

3. I/O 局部性（每个样本的分块获取次数） 0 3 6 9 12 11.33 MCAP + H.264（按话题） 3.29 我们的方案（话题分块）

**图 3：**我们的压缩和分块带来的存储大小节省和读取性能提升。两者是正交的——分块改变的是消息的写入顺序，而不是其大小，因此在面板 1 中与 MCAP + H.264 相同，而在面板 2 和 3 中发挥其作用。

摄取：DAG 分解、错峰启动与装箱批次

我们的摄取管道一度被限制在每周 14,000 场景小时。按此速度，处理一百万小时需要超过一年。处理机器人数据的典型摄取管道有三个阶段：数据转换、质量检查和特征增强。数据转换将所有摄像头和本体感觉流重新采样到共同的时间戳网格上，计算派生信号，将视频编码为标准 MCAP 格式，并为清单查询建立元数据索引。特别是在质量检查期间，我们检测并过滤掉摄像头黑屏、关节状态卡顿、手部位置缺失/遮挡、坏帧等质量问题。特征增强生成性能标签、视频描述、分割以及其他用于训练的数据。这些都是标准做法；难点在于大规模运行。

我们最初的数据处理管道实现为单个 Kubernetes 作业，除了扩展性问题外还存在多种问题。今年早些时候，我们使用 Airflow 重写了数据处理管道，其中每个步骤都在 DAG 中明确定义。这给我们带来了三个好处：

**可分离的扩展性：**每个 DAG 步骤都根据其特定需求（CPU、内存或 GPU）动态分配资源，从而最大限度地提高物理资源利用率，而无需将整个工作池扩大到最坏情况步骤的规模。

**更好的解耦和可观测性：**步骤被标记为关键或非关键，因此非关键失败不再取消整个 DAG 运行。每个步骤的状态可以从 DAG 中清晰观察到，并从该点恢复。

**动态编排：**处理需求不断变化，尤其是在我们开始从外部供应商摄取数据之后，每个供应商都有自己的数据类型、格式和质量特性。任何步骤子集都可以在每次运行时切换开或关。例如，质量检查作为转换前后的独立门控运行，而不是合并到转换中。这是在运行时控制的，而不是通过代码更改或新脚本。

在 DAG 编排器之上，我们还将管道状态备份到持久化存储中，而不是将其保存在活动进程中。这极大地提高了管道的可操作性：可检查点的多日运行、从任何步骤重放、跨 DAG 的构件共享、数十个并发运行的选择性重处理。此外，相同的设计适用于数据收集用例（一次运行处理一个场景）和数百万场景的批处理用例，直到相同的子 DAG 步骤集。运行配置文件决定哪些步骤实际运行（完全处理、仅元数据回填、重新标记），因此既不需要新的触发器类型，也不需要部分重运行来复制管道。每个处理过的场景都带有生成它的标记：模式版本、摄取管道版本以及录制时机器人上运行的软件版本。重新处理一百万小时需要数周时间，因此任何管道更改都会使语料库在一段时间内保持混合版本，有时甚至是永久性的。标记使得这种情况可以被容忍。我们可以准确找到哪些场景已过时，并仅重新处理那些场景，并且整理查询可以请求实验所需的所有版本范围。

在线 每个场景一次运行，落地时启动 延迟优先 · 高运行并发性 批处理 每个清单分片一次运行 吞吐量优先 · 批处理 · 分片 · 错峰 主 DAG —— 解析运行配置文件，仅触发所需的子 DAG 转换与同步 关键路径 格式转换 数据验证 时间同步 元数据 目录注册 元数据提取 完整性检查 标签与构件 分割 特征提取 非关键 · 失败隔离 媒体 本次运行禁用 转码 缩略图 训练就绪的场景 + 元数据 运行配置文件 · 相同图，启用不同的子 DAG 完全处理 同步 元数据 标签 媒体 元数据回填 同步 元数据 标签 媒体 仅重新标记 同步 元数据 标签 媒体

**图 4：**逻辑 DAG 结构

然而，这种设计不一定能解决可扩展性问题，因为仅仅向资源池投入更多计算并不能线性地提高吞吐量。在大规模下存在两个问题。首先，当数百万次运行并发发生时，调度器成为瓶颈，因为突发的写入会淹没调度器数据库并导致整个进程停滞。其次，数据文件大小差异很大，这造成了工作负载不平衡，导致资源未被充分利用。

解决方法直接应对每个瓶颈：

我们首先错峰不同批次的启动时间，使相同的步骤不再同步完成，从而平滑淹没调度器数据库的写入突发。

我们还引入了一个联合优化器，使用装箱算法将输入批次拆分成近似相等的字节。这些分割进一步被分解为块，由最优数量的 airflow worker 并行处理。这种方法确保我们遵守物理约束，例如网络和 I/O 吞吐量、节点、存储和数据库容量。

处理的场景小时数/周 0 100k 200k 300k 400k 二月 三月 四月 五月 六月 10k 14k 103k 288k 387k 440k

**图 5：**随时间推移的数据处理吞吐量改进。该系列从二月份的 10k 开始。14k 是原始单作业管道的平台期，重写提升了这个上限。

与存储级优化相结合，这些更改完全释放了水平扩展能力，将吞吐量从每周 14,000 场景小时提高到 440,000 场景小时，提升了 31 倍。这将处理一百万小时所需的时间从大约 16 个月缩短到不到三周。

整理：数仓查询与内存映射表

在百万小时规模下，在训练运行开始之前，构建训练清单大约需要 48 小时。每次训练运行都从构建训练清单开始：确切哪些场景在此次运行中，以及每个场景的起始和结束位置。批处理、跨 GPU 分片以及 epoch 长度都依赖于它。由于每次实验都会过滤语料库——按任务、按机器人、按运行是否成功、按摄像头是否掉线——因此清单每次都会重建。最初我们直接从文件本身构建它。元数据数据库提供了候选路径列表，但仅有路径并非清单。我们仍然必须确认每个文件确实存在，读取其 sidecar 以获取质量标记，打开其头部获取时间范围，然后再次打开以统计其包含的步数。这意味着每个场景需要四次存储访问，而我们的百万小时数据集有 4300 万个场景。单次预训练运行可以承受一次这样的代价。然而，为每次实验支付此代价成为迭代速度的重要瓶颈。我们的元数据数据库确实存储了这些信息。但它也处于数据收集和标注操作的关键路径上，而事务性数据库并不擅长支持大规模列式扫描。因此，与其让一个数据库擅长两项相反的工作，我们按工作负载将其拆分，并使用近实时变更数据捕获保持同步：

生产数据库—— 事务性繁重的系统记录，确保数据完整性和一致性。

数据仓库—— 分析型后端，支持水平扩展。整理操作只需读取整个表中的少数几列，而非逐行扫描。场景表现已超过 5000 万行，清单构建方式无需更改。

数据仓库比生产数据库滞后几秒，这是可以接受的，因为整理操作选择的是那些在任何人使用它们训练之前就已完成处理的场景。整理现在变成一个 SQL 查询。它将清单写成一个列式文件。一个 rank 下载该文件一次，然后每个 rank 在训练开始时内存映射本地副本，包括下载的那个 rank。构建清单从数千万次查找变成了一次查询，冷启动时间从大约 48 小时降到不到一分钟。改变的不仅是常数项。查询计划是基于表而非遍历文件列表，因此其代价不再与数据集包含的场景数量成正比，对完整表（现已超过 5000 万行）的整理查询在几秒内完成。（这是构建清单。加载清单是另一项成本，图 7 (https://www.dyna.co/research/dyna-2-infrastructure#fig-7) 衡量的是这个。）

构建训练清单所需时间（挂钟小时） 0 10 20 30 40 50 60 之前 遍历每个文件，然后统计步数，运行才能开始 约 48 小时 之后 一次查询，然后复制到本地磁盘，此处太小无法显示图 < 1 分钟

**图 6：**百万小时规模下构建训练清单所需时间