萤火 AI-HPC：面向深度学习的低成本软硬件协同设计

原文标题：Fire-Flyer AI-HPC: A Cost-Effective Software-Hardware Co-Design for Deep Learning arXiv：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

一、摘要（全文翻译）

深度学习（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 的发展提供了有价值的洞见。

二、核心贡献

以 PCIe A100 替代 SXM 的整集群架构与成本模型：用 10,000 块 PCIe A100 组成 Fire-Flyer 2，在 TF32/FP16 GEMM 达 DGX-A100 约 83% 性能下，把节点价格压到 60%、功耗从 4200W 降到 2500W，性价比达 1.38，全集群仅需 122 台交换机。
HFReduce：把 allreduce 的规约计算从 GPU 搬到 CPU：CPU 向量指令做节点内规约、Double Binary Tree + ibverbs RDMA 做节点间 allreduce，每单位数据只消耗 1 单位 PCIe 双向带宽，且不占用 GPU kernel；186 MiB 数据下节点间带宽 6.3–8.1 GB/s。
HaiScale：面向 PCIe 拓扑的并行训练优化：DDP 异步 allreduce 与反向计算重叠、按 DP rank 错开 PP 时序、FSDP 通信-计算重叠，实现 88%（VGG16）、91%（LLaMa-13B）、95%（GPT2-medium）的并行可扩展性，训练时间比同等 PyTorch 实现缩短近一半。
存算一体网络的无拥塞工程实践：用 IB SL→VL 隔离 HFReduce／NCCL／3FS／其他四类流量，改用静态路由，NCCL 走同 NUMA 节点的网卡与 GPU，3FS 引入 request-to-send 控制；并关闭 DCQCN，在不做拥塞控制下保持网络无拥塞。
3FS 与 HAI Platform 组成的生产级软件栈：180 个存储节点、2880 块 NVMe SSD、超过 20PiB 容量，实测读吞吐 8TB/s；配合秒级 checkpoint 与周度巡检，支撑 99% 利用率。
真实故障画像与下一代架构：公开一年生产集群故障统计（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」，共三步：

节点内规约（Algorithm 1）：按 Chunk_Size 切分梯度，异步 D2H 搬入 CPU 内存（小数据用 GDRCopy，大数据用 MemCpyAsync），再用 CPU 向量（SIMD）指令做 reduction add，支持 FP32/FP16/BF16/FP8。
节点间规约（Algorithm 2）：用 Double Binary Tree 两趟（Pass 1 规约、Pass 2 收集广播）完成节点间 allreduce，传输基于 ibverbs RDMA Write。
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)	电能利用效率

16 KiB Raw Blame History Unescape Escape