1. 多卡通信概述

大家好，我是你们的老朋友。今天咱们聊聊多卡通信。

说实话，我刚入行那会儿，单卡训练跑个 ResNet-50 都要等一整天。那时候觉得，一张卡能搞定的事，干嘛要折腾多卡？后来模型越来越大，数据越来越多，单卡根本撑不住。嗯，这就是多卡通信诞生的根本原因——单卡算力不够了。

1.1 为什么需要多卡通信？

你想想看，一张 A100 80G 的显存，能装下 GPT-3 吗？1750 亿参数，光参数就得 700GB 以上。单卡连模型都放不下，更别提训练了。

所以我们需要多张卡协同工作。但问题来了——卡与卡之间怎么交换数据？这就是多卡通信要解决的核心问题。

我在项目中遇到过这样一个场景：8 张 V100 跑分布式训练，结果发现通信开销占了总时间的 60% 以上。说白了，算力再强，通信跟不上也是白搭。

1.2 多卡通信的典型场景

多卡通信不是万能的，但某些场景下它是必须的。我归纳了三个最常见的场景：

场景一：分布式数据并行（DDP）

这是最常用的方式。每张卡持有完整的模型副本，但只处理一部分数据。每轮迭代结束后，所有卡需要交换梯度，然后同步更新参数。

• 通信模式：AllReduce（全规约）
• 通信量：与模型参数量成正比
• 典型框架：PyTorch DDP、Horovod

场景二：模型并行（Model Parallelism）

当模型大到单卡放不下时，就得把模型切分到多张卡上。每张卡只负责模型的一部分。

• 通信模式：P2P（点对点）通信
• 通信量：与切分边界处的张量大小有关
• 典型框架：Megatron-LM、DeepSpeed

我记得有一次做千亿参数模型的训练，模型并行切分后，卡间通信的延迟成了主要瓶颈。后来我们用了张量并行 + 流水线并行的混合方案，才把通信开销压下来。

场景三：流水线并行（Pipeline Parallelism）

把模型按层切分，每张卡负责连续的若干层。数据像流水线一样依次经过各卡。

• 通信模式：P2P + 广播
• 通信量：与每层的输出张量大小有关
• 典型框架：GPipe、PipeDream

1.3 通信瓶颈与挑战

多卡通信不是银弹。它带来了新的挑战，我总结为三大瓶颈：

瓶颈类型	具体表现	典型场景
带宽瓶颈	PCIe/NVLink 带宽有限，大张量传输耗时	AllReduce 梯度同步
延迟瓶颈	小消息的传输延迟高，频繁通信开销大	模型并行中的 P2P 通信
同步瓶颈	全局同步导致所有卡等待最慢的卡	DDP 中的 Barrier 操作

为什么会这样？说白了，GPU 算力增长的速度远快于互联带宽。你想想看，一张 H100 的算力是 60 TFLOPS，但 NVLink 带宽只有 900 GB/s。算力与通信带宽的剪刀差越来越大。

还有一个容易被忽视的挑战——拓扑感知。不同卡之间的通信路径不同，有的走 NVLink，有的走 PCIe，有的甚至走网络。如果不考虑拓扑，通信效率会大打折扣。

嗯，这里要注意：多卡通信的优化不是一蹴而就的。我个人的习惯是，先做 profiling，找到真正的瓶颈在哪，再对症下药。

1.4 知识体系总览

下面这张图是我自己画的，帮你快速建立本章的知识框架：

1.5 小结

这一章我们聊了多卡通信的来龙去脉。说白了，就是单卡不够用，多卡要协作，协作就得通信。而通信本身又带来了新的瓶颈——带宽、延迟、同步，一个都不能忽视。

我个人习惯在开始任何多卡项目之前，先搞清楚三个问题：

1. 我的模型有多大？——决定是否需要模型并行
2. 我的数据有多少？——决定是否需要数据并行
3. 我的硬件拓扑是什么？——决定通信优化的方向

嗯，把这些想清楚了，后面的调优才能有的放矢。