跑个 GPT-2 小模型，单卡显存直接爆掉——你怎么办？
加卡呗，可事情哪有这么简单。说实话，我第一次搞多卡训练时，天真地以为把数据分一分、模型拷一拷就完事了，结果性能掉成渣。那感觉，就像买了辆十二缸的跑车，却只敢在小区里用一档溜达。后来才发现，分布式训练这玩意儿，骨子里是一场通信与计算的量子纠缠。
——对，是纠缠，不是简单相加。这里面藏着一大堆让硬件流泪、让程序员头秃的细节。但一旦搞通了，几千张卡齐刷刷轰鸣起来的时候……啧，那种算力压榨干净的快感，确实让人上瘾。
拆解同步的舞蹈：AllReduce 与模型切分的底层美学
你肯定听过数据并行。每个 GPU 拿一份数据副本，各自前向反向，然后——梯度需要同步。同步这一步，千百个浮点数怎么高效地让所有卡都知道？不是毛毛躁躁地广播一通，那是暴殄天物。真正的做法，叫 Ring AllReduce。
想象一个环形拓扑，N 张 GPU 首尾相连。梯度数据被切成 N 个小块，大家同时往下一个邻居塞一块，自己手里攒着别人的一块。一圈下来，每个 GPU 都集齐了所有卡的部分和，再转半圈，全部规约成完整梯度。时间复杂度 O(N)，带宽利用率极高——这跟小时候玩的传话游戏根本不是一回事，它是精确的、流水线化的数学。
具体实现上，英伟达的 NCCL 库把这事玩出了花：GPU Direct RDMA 避免内存拷贝，显存到网卡直接飞过去；还针对各种拓扑做了树形或环形算法切换。但别以为这就稳了，通信总有个启动延迟，几百微秒的忙等能让你的 GPU 核心打瞌睡。于是大厂们折腾出了一套套重叠术：把梯度通信藏进反向传播的计算里，用 CUDA 流搞异步，梯度累加再同步……高手过招，争的就是那几毫秒的缝隙。
但数据并行有个硬伤：模型本身太大，单卡塞不下。这时候得上模型并行。模型并行又分两种流派：朴素的按层切分（流水线并行），和狠辣的张量切分（Tensor Parallelism）。后者是 Megatron-LM 带火的招数——把 Transformer 里的权重矩阵按行或列一刀切，每张卡算完一小块矩阵乘法，再聚合。比如自注意力的 QKV 投影，切了列以后，每张卡输出部分维度，最后 AllReduce 一下。推导过一遍，你会发现通信量跟模型大小增长得没那么快，这就很美妙了。数学上它就是一个分块矩阵乘法的工程化，但背后对通信库的优化要求极高，甚至要自己写 CUDA kernel 来拼合计算。初看代码，满屏的 ncclSend、ncclRecv 和 reshape，仿佛现代艺术。
压测数据说话：从 8 卡到千卡的线性加速幻象
理论很丰满，实测呢？我们团队用 8 张 A100 跑 ResNet-50，数据并行，单卡每秒 312 张图，8 卡一上去——才 2200 张，加速比 7.05x。丢掉的近 1x 去哪了？全耗在同步上了。微调了 NCCL 的 minBytes 和 maxBytes 参数，把通信粒度调大，总算压到了 7.6x。但这还没到顶。换成 Ring AllReduce 替换原本的树形算法，在跨节点场景下延迟又降了 30%。
更刺激的是大模型。训练一个 13B 参数的网络，单卡 A100 直接 OOM。用 4 卡张量并行，勉强跑起来，每卡吞吐 12 token/s。加上流水线并行，切成 2 个 stage，4 卡前排 4 卡后排，吞吐飙到 19 token/s——却冒出了“气泡”：前面算着，后面干等，整体利用率才 55%。再进一步，把微批次（micro-batch）塞进去，叠上 1F1B 调度，利用率爬到 78%，总算像个样子。这时候看 NVIDIA 的论文，他们能在千卡规模把效率做到 90% 以上，你就知道差距。
这些数字背后，全是真金白银砸出来的经验。有个同行用 InfiniBand 做多机扩展，误用了 TCP over IB，结果带宽折半，痛哭流涕。后来换上 RDMA 和 GDR，才把 16 卡提升到接近线性。我还见过有人用 RoCE v2，丢包率 0.01% 就被整怕了——重传一多，梯度同步慢得像便秘，直接带崩整个训练集群。所以网络选型，必须看真实的端到端带宽和尾延迟，别只盯着标称值。
趟过三个深坑：我的血泪踩坑指南
坑一：通信与计算的重叠之术，一不留神就翻车
很多人以为用了 PyTorch 的 DistributedDataParallel，自动就好了。天真。默认情况下，反向传播算完一层梯度才开始通信，GPU 傻等。你得手动把那该死的通信提前——用 async 操作，注册 hook，或者直接上 fused 版本。我们组花了整整两周调 CUDA 流，把通信下沉到计算图中，才把每步的训练时间从 320ms 砍到 290ms。那 30ms 的收益，抵得上三张卡的算力。记住：永远检查 nvidia-smi 的 GPU-Util 是不是在通信间隙掉下来，掉下来就是罪过。
坑二：数据负载不均衡，卡王拖死全班
变长序列是分布式训练的致命杀手。NLP 任务里，一句“好的”和一篇论文，padding 后长度能差 30 倍。如果你简单按 batch 分配，总有一个倒霉的 GPU 分到全是长序列，计算时间比别人多出好几倍，其他卡就干瞪眼。我们被这坑惨过，单步耗时标准差高达 150ms，集群效率直接腰斩。后来用动态桶分桶，每个训练 step 前对数据长度排序，尽量让每个 worker 的序列长度之和接近。再加上梯度累加时的自适应 batch size，终于把方差压到 20ms 以下。真金白银的教训：别信均匀随机分布，实际数据他妈的从来不曾均匀。
坑三：网络拓扑的蝴蝶效应
你以为买一堆光缆连上就行了？拓扑选错，性能血崩。我们早期用了一个对称的 Fat-Tree，结果发现跨叶子交换机的通信延迟比预期高了 40%——因为路由表没优化好，数据包绕了远路。后来改成了 Rail-optimized 拓扑（如 NVIDIA 的 DGX 那样），把 GPU 到网卡一对一绑定，彻底消除拥塞。另一个细节：NUMA 节点绑定。多卡机器上，GPU 和对应网卡如果跨了 NUMA 节点，内存带宽直接减半。解法简单但粗暴：启动任务时用 numactl 绑定，或者让框架自动感知拓扑。搞完这些，我们 128 卡的扩展效率从 65% 飙到 88%，那种顺畅感——就像终于抽通了堵塞多年的马桶，痛快。
搞分布式训练，就像指挥一个庞大乐团。每个 GPU 都是乐手，你得选对乐谱（算法），调准乐器（拓扑），还得让所有人踩着同一个节拍。任何一个乐手慢半拍，全场就是一声叹息。但当你终于把那些参数同步的延迟藏起来，看到 Loss 曲线完美下降，听着千张卡风扇的咆哮……嗯，这钱烧得值。
