1. 课程导论

大家好，我是你们这门课的老朋友。在正式开始之前，我想先问一个问题：你手头有一块性能不错的GPU，为什么还要折腾多卡通信？

说实话，我刚开始接触分布式训练时，也觉得单卡跑跑挺好的。直到有一次，我接了一个百亿参数的大模型训练任务——单卡显存根本装不下，强行跑起来，一个batch要等好几分钟。那时候我才意识到：单卡算力再强，也有天花板。

1.1 单卡瓶颈：显存与算力的双重困境

咱们先看看单卡训练会遇到什么问题：

• 显存不够用：一个70B的模型，光参数就要140GB显存（FP16）。目前最强的H100也才80GB，根本放不下。
• 算力吃不满：单卡算力再高，batch size受限，GPU利用率上不去。我见过不少项目，单卡利用率只有30%-40%，白白浪费算力。
• 训练时间太长：一个中型模型单卡训练可能要几周，迭代效率极低。

1.2 多卡通信：分布式训练的基石

多卡训练的核心思路很简单：把一个大任务拆成多个小任务，分给多张卡同时做。但这里有个关键问题——卡与卡之间需要交换数据，这就是多卡通信。

我举个例子：假设你要训练一个模型，把数据分给8张卡。每张卡算完自己的梯度后，必须把梯度汇总到一起，才能更新模型参数。这个汇总过程，就是通信。

通信效率直接决定了分布式训练能提速多少。如果通信开销太大，可能8张卡还不如4张卡快——我在项目中就踩过这个坑。

1.3 分布式训练基础概念

在进入实战之前，咱们先统一一下术语。这些概念后面会反复用到：

概念	说明	我的经验
节点（Node）	一台服务器，通常包含多张GPU	单机多卡是最常见的场景
Rank	每张卡的全局编号，从0开始	调试时经常用rank打印日志
World Size	总卡数，比如8卡就是world_size=8	决定了通信拓扑
All-Reduce	最常用的通信操作，汇总所有卡的梯度	通信瓶颈往往就在这里
Ring All-Reduce	一种高效的All-Reduce实现	NCCL默认采用这种方式
NCCL	NVIDIA的通信库，多卡通信的基石	几乎所有框架都依赖它

1.4 通信模式：同步 vs 异步

多卡通信有两种基本模式：

• 同步通信：所有卡算完一步，统一通信，再算下一步。简单可靠，但慢卡会拖慢整体。
• 异步通信：各卡算完就通信，不等别人。速度快，但容易出bug。

我个人习惯：调试阶段用同步，上线优化时再考虑异步。为什么？因为异步通信的bug非常隐蔽——我曾经花了两天时间，才发现是异步通信导致梯度没同步，模型根本不收敛。

1.5 课程目标与学习路径

这门课的目标很明确：让你能独立诊断多卡通信的性能问题，并找到优化方向。

具体来说，学完这门课，你应该能：

1. 理解多卡通信的底层原理（NCCL怎么工作的）
2. 掌握带宽测试工具（nccl-tests、perf等）
3. 能分析通信瓶颈（是带宽不够？还是拓扑问题？）
4. 给出优化建议（调整拓扑、改通信策略等）

学习路径是这样的：

• 先搞懂基础概念（就是现在这章）
• 然后学通信原理和NCCL
• 接着上手做带宽测试
• 最后实战诊断性能问题

1.6 知识体系总览

下面这张图展示了本章的核心知识结构。我习惯用这种图来梳理思路——你想想看，整个多卡通信的脉络是不是清晰多了？

1.7 避坑指南：我踩过的几个坑

最后，分享几个我亲身经历过的教训：

• 别迷信理论带宽：标称的NVLink带宽是600GB/s，实际能跑到400GB/s就算不错了。我曾经按理论值估算训练时间，结果被老板骂了一顿。
• 通信和计算要重叠：很多新手把通信和计算串行做，白白浪费GPU空闲时间。正确的做法是让通信和计算同时进行。
• 小消息别用All-Reduce：如果每次通信的数据量很小（比如小于1MB），All-Reduce的开销反而比直接传输大。这时候用点对点通信更合适。