120 lines
16 KiB
Markdown
120 lines
16 KiB
Markdown
# 萤火 AI-HPC：面向深度学习的低成本软硬件协同设计
|
||
|
||
> **原文标题**：Fire-Flyer AI-HPC: A Cost-Effective Software-Hardware Co-Design for Deep Learning
|
||
> **arXiv**：[2408.14158](https://arxiv.org/abs/2408.14158) ｜ **发布**：26 Aug 2024（v1），31 Aug 2024（v2）
|
||
> **作者/机构**：Wei An 等（按姓氏字母序排列），DeepSeek-AI（深度求索，北京）与 High-Flyer Quant
|
||
> **原文 PDF**：[01-Fire-Flyer-AI-HPC-2408.14158.pdf](./01-Fire-Flyer-AI-HPC-2408.14158.pdf)
|
||
|
||
## 一、摘要（全文翻译）
|
||
|
||
深度学习（Deep Learning, DL）与大语言模型（Large Language Model, LLM）的快速进步，使人们对算力与带宽的需求呈指数级增长。这一趋势与更快的计算芯片和互连技术的高昂成本叠加，显著推高了高性能计算（High Performance Computing, HPC）的建设成本。为应对这些挑战，我们提出萤火 AI-HPC（Fire-Flyer AI-HPC）架构——一套软硬件协同设计（hardware-software co-design）框架及其最佳实践。在深度学习训练方面，我们部署了拥有 10,000 块 PCIe A100 GPU 的 Fire-Flyer 2，其性能接近 DGX-A100，同时将成本降低一半、能耗降低 40%。我们专门设计了 HFReduce 来加速 allreduce 通信，并实施了大量措施以保持「计算-存储一体化网络」无拥塞。通过包括 HaiScale、3FS 和 HAI-Platform 在内的软件栈，我们借助计算与通信的重叠（overlap）实现了良好的可扩展性。我们在深度学习训练中积累的这类面向系统的经验，为未来 AI-HPC 的发展提供了有价值的洞见。
|
||
|
||
## 二、核心贡献
|
||
|
||
1. **以 PCIe A100 替代 SXM 的整集群架构与成本模型**：用 10,000 块 PCIe A100 组成 Fire-Flyer 2，在 TF32/FP16 GEMM 达 DGX-A100 约 83% 性能下，把节点价格压到 60%、功耗从 4200W 降到 2500W，性价比达 1.38，全集群仅需 122 台交换机。
|
||
2. **HFReduce：把 allreduce 的规约计算从 GPU 搬到 CPU**：CPU 向量指令做节点内规约、Double Binary Tree + ibverbs RDMA 做节点间 allreduce，每单位数据只消耗 1 单位 PCIe 双向带宽，且不占用 GPU kernel；186 MiB 数据下节点间带宽 6.3–8.1 GB/s。
|
||
3. **HaiScale：面向 PCIe 拓扑的并行训练优化**：DDP 异步 allreduce 与反向计算重叠、按 DP rank 错开 PP 时序、FSDP 通信-计算重叠，实现 88%（VGG16）、91%（LLaMa-13B）、95%（GPT2-medium）的并行可扩展性，训练时间比同等 PyTorch 实现缩短近一半。
|
||
4. **存算一体网络的无拥塞工程实践**：用 IB SL→VL 隔离 HFReduce／NCCL／3FS／其他四类流量，改用静态路由，NCCL 走同 NUMA 节点的网卡与 GPU，3FS 引入 request-to-send 控制；并**关闭 DCQCN**，在不做拥塞控制下保持网络无拥塞。
|
||
5. **3FS 与 HAI Platform 组成的生产级软件栈**：180 个存储节点、2880 块 NVMe SSD、超过 20PiB 容量，实测读吞吐 8TB/s；配合秒级 checkpoint 与周度巡检，支撑 99% 利用率。
|
||
6. **真实故障画像与下一代架构**：公开一年生产集群故障统计（Xid74 占 42.57%、Xid43 占 33.48%、IB 链路闪断占其余故障的 30%），并提出面向 MoE 训练、1:1 GPU/NIC 配比、多平面 Fat-Tree + RoCE 的下一代架构。
|
||
|
||
## 三、方法与技术要点
|
||
|
||
### 3.1 节点架构：为什么选 PCIe
|
||
|
||
依据是模型规模分布：ResNet、BERT、MAE 等参数量均小于 1B，显存需求不高，故 2021 年建设以深度学习为主的集群时 PCIe A100 已足够。节点为 2×AMD 32 核 EPYC Rome/Milan、512GB 16 通道 DDR4-3200、8×PCIe-A100-40GB、1×CX6 200Gbps IB 网卡。要点：不用 PCIe Switch，8 块 GPU 与网卡直连 CPU，网卡独占一个 Root Complex，避免与 GPU 争抢根端口带宽；预留 NVLink Bridge 位置，LLM 到来后确在两两卡间加装（600 GB/s）；实测 8 块 A100 的存储 IO 与通信带宽可由单块 200Gbps 网卡满足，这也是后文 PP 带宽竞争的根源。
|
||
|
||
### 3.2 网络拓扑：双区两层 Fat-Tree 与存算一体
|
||
|
||
选 Fat-Tree 而非 Dragonfly，因前者对分带宽极高，后者不足；实施时 RoCE 尚不成熟，故选 IB（QM8700，40 端口 × 200Gbps）。降本核心是**用两个两层 Fat-Tree 代替一个三层 Fat-Tree**：每区 800 端口，接入约 600 个计算节点；存储服务器各配两块 IB 网卡分接两区，使全部计算节点共享同一套存储；两区只用少量链路互连，并由 HAI Platform 保证跨区任务至多一个。这样即便用 NCCL 或 HFReduce（均可用双二叉树算法跨区），全集群任务只需一对节点跨区通信，仍能跑满 10,000 GPU。
|
||
|
||
### 3.3 HFReduce：网络中的软硬件协同
|
||
|
||
HFReduce 的核心策略是「**先节点内规约，再对各节点归并后的数据做节点间 allreduce**」，共三步：
|
||
|
||
1. **节点内规约（Algorithm 1）**：按 `Chunk_Size` 切分梯度，异步 D2H 搬入 CPU 内存（小数据用 GDRCopy，大数据用 MemCpyAsync），再用 **CPU 向量（SIMD）指令**做 reduction add，支持 FP32/FP16/BF16/FP8。
|
||
2. **节点间规约（Algorithm 2）**：用 **Double Binary Tree** 两趟（Pass 1 规约、Pass 2 收集广播）完成节点间 allreduce，传输基于 ibverbs RDMA Write。
|
||
3. **H2D 回写**：CPU 把梯度经 PCIe 写回 GPU；用 GDRCopy 向同一 NUMA 节点内 4 块 GPU 写数据，因其可把 host 数据暂存于 CPU cache，使 host 内存读取相比 MemCpyAsync 降至 1/3。
|
||
|
||
**为什么能超过 NCCL**：设 GPU 总数为 $n$，NCCL ring 下每单位数据需 $2n-1$ 次传输，消耗 $\frac{2n-1}{n}$ 单位 PCIe 双向带宽；HFReduce 只需一次 D2H 加一次 H2D，即 **1 单位**。本机器上 NCCL 主要受 PCIe 带宽限制，故 HFReduce 占优。此外 HFReduce 借 GPU 的 **Copy Engine（CE）** 做异步传输，不执行 GPU kernel，故不干扰其他 kernel。根因上，作者确认 EPYC Rome **不支持 chained write**（该特性可大幅加速 GPU↔IB 网卡的 PCIe P2P 传输），Rome 上二者最大带宽约 9 GiB/s，这解释了 NCCL 仅 4GB/s。
|
||
|
||
**HFReduce 自身的瓶颈**：单节点内存操作量合计约 **24 倍**于 GPU 上原始数据量：D2H 8 次写、节点内规约 8 读 1 写、节点间 allreduce（IB 发送 2 读、接收 2 写与 1 次 reduce-add 读）、H2D（GDRCopy 2 读，MemCopy 8 读）。16 通道 DDR4-3200 实测访存约 320GB/s，理论上限约 13.3GB/s，扣除算法与网络开销后约 12GB/s，实测仅略超 8GB/s。原因是另一处 EPYC 限制：GPU5/GPU6 共享同一 Root Complex Port，Rome/Milan 上根端口到 CPU 内部总线最大带宽约 37.5GB/s，两块 GPU 并发即受限；论文指出 Genoa 仍有此问题。**HFReduce with NVLink** 即用于缓解该受限：先在 NVLink 互连的 GPU 对间规约再交给 CPU，CPU 返回时把结果切分送回成对 GPU，再经 NVLink 做 allgather，使节点间带宽超过 10 GB/s。
|
||
|
||
### 3.4 HaiScale：并行训练优化
|
||
|
||
HaiScale 定位类似 Megatron 与 DeepSpeed，针对 PCIe 架构优化 DP/PP/TP/EP：**DDP 重叠**——以 HFReduce 替代 NCCL，在反向传播中对已算出的梯度做异步 allreduce，因 HFReduce 不占用 SM，该通信可与反向计算完全重叠；**PP 带宽竞争**——单节点 8 卡只有一块网卡，故让 8 卡分属不同 DP rank，**错开各 rank 的 PP 时序**、拉开通信峰值；**TP** 借 NVLink Bridge 的 600GB/s 卡间带宽提升效率；**FSDP** 同属 ZeRO Stage-3，但改良显存管理，并把 allgather 与 reduce-scatter 与前后向计算重叠、把优化器更新切分进反向传播。
|
||
|
||
### 3.5 网络无拥塞工程与 3FS
|
||
|
||
流量分为 HFReduce、NCCL、3FS 存储、其他四类，建连时赋予不同 IB **Service Level（SL）**并映射到物理队列 **Virtual Lane（VL）**，按比例配置实现隔离，避免队头阻塞与流量互撞。高吞吐存储场景天然有大量 incast，实测开启自适应路由会让拥塞扩散更严重，故**改用静态路由**，并把各类节点均匀分散到 leaf→spine 链路以均摊存储流量。NCCL 侧调整拓扑使其经同 NUMA 节点内的 IB 网卡与 GPU 通信，减少 chiplet 互连引起的 PCIe 拥塞，并启用 PCIe Relaxed Ordering。
|
||
|
||
**3FS** 存储节点为 1×64 核 EPYC 7742、512GB 8 通道内存、2×CX6 200Gbps IB、16×15.36TB PCIe 4.0×4 SSD。系统含 cluster manager、meta service、storage service、client 四种角色；元数据以键值对存于分布式 KV 系统（inode 表存文件元数据与内容位置，目录项表存 (parent_dir_inode_id, entry_name):(entry_inode_id,…)）。存储层用 **CRAQ** 的 write-all-read-any 策略保证强一致性并释放 SSD 吞吐与 IOPS，文件按 stripe size $k$ 切块复制到链上，每块 SSD 承载多个链的 target 以均衡读写。针对客户端 incast 拥塞，服务端与客户端间实现 **request-to-send** 流控：服务端读完 SSD 后先申请许可，客户端限制并发发送者数，获准后以 RDMA WRITE 发送并通知；该机制抬高 IO 时延，但为可持续高吞吐所必需。**3FS-KV** 在其上提供键值、消息队列、对象存储三种模型，支持读写分离与按需启动，并支撑 DeepSeek 的 KV Context Caching on Disk 技术，把 LLM 服务成本降低一个数量级。
|
||
|
||
### 3.6 HAI Platform、稳定性与容灾
|
||
|
||
**HAI Platform** 采用分时调度：用户提交 Python/bash 任务或容器，平台按资源需求与繁忙度中断并重装任务；任务代码须支持断点续跑——接受中断信号、保存 checkpoint、上报中断、从 checkpoint 恢复。集群不以 GPU 池化方式管理，而是**以计算节点为基本单位**按资源类型、网络区域分类标记，并鼓励用户多卡并行训练，从而实现 **99% 利用率**。
|
||
|
||
**Checkpoint Manager**：参数与优化器状态切块后经 3FS 批量写 API 写入（每节点超 10 GiB/s），几秒内完成；并异步从 GPU 搬到主机内存，周期保存（通常每 5 分钟）；保存时记录张量索引与偏移，配合批量读 API 使加载同样只需几秒，故故障中断最多只丢 5 分钟进度。**Validator** 每周运行：查硬件频率与链路速率、状态，CPU 压力与内存带宽，逐字节 GPU 显存，满显存 GEMM（并查芯片运算逻辑），节点内 allreduce（借上层应用查 NVLink 带宽），存储带宽压力。
|
||
|
||
**故障画像**：GPU Xid 错误分五类——软件成因（Xid 13/31、43/45）、NVLink 错误（Xid 74）、显存 ECC 错误（Xid 63/64、94/95，A100 行重映射使多数只需重置 GPU）、不可纠正故障（Xid 44/48、61/62/69/79，需重置 GPU 或重启节点）、其他（Xid 119，GSP 失效，多需 RMA）。实践中还遇到过 ECC 未检出的计算与显存错误，会造成 gradnorm 尖峰、loss 爆炸甚至不收敛。
|
||
|
||
## 四、主要实验结果
|
||
|
||
| 基准 / 任务 | 本方案 | 对比对象 | 说明 |
|
||
|---|---|---|---|
|
||
| TF32 GEMM（TFLOPS/GPU） | 107 | DGX-A100 131 | 相对性能 83% |
|
||
| FP16 GEMM（TFLOPS/GPU） | 220 | DGX-A100 263 | 相对性能 83% |
|
||
| 节点相对价格 | 60% | DGX-A100 100% | 性价比 1.38 vs 1 |
|
||
| 功耗（Watts） | 2500 | DGX-A100 4200 | 降约 40% |
|
||
| 交换机数 / 网络价格 / 总价 | 122 / 350 / 11600 | 三层 Fat-Tree 200 / 600 / 11850；DGX 架构 1320 / 4000 / 23000 | 网络成本省 40% |
|
||
| allreduce 节点间带宽（186 MiB，16→1440 GPU） | HFReduce 6.3–8.1 GB/s | NCCL 1.6–4.8 GB/s | HFReduce with NVLink 超过 10 GB/s |
|
||
| VGG16 训练（32→512 GPU） | 时间约为一半，并行可扩展性近 88% | Torch DDP（NCCL 后端） | 弱扩展性 |
|
||
| GPT2-medium 训练（16→128 GPU） | 并行可扩展性 95%，时间比 PyTorch 少近一半 | Torch FSDP | 弱扩展性 |
|
||
| LLaMa-13B（seq 2048, batch 4096, PP 4） | 64→512 GPU：step 64.118s → 9.717s，效率 91% | — | 强扩展性 |
|
||
| DeepSeekMoE-16B（seq 4096, batch 4608, PP 10） | 40→640 GPU：79.615s → 6.535s，效率 76.14%；320 GPU 时 10.71s，效率 92.92% | — | 强扩展性 |
|
||
| 3FS 存储吞吐 | 180 节点 / 360 个 200Gbps HCA，理论 9TB/s，实测读 8TB/s，>20PiB | — | 2880 块 NVMe SSD，镜像冗余 |
|
||
| 整集群能耗 | 不超过 4 MW（约略高于 3 MW） | — | 含 IB 交换机与其他节点 |
|
||
| GPU Xid 年度分布 | 共 12970 次：Xid74 5521（42.57%）、Xid43 4342（33.48%）、Xid31 2487（19.18%）、Xid45 240、Xid13 45，ECC 类约 2% | — | 不可纠正故障合计 57 次（0.45%） |
|
||
| 稳定性对比 | NVLink 相关（主要 Xid-74）占 GPU 故障约 42.57% | 另一论文报告 NVLink 相关占 52.42%（54/103） | 原始数据：54 NVLink、21 CUDA、16 节点、12 ECC、12 网络错误 |
|
||
|
||
强扩展性最好的观测点是 LLaMa-13B 的 91% 与 DeepSeekMoE-16B 在 320 GPU 时的 92.92%，后者扩到 640 GPU 时降至 76.14%，说明大规模 EP 通信仍有损耗。相对 DGX-A100，本架构 GEMM 稳定落后约 17%，但以半价与六成功耗换来 80% 的整体性能。主要故障来源是 Xid74（占 42.57%）与 Xid43（占 33.48%，也需警惕显存数据损坏）；IB 链路闪断占其余硬件故障的 30%。
|
||
|
||
## 五、结论、局限与影响
|
||
|
||
- **结论**：Fire-Flyer 2 用 10,000 块 PCIe A100 达到接近 DGX-A100 的性能并将建设成本减半；软件侧以 HFReduce、HaiScale 突破硬件限制保证可扩展性，以 3FS 与网络协同防拥塞，以 HAI Platform 覆盖系统故障。整体上本架构达到 DGX-A100 的 80% 性能，功耗低于其 60%。
|
||
- **局限性**：
|
||
- PCIe 与 SXM 的规格固有差距带来约 17% 性能落后，论文自述已「reaching the utilization upper limit of PCIe GPUs」；
|
||
- HFReduce 受 EPYC Rome/Milan（乃至 Genoa）PCIe Host Bridge 带宽限制，实测约 8GB/s 未达约 12GB/s 的现实上限；
|
||
- Xid74 占 42.57%，作者坦言除压测筛除反复出错的卡外「没有好的办法避免」；
|
||
- 无法为 HFReduce 与 3FS 找到可共存的 DCQCN 参数，只能关闭拥塞控制、改以静态路由与流量隔离维持无拥塞；
|
||
- NVLink 是 LLM 需求倒逼的后期补丁，论文强调是否加装应基于实际需求，因其有潜在缺点。
|
||
- **影响**：本文是 DeepSeek 训练基础设施的一手工程披露，价值在于可复现的成本-性能权衡路径（PCIe 替代 SXM、两层替代三层 Fat-Tree、CPU 规约替代 GPU 规约、存算一体的流量隔离）、真实故障分布数据与开源实践（HAI Platform 已开源）。未来工作提出面向 MoE LLM 训练的下一代架构：节点采用 1:1 GPU/NIC 配比（对标 DGX-H100/B100），引入多平面网络降成本，并探索以 RoCE 替代 IB——128 端口 400Gbps RoCE 组成的 4 平面两层 Fat-Tree 可支持 32,768 GPU。
|
||
|
||
## 六、关键术语对照表
|
||
|
||
| English | 中文 |
|
||
|---|---|
|
||
| Fire-Flyer AI-HPC / Fire-Flyer 2 | 萤火 AI-HPC／萤火二号 |
|
||
| Software-Hardware Co-Design | 软硬件协同设计 |
|
||
| All-Reduce / AllGather / Reduce-Scatter | 全规约／全收集／规约散射 |
|
||
| HFReduce / HaiScale | 萤火自研 allreduce 通信库／并行训练框架 |
|
||
| 3FS (Fire-Flyer File System) | 萤火分布式文件系统 |
|
||
| HAI Platform | 萤火集群分时调度平台 |
|
||
| Computation-Storage Integrated Network | 计算-存储一体化网络 |
|
||
| Two-Layer Fat-Tree | 两层胖树拓扑 |
|
||
| Bisection Bandwidth | 对分带宽 |
|
||
| Double Binary Tree | 双二叉树算法 |
|
||
| DP / PP / TP / EP | 数据／流水线／张量／专家并行 |
|
||
| FSDP / ZeRO | 完全分片数据并行／零冗余优化器 |
|
||
| MFU (Model FLOPs Utilization) | 模型算力利用率 |
|
||
| GDRCopy / Copy Engine (CE) | GPU 直接拷贝／（GPU）拷贝引擎 |
|
||
| Service Level (SL) / Virtual Lane (VL) | 服务等级／虚拟通道 |
|
||
| Head-of-line (HOL) Blocking / Incast | 队头阻塞／多点汇聚 |
|
||
| DCQCN / PFC / ECMP / Adaptive Routing | 数据中心量化拥塞通知／优先级流控／等价多路径／自适应路由 |
|
||
| RoCE (RDMA over Converged Ethernet) | 融合以太网 RDMA |
|
||
| CRAQ / Request-to-Send Control | 分配查询的链式复制／发送许可控制 |
|
||
| Silent Data Corruption | 静默数据损坏 |
|
||
| Xid Error / NVLink Bridge | GPU Xid 错误／NVLink 桥接器 |
|
||
| Checkpoint Manager / Validator | 检查点管理器／硬件校验工具 |
|
||
| PUE (Power Usage Effectiveness) | 电能利用效率 |
|