第 7 章 多维并行策略与拓扑映射¶
开场问题：一份开源大模型的训练配置写着 TP=8, PP=4, EP=32, DP=16。这些数字是怎么定出来的？
7.1 从约束倒推，不从缩写出发¶
按这个顺序问自己，每一步的答案决定下一步：
- 单层的参数和激活能放进一张卡吗？ 不能 → 开 TP，大小不超过单机卡数。
- 单条训练样本的序列有多长？ 长到单卡装不下注意力 → 开 CP。
- 是 MoE 吗？ 是 → 专家必须分布，开 EP，大小由专家数和网络拓扑决定。
- 上面配完，每卡的训练状态还放得下吗？ 放不下 → 上 FSDP/ZeRO 分片，仍不够再考虑 PP。
- 剩下的卡全部给数据并行，并让全局 batch 落在目标值上。
PP 放在最后，因为它引入气泡和最复杂的调度，其他办法够用时没必要。
7.2 并行维度要贴着物理网络摆¶
逻辑上的并行维度必须映射到物理拓扑：通信最频繁的 TP 放在 NVLink 域内（同机 8 卡）；EP 的 AllToAll 流量大，尽量落在同一个高速网络分组里；PP 只在 stage 边界传激活，通信最稀疏，最适合跨机；DP 在最外层，每步一次 AllReduce 且可以和反向重叠。
摆错的代价很直观：把 TP 跨机，step 时间可能翻倍。
7.3 一份方案必须能算出这些数¶
"TP8 PP4 DP16" 不是设计，只是标签。可执行的方案要给出：每卡参数、梯度、优化器状态、激活峰值分别多少 GB；每步各维度的通信字节数；预计 step 时间和 MFU；以及留给碎片和临时张量的余量。
算完之后和实测对比，差距大就说明有理解错误——这是本册最有效的自检方式。
7.4 MFU 和 HFU 不是一回事¶
MFU（模型 FLOPs 利用率）= 按模型定义必须做的计算量 ÷ 硬件峰值算力 ÷ 时间。HFU（硬件 FLOPs 利用率）把激活重计算这类"额外做了一遍"的计算也算进去。
开了重计算之后，HFU 会明显高于 MFU，因为你确实让 GPU 多算了。跨报告比较数字之前必须先确认对方报的是哪一个，否则会得出完全错误的结论。业界主流报告的是 MFU，大规模稠密模型训练能做到 40%–50% 已经是不错的水平。
7.5 读一份真实配置¶
把上面的方法用在一个公开的大模型训练配置上，逐个字段解释：为什么 TP 正好等于单机卡数、为什么 micro-batch 数是 stage 数的若干倍、EP 大小和专家总数是什么关系、全局 batch 落在多少 token。
这一节在第二册的作用，等同于第一册第 7 章"逐行读懂一个 8B 模型"——能逐字段解释别人的配置，才算真的会配。
核心问答¶
Q：有没有通用的并行配置模板？ 没有。模型形状、序列长度、集群拓扑、目标 batch 任何一个变了，最优解都会变。但 7.1 的决策顺序是通用的。
Q：为什么不能同时把所有并行都开到最大？ 每多一个并行维度，通信、checkpoint、故障恢复和调试难度都会上升，而收益递减。能用简单方案就别上复杂的。
Q：MFU 只有 25%，一定有问题吗？ 要看模型和场景。MoE、超长序列、小模型的 MFU 天然偏低。重要的是找到差距在哪：通信没藏住、数据没喂饱、还是 kernel 效率低。
Q：怎么判断通信是否被藏住了？ 看 profiler 时间线上通信 kernel 是否与计算 kernel 重叠，以及关键路径上暴露的通信时长占 step 时间的比例。