📚 课程目录第2章 AI训练与推理流量特征建模

2. AI训练与推理流量特征建模

在AI数据中心里，网络性能调优的第一步不是改参数，而是搞清楚“网络上到底跑的是什么流量”。AI集群的流量与通用数据中心有本质区别：它由集合通信原语驱动，呈现出高度同步、突发、周期性、大带宽的特征。如果只按平均带宽做容量规划，往往会在同步点出现严重拥塞。本节从集合通信模式出发，建立训练、微调、推理三类场景的流量特征模型。

一、集合通信原语的流量本质

分布式训练依赖NCCL等通信库实现集合通信。理解每种原语的流量方向、数据量和同步特性，是建模的基础。设参与通信的GPU数量为N，单次传输的数据量为S（字节），则各原语的理论通信量如下：

AllReduce：所有节点归约求和后广播结果。采用Ring算法时，每个节点发送和接收的数据量约为 2S(N-1)/N，总通信量约 2S(N-1)。它是数据并行训练中最核心的原语，出现在每次梯度同步。
AllGather：每个节点收集所有节点的数据分片。每节点接收 (N-1)S/N，总通信量约 S(N-1)。常见于张量并行、序列并行的激活收集。
ReduceScatter：先归约再分散，每节点得到部分归约结果。通信量与AllGather对称，约 S(N-1)。常与AllGather配对构成ZeRO优化。
AlltoAll：每个节点向所有其他节点发送不同数据。总通信量约 S(N-1)，但流量模式是全互联，对网络对分带宽压力最大，常见于MoE专家并行。
点对点（P2P）：Send/Recv，用于流水线并行的阶段间传递，通信量取决于流水线切分，方向单一但存在依赖等待。

关键区别在于：AllReduce和ReduceScatter是“先聚合后分发”，流量在时间上高度集中；AlltoAll是“全对全”，流量分散但总量大；P2P是链式依赖，时延敏感。这些差异直接决定了拥塞形态和调优策略。

二、训练场景：同步周期与突发建模

大模型数据并行训练中，每个迭代步包含前向、反向和梯度同步。梯度同步就是一次AllReduce。设模型参数量为P，采用FP16梯度，则单次AllReduce的数据量S≈2P字节（含梯度本身）。以70B模型为例，P=70×10⁹，S≈140GB。若N=64，Ring AllReduce总通信量约2S(N-1)/N≈275GB。假设节点间有效带宽为200Gbps（约25GB/s），则单次AllReduce耗时约11秒。而一个迭代步的计算时间可能只有几秒，通信成为瓶颈。

更关键的是同步周期。所有GPU必须等待最慢的节点完成AllReduce才能进入下一步，这导致流量呈现“计算静默—通信爆发”的周期性方波。建模时需要提取三个参数：同步周期T（迭代步时间）、突发带宽B（AllReduce期间瞬时带宽）、占空比D（通信时间/T）。若D超过0.5，说明网络已成为训练瓶颈，需要优化拓扑或增加并行度。

教学示例：假设某集群N=32，S=20GB，有效带宽25GB/s，则AllReduce耗时≈2×20×31/32/25≈1.55秒。若计算时间3秒，T≈4.55秒，D≈0.34，网络尚有裕量。若N增至128，通信量上升但带宽不变，D会显著增大。

三、微调场景：ZeRO带来的流量重构

微调（尤其是LoRA、全参微调）常采用ZeRO优化。ZeRO-1对优化器状态分片，ZeRO-2对梯度分片，ZeRO-3对参数分片。分片后，原本的AllReduce被拆解为ReduceScatter+AllGather。以ZeRO-3为例，前向传播时每个节点需要AllGather收集参数，反向传播时ReduceScatter归约梯度。通信次数从每步1次AllReduce变为每层多次AllGather/ReduceScatter，总通信量可能增加，但单次数据量减小，突发性降低，对网络时延更敏感。

微调场景的流量特征与训练不同：通信频次高、单次数据量小、同步点密集。建模时应关注每层通信的时延累积，而非单次大带宽。若网络RTT为10微秒，每层两次集合通信，100层模型每步额外增加2毫秒时延，在短迭代步中占比可观。

四、推理场景：AlltoAll与P2P的时延敏感型流量

推理场景的流量特征与训练差异巨大。以MoE架构为例，每个token需要经过门控网络路由到不同专家，这产生AlltoAll通信：每个GPU将token发送到持有目标专家的GPU。AlltoAll的流量矩阵是全互联的，对网络对分带宽要求极高。设每GPU处理B个token，每个token隐藏维度H，则AlltoAll数据量约B×H×2字节。若B=64，H=4096，FP16，则单次约1MB，但每层都发生，且推理请求到达是随机的，导致流量突发无固定周期。

流水线并行推理则使用P2P：阶段0计算完发送给阶段1，阶段1再发送给阶段2。P2P流量方向单一，但存在依赖等待。若阶段间计算时间不均衡，会出现流水线气泡，网络空闲与突发交替。推理场景建模的核心参数是请求到达率λ、单次AlltoAll数据量、P2P阶段数和端到端时延预算。与训练不同，推理更关注P99时延而非平均带宽。

五、流量特征提取的实操方法

要建立准确的流量模型，不能只靠理论计算，需要实际采集。推荐以下步骤：

采集通信库日志：设置NCCL_DEBUG=INFO和NCCL_DEBUG_SUBSYS=COLL，记录每次集合通信的原语类型、数据量、耗时。示例输出：NCCL INFO AllReduce: 140000000 bytes, 64 ranks, time 11.2s。
抓取网络流量：在交换机或主机侧用tcpdump/DPDK抓包，统计每秒字节数、包速率、流数量。重点观察同步点的突发峰值。
提取周期参数：对带宽时间序列做自相关分析，找出同步周期T；用峰值检测提取突发带宽B；计算占空比D=B×通信时间/T。
建立参数表：将S、N、T、B、D、时延分布等写入容量规划模型，作为后续调优的输入。

注意：NCCL日志中的时间包含计算等待，不能直接当作纯通信时间。应结合GPU利用率曲线，将通信区间与计算区间分离后再统计。

综合来看，训练流量是“大块同步突发”，微调流量是“高频小包密集”，推理流量是“随机短促时延敏感”。三者的建模参数、拥塞形态和调优方向完全不同。只有先建立准确的流量特征模型，后续的拥塞控制、QoS配置和容量规划才有可靠依据。