[Paper] 可靠且弹性的集合通信库用于LLM训练与服务

Source: arXiv - 2512.25059v1

概览

训练和服务大型语言模型（LLMs）现在通常涉及数十甚至数千块 GPU，通过高速网络相连。一次网络故障——例如 NIC 失效或瞬时链路减速——就可能导致整个作业停滞，浪费 10–15 % 的宝贵 GPU 时间。本文介绍了 R²CCL，一种容错的集合通信库，能够自动在多个 NIC 之间重新路由流量，使训练和推理流水线几乎不受性能影响地持续运行。

Key Contributions

• 无损、低开销故障转移: R²CCL 利用多 NIC 硬件，在 NIC 或链路故障时即时迁移连接，避免昂贵的作业重启。
• 带宽感知的负载重新分配: 该库持续监测链路容量，并重新平衡流量，以最佳利用剩余的健康路径。
• 弹性集合算法: 经典的集合原语（例如 all‑reduce、broadcast）被重新实现，以容忍部分网络分区而不牺牲正确性。
• 全面评估: 在两台 8‑GPU H100 服务器以及大规模模拟（数百 GPU）上的实验表明，在真实故障模式下，训练开销低于 1 % ，推理开销低于 3 % 。
• 相较于已有技术的显著加速: 在故障恢复延迟方面，R²CCL 分别比最接近的开源方案（AdapCC 和 DejaVu）快 12× 和 47×。

方法论

1. Multi‑NIC exploitation：现代 GPU 服务器通常配备多个网络接口（例如双端口 InfiniBand）。R²CCL 将所有 NIC 注册到 MPI 风格的运行时，并将它们视为可互换的端点。
2. Rapid connection migration：当某个 NIC 报告错误时，库会立即拆除受影响的套接字，并在备用 NIC 上重新建立连接，通过每个连接的少量缓冲区保留正在传输的消息。
3. Dynamic bandwidth profiling：轻量级后台线程测量每条链路的吞吐量。如果链路性能下降，R²CCL 会重新分配集合通信流量（例如拆分 all‑reduce 树），以规避瓶颈。
4. Resilient collectives：作者重新设计了集合算法，使其具备 partition‑tolerant 特性：若部分参与者暂时不可达，算法仍可在剩余节点上继续执行，并在故障路径恢复后合并缺失的贡献。
5. Simulation framework：为测试可扩展性，作者构建了一个故障注入模拟器，模拟 GPU 集群拓扑、不同的故障率和网络抖动，从而在超出两节点硬件环境的情况下实现可复现的压力测试。

结果与发现

• 鲁棒性：R²CCL 在 > 99 % 的模拟故障注入中保持训练进度不间断。
• 可扩展性：在 256‑GPU 集群的模拟中，库的开销呈亚线性增长，确认额外的账务记录不会成为瓶颈。
• 资源效率：因为 R²CCL 重用现有 NIC 而不是生成额外进程或对整个模型进行检查点保存，GPU 内存和存储占用保持不变。

实际影响

• 降低云成本：云服务提供商按 GPU 小时计费；削减 10 % 的浪费直接转化为 LLM 开发者的账单降低。
• 更高的 SLA 合规性：对于推理服务（例如聊天机器人），能够在 NIC 故障时仍保持请求不中断，可提升延迟保证和用户体验。
• 简化运维：工程师无需为网络故障编写繁琐的检查点与重启脚本；R²CCL 能透明地处理恢复，降低运维复杂度。
• 硬件无关的弹性：该方法适用于任何多 NIC 服务器（InfiniBand、RoCE、以太网），可直接用于现有 PyTorch/DeepSpeed 流水线，无需额外改动。
• 支持更大规模集群：随着集群规模扩展至数千个 GPU，至少出现一次网络故障的概率急剧上升；能够降低此风险的库可解锁更激进的扩展策略。

限制与未来工作

• 依赖多个 NIC：只有单个网络接口的系统无法受益于 R²CCL 的故障转移；作者建议探索基于软件的虚拟 NIC 作为后备方案。
• 部分故障覆盖：当前设计假设每个节点至少有一个 NIC 保持可用；同时出现多 NIC 故障仍会导致作业中止。
• 集成深度：R²CCL 作为独立库呈现；与流行框架（如 NCCL、Horovod）更紧密的集成可以降低学习曲线。
• 安全考虑：跨 NIC 的自动重连可能暴露新的攻击面；未来工作将加强握手协议的安全性。

作者

• Wei Wang
• Nengneng Yu
• Sixian Xiong
• Zaoxing Liu

论文信息

• arXiv ID: 2512.25059v1
• 分类: cs.DC, cs.LG, cs.NI
• 出版日期: 2025年12月31日
• PDF: Download PDF