🤖 machine learning

Online Dynamic Batching with Formal Guarantees for LLM Training

本文介绍了在线动态批处理（Online Dynamic Batching, ODB），这是一种即插即用的数据加载器（DataLoader）系统，通过将批次构建转移到能够实现精确成本观测的时点，解决了大语言模型训练中的盲目批次构建问题，从而在无需修改模型或算子内核的情况下，提供显著的吞吐量提升（高达 4.43 倍）并具备形式化的无死锁保证。

原作者： Dian Li, Zekun Wang, Yaoru Wang, Jiahong Yan

发布于 2026-06-19

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Dian Li, Zekun Wang, Yaoru Wang, Jiahong Yan

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你是一位繁忙厨房的经理（你的计算机 GPU），正试图为一大群人烹饪一顿丰盛的大餐（训练一个大语言模型）。

问题所在：“盲目”的厨师

在旧有的做法中（标准批处理/Standard Batching），厨房经理必须在食材被准备好之前，就去猜测每份订单的大小。

猜测： “我会放 8 份订单在一个托盘里。”
现实： 有些订单非常小（仅仅是一块饼干），而有些订单则非常庞大（一整只火鸡）。
浪费： 如果你把一块小饼干和一只大火鸡放在同一个托盘里，你必须用大量的空白空间来填充托盘，以确保它们能放得下。如果火鸡实在太大，托盘就会碎裂（显存溢出/Out of Memory）。
结果： 厨房要么充满了空置空间（浪费能量），要么不断地弄碎托盘（崩溃）。厨师把大量时间花在等待下一个托盘准备就绪上，而不是在专注于烹饪。

解决方案：在线动态批处理 (Online Dynamic Batching, ODB)

该论文的作者引入了一种名为 在线动态批处理 (ODB) 的新系统。你可以把它想象成一条智能的、实时的流水线，它会一直等到最后一秒钟才决定如何对订单进行分组。

等待真相： 系统不再进行猜测，而是等待食物被完全准备好、切好并装盘（在分词/tokenization 和图像处理之后）。现在，它确切地知道了每一份订单的精确大小。
智能分组： 它立即按大小对订单进行分组。它把所有的小饼干放在一个托盘里，把大火鸡放在另一个托盘里。
- 无浪费： 托盘被填得很紧凑。没有任何空白空间。
- 不破碎： 托盘的大小经过完美设计，因此永远不会碎裂。
“同步”技巧： 这是最难的部分。在多厨房设置中（多台计算机协同工作），每个人都必须在完全相同的时间完成他们的托盘并摇铃。如果一个厨房提前完成了并开始等待，整条生产线就会停滞。
- 论文引入了一种“组对齐”（Group Alignment）协议。这就像一位指挥家，确保即使厨房 A 有 5 个托盘而厨房 B 有 7 个托盘，他们也能快速地重新分配食物，让所有人都能同时摇铃，而不会有人掉落食物或陷入无尽的等待。

结果：烹饪更快，味道如初

研究人员在各种“菜单”（数据集）上测试了这一新系统，涵盖了从简单的文本到复杂的图文结合内容。

速度： 他们发现 ODB 比旧有的猜测方法快了 1.5 到 4 倍。在某些生产场景中，速度提升了近 4.5 倍。
质量： 尽管烹饪速度更快，但食物的味道依然一样好。通过“味觉测试”（基准测试得分）显示，使用 ODB 训练的模型与使用旧有的、更慢的方法训练的模型一样聪明。
无需新设备： 最棒的一点是？他们不需要重建厨房，也不需要改变食谱。他们只是将“托盘管理员”（数据加载器/data loader）更换为了一个更聪明的管理者。

为什么这很重要

这个系统就像是从手动组装线升级到了一个能够实时自我重组的智能自适应机械臂。它解决了“空间浪费”和“等待时间”的问题，而无需改变核心的烹饪过程或预先计算一切。

简而言之， ODB 是一个智能的交通警察，它会观察实际的车辆（数据样本）后再决定如何对它们进行分组，从而确保高速公路（GPU）始终车流不断却从不拥堵，让整个旅程在不丢失任何乘客的情况下变得更加高效。

技术摘要：具有形式化保证的 LLM 训练在线动态批处理

1. 问题陈述

现代大语言模型（LLM）和多模态微调流水线在训练时批处理方面面临着根本性的可观测性问题。在标准的离线批采样器中，样本的真实训练成本（序列长度）在经过涉及数据增强、对话模板、分词以及多模态视觉 Token 扩展等复杂的预处理流水线之前是未知的。

因此，批构建过程对于决定填充（padding）、内存使用量和 GPU 饱和度的变量是“盲目”的。现有方案面临着权衡：

固定批次采样（Fixed-batch sampling）： 为了避免因长尾数据导致的显存溢出（OOM），通常使用较小的批次大小，这导致了 GPU 利用率不足。较大的固定批次则会导致过多的填充或 OOM。
离线长度缓存（Offline length caches）： 诸如 GMT/BMT 等需要预计算长度的方法依赖于昂贵的静态缓存，而每当增强策略、模板或截断长度发生变化时，这些缓存都必须重新构建。
序列打包（Sequence packing）： 虽然有效，但通常需要模型级或算子级的干预（例如可变长度注意力机制），而非纯粹的 DataLoader 解决方案。

此外，将批构建移动到准确的可观测点（即预处理之后）会引入分布式组对齐问题（Distributed Group Alignment Problem, DGAP）。在分布式数据并行（DDP）设置中，所有 Rank 必须执行相同数量的梯度规约步骤。如果每个 Rank 根据本地实现的长度独立形成可变大小的组，则各 Rank 之间的组数将会不同，从而破坏 DDP 契约，导致死锁或样本丢失。

2. 方法论：在线动态批处理 (ODB)

作者提出了在线动态批处理（Online Dynamic Batching, ODB），这是一个实现在 DataLoader 边界的即插即用系统，它在观察到预处理后的实际长度后动态形成批次，且无需修改模型、优化器或注意力算子。

架构

位置： ODB 封装了 PyTorch 的 DataLoader 迭代器。它保持 Dataset 和 Model 不变。
工作流：
1. Worker： 以 null collate 函数运行，将单个样本传递给专门的整理进程（Collate Process）。
2. 分组： 整理进程将样本抽入缓冲区，按长度排序，并贪婪地形成满足用户指定 Token 预算（ $L_{max}$ ）的可变大小批次。
3. 对齐： 一个专门的 Gloo 组（与主 NCCL 组隔离）用于同步所有 Rank 之间的组数。
4. 输出： 对齐后的组被传递给训练器。未填满的槽位使用 IDLE_DATA 哨兵进行填充，主进程会跳过这些数据，从而确保步骤对齐。

分布式组对齐问题 (DGAP)

ODB 将同步需求形式化为 DGAP。它引入了一种基于最大值的双向组对齐协议，以确保所有 Rank 在执行相同数量的 AllReduce 操作时既不会发生死锁，也不会造成样本丢失。

目标计算： 目标组数（ $T_{grp}$ ）计算为所有活跃 Rank 中“最小正输出容量”与“最小正缓冲样本计数”的最大值。
调整机制：
- 拆分（Split）： 如果一个 Rank 的组数少于 $T_{grp}$ ，它会将较大的组拆分为单例（singletons）。
- 溢出（Overflow）： 如果一个 Rank 的组数多于 $T_{grp}$ ，它会保留前 $T_{grp}$ 个组，并将剩余样本重新循环回缓冲区。
终止模式：
- 默认 Join 模式： 通过在全局完成前排空所有待处理的采样视图，确保严格的身份覆盖（identity coverage）。
- 可选 Non-Join 模式： 仅确保样本配额闭合（累计计数），而不保证严格的逐迭代身份一致性，适用于受限的运行时间场景。

损失缩放

由于 ODB 批次的 Token 总数在不同 Rank 之间存在差异，朴素的 DDP 平均会导致有偏的损失估计。ODB 实现了Token 级损失缩放，通过将每个 Rank 的损失乘以其占总 Token 的比例（ $w_r = t_r / T_{tok}$ ）进行加权，以恢复精确的逐 Token 参考损失。

3. 核心贡献

系统设计： 引入了 ODB，一种在 DataLoader 端观察后处理长度并形成 DDP 安全的可变大小批次的系统，无需模型重写或预计算长度缓存。
形式化保证： 形式化了 DGAP，并证明了无死锁的有界终止性、严格的身份覆盖（在 Join 模式下）以及样本配额闭合（在 Non-Join 模式下）。
经验性能： 在 Qwen3-VL 模型（UltraChat, LLaVA, ShareGPT4o 数据集）上进行了评估，展示了在保持标准质量水平的同时，显著提升了吞吐量。
开源： 发布了带有轻量级训练器适配器的 online-dynamic-batching 包。

4. 实验结果

实验在 8×H20 节点（DeepSpeed ZeRO-2, bf16）上使用 Qwen3-VL-2B/8B 模型进行。

吞吐量增益

ODB 显著优于固定批次基准（Standard, Sorted），并接近离线 Oracle 方法（GMT/BMT），且无需其缓存开销：

单节点（全量微调/LoRA）： 相比 Standard 实现 1.58× – 2.51× 的提升。
两节点（全量微调）： 相比 Standard 实现 1.71× – 3.78× 的提升。
高异质性（ShareGPT4o, CV=1.00）： ODB 实现了 2.46× (8B) 和 2.47× (2B) 的加速，而 Sorted 由于长尾约束被迫使用小批次，加速比仅约为 1.03×。
生产案例（MM-Mix）： 在具有高短样本密度的生产级多模态混合数据集中，ODB 实现了相对于 Standard 的 4.43× 加速。

质量指标

验证损失与基准测试： ODB 保持在“与 Standard 相当的区间”内。例如，在 8B UltraChat 上，ODB 的 MMLU 分数（74.75%）与 Packing（75.18%）和 GMT（75.14%）相当。
与 Sorted 的对比： 虽然 Sorted 通常比 Standard 具有更高的吞吐量，但它经常出现验证损失退化和回答格式降级的问题（例如在 LLaVA 上，Sorted 的生成回答 MMMU 得分从 Standard 的 22.30% 骤降至 5.52%，这是由于格式漂移导致的）。ODB 通过分组而非排序避免了这一问题。
与 Oracles 的对比： 离线 Oracle（GMT/BMT）通常能获得略高的原始吞吐量，但需要昂贵的静态缓存，且在策略变更时必须重建。ODB 在“在线/即插即用”范式下运行，提供了相当的质量且无需预计算缓存。

消融实验

Token 预算（ $L_{max}$ ）： 吞吐量随 $L_{max}$ 增加，直到内存压力或步时（step time）占据主导。最优 $L_{max}$ 因数据集而异（例如 UltraChat 为 12288，ShareGPT4o 为 14336）。
待处理深度（ $D$ ）： 一旦流水线重叠达到饱和（通常 >95%），增加 $D$ 的收益递减。
短样本利用率： 加速比与变异系数（CV）相关，但会被短样本比例（ $f_s$ ）放大。MM-Mix（低 CV 但高 $f_s$ ）比 ShareGPT4o（高 CV, 低 $f_s$ ）获得了更大的收益。

5. 意义与主张

论文声称 ODB 成功占据了高异质性 LLM 微调中的在线/即插即用范式。其意义在于：

弥补差距： 它缩小了固定批次训练与更强的离线/模型侧方法（如 Packing 或 Oracle Batching）之间的吞吐量差距，同时避免了需要标量长度缓存或模型侧算子重写的需求。
形式化安全性： 它为 DDP 中的运行时可变大小批处理提供了首个形式化保证（死锁自由、身份覆盖、配额闭合），而此前该领域多采用静态系统。
部署可行性： 由于完全在 DataLoader 边界运行，它兼容现有的训练栈（DeepSpeed, LLaMA-Factory），并且对于会使离线缓存失效的动态增强或模板策略具有鲁棒性。

作者保持了谦逊的态度，指出其收益取决于数据（在高CV/高短样本数据集上表现最佳），并且 ODB 是对已有模型侧 Packing 方法的补充而非替代。他们并不声称 ODB 解决了所有的批处理低效问题，而是为现代多模态和增强型 LLM 训练中特定的可观测性瓶颈提供了一个稳健且具有形式化保证的解决方案。