Fire-Flyer AI-HPC：DS使用PTX原因的佐证

xiejin77 · 发表于 5 天前

名为火烈鸟的HPC高性能计算集群设计，是佐证DS实干的一个非常清晰的论文。逢山开路遇水搭桥，筚路蓝缕的因陋就简；反过来也能看出晨大的疑问，DS的团队用PTX，很有可能只是因为没有使用SXM的满血DGX-a100的条件，而不得已手搓pcie版本的多卡集群，在其中发现了IB与nvlink配合的瓶颈，根据自己模型的训练架构进行了优化。

1. 深度学习的算力饥渴与 HPC 的成本困境
深度学习的浪潮，正以势不可挡的姿态席卷而来。从图像识别领域的 AlexNet 和 ResNet，到自然语言处理领域的 Transformer，再到如今参数规模动辄千亿、万亿的大型语言模型 (LLM)，如 GPT-3 和 PaLM，以及混合专家模型 (MoE) 和多模态模型，深度学习模型的能力在不断突破，但其背后对计算资源的需求也呈现出爆炸式的增长。

高性能计算 (HPC) 集群，作为支撑深度学习训练的基石，其重要性日益凸显。然而，传统的 HPC 集群，往往面向双精度科学计算，对深度学习训练的支持并不完美。基于 GPU 的 HPC 集群虽然能够较好地支持深度学习训练，但随着模型规模的不断扩大，建设成本也急剧攀升。更快的计算芯片和互连技术固然性能强劲，但其高昂的价格却让许多研究机构和企业望而却步。此外，大规模集群的能耗问题也日益突出，不仅增加了运营成本，也对环境可持续性构成了挑战。

如何在满足深度学习日益增长的算力需求的同时，控制 HPC 集群的建设成本和能耗，成为了一个摆在整个行业面前的难题。这不仅仅是一个技术问题，更是一个关乎深度学习未来发展方向的关键问题。

2. Fire-Flyer AI-HPC：软硬件协同设计的破局之道
DeepSeek-AI 的研究团队敏锐地捕捉到了这一挑战，依托于实践提出了 Fire-Flyer AI-HPC 这一创新性的软硬件协同设计架构。Fire-Flyer AI-HPC 的核心理念，并非简单地追求硬件性能的堆砌，而是通过对硬件和软件的深度融合与精细优化，打造一个高性价比、高可扩展性、高稳定性的深度学习计算平台。

Fire-Flyer AI-HPC 架构的精妙之处，在于它并非孤立地看待计算、网络、存储等各个环节，而是将它们作为一个整体进行系统性的设计和优化。从计算节点的硬件配置，到网络拓扑的选择，再到通信库、训练框架、存储系统以及资源管理平台的开发，每一个环节都经过了精心的考量和定制，以实现最佳的整体性能和成本效益。

3. Fire-Flyer 2：以 PCIe A100 为核心的务实选择
Fire-Flyer 2 是 Fire-Flyer AI-HPC 架构的第一个具体实现，它选择了一条务实而高效的道路——以 PCIe A100 GPU 为核心，构建一个面向深度学习和早期 LLM 训练的高性能计算集群。

每个 Fire-Flyer 2 计算节点的配置都体现了对性能、成本和能耗的精妙平衡。8 个 NVIDIA A100 PCIe GPU 提供了强大的计算能力，足以应对当前大多数深度学习模型的训练需求。选择 PCIe 版本的 A100，而非 SXM 版本，是在性能和成本之间做出的权衡。虽然 SXM 版本的 A100 具有更高的 NVLink 带宽，但其价格也更为昂贵。对于 Fire-Flyer 2 的目标应用场景而言，PCIe A100 的性能已经足够，而其更低的成本则能够显著降低整个集群的建设成本。

1 个 Mellanox CX6 200Gbps IB 网卡为计算节点提供了高速的网络连接，确保节点间的数据传输不会成为瓶颈。2 颗 AMD 32 核 EPYC Rome/Milan CPU 则承担了数据预处理、通信调度等辅助任务，与 GPU 形成互补，共同完成深度学习训练的各项任务。512GB 16 通道 DDR4-3200MHz 内存则为大规模数据的存储和访问提供了充足的容量和带宽。

Fire-Flyer 2 的计算节点采用了 GPU 和网卡直连 CPU 的设计，省去了 PCIe 交换机。这样做的好处是最大程度地利用了 PCIe 带宽，减少了数据传输的延迟和开销。因为数据不需要经过 PCIe 交换机的转发，直接在 GPU、网卡和 CPU 之间传输，从而提高了整体的通信效率。此外，Fire-Flyer 2 还预留了 NVLink 桥接的空间，为未来的扩展留下了余地。如果将来需要更高的 GPU 间通信带宽，可以通过安装 NVLink 桥接器来实现。

与 NVIDIA 的 DGX-A100 系统相比，Fire-Flyer 2 在成本和能耗方面具有显著优势。其节点成本约为 DGX-A100 的 60%，能耗也约为 DGX-A100 的 60%。虽然 PCIe A100 在某些性能测试中略低于 DGX-A100，但考虑到其显著的成本优势，Fire-Flyer 2 无疑具有更高的性价比。

*上面术语太多，做个注释：

SXM版本的A100，更准确地说是A100 SXM4，是NVIDIA A100 Tensor Core GPU为了极致高性能计算和数据中心应用而采用SXM4封装和连接方式的特殊版本，它相比PCIe版本拥有更高的性能潜力、更优的NVLink连接及更高的GPU密度，堪比F1赛车专为赛道驰骋。

而NVIDIA DGX A100系统正是为了充分发挥SXM版本A100的极致性能而设计的高度集成平台，DGX A100必须且只能使用SXM接口的A100 GPU模块，因为SXM接口是实现DGX A100系统内8个A100 GPU通过NVLink高速互联、达到极致AI训练和推理性能的关键，正如高铁列车必须搭载专门设计的高功率发动机才能高速运行，DGX A100系统和SXM A100 GPU是为追求极致性能而生的完美组合，PCIe版本的A100则无法满足DGX A100对GPU互连速度和整体系统性能的苛刻需求。*

4. Fat-Tree 网络：高带宽与精细调优的结合
网络架构对于 HPC 集群的性能至关重要。Fire-Flyer 2 采用了双层 Fat-Tree 网络拓扑，并将存储和计算网络整合在一起。Fat-Tree 拓扑以其高二等分带宽的特性而著称，能够确保集群中任意两个节点之间都能以较高的带宽进行通信，避免了网络拥塞的发生。这种拓扑结构非常适合 AI-HPC 和高吞吐量存储环境对网络带宽的严苛要求。

Fire-Flyer 2 的集群被划分为两个区域，每个区域构成一个 800 端口的 Fat-Tree 网络，连接大约 600 个 GPU 计算节点。这种分区设计不仅降低了网络成本，还支持跨区域任务的执行，提高了集群的灵活性和利用率。

为了防止网络拥塞，Fire-Flyer 2 团队采取了一系列精细的网络调优策略。首先，利用 InfiniBand 的服务级别 (SL) 技术，将不同类型的流量（如控制流量、数据流量、存储流量）分配到不同的虚拟通道 (VL) 中。这就像在高速公路上为不同类型的车辆划分不同的车道，避免了相互干扰，保证了关键流量的优先级。其次，采用静态路由策略，避免了自适应路由 (AR) 可能导致的网络拥塞扩散问题。自适应路由虽然在某些情况下能够提高网络利用率，但在大规模集群中，其动态调整路由的行为可能会导致拥塞的快速蔓延，反而降低整体性能。静态路由则像预先规划好的路线，虽然可能不是在所有情况下都是最优的，但它能够保证网络的稳定性和可预测性。再次，将存储节点、计算节点和管理节点均匀地分布在网络中，使得存储流量能够均匀地分散到各个链路，避免了局部热点的产生。最后，针对 NCCL (NVIDIA Collective Communications Library) 进行了深度优化，调整 NCCL 拓扑，使其优先在同一 NUMA 节点的 IB 网卡和 GPU 之间进行通信，减少跨 NUMA 节点通信带来的 PCIe 拥塞；同时，启用了 PCIe Relaxed Ordering，进一步降低拥塞，提高带宽利用率。

5. HFReduce：通信库的创新，突破 allreduce 瓶颈
在大规模深度学习训练中，allreduce 操作是一个非常频繁且耗时的操作。它负责将所有 GPU 上计算得到的梯度进行汇总，然后更新模型的参数。传统的 allreduce 实现，如 NCCL，虽然已经经过了高度优化，但在 PCIe 架构下，仍然存在一定的性能瓶颈。

为了解决这个问题，Fire-Flyer 2 团队自主研发了 HFReduce 通信库，专门针对 allreduce 操作进行了深度优化。HFReduce 的核心思想是“先局部 reduce，再全局 allreduce”。它巧妙地利用了 CPU 和 GPU 各自的优势。首先，在每个节点内部，利用 CPU 的向量指令（如 AVX512）对节点内所有 GPU 的数据进行快速 reduce 操作。由于 CPU 擅长执行向量化计算，这一步能够非常高效地完成。然后，将每个节点 reduce 后的结果，利用双二叉树算法和 RDMA 传输，进行节点间的 allreduce 操作。双二叉树算法能够有效地减少通信的跳数，降低通信延迟；RDMA 传输则能够直接在节点间进行数据传输，避免了 CPU 的参与，进一步降低了开销。

这种分而治之的策略，使得 HFReduce 相比于 NCCL 具有显著的优势。首先，它大幅降低了 PCIe 带宽的消耗。由于节点内部的 reduce 操作已经在 CPU 上完成，节点间只需要传输 reduce 后的结果，数据量大大减少，从而降低了对 PCIe 带宽的压力。尤其是在大规模集群中，这一优势更加明显。其次，它消除了 GPU 内核的开销。HFReduce 的 reduce 操作完全在 CPU 上进行，不占用宝贵的 GPU 计算资源，避免了 NCCL 的 GPU 内核启动开销，使得 GPU 能够更专注于深度学习模型的计算。

为了进一步提升性能，HFReduce 还支持 NVLink 加速。通过在 PCIe A100 GPU 之间安装 NVLink 桥接器，可以利用 NVLink 的高带宽进行 GPU 之间的预 reduce 操作，进一步减少 PCIe 带宽的压力，然后再将结果传输到 CPU 进行最终的 allreduce。

HFReduce 的实现细节也体现了精益求精的工匠精神。对于小数据量的传输，利用 GDRCopy (GPU Direct RDMA) 技术，直接在 GPU 之间进行数据拷贝，避免了 CPU 的参与，降低了延迟；利用 CPU 的 SIMD (Single Instruction, Multiple Data) 指令，如 AVX512，对 reduce 操作进行向量化加速，充分发挥 CPU 的计算能力；优化内存访问模式，减少跨 NUMA 节点访问内存带来的延迟；利用 RDMA (Remote Direct Memory Access) 技术，实现高效的节点间数据传输，避免额外的 CPU 开销。

6. HaiScale：为深度学习量身打造的训练框架
HaiScale 是 Fire-Flyer 2 AI-HPC 的深度学习训练框架，它不仅仅是一个简单的训练工具，而是针对 PCIe 架构进行了全方位的优化，旨在最大程度地发挥硬件性能，为深度学习训练提供强大的支持。

HaiScale 实现了一个增强版的分布式数据并行 (DDP) 算法。通过异步 allreduce 和反向传播计算的重叠，HaiScale 进一步提高了训练效率。传统的 DDP 算法在进行 allreduce 操作时，需要等待所有 GPU 完成梯度计算，然后才能进行参数更新。HaiScale 则将 allreduce 操作和反向传播计算进行重叠，即在 GPU 计算梯度的同时，就开始进行部分 allreduce 操作，从而隐藏了通信延迟，提高了整体的训练效率。

针对 LLM 训练，HaiScale 提供了多种并行化策略的支持，包括张量并行 (TP)、流水线并行 (PP) 和全分片数据并行 (FSDP)。对于需要高带宽的张量并行操作，HaiScale 支持利用 NVLink 桥接，实现 PCIe GPU 之间的张量并行，提升 TP 效率。对于流水线并行，HaiScale 通过精细的数据并行 rank 配置，错开不同流水线阶段的执行时间，减少网络竞争，提升流水线并行的效率。对于全分片数据并行 (FSDP)，HaiScale 针对 PCIe 架构进行了深度优化，包括高效的内存管理，减少内存碎片，提升内存利用率；以及通信与计算重叠，将参数的通信和计算过程进行重叠，隐藏通信延迟。

除了上述策略外，HaiScale 还支持 ZeRO (Zero Redundancy Optimizer) 等其他并行化策略。用户可以根据不同的模型和训练需求，灵活选择合适的策略，实现最佳的训练效率。HaiScale 的这种灵活性和可扩展性，使得它能够适应各种不同的深度学习训练场景。

7. 存储、资源管理与稳定性：全方位的保障
Fire-Flyer 2 采用了计算-存储一体化网络设计，将计算流量和存储流量融合在同一网络中，简化了网络架构，降低了成本。为了避免网络拥塞，Fire-Flyer 2 采取了前面提到的多种网络调优策略。

在存储方面，Fire-Flyer 2 采用了自主研发的 3FS 分布式文件系统。3FS 针对 NVMe SSD 和 RDMA 网络进行了专门的优化，实现了高吞吐量和低延迟，满足了深度学习训练对存储系统的高要求。3FS 存储节点的配置包括：1 颗 AMD 64 核 EPYC 7742 CPU，512GB 8 通道 DDR4-3200MHz 内存，2 个 Mellanox CX6 200Gbps IB 网卡，以及 16 个 15.36TB PCIe 4.0x4 NVMe SSD。

3FS 的核心技术之一是采用了 Chain Replication with Apportioned Queries (CRAQ) 协议。CRAQ 实现了强一致性和高性能。它将读写操作分离，写操作在链式复制的尾节点执行，读操作可以在任意节点执行，从而提高了读性能。此外，3FS 还通过精细的请求发送控制机制，有效地缓解了网络拥塞，实现了可持续的高吞吐量。

为了进一步提升 LLM 服务的效率和经济性，Fire-Flyer 2 还开发了 3FS-KV 分布式数据处理系统，支持 KV 存储、消息队列和对象存储等多种模式，并支持 DeepSeek 的 KV Context Caching on Disk 技术，可以将 LLM 服务的成本降低一个数量级。

在任务调度和资源管理方面，Fire-Flyer 2 采用了 HAI 平台。HAI 平台采用分时调度策略，根据资源需求和集群负载情况进行任务调度，并鼓励用户进行多 GPU 并行训练，提高资源利用率。

为了保证集群的稳定可靠运行，Fire-Flyer 2 实现了多种机制，包括检查点管理器 (Checkpoint Manager) 和验证器 (Validator)。检查点管理器能够将模型参数和优化器状态分块写入 3FS，实现快速保存和加载，并采用周期性异步保存策略，减少硬件故障带来的损失。验证器则定期检查硬件的运行状态，及时发现潜在问题。

8. 总结与展望：Fire-Flyer AI-HPC 的深远意义
Fire-Flyer 2 AI-HPC 不仅仅是一个高性能计算集群，更是一个深度学习软硬件协同设计的典范。它通过对计算节点、网络架构、通信库、训练框架、存储系统以及资源管理平台的全面优化，实现了深度学习训练的高性能、低成本和可持续性。Fire-Flyer 2 的成功，证明了软硬件协同设计在构建高性价比 AI 基础设施方面的巨大潜力。

Fire-Flyer AI-HPC 的研究成果和实践经验，为 AI-HPC 集群的建设和发展提供了宝贵的参考，也为深度学习的未来发展奠定了坚实的基础。随着深度学习技术的不断演进，Fire-Flyer AI-HPC 也将持续创新，不断探索 AI-HPC 架构的未来，为人工智能的发展贡献力量。

附录
对于NVlink，DeepSeek的研究人员是边用边骂：

B. Discussion about NVLink Technology Choices

Initially, we did not use NVLink to avoid extra costs and maintain stability, as HFReduce was sufficient for training requirements at that time. However, as the demand for LLMs increased, we added NVLink specifically for LLM training purposes. The decision to install NVLink should be based on actual needs due to its potential drawbacks。

还在附录里列出了关键的典型错误：

IB网络也被吐槽的体无完肤，这也许是之前英伟达股票狂跌的原因之一吧

而且仔细想一想，结合后面DeepSeek V3的论文中专门强调了对于内存读写和网络框架及驱动的优化内容（甚至用了PTX），并且被误解为要取代CUDA。就知道他们是在踩坑的同时填坑，填完了坑才有了这种软硬件一体化设计的论文公开。

参考论文： arXiv:2408.14158v2 [cs.DC] 31 Aug 2024

原文链接

有图片都在原文里，有兴趣的可以看看。

WiFi · 发表于 4 天前

我从来没有称呼过没有教过我的人老师。看完后，我尊尊敬敬的称一声：谢谢，谢老师。解惑了。
同时也让我对喷DS只是蒸馏了OpenAI的人及其不屑。

晨枫 · 发表于 4 天前

本帖最后由晨枫于 2025-2-7 20:57 编辑

我也从来没有称呼过没有教过我的人老师。看完后，我尊尊敬敬的称一声：谢谢，谢老师。不过没有解惑，因为没看懂。隔行如隔山，也就不勉强弄懂了。还是要多谢解释。

问题：

这里提到的A100，和英伟达的A100卡不是一回事吧？

最大的问题：这样的做法在scalability和transportability方面有什么长处、短处？因为没有看懂，所以还是没有解答最初的疑问：如果换GPU，换模型架构，或者极大增大模型尺寸，这套架构需要推倒重来吗？

这是case by case optimization，还是scalable and transportable framework not only in terms of concept but also toolset？

xiejin77 · 发表于 4 天前

晨枫发表于 2025-2-8 10:55
& S/ g4 M1 Q( f; D我也从来没有称呼过没有教过我的人老师。看完后，我尊尊敬敬的称一声：谢谢，谢老师。不过没有解惑，因为没 ...

晨大你这么说我可当不起，看你文章十几年了。

这里说的A100，就是英伟达的芯片。基于A100的芯片设计的有不同接口的卡。SXM的满血卡可以组成DGX a100。

火烈鸟的这套框架体系，我的理解，是可以作为相对底层的基础设施优化的，不算是定制的。但是具体到用PTX的手段，就是和硬件相关的了。这是两件事情，框架和架构是相对通用的，但底层的针对性修正是case by case的。

我深度的梳理一下，争取能让晨大理解：

这套架构既包含了 case-by-case optimization，又提供了 scalable and transportable framework，在概念和工具集方面都具有可扩展性和可移植性。

1. Case-by-Case Optimization 的部分

硬件选择: Fire-Flyer 2 选择了 PCIe A100 GPU，这是在性能、成本和功耗之间针对特定训练场景 (早期 LLM 和其他深度学习模型) 做出的权衡。如果是不同的应用场景，比如需要极高的 GPU 间带宽，可能会选择 SXM A100 或者其他加速器。
HFReduce 针对 PCIe 架构优化: HFReduce 通信库的核心优化是利用 CPU 进行节点内 reduce，减少 PCIe 带宽压力。这种优化是特定于 PCIe 架构的。如果底层是 NVLink-only 的架构 (如 DGX A100)，HFReduce 的优势就不明显，甚至可能不如 NCCL。
网络调优: 流量隔离、静态路由、节点均匀分布、NCCL 优化等，这些都是根据特定网络拓扑 (双层 Fat-Tree) 和特定流量模式 (深度学习训练) 进行的调优。
3FS文件系统优化: 存储系统的设计和优化是根据硬件（NVMe SSD, RDMA网络）来优化的

2. Scalable and Transportable Framework 的部分

核心设计理念 (Scalable Concept): Fire-Flyer AI-HPC 的核心是软硬件协同设计。这种理念是通用的，可以应用于不同的硬件平台和不同的深度学习任务。无论底层硬件是 GPU、TPU 还是其他 AI 加速器，都可以通过软硬件协同设计来最大化性能、降低成本、提高能效。
HaiScale 训练框架 (Transportable Toolset): HaiScale 支持多种并行化策略 (DDP, TP, PP, FSDP, ZeRO)，这使得它可以适应不同规模的模型和不同的训练需求。框架本身是可移植的，理论上可以移植到其他硬件平台 (如 AMD GPU)，只需要针对新平台进行适配和优化。
模块化设计: Fire-Flyer AI-HPC 的各个组件 (计算节点、网络、存储、通信库、训练框架) 是相对独立的，可以根据需要进行替换或升级。这种模块化设计提高了架构的可扩展性和可维护性。
HAI 平台 (Scalable Management): HAI 平台提供了任务调度和资源管理功能，可以支持大规模集群的部署和管理。平台本身是可扩展的，可以适应不同规模的集群。
HFReduce通信库的设计理念（Transportable concept)：虽然HFReduce现在是为PCIe优化，但它的设计思想，先本地聚合，再全局聚合，是可以移植到其他异构硬件架构的。

总的看来，Fire-Flyer AI-HPC 架构既有针对特定硬件和场景的优化，也有通用的设计理念和可移植的工具集。它展示了DS如何通过软硬件协同设计来构建高性价比的 AI 计算平台。虽然某些优化是特定于 Fire-Flyer 2 的具体实现的，但其核心思想和方法可以推广到其他 AI-HPC 架构的设计中。换句话说，它提供了一个框架和方法论，而不仅仅是一个孤立的案例。

xiejin77 · 发表于 4 天前

WiFi 发表于 2025-2-8 09:05
; F5 E# h: Q1 J, R/ N4 H我从来没有称呼过没有教过我的人老师。看完后，我尊尊敬敬的称一声：谢谢，谢老师。解惑了。
+ F5 I+ b# x, H, ?: K0 H8 f, I) l同时也让我对 ...

wifi老师，您过奖了。咱们一同学习交流吧

		自动登录	找回密码
密码			注册

[科技前沿] Fire-Flyer AI-HPC：DS使用PTX原因的佐证

评分

评分