1. 课程导入

在大模型训练中，吞吐量（Throughput）通常指单位时间内系统完成的训练样本数或 token 数，例如 tokens/s、samples/s、steps/s。它直接决定一次预训练、微调或对齐任务需要多少 GPU 小时、多少电费和多少排队时间。很多团队在扩到数十卡、数百卡后才发现：算力并没有线性增长，训练速度反而被通信、数据加载、显存或调度拖住。吞吐量诊断与调优，本质上是在“算力、通信、内存、数据、并行策略”之间找到当前集群的最优工作点。

吞吐量不是单一指标，而是“有效算力利用率”的外在表现。诊断的目标不是把某个局部指标拉满，而是让端到端训练时间最短、单位成本最低。

一、为什么吞吐量决定训练成败

大模型训练的成本结构非常集中：GPU 时间占主导，其次是网络、存储和人力。假设一个 70B 模型在 1024 张卡上训练，若吞吐量下降 30%，意味着同样的 token 预算要多花约 43% 的墙钟时间；如果按云上 GPU 单价折算，就是直接的成本超支。更隐蔽的是，低吞吐往往伴随低 MFU（Model FLOPs Utilization），让团队误以为“卡不够”，继续加卡，结果通信开销更大、效率更低。

吞吐量还影响实验迭代速度。预训练阶段需要反复调整数据配比、学习率和并行策略；微调阶段需要快速验证 SFT、LoRA、DPO 等方案。吞吐量高，单位时间能跑更多消融实验，模型迭代周期从“周”缩短到“天”。因此，吞吐量调优不是运维细节，而是决定模型竞争力的工程能力。

二、常见瓶颈类型：先分类，再定位

大模型训练吞吐量瓶颈通常不是单点问题，而是多因素耦合。为了便于诊断，可以按“资源域”分为五类：计算瓶颈、通信瓶颈、显存瓶颈、数据瓶颈和调度瓶颈。每一类都有典型现象和对应指标。

瓶颈类型 典型现象 关键指标 常见原因
计算瓶颈 GPU 利用率高但 MFU 低，kernel 排队 SM 占用率、Tensor Core 利用率 算子未融合、精度配置不当、batch 过小
通信瓶颈 AllReduce/AllGather 等待时间长，GPU 空转 NCCL 耗时、网络带宽、等待占比 并行策略不匹配、拓扑跨机、梯度同步频繁
显存瓶颈 OOM 或频繁重算，batch 上不去 显存占用、激活重算次数 激活值过大、优化器状态未分片、碎片化
数据瓶颈 GPU 等数据，输入流水线断流 DataLoader 耗时、IO 吞吐 解码慢、样本不均衡、存储带宽不足
调度瓶颈 多任务抢占、卡间负载不均 任务排队时间、GPU 分配率 资源碎片、优先级混乱、弹性伸缩滞后

下面这张图把五类瓶颈与端到端训练流水线对应起来，帮助你在看到“慢”的时候，先判断它发生在哪个阶段。

训练吞吐量瓶颈与流水线阶段对应 端到端训练流水线 数据读取/解码 前向计算 反向计算 梯度同步 参数更新 数据瓶颈 DataLoader 慢 IO 带宽不足 解码 CPU 打满 计算瓶颈 算子未融合 MFU 偏低 batch 过小 显存瓶颈 激活值过大 OOM / 重算 优化器状态未分片 通信瓶颈 AllReduce 等待 跨机拓扑差 同步频率过高 调度 抢占 碎片 负载不均 诊断顺序建议 1. 先看 GPU 利用率与 MFU，判断是“算得慢”还是“等得久” 2. 再看 NCCL / 通信等待占比，区分计算瓶颈与通信瓶颈 3. 最后查 DataLoader、显存与调度日志，定位数据、显存或资源竞争问题

三、课程整体框架：从诊断到调优的闭环

本课程共 30 章，按“认知—诊断—调优—实战”四段式展开。前几章建立吞吐量指标体系与 profiling 方法；中段深入并行策略、通信优化、显存管理、数据流水线和混合精度；后段覆盖 MoE、长序列、多机多卡、弹性训练和成本优化；最后以真实案例复盘收束。

  1. 基础认知：吞吐量、MFU、扩展效率、墙钟时间与成本的关系。
  2. 诊断工具：Nsight Systems、PyTorch Profiler、NCCL 日志、DCGM、自定义计时埋点。
  3. 计算优化：算子融合、FlashAttention、编译加速、batch 与序列长度调优。
  4. 通信优化：DP/TP/PP/EP 组合、梯度压缩、通信重叠、拓扑感知调度。
  5. 显存优化：ZeRO、激活重算、Offload、分片优化器状态。
  6. 数据与调度：流式加载、预取、样本打包、多任务资源隔离。
  7. 实战复盘：典型瓶颈案例、调优前后对比、常见误区与检查清单。

四、案例场景：一次“加卡反而变慢”的复盘

某团队在 64 卡 A100 上训练 13B 模型，吞吐约 1.8k tokens/s/GPU。扩到 128 卡后，期望接近 3.6k，实际只有 2.1k。初步排查发现：GPU 利用率从 92% 降到 71%，NCCL AllReduce 等待时间占比从 8% 升到 27%。进一步看日志，跨机通信量随 DP 规模增大而增加，而该集群只有 25Gbps 以太网，没有 InfiniBand。问题不在算力，而在通信拓扑与并行策略不匹配。

# 典型 NCCL 日志片段
NCCL INFO AllReduce: 128 ranks, 2 nodes, ring algorithm
NCCL INFO Channel 00/08 : 0[0] -> 1[0] -> ... -> 127[0]
NCCL INFO Time: 18.4 ms, Algo: Ring, BusBW: 3.2 GB/s
# 对比单机 8 卡时 BusBW 可达 22 GB/s

调优动作包括：将部分 DP 改为 TP+PP 混合并行，减少跨机 AllReduce 数据量；启用梯度累积降低同步频率；把数据加载改为预取+内存映射，消除 DataLoader 抖动。最终 128 卡吞吐恢复到 3.3k tokens/s/GPU，扩展效率从 58% 提升到 92%。这个案例说明：吞吐量问题必须按“指标—日志—拓扑—策略”的顺序定位，不能盲目加卡。

常见误区：只盯 GPU 利用率，不看 MFU 和通信等待；只调 batch size，不改并行策略；把 OOM 简单归因于模型太大，而忽略激活值和优化器状态的分片空间。

五、学习目标与检查清单

完成本课程后，你应当能够独立完成一次吞吐量诊断，并给出可验证的调优方案。具体目标包括：

  • 能解释吞吐量、MFU、扩展效率、墙钟时间之间的量化关系。
  • 能使用至少两种 profiling 工具定位计算、通信、数据或显存瓶颈。
  • 能根据集群拓扑选择 DP、TP、PP、EP 的合理组合。
  • 能通过配置调整和代码优化，把典型任务的吞吐量提升 20% 以上。
  • 能建立吞吐量回归监控，避免版本迭代导致性能回退。
建议在开始后续章节前，先在自己的训练任务上记录一组基线数据：tokens/s、GPU 利用率、MFU、NCCL 等待占比、DataLoader 耗时、峰值显存。后续每学完一个模块，就回到这组数据做对比，形成自己的调优闭环。

吞吐量调优没有“一招鲜”，它依赖对系统全链路的理解和对真实指标的持续观测。接下来，我们将从吞吐量指标体系与度量方法开始，逐步建立可复现、可量化的诊断能力。

← 上一章 📖 返回目录 下一章 →