AREX Feed Article
Dyna 公开 Dyna-2 训练管线：百万小时摄取提速 31 倍
8 月 17 日，Dyna Robotics 官方账号在 X 上发帖并发布技术博客《Training Dyna-2 at million-hour scale, repeatably》，首次公开训练 Dyna-2 的数据管线工程细节（、）。
公司称，在百万小时量级上：数据摄取吞吐从 14,000 episode-hours/周提升到 440,000，为原来的 31 倍；训练 manifest 构建从约 48 小时缩到 1 分钟以内；PB 级数据读取从 57.9 天降到 5.8 天；暖机后的多节点训练 run 中 GPU 利用率维持在 98%。
Dyna-2 是 Dyna Robotics 的旗舰 world-action model（WAM），预训练数据超过 100 万小时人类自我中心视频，公司发布模型时公布了 human-to-robot 迁移 scaling law 等结果（）。新博客处理的是模型之外的另一半：训练开始前，这些数据怎么进得来、读得快、喂得饱 GPU。
摄取吞吐 31 倍：从 Kubernetes 单任务到 Airflow DAG
博客开篇给了一个观察：在万小时量级有效的做法，到百万小时大多失效。瓶颈还会移动，先是存储格式，再是摄取管线，然后是训练 manifest。
摄取是第一个撞上的墙：原来的管线是单个 Kubernetes job，吞吐封顶在 14,000 episode-hours/周，按这个速度处理 100 万小时要一年多。
今年早些时候，团队用 Airflow 把管线重写成 DAG。每个步骤按需分配 CPU、内存或 GPU，不再按最差步骤的 footprint 撑大整个 worker 池；步骤标记为 critical 或 non-critical，非关键步骤失败不再取消整次 run；质量检查变成 transformation 前后的独立 gate，运行时开关，不需要改代码。
管线状态落盘，换来可断点的多天运行、从任意步骤重放、跨 DAG 共享产物。
规模化的墙有两道。第一道是调度器：百万级 run 并发时，写突发会灌满调度器数据库、拖停整个流程，对策是错开各 batch 的启动时间（staggered starts）。第二道是负载不均：数据文件大小差异大，资源用不满，对策是一个用 bin-packing 的联合优化器，把输入 batch 切成字节数相近的块再并行处理。
存储层同步换血。原来的 H5 装 per-frame JPEG，无帧间压缩、不能直接可视化；换成自动驾驶常用的 MCAP 容器后，公司又针对 video-action 训练改了默认 chunking：H.264 加大 GOP（WAM 读长连续序列，一个关键帧摊给很多帧），相机流按时间主序写成一串、本体感受与动作流写成一串，组装一个样本从每 topic 一次读取变成每组一次。
实测存储体积比 per-frame JPEG 基线小约 68%，chunk 获取次数少约 3.4 倍，读取快约 2.9 倍。
每个 episode 还盖了版本戳（schema 版本、摄取管线版本、机器人软件版本）。重跑 100 万小时要几周，管线改动后语料会长期混版本，版本戳让系统只重处理过期部分。最终吞吐从 14,000 提到 440,000 episode-hours/周，官方称是 31 倍提升，100 万小时从约 16 个月的处理时间缩到 3 周以内（）。
一次 SQL 查询替代几千万次文件访问
每次训练开始前都要建训练 manifest：这次 run 包含哪些 episode、每段从哪开始到哪结束，batch、跨 GPU 分片、epoch 长度都依赖它。实验的过滤条件各不相同（按任务、按机器人、按是否成功、按相机是否掉线），所以 manifest 每次都要重建。
旧做法是从文件系统遍历：metadata DB 给出候选路径后，每个 episode 还要访问存储四次——确认文件存在、读 sidecar 质量标记、开文件头取时间范围、再开一次数 steps。
百万小时数据集是 4,300 万 episodes，单次预训练还能忍，每个实验都付一遍就成了迭代瓶颈。
修法是按负载拆库：生产 DB 保留事务型系统记录，另建一个数据仓库做分析，用近实时 change-data-capture 同步。curation 变成一条 SQL 查询，输出列式 manifest 文件；episodes 表已超过 5,000 万行，全表查询几秒返回，冷启动从约 48 小时降到 1 分钟以内。
加载是另一半问题。10 万小时时没事，100 万小时时，manifest 在所有 rank 上加载会顶破单节点约 2 TB CPU 内存，训练 job 一个 step 没跑就崩；列式文件的 footer-first 随机寻址在网络挂载上又是最差情形。
三个配套改动：单个 rank 从对象存储 API 直连并行下载一次，绕开网络挂载；每个 rank memory-map 本地副本，只驻留真正碰到的页；加载时零拷贝切片，每个 rank 只取 1/N 行。结果加载从 737 秒降到 12.4 秒，单节点常驻内存从 2,151 GB 降到 218 GB。
57.9 天对 5.8 天：一个 PB 数据怎么喂给 GPU
训练数据在云对象存储里，训练集群却不一定在旁边。GPU 稀缺让公司经常同时租几家供应商的集群；把语料复制到每个集群不现实，语料持续增长，复制要付存储和 egress 费用，而且不是每家供应商都卖对象存储。
修法是直接用节点上现成的 NVMe 做集群内缓存。公司从去年起用 Alluxio 做缓存层：原生分布式、按页缓存（不缓存整文件）、按路径一致性哈希分散所有权。上面再自建数据编排服务：训练启动前解析 manifest，把工作集预热进各节点本地存储；训练期间缓存就近服务，miss 才回源云存储。
数字对比：单 reader 直连对象存储约 200 MB/s，集群内缓存每节点约 2 GB/s，约 10 倍；一个 reader 完整读一遍 PB 级数据，云存储 57.9 天、集群本地缓存 5.8 天。博客说明这两个数都是单 reader 口径，比值才是要点，真实训练是每个节点并行读。
博客并称，暖机后的多节点 run 上 GPU 利用率 98%，读取负载跨集群一致、撑住数周，训练配置因此与集群无关。
Muon 分片留在节点内，优化器 step 快约 3 倍
数据喂饱 GPU 之外，训练本身也有规模问题。Muon 优化器原本占 wall-clock step 时间的一半左右，最初方案是把状态切到每个 rank，各更新第 N 个参数再 all-reduce，几台节点时很好用。
节点一多就慢：B200 节点内 NVLink 约 1.8 TB/s，跨节点 InfiniBand 每 GPU 慢一个数量级以上，节点越多，慢速跨节点通信占比越大。
修法借鉴 FSDP Hybrid sharding：分片留在节点内，用 per-node NCCL 子组，广播流量不出节点；各节点重算同样的更新，多花算术、不占 fabric 带宽，通信量不再随节点数增长；训练器按运行时看到的节点数在两种策略间切换，小规模下全局分片仍然更快。
切换生效后，优化器 step 平均比全分片设计快约 3 倍，节点越多差距越大。博客给出原因：全分片方案中位数好看，均值却是中位数的 2.6 倍，因为它搬 7.6 倍广播流量且走 InfiniBand；同步训练中一个慢 step 由所有 rank 一起买单。
预检与自动重启：让百万小时训练可复现
小 job 挂一台节点，重启损失几分钟；一个 run 占住整个集群几周时，每台机器都可能拖慢所有人，而坏节点大多不会出现在告警里。
博客举了三个例子：一块 GPU 累计记了 25 万多次已纠正 ECC 错误，才被和反复崩溃联系起来；一台被 drain 的节点空闲约 10 小时才被发现；控制器重启后，节点带着过期 reservation 空转。
三层对策。Slurm preflight 在 job 落地前检查 GPU 清单、错误计数器、内核日志、本地磁盘和容器运行时，不合格即 drain，而且只信开机清零的计数器，因为部分 GPU 的全寿命计数无法清零，一次旧故障会永久连累健康节点。
自动重启让 worker 就地重启，整个 job 死了就 requeue、从最近 checkpoint 续跑，诊断痕迹按尝试次数编号。建集群收敛成一个 Ansible playbook，各供应商差异放在 inventory 里，新集群从周级建好变成天级。
这套工程对应博客标题里的 "repeatably"：一次性脚本只能把一个 run 送出门，可复用基础设施让每个实验从上一个结束的地方开始。公司称研究者现在可以摄取、策展和实验数量级更大的数据，不必每次重建管线。
社区回应：隐形英雄，多云细节留待下篇
Dyna Robotics 联合创始人兼 CEO Lindon Gao（据其 X 账号简介）在推文下回复："Infra ppl are the unsung heroes"（基础设施的人是默默无闻的英雄）（）。
@Jeffcryptoo 说 "The 48 hour manifest build is the detail nobody warns you about"（48 小时 manifest 构建是没人警告过你的细节）（）。
@rzhang139 则指出一个技术观察：WAM 架构能牺牲一部分 dataloader 随机采样来换吞吐，这与预测目标的性质有关（）。
截至 8 月 18 日，主推文显示 421 次点赞、57 次转发和约 5.7 万次浏览。文中的性能数字全部来自 Dyna Robotics 对自身系统的测量，属公司自述。
两个问题在公开帖子里还没有答案：@LxKus 问分片策略切换的节点数拐点在哪、会不会随供应商的 InfiniBand 配置变化（）；博客结尾只预告多云架构的更多细节将放在未来的报告里，未展开具体内容。98% GPU 利用率也带限定条件：暖机后的多节点 run。