1 集合通信要理解什么
训练图像分类模型时，增加 GPU 并不等于训练时间按比例缩短。假设用公开的 CIFAR-10 数据集训练，把原训练集分成 45000 张训练图像、5000 张验证图像，保留官方 10000 张测试图像。4 个训练进程各自处理当前批次的不同图像，计算出的梯度也各不相同。若希望它们继续维护同样的模型参数，就要先交换并合并这些梯度，再执行参数更新。这里反复发生的协作，就是集合通信的重要使用场景。
集合通信指同组进程共同参与、按约定完成的数据交换或归约操作。组内每个进程通常有编号，称为 rank；编号表示参与者身份，不保证对应某台机器上的某张 GPU。进程组定义谁必须到场，操作定义谁提供数据、怎样合并、谁得到结果。理解它时，先问清这 3 件事，比先记住算法名更有用。集合操作通常要求组内成员按兼容的顺序调用；某个成员漏掉调用，其他成员可能一直等到超时。
数据并行训练中，各成员持有模型副本，处理不同样本，通信梯度或其他训练状态。它不同于把不同网络层放到不同设备的模型划分，也不同于普通文件下载：下载常有明确的发送端与接收端，集合操作则描述整个参与组的共同结果。通信库把这个结果映射到实际传输步骤，训练框架负责在适当位置发起调用。本课关注这层分工，不展开设备内核、传输协议和网络拥塞控制的实现。
讨论性能之前，先保持学习任务有效。图像增强只作用于训练集，验证和测试阶段使用固定预处理；短文本分类要避免近重复文本跨集合；客户流失预测则应按预测时点划分数据，不能把流失后才产生的字段当作输入。通信再快也无法修复这些泄漏。最终比较至少包含训练吞吐、达到目标验证指标的时间，以及冻结配置后的测试结果，而不是只比较某段通信调用的毫秒数。
还要区分“算得一致”和“模型有效”。正确的集合操作可以让各模型副本获得兼容的更新，却不能保证分类器有足够召回率。客户流失样本较少时，全部预测为未流失也可能得到很高准确率，因此需要同时观察 precision、recall、F1 与 AUC。通信指标回答系统是否高效，验证指标回答学习是否有效；它们属于同次实验记录，却不能相互替代。
2 AllReduce、AllGather 与 Broadcast
AllReduce 的含义是先按指定运算归约，再让组内所有成员得到归约结果。例如 4 个 rank 分别提供数值 2、4、6、8，执行求和 AllReduce 后，每个成员都得到 20。若训练需要平均值，还要按约定除以 4；有些框架会完成这步，有些接口只负责求和。不能仅凭函数名字推断缩放规则，应查看实际调用层的语义与训练设置。
梯度平均还隐含样本权重。若每个成员处理相同数量的样本，且本地损失采用相同的平均方式，本地平均梯度再平均就对应整个批次的平均梯度。若各成员分别处理 16、16、16、8 个样本，直接把 4 份本地平均梯度等权平均，会给最后 8 个样本过高权重。此时要使用与样本数一致的加权方式，或让批次安排满足框架的约束。尾批次、梯度累积与损失缩放都应一起确认。
AllGather 不做求和，而是让每个成员收集所有成员提供的数据。若 4 个 rank 分别提供同形状的向量 A、B、C、D，结束后各自都拥有按约定顺序排列的 A、B、C、D。常见等长接口要求输入大小兼容；变长文本的结果通常需要长度信息、填充或支持变长的接口。代价不仅是网络传输，每个接收者还要容纳收集后的总数据，不能把它当作几乎免费的“同步”。
Broadcast 则由指定根成员提供数据，其他成员获得它的副本。例如训练开始时，让 rank 0 的初始参数广播到其余成员，避免随机初始化差异。根成员指身份，不一定指长期运行的中心服务器。广播不会自动对其他成员已有的数据求平均；把 Broadcast 误写成 AllReduce，或把 AllGather 当成平均梯度，都会改变计算含义，即使程序没有立即报错。
可以用结果形状检验理解：求和 AllReduce 的输入与输出通常同形；等长 AllGather 的输出总量随成员数增加；Broadcast 的输出对应根成员的输入。再检查数据类型、元素数、进程组和调用顺序是否匹配。若组内有成员先执行广播、其他成员先执行归约，程序可能等待或失败。集合通信不是“大家最后都调用过就可以”，而是同组调用必须形成一致的协作序列。
AllReduce 的语义也不指定某种唯一算法。环形实现可以先让每个成员获得部分归约结果，再把这些部分交换完整；树形实现可以沿树向上归约，再向下传播。实际库可能使用分层、分块或其他组合。初学阶段只需守住边界：算法可以改变传输路径和时间，不能随意改变调用要求的数学结果；浮点数因加法顺序改变而出现微小差异，则要用合理容差检查。
3 拓扑感知与算法选择
拓扑描述参与者怎样连接。同机 GPU 之间可能拥有专用高速连接，也可能共享部分总线；跨机器则要经过网卡、交换设备与网络链路。即使机器数量、GPU 数量相同，实际通信路径也可能不同。把所有连接都当成同样快，往往会误判扩展效果。方案至少要画出进程到设备、设备到机器、机器到网络的对应关系，并注明哪些带宽由多个参与者共享。
在简化环形 AllReduce 中，数据被切成若干块，成员沿环交换并归约，再交换已完成的结果块。它能分散传输负担，大消息下常有较好的带宽利用率，但需要多轮推进。随着成员增加，轮次带来的启动开销会变得明显。树形算法则按层级汇合与分发，关键路径层数常随成员数的对数增长，适合解释为什么某些小消息更看重较少的启动轮次。
“树一定快”或“环一定省带宽”都过于绝对。树的分支可能争用同条物理链路，某些中间节点也可能承担较多工作；环若把相邻 rank 映射到较慢的跨机路径，也可能损失很大。通信库通常结合消息大小、成员数、硬件能力和拓扑选择实现。教材中的环与树是便于分析的模型，具体库的名称、分段方式与阈值必须以所用版本的文档和实测为准。
以 2 台机器、每台 4 张 GPU 为例，同机连接快于跨机连接时，可以考虑先在机内归约，再让机器之间交换结果，最后在机内分发。这个分层思路能帮助理解拓扑感知，但不能直接推出“跨机数据量必定减少到某个固定值”：实际分片和并发方式会影响结果。应记录跨机出口是否共享、每个进程使用哪个网络接口，以及运行时是否识别到了预期连接。
选择算法前还要看业务形态。小型表格模型可能每步计算很短，集合调用的启动成本很显眼；图像模型的梯度总量较大，持续传输能力可能更关键；短文本分类中，序列长度差异又可能让某个进程较晚完成计算。后者看上去像“通信在等”，根因却是成员没有同时到达。先区分计算不均与传输缓慢，再讨论拓扑和算法，才能避免调错对象。
4 动手：对比一次环与树耗时
实验分成通信基准与训练验证。通信基准只回答固定条件下的集合操作耗时；训练验证再回答端到端收益。准备同组 4 个进程，每个进程绑定独立设备，使用相同数据类型的连续张量。选择每个 rank 输入 4 KiB、1 MiB、64 MiB 的求和 AllReduce，分别测试库默认策略、受支持的环策略与树策略。这里的消息大小统一指每个 rank 的输入字节数，避免把总传输量混进横轴。
强制策略的方法依赖通信库与版本，不应把某个环境变量当成跨库标准。先确认该版本支持指定算法，再记录配置及生效证据；若无法确认，就把结果标为默认策略，不能仅按想象给曲线命名。固定设备、网络接口、进程映射、数据类型和消息大小，每轮实验只改变策略。避免同设备上混跑其他训练任务，也不要在通信测量窗口内下载数据或写大型检查点。
下面是实验逻辑的伪代码，完成等待 必须覆盖异步工作真正结束，具体同步接口以所用运行时为准。正确性检查独立于计时窗口：可让 rank r 的每个输入元素取 r+1，4 个成员求和后的每个元素都应接近 10。每次迭代重新准备输入，避免原地归约后把上次输出又当作新输入。检查全部元素的误差，而不只是打印首个数值。
建立进程组，记录 rank、设备与通信配置
对每个策略和消息大小：
准备输入，执行正确性检查
预热 20 次，每次等待操作完成
重复 100 次：
准备输入并等待准备工作结束
组内对齐起点，再完成必要的设备同步
记录起始时间
发起求和 AllReduce
完成等待并同步相关设备工作
记录本 rank 的本次耗时
在测量窗口外汇集各 rank 的耗时
逐次取各 rank 最大耗时，再统计中位数与 P95对齐起点的操作不计入被测集合的窗口，预热用来减弱首次初始化等因素的影响。不要只测主机提交调用的时间，否则异步接口可能显得异常快。逐次取成员耗时的最大值，是为了贴近整组何时可以继续的含义；但它仍是局部计时的近似，不是由同步时钟测得的全局绝对时间。保留原始样本，能够帮助判断偶发抖动是否左右结论。
最后用 CIFAR-10 做短训练验证：先运行单设备基线，再保持相同模型、精度和全局批次比较 4 个设备的配置。全局批次固定为 128 时，每个成员处理 32 张图像；不要同时把全局批次增到 512，又把精度变化归因于通信算法。记录每步中位耗时、P95、图像吞吐、验证集 macro-F1 和各类别召回率。只有基准和训练都支持的收益，才值得进入正式方案；短跑实验也不能替代完整收敛验证。
5 带宽与延迟敏感取舍
理解取舍可以从简化式开始：通信时间约等于“串行启动轮数 × 单轮启动延迟”，再加上“关键路径传输量 ÷ 有效带宽”。启动延迟可以理解为让某轮交换开始并推进所需的固定成本；有效带宽是该负载下实际可用的传输能力，不是接口标称速率。小消息的传输项很小，启动成本更突出；大消息的传输项增长，带宽利用率就更关键。这只是分析框架，不是精确预测器。
对于每个 rank 输入大小为 M、成员数为 p 的简化环形 AllReduce，常用估计是 2(p−1)α + 2(p−1)M/(pB)。其中 α 表示每轮启动成本，B 表示有效带宽，忽略计算、争用和流水细节。用来教学的二叉树估计可以写成 2⌈log₂p⌉α + 2⌈log₂p⌉M/B，表示每层传完整消息的朴素归约与广播。它不代表所有优化树算法，更不能用它证明任何库的树实现必然输给环。
设 p 为 8、α 为 10 微秒、B 为 10 GB/s，并约定 GB 使用十进制字节。对于 4 KiB 消息，简化环的启动项约为 140 微秒，朴素树约为 60 微秒，传输项都较小。对于 64 MiB 消息，环的估计约为 11.9 毫秒，朴素树约为 40.3 毫秒。这里展示的是同组假设怎样产生交叉趋势，不能把这些数值当成真实硬件的承诺或通信库排名。
训练中还有计算与通信重叠。框架可能在部分梯度就绪后立即通信，而其他层继续反向计算。此时通信耗时减少 20%，训练步耗时未必减少 20%，因为部分通信原来就被计算覆盖；反过来，最后无法覆盖的等待段减少，收益可能很明显。因此需要同时看集合本身的耗时与训练步结束前暴露出的等待。入门阶段先确认时间线里谁先完成、谁仍在等待，无需深入调度器内部。
参数选择也涉及内存与优化行为。增大通信分组可以摊薄启动开销，却会推迟首组梯度发出并占用缓冲空间；减小分组可能更早开始交换，却产生更多小调用。梯度累积能减少某些同步频率，但会改变有效批次和更新节奏，不能把它当成纯粹的通信开关。每次改变都要注明影响范围，以验证曲线与端到端时间共同决定是否保留。
6 常见坑：小消息却走大算法
典型问题是把适合大消息的配置强制用于所有集合调用。模型除了大量梯度，还可能交换损失统计、样本计数和控制信息。这些消息只有几十字节到几 KiB，若仍承担很多启动轮次，即使链路带宽很高也不容易更快。先按消息大小统计调用次数和累计时间，辨认“少数大消息慢”还是“很多小消息积累慢”，再考虑撤销强制策略或调整受支持的阈值。
还要区分逻辑消息与实际调用。框架可能把许多参数的梯度装进若干通信桶，单个参数很小不代表每次集合调用都小。反过来，模型总参数量很大，也可能因分组过碎产生大量小调用。观察真实调用的字节分布，才能解释配置效果。初次排查优先恢复库默认自动选择，再用相同负载与显式配置对照；自动选择是合理起点，但也需要验证是否识别了实际环境。
另类错误来自“测得更快”的假象。只计调用提交时间、把首次初始化计入某种算法而没有计入另种算法、采用不同精度、漏掉设备同步，都会破坏可比性。只报告平均值也会隐藏偶发长尾，而同步训练往往被长尾影响。报告中位数、P95、运行次数和实验条件，比单独写“快 30%”更容易复核。性能变化小时，先重复独立运行确认稳定性，再解释差异。
数据管道也会伪装成通信问题。短文本分类中，某个批次包含大量接近最大长度的句子，成员计算量变大，其他成员提前进入集合操作后等待。若按墙钟观察等待，就可能把变长输入造成的不均衡误判为网络差。记录每个 rank 的有效 token 数、数据加载耗时与反向计算结束时间，能够把晚到和慢传分开。分桶采样可减轻长度差异，但应保持数据划分与采样规则可解释。
最后不要用更多设备掩盖学习问题。以公开的 Bank Marketing 数据作表格分类示例，预测是否订阅定期存款时，通话结束后才知道的通话时长不能用于通话前预测。按实际预测时点保留年龄、职业、历史联系等可用字段，编码器只在训练集拟合，再固定验证与测试集合。若正类较少，应记录正类 precision、recall、F1 及明确口径的 ROC-AUC 或 PR-AUC；通信配置比较不能悄悄更换阈值来制造收益。
7 案例：慢链路拖垮集合操作
某图像分类实验使用 2 台机器、每台 4 张 GPU，共 8 个 rank。团队先在单机 4 卡运行，再扩到 8 卡，发现吞吐只略有增加，训练步 P95 却明显升高。训练、验证和测试划分保持不变，全局批次仍为 128，验证集 macro-F1 波动处于重复实验范围内。此时已有证据说明主要问题在效率，但还不能直接断言“跨机网络坏了”：输入流水线、设备负载和成员到达时间都可能造成类似现象。
排查先对齐同个训练步的时间线。记录各 rank 数据就绪、反向计算结束、集合开始与完成的相对时间，同时记录消息大小和参与组。发现各成员进入主要集合的时刻接近，跨机运行时完成时间整体拉长，而单机集合稳定。接着对相同消息大小运行通信基准，跨机结果也变差，说明问题可以在脱离训练的数据交换中复现。这个结果缩小了范围，却仍需检查实际接口和路径。
检查发现其中 1 台机器的训练进程选择了较慢的网络接口，并与后台传输共享出口。这是案例的假设性诊断结果，实际现场必须有接口映射、计数器和对照实验支持。环中部分数据要经过这段路径，后续成员收到分块也会延迟；树中若关键分支经过该路径，对应子树同样会拖慢。更换算法可能改变受影响程度，但不能凭算法名称消除实际带宽瓶颈。
修复时先让进程使用预期的训练网络接口，并安排后台传输避开对比窗口；这 2 项分别验证，记录各自效果。随后重复相同消息、映射和配置的基准，再运行相同训练负载。若通信中位数恢复但 P95 仍差，应继续观察共享流量和成员到达时间。只有在正确性检查通过、尾部耗时改善、端到端吞吐提升且验证指标未出现异常后，才能把修复记为有效。
本案例也揭示同步训练的特点：整组完成受关键慢路径约束，其他成员空等并不说明它们也发生了硬件故障。排查报告要给出“在哪种负载、哪条路径、哪些证据支持”的陈述，避免笼统写成“网络不行”。若无法立刻修复，可以评估缩回单机的吞吐与成本，但必须重新比较达到目标验证指标的时间。减少设备有时更合算，结论取决于任务而非设备数量本身。
8 把通信库配置写进方案
通信库配置是可复现实验的一部分。方案先写任务和正确性边界：使用哪个数据集版本，训练、验证、测试如何划分，输入有哪些特征，哪些字段因预测时点不可用而排除。图像分类说明增强规则；短文本分类说明去重与截断长度；表格分类说明缺失值和类别编码怎样拟合。这样才能确认性能对比在做相同的学习任务，避免把样本减少或数据泄漏误当成系统优化。
然后写参与关系与软件条件：机器数量、每机设备数、rank 映射、进程组范围、框架和通信库版本、数据类型及网络接口选择。对每项显式配置，写出准确名称、设置值、作用范围、是否已确认生效，以及恢复默认的方法。没有修改的算法选择可以写“库默认策略”，不应为了显得完整而填入未经证实的算法名。配置文件和启动参数也要有可追踪的版本。
性能验收要有共同口径。通信基准写清每个 rank 的输入字节数、预热与测量次数、计时完成条件，以及逐次最大耗时的统计方法。训练侧固定全局批次、学习率安排和验证频率，记录每步中位数、P95、样本吞吐及达到目标指标的墙钟时间。达到目标验证 macro-F1 的时间通常比孤立的峰值吞吐更贴近任务目标，但目标应在比较前确定，不能看完结果后临时挑选。
质量验收另列指标解释。precision 关注预测为正的样本中有多少真正为正，recall 关注真实正类找回多少，F1 综合这 2 项；ROC-AUC 衡量跨阈值排序能力，PR-AUC 在正类稀少时常能补充观察。记录阈值如何由验证集确定，测试集只用于最终评估。若新采集图像、文本来源或用户群发生变化，要检查分布偏移，不能因为通信基准稳定就认定模型效果也稳定。
最后写回退与责任边界。若显式算法配置只改善微基准，却让训练 P95 变差，就回到已验证的默认设置；若接口选择错误，先修正映射而非反复调整分组。记录何种现象触发重测，例如升级通信库、改变机器数量、迁移网络路径或更换模型。方案不需要罗列所有底层选项，只需让接手者知道为什么选它、怎样确认有效、失败后恢复到哪里。
9 从集合通信走向AI 服务器（H45）
集合通信把“多张 GPU”连接成协同训练系统，也让服务器配置的含义更具体。购买或分配设备时，显存容量决定模型与批次能否放下，设备计算能力影响本地计算时间，设备间连接与网络则影响协作成本。只看 GPU 数量无法解释训练速度；同样是 8 个成员，位于同机还是跨机、是否共享出口、输入是否及时到达，都会改变有效吞吐。
进入 AI 服务器主题前，可以把需求整理成任务、资源和证据的对应关系。任务写模型类型、数据规模、目标验证指标和可接受训练时间；资源写设备数量、内存与显存、数据读取路径及互联关系；证据写单设备基线、集合基准和端到端训练结果。遇到扩展效果差时，先确认哪部分占主导，再决定是否需要更强计算、更多容量或更合适的连接，不凭某个单项规格做判断。
服务器也不只服务训练。上线推理可能更关心单请求延迟、批处理吞吐和模型常驻显存，未必频繁执行训练梯度的 AllReduce。短文本分类服务与离线图像训练即使使用相同模型框架，资源侧重点也可能不同。下一课讨论 AI 服务器时，应把训练与推理目标分别写清，沿着数据如何进入、计算怎样进行、结果如何离开的路径理解整体配置，而不把本课算法偏好直接迁移过去。
到这里应能解释 3 个问题：集合操作规定的结果是什么，物理连接怎样影响实现，观察到的等待究竟来自晚到还是慢传。更复杂的分层实现、传输协议和内核优化可以以后再学。先用可复现的小实验建立判断习惯，再把通信要求写进服务器需求，已经足以避免许多“增加设备却没有增加有效产出”的入门误区。
放进方案里
本项目采用 CIFAR-10 图像分类任务，使用原训练集中的 45000 张图像训练、5000 张验证，并保留官方 10000 张测试图像。训练集使用随机裁剪与翻转，验证和测试使用固定预处理；划分清单与随机种子归档。以验证 macro-F1 作为模型选择指标，同时观察各类别 precision、recall 与混淆矩阵。测试集在配置冻结后评估，新增图像来源须另查分布偏移。
初始资源为 2 台机器、每台 4 张 GPU，按机器内设备顺序分配 8 个 rank，使用完整进程组执行梯度 AllReduce。全局批次固定为 128，每个 rank 处理 16 张图像；梯度平均遵循框架约定，尾批次规则保持一致。记录框架、通信库版本及设备映射，默认采用库自动算法选择；指定训练网络接口，并保存配置生效记录和恢复默认的启动配置。
通信基准覆盖每个 rank 输入 4 KiB、1 MiB、64 MiB 的同类型张量，预热 20 次、测量 100 次。每次计时等待实际完成，逐次取各 rank 最大耗时，报告中位数与 P95，并检查归约结果误差。显式环与树只在版本支持且能确认生效时纳入对比，记录共享网络流量，保留原始耗时样本。
训练验收固定模型、精度、全局批次与学习率安排，对比单设备基线和多设备配置，记录吞吐、每步 P95 及达到预定验证指标的时间。若仅通信基准改善而训练变慢，恢复已验证配置；若出现成员等待，先区分数据晚到、计算不均与慢链路。更换通信库、机器数量或网络路径后重新验收，由训练负责人维护配置记录与回退依据。
集合正确性验收要求所有 rank 的输出均通过预先约定的浮点误差容差，并核对调用顺序、张量元素数与进程组一致。出现超时或结果不一致时，该配置不得进入训练性能比较；保存各 rank 的调用日志、接口映射和失败步骤，作为定位参与者缺席或调用不匹配的证据。
10 小结：下一步AI 服务器（H45）
AllReduce 合并并分发结果，AllGather 收集各成员数据，Broadcast 复制根成员数据。环与树是实现路径，选择取决于消息、成员和拓扑；小消息重视启动成本，大消息更受有效带宽影响。任何优化都要同时通过正确性、通信基准和训练效果检查。
自测：4 个成员样本数不同时，为什么不能总把本地平均梯度等权平均？小张量调用很慢时，为什么先查启动轮次与成员到达时间？跨机扩展变差时，哪些证据能把网络慢与数据加载慢区分开？带着这些问题进入 AI 服务器（H45），就能把计算、容量与互联放在同个任务目标下评估。