SlideDP 让多 GPU 共享主机内存的全参数微调提速 1.46–2.64 倍,并在四张 H100 上以更大批次超过 FSDP2 峰值 11.2%
核心概要
SlideDP 提出一种面向共享主机多 GPU 系统的同步数据并行运行时,通过维护单一权威主机状态、将通信路径与状态布局解耦、并在 rank 与 chunk 之间流水化参数下发、梯度聚合与 CPU 更新,在匹配批次扫描中对 SlideFormer、MegaTrain 和 ZeRO-Offload 取得 1.46–2.64 倍的几何平均吞吐比,在四张 H100 上以较小批次接近 GPU 常驻的 FSDP2、以较大批次超过其测得峰值吞吐 11.2%,并支持 Qwen3-14B 的 256K token 序列以及在四张 RTX 4090 上微调 Qwen2.5-72B。
深度剖析
SlideDP 把主机常驻层流式训练从单 GPU 变通方案扩展为共享主机上的多 GPU 同步数据并行运行时:主机保存一份权威的 FP32 主权重与 Adam 状态,各 rank 在受限的可复用 GPU 窗口内使用临时 BF16 层副本,rank-0 优化器 worker 每轮只更新一次该状态。 此前 SlideFormer 与 MegaTrain 的多 GPU 模式采用复制式参数下发与 CPU 侧梯度归约,使主机需求随 rank 数增长;ZeRO-Offload 等分片卸载方案则聚焦于减少冗余状态搬运。SlideDP 的差异在于在保持同步 DP 语义(同一参数版本、跨 rank 聚合梯度、下一次下发等待更新)的前提下,把持久状态布局与通信路径解耦。 论文给出三条同步 DP 不变量与逐层参数版本门控的描述,并在 RTX 4090、A800、H100 三类平台上实现于 PyTorch Distributed;正确性方面,在四张 H100 上用 Qwen3-14B、每 GPU 批次 16、序列长度 1024 与 FSDP2 对比 200 步,匹配初始权重、C4 样本及顺序与优化器设置,所有 rank 损失有限且全局批次平均损失的最大绝对差在文中给出。
论文给出共享主机扩展的解析步时模型,用资源服务需求与跨层、跨 rank 的执行依赖刻画 host-bound 与 GPU-bound 两种执行状态,解释何时减少流量能缩短一步、强扩展下计算窗口收缩如何暴露主机工作,以及为何最优路径同时取决于拓扑与负载。 该模型把就绪、缓冲区复用与参数版本依赖纳入完成时间约束,并区分稳态步时与末尾更新排空区间;这为“减少逻辑字节数并不足够”这一判断提供了可检验的表述,而不仅是经验性调参。 模型以资源容量下界与依赖完成时间方程形式给出,并通过通信路径、GPU 数量与 chunk 大小的对比实验加以检验;例如在 A800 上移除 NVLink 桥会反转 host-bound 负载下的首选下发路径,而在 GPU-bound 负载下路径差异很小。
AutoPolicy 依据实测的流水线效应选择通信路径、chunk 大小与激活布局,Elastic Checkpointing 提供逐层的保留、卸载与重算选择;在 H100 上 Qwen3-14B 批次 16 的吞吐从 10,231 提升到 12,832 token/s(+25.4%),在 64K 序列上相对固定策略提升 21.7%。 与仅以显存削减为目标的固定检查点策略不同,这里把显存分配本身当作运行时策略决策:保留激活可减少卸载/重载流量,保留中间结果可减少重算,二者收益取决于当前瓶颈。 表 3 给出多平台逐配置对比,例如四张 H100 上批次 32 的组合使用 76.6 GiB 显存(固定策略为 15.0 GiB)并取得 12.4% 吞吐增益;四张 RTX 4090 上批次 16 保留全部 36 层输入使主机 PSS 下降 14.5%。选择开销方面,四张 H100、Qwen3-14B、每 GPU 32 序列的一次选择运行耗时 1218 秒,测得每步节省 0.970 秒,估计盈亏平衡为 1257 步(约 2.72 小时基线训练),占 24 小时训练预算的 1.4%。
在端到端评测中,SlideDP 在四张 RTX 4090 上对 ZeRO-Offload 与 MegaTrain 的几何平均加速为 1.83 与 1.48,在四张 H100 上为 1.46 与 1.59;批次 256 时达到 23.2K token/s 与每步 1,048,576 token 且不使用梯度累积,并支持 256K token 序列与四张 RTX 4090 上的 Qwen2.5-72B 微调。 这些结果把主机内存容量转化为更大的可行训练负载:在 RTX 4090 上 Qwen3-32B 达到 ZeRO-Offload 吞吐的 4.24 倍,Qwen2.5-72B 达到 240 TFLOPS 且其余三个卸载基线标记为 OOM;在 H100 上 4B–72B 模型维持 1.8–2.0 PFLOPS。 评测覆盖三种互连拓扑(PCIe-only 工作站、NVLink 桥接 A800 服务器、NVSwitch H100 服务器),批次扫描通常运行 15 次迭代并丢弃前 8 次预热、每点报告两次运行的算术平均;弱扩展方面 Qwen3-32B 在每 GPU 64 序列下于 2 至 8 张 A800 上保持 95–98% 并行效率,强扩展方面 Qwen3-14B 全局批次 256 从 4 到 8 张 GPU 取得 1.94 倍扩展(SlideFormer 为 1.04 倍)。
启示与展望
这项工作面向单节点、共享主机资源的多 GPU 同步数据并行全参数微调场景,评测覆盖 PCIe-only 工作站、NVLink 桥接的 A800 服务器与 NVSwitch 的 H100 服务器三类拓扑,模型范围从 Qwen3-1.7B 到 Qwen2.5-72B 并包含两个 MoE 模型。它使主机内存容量可以转化为更大的可行批次与更长的序列,例如四张 H100 上 Qwen3-14B 每步超过 1M token、支持 256K token 序列,以及在四张 RTX 4090 上微调 Qwen2.5-72B。对读者而言,这意味着在显存受限但主机内存充裕的节点上,全参数微调的可行边界被重新划定;AutoPolicy 的选择开销在四张 H100 上一次为 1218 秒,估计 1257 步后摊销,适合训练步数足够多的场景。
解析模型依赖实测的有效服务速率,这些速率会随并发转换、DMA 与 Adam 的相互作用而变化,因此模型预测与具体硬件配置的贴合程度仍需按平台校准。AutoPolicy 的选择开销与摊销步数在文中以四张 H100、Qwen3-14B、每 GPU 32 序列的一次运行给出,其他模型与拓扑下的开销规模属于开放问题。评测覆盖稠密模型与两个 MoE 模型,更多架构与更长训练步数下的行为有待进一步观察。此外,本文为全文阅读,但部分图表以图像形式呈现,具体绘图数据与部分数值细节需查阅原文图表。
