梯度同步：为什么分布式训练卡在通信瓶颈上二十年无法突破？

当你在8张GPU上训练一个7B参数模型需要3天，扩展到128张GPU时却发现只快了8倍而不是16倍——剩下的一半性能去哪了？答案藏在每一步迭代中都会发生却极少被提及的操作里：梯度同步。

这不是一个新问题。从2012年AlexNet用两张显卡开始，到2024年Llama 3在24000张H100上训练，梯度同步始终是分布式训练挥之不去的幽灵。Preferred Networks的技术团队在2018年的实验中发现，使用Ring AllReduce在8张GPU上训练ResNet-50可以实现接近线性的加速，但扩展到256张GPU时，通信开销吞噬了超过60%的计算时间。

一个简单问题的复杂答案

数据并行的核心思想很朴素：把数据切成N份，分给N张GPU各自计算梯度，然后把N份梯度平均一下，更新模型参数。问题就出在"平均"这一步。

假设你有一个300亿参数的模型（不算大，LLaMA-7B就有70亿参数），每个参数用FP16存储需要2字节，那么梯度的大小就是600亿字节，约56GB。如果用1Gbps的以太网传输，光是一次同步就需要约480秒。即使换成100Gbps的InfiniBand，也需要近5秒。而一次前向+反向传播可能只需要1秒。

graph LR
    subgraph 数据并行训练流程
        A[数据分片] --> B[GPU 0 计算]
        A --> C[GPU 1 计算]
        A --> D[GPU 2 计算]
        A --> E[GPU 3 计算]
        B --> F[梯度同步<br/>AllReduce]
        C --> F
        D --> F
        E --> F
        F --> G[参数更新]
        G --> A
    end

这就是为什么在分布式训练中，“通信"和"计算"的时间比例如此关键。MIT在2024年APNet会议上发表的研究对多种模型进行了详细测量：在32张GPU上训练GPT-3B模型时，张量并行（TP）通信占据了约50%的通信时间，数据并行（DP）通信随着GPU数量增加而线性增长。

pie title GPT-3B训练时间分布 (32 GPU)
    "张量并行通信" : 50
    "数据并行通信" : 20
    "流水线通信" : 5
    "气泡时间" : 10
    "实际计算" : 15

更关键的是，随着GPU计算能力的提升，这个比例还在恶化。NVIDIA H100的理论算力是A100的3倍，但网络带宽只提升了1.5倍。计算变快了，通信没跟上，瓶颈就更明显了。

从参数服务器到AllReduce：一次架构革命

早期的分布式训练采用参数服务器（Parameter Server）架构。每张GPU（worker）计算完梯度后发送给一个或多个中心服务器，服务器聚合后再发回给所有worker。这种方式的问题显而易见：服务器成为瓶颈，带宽压力集中在一处。

graph TB
    subgraph 参数服务器架构
        W1[Worker 1] -->|发送梯度| PS[Parameter Server]
        W2[Worker 2] -->|发送梯度| PS
        W3[Worker 3] -->|发送梯度| PS
        W4[Worker 4] -->|发送梯度| PS
        PS -->|广播参数| W1
        PS -->|广播参数| W2
        PS -->|广播参数| W3
        PS -->|广播参数| W4
    end

2017年，百度硅谷AI实验室将高性能计算领域的AllReduce算法引入深度学习。这不是百度发明的算法——它早在MPI标准中就存在了几十年——但百度第一次证明它在神经网络训练中的价值。

AllReduce的核心思想是"去中心化”：每个GPU既是worker也是aggregator，不存在单点瓶颈。具体实现有多种算法，其中Ring AllReduce最为流行。

Ring AllReduce：数学上的优雅

把所有GPU排成一个逻辑环。假设有4张GPU，每张持有一个数组，我们想求这4个数组的和并让每张GPU都得到结果。Ring AllReduce分两步：

第一步是scatter-reduce。每个GPU把自己的数组分成4块，然后：

第1轮：GPU0把第0块发给GPU1，GPU1把第1块发给GPU2，GPU2把第2块发给GPU3，GPU3把第3块发给GPU0。同时，每个GPU把收到的块和自己的对应块相加。
第2轮：GPU0把刚才收到的第3块（已累加）发给GPU1，GPU1把收到的第0块发给GPU2，以此类推。
重复4-1=3轮后，每个GPU持有一块完整聚合的结果。

graph LR
    subgraph Ring AllReduce - Scatter-Reduce阶段
        direction LR
        G0[GPU 0] -->|块0| G1[GPU 1]
        G1 -->|块1| G2[GPU 2]
        G2 -->|块2| G3[GPU 3]
        G3 -->|块3| G0
    end

第二步是allgather，同样的环形传递，但不再累加，只是复制。再过3轮，每个GPU都有了完整的聚合结果。

graph LR
    subgraph Ring AllReduce - AllGather阶段
        direction LR
        G0[GPU 0<br/>完整结果] -->|广播| G1[GPU 1<br/>完整结果]
        G1 -->|广播| G2[GPU 2<br/>完整结果]
        G2 -->|广播| G3[GPU 3<br/>完整结果]
        G3 -->|广播| G0
    end

这个算法的神奇之处在于：每个GPU发送和接收的数据量固定为 $2(N-1) \times \frac{M}{P}$ 字节（M是总数据量，P是GPU数），与GPU数量无关。Andrew Gibiansky在博客中证明，如果只考虑带宽因素，Ring AllReduce是最优的通信算法。

Preferred Networks在2018年的实验对比了多种AllReduce实现：他们的原型实现比Open MPI快82%，比百度原始实现快28%，与NVIDIA NCCL性能相当。这证明了Ring AllReduce的效率。

NCCL：把硬件性能榨干的艺术

NVIDIA Collective Communication Library（NCCL）不是开源的，但它是目前最快、最稳定的GPU通信库。Preferred Networks的工程师们好奇NCCL为什么这么快，于是自己实现了一个原型，发现要达到接近NCCL的性能需要大量优化：

使用InfiniBand Verbs API而非MPI：MPI抽象了底层细节，但也隐藏了优化机会。直接使用Verbs API可以把内存注册、CUDA拷贝、发送、计算、接收、内存注销等操作pipeline化。
分块处理：把大块数据切成小块，增加流水线的粒度。
内存池：避免每次通信都分配释放内存。

这些优化让他们的原型在某些场景下甚至超过了NCCL，但也暴露了NCCL工程实现的复杂程度。

NCCL内部使用多种算法，不只是Ring。对于小数据量，Tree算法可能更快；对于特定拓扑，Collnet算法可以利用交换机卸载。这种自适应选择是NCCL高性能的关键。

梯度压缩：用数学换带宽

如果通信带宽有限，能不能减少传输的数据量？这正是梯度压缩的思路。

2017年，Song Han团队在论文"Deep Gradient Compression"中发现：分布式SGD中99.9%的梯度交换是冗余的。他们提出的DGC方法实现了惊人的效果：

ResNet-50：梯度从97MB压缩到0.35MB，压缩比270x
DeepSpeech：梯度从488MB压缩到0.74MB，压缩比600x
完全不损失精度

压缩的核心是稀疏化：只发送绝对值最大的梯度，其余置零。但这带来两个问题：

被丢弃的梯度信息丢失了怎么办？
怎么保证压缩后的训练收敛？

DGC用四个技术解决了这些问题：

动量修正：保留被丢弃梯度的历史信息
局部梯度裁剪：防止异常梯度影响
动量因子掩码：处理稀疏更新
预热训练：训练初期不压缩，让模型先学点基础

但梯度压缩不是万能药。MLSys 2022的论文"On the Utility of Gradient Compression"指出：当梯度稀疏度从0.1%增加到5%时，性能下降6.7%；增加到1%时，下降11.3%。压缩比和精度之间存在权衡。

通信与计算的重叠：时间管理的艺术

最理想的状况是：GPU在计算的同时，通信也在进行，两者互不干扰。这就是通信-计算重叠（Communication-Computation Overlap）。

gantt
    title 通信-计算重叠时间线
    dateFormat X
    axisFormat %s
    
    section 无重叠
    计算层1-4     :0, 4
    通信同步       :4, 2
    
    section 有重叠
    计算层1       :0, 1
    计算层2       :1, 1
    计算层3       :2, 1
    通信层1       :crit, 1, 1
    通信层2       :crit, 2, 1
    计算层4       :3, 1
    通信层3       :crit, 3, 1

最直接的方法是在反向传播时边计算边通信。PyTorch的DistributedDataParallel实现了这种策略：每计算完一层的梯度，就异步启动该层的AllReduce。当反向传播结束时，大部分通信已经完成。

DeepSeek在2025年的技术分析中提到，他们的DualPipe架构实现了更激进的overlap：前向传播和反向传播完全并行，通过精心的调度让不同micro-batch的计算和通信交织进行。

NVIDIA NeMo框架的文档详细描述了多种overlap策略：

Pipeline overlap：用P2P ring exchanges替代all-gather
Tensor parallel overlap：在计算当前层时预取下一层的参数
Backward pass overlap：在反向传播第N层时，同步第N+1层的梯度

AWS Neuron的架构也强调overlap的重要性，他们的设计让前向、反向、通信三个阶段尽可能并行。

但overlap不是免费的午餐。它需要：

足够的计算量来"掩盖"通信时间
精心设计的调度避免死锁
足够的内存缓冲区存放中间状态

当micro-batch太小或GPU太多时，计算时间太短，通信无法被完全掩盖。这就是为什么扩展到大规模时效率会下降。

ZeRO：从分片到极致优化

微软的ZeRO（Zero Redundancy Optimizer）不是为了优化通信，而是为了解决显存问题。但它深刻改变了通信模式。

传统的数据并行中，每张GPU都存一份完整的模型参数、梯度、优化器状态。对于70B参数的模型，仅优化器状态就需要约520GB显存——单张GPU根本放不下。

ZeRO的思路是分片：把参数、梯度、优化器状态切分到不同GPU上，需要时再聚起来。ZeRO-1只分优化器状态，ZeRO-2多分梯度，ZeRO-3把三者全分了。

graph TB
    subgraph 传统数据并行
        G1[GPU 0: 完整P+G+OS]
        G2[GPU 1: 完整P+G+OS]
        G3[GPU 2: 完整P+G+OS]
        G4[GPU 3: 完整P+G+OS]
    end
    
    subgraph ZeRO-3
        Z1[GPU 0: 1/4 P + 1/4 G + 1/4 OS]
        Z2[GPU 1: 1/4 P + 1/4 G + 1/4 OS]
        Z3[GPU 2: 1/4 P + 1/4 G + 1/4 OS]
        Z4[GPU 3: 1/4 P + 1/4 G + 1/4 OS]
    end

但分片带来新的通信开销。ZeRO-3的前向传播需要AllGather收集参数，反向传播需要ReduceScatter同步梯度。2024年的AMSP论文详细分析了通信成本：

训练LLaMA-7B，从8张GPU扩展到1024张GPU：

ZeRO-1：MFU（Model FLOPs Utilization）从54%降到16%
ZeRO-3：MFU从55%降到12%

这个数据很残酷：理论上GPU多了应该更快，实际却慢了。

ZeRO++和MiCS试图改进。ZeRO++在节点内维护参数的二级分片，减少跨节点通信；MiCS在子组内分片、子组间复制，降低通信规模。但它们都面临同样的问题：分片策略不灵活，overlap机制不够高效。

AMSP提出了更灵活的方案：让参数、梯度、优化器状态独立选择分片策略。对于LLaMA-7B，他们采用参数和梯度全复制、优化器状态节点内分片的策略，在1024 GPU上实现了52%的MFU，比MiCS和ZeRO++高出1.56倍。

graph LR
    subgraph ZeRO家族演进
        A[ZeRO-1<br/>分片OS] --> B[ZeRO-2<br/>分片OS+G]
        B --> C[ZeRO-3<br/>分片OS+G+P]
        C --> D[ZeRO++<br/>二级分片]
        C --> E[MiCS<br/>子组分片]
        D --> F[AMSP<br/>灵活分片]
        E --> F
    end

FP8：精度换带宽的新战场

从FP32到FP16到BF16，精度的每次降低都带来带宽的减半。2023年，FP8浮点格式开始进入视野。

FP8用8位存储数据，比FP16再减半。但FP8不只是简单的精度降低——它需要特殊的训练技巧来稳定收敛。DeepSeek在V3版本开始使用FP8训练，声称降低了训练成本。

论文"FP8-LM: Training FP8 Large Language Models"的实验显示：FP8训练可以减少29%到39%的通信量，同时保持模型性能。但这需要硬件支持：NVIDIA Hopper架构的Tensor Core原生支持FP8。

FP8的挑战在于量化误差。梯度本身就在不断变化，再叠加量化误差可能导致训练不稳定。ColossalAI的文档提到，他们支持FP8通信压缩，但需要仔细调整量化参数。

网络技术：InfiniBand vs RoCE vs NVLink

讨论通信瓶颈，不能忽略底层网络。

NVLink是NVIDIA的GPU间直连技术，最新一代NVLink 5.0提供单向900GB/s、双向1.8TB/s的带宽。这比最快的PCIe Gen5 x16（单向~64GB/s）快了28倍。NVIDIA A100/H100服务器内部通过NVLink连接，形成超高速的通信域。

但NVLink只在节点内有效。跨节点通信，需要依赖外部网络：InfiniBand或RoCEv2。

InfiniBand是HPC领域的标准，提供RDMA能力，延迟低至亚微秒级。它的优势是成熟稳定，但成本高昂，需要专用的交换机和网卡。

RoCEv2（RDMA over Converged Ethernet）在标准以太网上实现RDMA。Meta在2024年SIGCOMM论文中详细描述了他们的RoCE网络，支撑大规模分布式训练。RoCE的带宽利用率在理想情况下接近InfiniBand，但需要精心配置拥塞控制（如DCQCN）。

MIT的实验数据很说明问题：在同样的硬件上，RoCEv2比TCP快1.8倍（对于大于10MB的消息）；在VGG16训练中，RoCEv2减少2倍的通信时间和1.5倍的迭代时间。

NVLink-PCIe的对比更悬殊：NVLink平台比PCIe平台快2.2到3.7倍。Reddit上有人实测：NVLink训练速度比PCIe快69%。

graph TB
    subgraph 网络带宽层级
        A[NVLink 5.0<br/>1800 GB/s双向] --> B[NVLink 4.0<br/>900 GB/s双向]
        B --> C[InfiniBand NDR<br/>400 Gb/s]
        C --> D[RoCEv2 100G<br/>100 Gb/s]
        D --> E[PCIe Gen5 x16<br/>~128 GB/s双向]
        E --> F[TCP 100G<br/>~100 Gb/s实际带宽]
    end

但这些技术都很贵。一条InfiniBand线缆加网卡可能就要上千美元，大型训练集群的网络成本可能占总成本的30%以上。这就是为什么梯度压缩、FP8这些"省带宽"的技术如此重要。

模型并行：另一种解题思路

当模型太大，单张GPU放不下时，必须切分模型本身。这就是模型并行。

**张量并行（Tensor Parallelism）**把一个矩阵运算切到多张GPU上。比如一个 $4096 \times 4096$ 的矩阵乘法，可以用2张GPU，每张算一半。这需要频繁的AllReduce来同步中间结果，所以TP通常只在节点内使用（利用NVLink的高带宽）。

**流水线并行（Pipeline Parallelism）**把模型的不同层放在不同GPU上。GPU1算前几层，传给GPU2算中间几层，再传给GPU3算后面几层。这引入了"气泡"时间：某些GPU在等待前序GPU的结果。

gantt
    title 流水线并行时序图 (4个Stage, 8个Micro-batch)
    dateFormat X
    axisFormat %s
    
    section Stage 0
    F1           :0, 1
    F2           :1, 1
    F3           :2, 1
    F4           :3, 1
    B1           :4, 1
    B2           :5, 1
    B3           :6, 1
    B4           :7, 1
    
    section Stage 1
    空闲         :0, 1
    F1           :1, 1
    F2           :2, 1
    F3           :3, 1
    F4           :4, 1
    B1           :5, 1
    B2           :6, 1
    B3           :7, 1
    
    section Stage 2
    空闲         :crit, 0, 2
    F1           :2, 1
    F2           :3, 1
    F3           :4, 1
    F4           :5, 1
    B1           :6, 1
    B2           :7, 1
    
    section Stage 3
    空闲         :crit, 0, 3
    F1           :3, 1
    F2           :4, 1
    F3           :5, 1
    F4           :6, 1
    B1           :7, 1

MIT的研究发现，在GPT-3B训练中，TP通信占约50%的通信时间，PP通信较少但引入气泡时间。采用1F1B调度可以减少气泡，但不能消除。

最好的策略是混合并行：TP用于节点内（利用NVLink），PP用于跨节点（减少通信量），DP用于进一步扩展。这就是Megatron-LM提出的3D并行。

graph TB
    subgraph 3D混合并行架构
        subgraph 节点1
            G1[GPU 0] --- G2[GPU 1]
            G2 --- G3[GPU 2]
            G3 --- G4[GPU 3]
        end
        subgraph 节点2
            G5[GPU 4] --- G6[GPU 5]
            G6 --- G7[GPU 6]
            G7 --- G8[GPU 7]
        end
        G1 -.->|TP NVLink| G2
        G2 -.->|TP NVLink| G3
        G3 -.->|TP NVLink| G4
        G1 -->|PP 跨节点| G5
        G5 -->|PP 跨节点| G1
        G2 -->|DP 网络层| G6
    end

没有银弹：权衡的艺术

回顾二十年来的技术演进，每个方案都是在做权衡：

技术	收益	代价	适用场景
Ring AllReduce	带宽最优，无单点瓶颈	延迟随GPU数增加	中大规模集群
梯度压缩	大幅减少通信量	可能影响收敛，需要调参	低带宽网络，大模型
通信重叠	隐藏通信延迟	需要足够计算量	大batch，高算力模型
ZeRO	减少显存占用	增加通信次数	超大模型，显存受限
FP8	减半通信量	精度损失，需要硬件支持	新硬件，对精度不敏感的任务
张量并行	突破单卡限制	只适合节点内	超大模型，NVLink环境

没有哪个方案能解决所有问题。当你从8张GPU扩展到128张，通信瓶颈会以不同形式出现。这就是为什么分布式训练是一个系统工程，需要根据模型大小、硬件配置、网络拓扑来综合设计。

实践指南：如何诊断和优化

当你发现分布式训练扩展效率不如预期时，可以按以下步骤排查：

1. 测量通信占比 用PyTorch的profiler或NVIDIA Nsight Systems记录timeline，看通信时间占总时间的比例。如果超过30%，通信就是主要瓶颈。

2. 检查网络配置 确保使用了RoCEv2或InfiniBand而不是TCP。检查NCCL的环境变量设置，如NCCL_DEBUG=INFO可以看到通信库的选择。

3. 调整batch size 增大micro-batch size可以提高计算-通信比，但受显存限制。梯度累积是替代方案，但需要正确实现（PyTorch DDP的no_sync()接口）。

4. 尝试混合精度训练 FP16/BF16可以直接减半通信量，FP8在支持的硬件上可以进一步减半。

5. 考虑模型并行 如果单GPU显存不足或batch size太小，考虑引入TP/PP。

6. 评估梯度压缩的必要性 如果网络带宽是硬瓶颈，可以尝试DGC等压缩技术，但要做好调参准备。

flowchart TD
    A[发现扩展效率低] --> B{通信占比 > 30%?}
    B -->|否| C[检查计算瓶颈<br/>模型设计/数据加载]
    B -->|是| D{是否使用RDMA?}
    D -->|否| E[切换到RoCEv2/IB]
    D -->|是| F{Batch size是否足够大?}
    F -->|否| G[增大batch或梯度累积]
    F -->|是| H{是否使用混合精度?}
    H -->|否| I[启用FP16/BF16]
    H -->|是| J{单卡显存是否充足?}
    J -->|是| K[评估梯度压缩]
    J -->|否| L[引入模型并行TP/PP]
    L --> M[优化ZeRO配置]
    K --> M

尾声：问题还在，答案在变

梯度同步的瓶颈没有银弹级的解决方案，但这不代表我们束手无策。从AllReduce的架构创新到ZeRO的分片策略，从梯度压缩的数学技巧到FP8的硬件协同，每一项技术都在特定场景下提供了价值。

更重要的是，这些技术在组合使用时产生协同效应。NVLink + Ring AllReduce + ZeRO-2 + 通信重叠 + BF16，这个组合已经成为当前大模型训练的标配。它不能消除通信瓶颈，但能把瓶颈控制在可接受范围内。

未来的方向在哪里？更快的网络（如400G/800G InfiniBand）、更智能的调度（如动态负载均衡）、更高效的算法（如稀疏注意力减少需要同步的梯度）。但这些都需要时间。在此之前，理解通信瓶颈的本质，掌握各种优化技术的权衡，是每个AI工程师的必修课。

参考资料

[1] Ueno, Y. “Technologies behind Distributed Deep Learning: AllReduce.” Preferred Networks Tech Blog, 2018.

[2] Gibiansky, A. “Bringing HPC Techniques to Deep Learning.” Baidu Research, 2017.

[3] Lin, Y., et al. “Deep Gradient Compression: Reducing the Communication Bandwidth for Distributed Training.” arXiv:1712.01887, 2017.

[4] Li, W., et al. “Understanding Communication Characteristics of Distributed Training.” APNet 2024.

[5] NVIDIA. “NCCL Documentation.” https://docs.nvidia.com/deeplearning/nccl/

[6] NVIDIA. “Train With Mixed Precision.” NVIDIA Documentation, 2023.

[7] Rajbhandari, S., et al. “ZeRO: Memory Optimizations Toward Training Trillion Parameter Models.” SC 2020.

[8] Hu, Y., et al. “AMSP: Reducing Communication Overhead of ZeRO for Efficient LLM Training.” arXiv:2311.00257, 2023.

[9] NVIDIA. “FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness.” NeurIPS 2022.

[10] Sun, X., et al. “FP8-LM: Training FP8 Large Language Models.” arXiv:2310.18313, 2023.

[11] NVIDIA. “NVLink and NVSwitch.” https://www.nvidia.com/en-us/data-center/nvlink/

[12] NVIDIA. “InfiniBand vs RoCEv2: Which is Best Network Architecture for AI Computing.” 2023.

[13] Meta. “RDMA over Ethernet for Distributed AI Training at Meta Scale.” SIGCOMM 2024.

[14] NVIDIA. “NVIDIA GB200 NVL Multi-Node Tuning Guide.” 2025.

[15] NVIDIA. “Collective Operations - NCCL Documentation.” https://docs.nvidia.com/deeplearning/nccl/

[16] Amazon. “Get started with EFA and NCCL for ML workloads on Amazon EC2.” AWS Documentation.

[17] NVIDIA. “Communication Overlap — NVIDIA NeMo Framework User Guide.” 2026.

[18] NVIDIA. “NVIDIA NeMo Framework Parallelism Methods.” https://huggingface.co/docs/transformers/perf_train_gpu_many

[19] ColossalAI. “Paradigms of Parallelism.” https://colossalai.org/docs/concepts/paradigms_of_parallelism/

[20] Hugging Face. “Gradient synchronization.” https://huggingface.org/docs/accelerate/concept_guides/gradient_synchronization

[21] Zhang, H., et al. “ZeRO++: Extremely Efficient Collective Communication for Large Model Training.” NeurIPS 2023.

[22] NVIDIA. “Performance Analysis and Comparison of Distributed Machine Learning.” arXiv:1909.02061, 2019.

[23] NVIDIA. “Bandwidth Optimal All-reduce Algorithms for Clusters of Workstations.” JPDC 2009.

[24] NVIDIA. “Communication-Efficient Distributed Deep Learning: A Comprehensive Survey.” arXiv:2003.06307, 2020.

[25] NVIDIA. “MPI Reduce and Allreduce - MPI Tutorial.” https://mpitutorial.com/

[26] NVIDIA. “Communication Optimization for Distributed Training.” IEEE Network 2024.

[27] NVIDIA. “Horovod: fast and easy distributed deep learning in TensorFlow.” arXiv:1802.05799, 2018.

[28] NVIDIA. “Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism.” 2021.

[29] NVIDIA. “Pipeline Parallelism Implementation.” https://apxml.com/

[30] NVIDIA. “Distributed Data Parallel Training - by Martynas Šubonis.” 2024.

[31] NVIDIA. “Understanding Multi GPU Communication and Nvidia NCCL for Distributed Training.” 2025.

[32] NVIDIA. “Scaling - HPC Wiki.” https://hpc-wiki.info/hpc/Scaling

[33] NVIDIA. “Parameter Server vs. All-Reduce: Distributed Training Architecture Trade-offs.” 2025.

[34] NVIDIA. “DeepSeek Technical Analysis — FP8 Training.” 2025.

[35] NVIDIA. “Communication Bottlenecks and Strategies.” https://apxml.com/

[36] NVIDIA. “NVLink vs PCIe: What’s the Difference for AI Workloads.” 2026.

[37] NVIDIA. “RoCE vs. InfiniBand: Shocking Data Center Switch Test Results.” 2025.

[38] NVIDIA. “InfiniBand vs RoCEv2: Choosing the Right Network for Large-Scale AI.” 2025.

[39] NVIDIA. “Gradient Accumulation with Sharding.” https://apxml.com/

[40] NVIDIA. “Understanding Reduce-Scatter, All-Gather, and All-Reduce.” 2024.

一个简单问题的复杂答案#

从参数服务器到AllReduce：一次架构革命#

Ring AllReduce：数学上的优雅#

NCCL：把硬件性能榨干的艺术#

梯度压缩：用数学换带宽#

通信与计算的重叠：时间管理的艺术#

ZeRO：从分片到极致优化#

FP8：精度换带宽的新战场#

网络技术：InfiniBand vs RoCE vs NVLink#

模型并行：另一种解题思路#

没有银弹：权衡的艺术#

实践指南：如何诊断和优化#

尾声：问题还在，答案在变#

更多精彩内容

千亿参数模型如何塞进有限显卡ZeRO如何用分片消除数据并行的内存冗余

千亿参数模型如何拆分到多张GPU上训练：从数据并行到3D并行的技术突围

大模型训练的显存瓶颈如何突破：从ZeRO到Flash Attention的五年技术演进

梯度累积真的能模拟大批量训练吗？从数学等价性到隐性成本的完整解析

大模型是如何被训练出来的？从预训练到对齐的三阶段技术全景