进阶专题 · 模块 A 第 1 讲：并行训练与 ms-swift Megatron 模式

讲次：第二阶段进阶专题 / 模块 A 训练工程 · 第 1 讲（A1） 建议时长：2.5–3 小时（讲解约 100 分钟 + 实操约 60–80 分钟） 前置知识：第一阶段技术轨全部内容——Transformer 与推理原理、vLLM 部署与压测运维、SFT 微调（LLaMA-Factory）、数据蒸馏结课项目。学员应能独立算参数量、KV Cache 与显存账，能读训练日志的 loss 与吞吐字段。 素材来源说明：本讲引用素材均来自公司内部存档 materials-advanced/，逐节标注来源（机构 / 文档名）。框架命令与参数以 ms-swift 官方文档存档为准，开课时须按当前版本复核；自组织教学内容标注「Muse 整理」。社区与机构文档版权归原作者 / 机构所有，仅供公司内部学习。

本讲一句话结论：并行训练不是「卡多力量大」，而是一道在显存、算力、通信之间做交换的工程题；先把账算清，再选策略，最后才轮到敲命令。

1. 学习目标与本讲地图

学完本讲，学员应能做到：

对任意一个模型，先算两笔账（显存账、算力账），判断它在公司双机 DGX Spark 上「能不能训、要训多久」；
说清 DP / TP / PP / SP / CP / EP / VPP 七种并行各自切什么、通信什么、代价什么，并能给一个给定场景选出合理的组合；
说清 ZeRO/FSDP 路线与 Megatron 路线的理念差异，知道 ms-swift 两条路线都在什么位置；
看懂训练的稳定性信号（loss 曲线、梯度、显存曲线），对训崩、卡死、变慢有初步诊断路径；
会算 MFU，会把一次训练折算成时间与成本；
读懂 ms-swift Megatron 模式的官方快速开始脚本与 Qwen3.8-Flash-Next 最佳实践脚本，能在实操中改对并行参数并记录对照数据。

本讲地图（Muse 整理）：

节	内容	解决的问题
§2	两笔账：显存与算力	为什么必须并行
§3	并行策略全景	有哪些切法、各付什么代价
§4	两条路线对照	ZeRO/FSDP 与 Megatron 怎么选
§5	混合精度与稳定性	怎么训得稳、崩了怎么查
§6	MFU 与成本账	训得快不快、贵不贵
§7	ms-swift Megatron 实战导读	命令与参数怎么读
§8	贯穿案例	公司同款模型的官方最佳实践拆解
§9	实操	双机并行对照实验
§10–§11	常见坑 / 练习与延伸阅读	避坑与课后巩固

2. 为什么需要并行：单卡装不下、算不完的两笔账

要点：并行的动机只有两个——一台设备装不下（显存账），一台设备算不完（算力账）。先算账，再谈策略。本节算例为 Muse 整理，输入数据为公司实测值与公开模型参数；Adam 状态占用的口径来自 Datawhale《So Large LM》第 6 章，内存墙背景来自该书第 8 章。

So Large LM 第 8 章开篇点明了背景：模型规模的增长撞上了「内存墙」——单芯片的算力与容量受物理规律限制，增速跟不上模型膨胀，分布式训练因此势在必行（来源：Datawhale《So Large LM》第 8 章《分布式训练》）。下面用公司自己的硬件把这句话算成数字。

2.1 第一笔账：显存装不装得下

全参数训练时，每台设备要同时放下四样东西：权重、梯度、优化器状态、激活值。前三样是静态大头，可以按参数量直接估算：

权重（BF16）：2 字节 / 参数；
梯度（BF16）：2 字节 / 参数；
优化器状态（AdamW）：一阶动量 m、二阶动量 v 各一份 FP32（8 字节），混合精度训练还要保留一份 FP32 主权重（4 字节），合计 12 字节 / 参数。

依据：Adam 需要同时保存 θ（参数）、g（梯度）、m、v 四份张量，存储是参数本身的 4 倍量级；混合精度训练则把主权重存为 FP32、在低精度下执行其余运算（来源：Datawhale《So Large LM》第 6 章《模型训练》6.2.2、6.2.4 节）。

合计口径：全参数 AdamW 混合精度训练，静态占用 ≈ 16 字节 / 参数（未含激活值，激活另随 batch、序列长度、层数增长，可用重计算压低，见 §5、§8）。

拿公司硬件对账（单台 DGX Spark 系统可见内存约 121.6 GB，两台合计约 243 GB；注意 Spark 是统一内存，训练可用内存还要先扣掉系统与现行服务占用）：

模型	参数量	静态占用（16 B/参数）	单台 Spark	双台 Spark
Qwen2.5-7B	7B	≈112 GB	临界：静态已逼近上限，激活无处放	切分后可行
Qwen3-32B 级别	32B	≈512 GB	装不下	仍装不下（需 ZeRO-3/卸载/LoRA）
Qwen3.8-Flash-Next（公司在跑）	125B	仅 BF16 权重就 ≈250 GB	装不下	权重都装不下

最后一行最能说明问题：公司现行模型光权重（BF16）就超过两台 Spark 的内存总和，所以线上只能以 NVFP4 量化形态（约 62.5 GB）做推理；而它的官方训练最佳实践是 8 卡集群 + 关键权重卸载到 CPU 内存（见 §8）。结论：全参数训练稍大一点的模型，单机在物理上就不成立，并行与切分不是优化项，是入场券。

对照 LoRA：可训练参数占比通常不到 1%，优化器状态随之缩小两个数量级，静态大头只剩冻结的 BF16 权重（2 字节 / 参数）。这就是第一阶段 SFT 课上 7B 级 LoRA 能在单机跑通的原因（ms-swift 官方快速开始给出的参照：单卡 3090、13 GB 即可完成 Qwen3-4B 的 LoRA 自我认知微调，来源：ms-swift《快速开始》）。

2.2 第二笔账：时间等不等得起

训练计算量的经验公式（Muse 整理，业界通用估算口径）：

训练 FLOPs ≈ 6 × 有效参数量 × 训练 token 数（MoE 模型用每 token 激活参数量）

算例：对一个 7B 稠密模型做 10 亿 token 的继续训练，FLOPs ≈ 6 × 7×10⁹ × 1×10⁹ ≈ 4.2×10¹⁹。公司实测 GB10 在优化过的 torch 构建下 FP16 矩阵乘约 90 TFLOPS 量级（公司实测数据，见模块 C 相关材料）；即便乐观地按有效利用率 35%（MFU 的概念见 §6）折算成约 31 TFLOPS 的持续算力，单机耗时 ≈ 4.2×10¹⁹ ÷ 3.1×10¹³ ≈ 1.35×10⁶ 秒 ≈ 15 天以上。两台并行、且并行效率打八折，也要一周量级。

反过来，第一阶段蒸馏项目的量级是 1 万条样本、约 1000 万 token，同口径估算单机数小时——与实际体验吻合。结论：SFT 数据「以条计」时单机够用；一旦目标变成「以 token 计」的继续预训练或大规模微调，时间账立刻逼你并行。

2.3 两笔账的用法

显存账决定切分的下限：至少要把静态占用切到每台设备装得下、还留得出激活空间；
算力账决定并行的收益上限：设备翻倍，时间最好情况下减半，通信开销会吃掉一部分（吃掉多少，取决于策略，见 §3）；
两台 Spark 之间的互联远慢于单机内部的统一内存访问——这是后面所有选型直觉的物理根源：通信量大的切法尽量别跨机器（公司现行 vLLM 服务用 TP2+EP 跨双机是推理场景的权衡，训练选型另有讲究，见 §3.3 与 §9 的对照实验）。

3. 并行策略全景：切什么、通信什么、代价什么

要点：七种并行只做三件事——切数据、切权重、切层（含切序列、切专家）。选型的核心变量是通信量与通信频率。策略定义与矩阵乘法图解来自 Datawhale《So Large LM》第 8 章；ms-swift 的官方选型规则来自 ms-swift《Megatron-SWIFT 快速开始》的「训练技巧」一节；组合直觉表为 Muse 整理。

先建立一个统一视角（Muse 整理）：一次训练迭代 = 前向 + 反向 + 优化器更新。任何并行策略都是在回答同一个问题——这一步里，每台设备算哪一部分、存哪一部分、需要和谁交换什么。交换得越频繁、数据量越大，对互联带宽越敏感。

3.1 逐个讲清

DP（数据并行，Data Parallel） - 切什么：切数据。每台设备持有一份完整模型副本，各吃一个数据分片。 - 通信什么：反向后对梯度做 AllReduce 求平均，保证各副本更新一致（来源：So Large LM 第 8 章 8.2.1 节）。 - 代价：每台设备都要装下完整模型 + 优化器状态，显存不省；通信量与梯度大小成正比，每步一次。ms-swift 官方评价：DP 速度最快，但显存占用最多（来源：ms-swift《Megatron-SWIFT 快速开始》）。

TP（张量并行，Tensor Parallel） - 切什么：切单个算子内部的权重矩阵（模型并行的一种，如把一层的大矩阵乘按列/行拆到多台设备）。 - 通信什么：每层前向、反向中都要做 AllReduce / AllGather 拼接部分结果——通信频率最高、与计算交织。 - 代价：对互联带宽与延迟极其敏感。ms-swift 官方规则：TP 通信量大，尽量不跨节点、限制在高速互联域内（来源：同上）。

PP（流水线并行，Pipeline Parallel） - 切什么：按层切阶段（stage），设备之间接力：stage 0 算完前几层，把激活传给 stage 1（来源：So Large LM 第 8 章 8.2.3 节）。 - 通信什么：只在 stage 边界传激活值，通信量最小；靠 micro-batch 切分把流水线填满，减少空泡（bubble）。 - 代价：切分不均会让某个 stage 成为瓶颈（§8 有一个真实案例：因为某层特别重，官方专门调了第一个 stage 的层数）；空泡率随 micro-batch 数下降。

SP（序列并行，Sequence Parallel） - 切什么：切 TP 没覆盖到的部分——LayerNorm、Dropout 等沿序列维度的激活，配合 TP 使用。 - 通信什么：把 TP 区域边界的 AllReduce 拆成 ReduceScatter + AllGather，总量不增、激活显存下降。 - 代价：必须与 TP 搭配（ms-swift 脚本里常以 --sequence_parallel true 与 TP 同时出现，来源：ms-swift《Megatron-SWIFT 快速开始》快速入门案例）。收益主要是省激活显存，让 TP 组的单设备占用再降一截。

CP（上下文并行，Context Parallel） - 切什么：沿序列长度切分，让多台设备分摊一条超长序列的注意力计算。 - 通信什么：注意力需要跨分片交换 K/V（环状传递一类实现）。 - 代价：为长上下文而生（32K、128K 训练）；短序列场景没有收益，属按需开启项。ms-swift 已将 CP 列入 Megatron 并行支持清单（来源：ms-swift《快速开始》框架介绍）。

EP（专家并行，Expert Parallel） - 切什么：MoE 模型的专家分发到不同设备，每个 token 只被路由到少数专家。 - 通信什么：token 的分发与回收（All-to-All），通信量随激活专家数与 token 数增长。 - 代价：与 TP 一样属高通信策略。ms-swift 官方规则：专家层建议用 EP 而不是 ETP（专家张量并行）——ETP 更省显存，但速度较慢；且 MoE 的并行组与稠密部分是分离的（注意力用 tp-cp-dp-pp 组，MoE 用 etp-ep-dp-pp 组），称为并行折叠（来源：ms-swift《Megatron-SWIFT 快速开始》训练技巧）。

VPP（虚拟流水线并行，Virtual Pipeline Parallel） - 切什么：PP 的细化版——每个 stage 再拆成多个不连续的层块（虚拟 stage），交错排布。 - 通信什么：边界通信次数增多，但单个 stage 的工作粒度变细。 - 代价：主要收益是削减流水线空泡，在 PP 深度较大时才有意义；小规模（如双机）基本用不上，知道概念即可。ms-swift 将 VPP 列入 Megatron 并行策略清单（来源：ms-swift《快速开始》）。

3.2 组合策略与选型直觉

真实的大规模训练从来都是组合（混合并行）。So Large LM 给出的经典案例：GPT-3 训练用了 64 个流水线阶段、每阶段跨 6 台 DGX-A100 主机，主机间做数据并行、主机内 8 卡做模型并行（来源：So Large LM 第 8 章 8.2.4 节）。规律是：通信越重的并行，越往高速互联域里收；通信越轻的，越往外放。

选型直觉表（Muse 整理，依据上述官方规则归纳）：

场景	优先组合	理由
模型单机装得下、数据量大	DP（+ ZeRO 切优化器状态，见 §4）	通信每步一次，扩展效率最高
模型单机装不下、设备在同一高速互联域	TP（+SP）打底，外层套 DP	TP 通信最重，必须留在域内
跨机器扩展	PP / DP 优先，TP、EP 不跨机	跨机带宽低，PP 只传边界激活、DP 每步同步一次
MoE 模型	专家层 EP（不首选 ETP），注意力侧 TP/CP/DP/PP 分开组网	官方并行折叠规则
超长上下文	CP 或 SP 降激活显存，配重计算	激活随序列长度膨胀，先治激活
只有两台 Spark（公司实境）	见 §9 实验：DP 与 TP 跨机正面对照	双机是最小可实验规模，结论以实测为准

3.3 一个必须破除的直觉

「并行度越高越快」是错的。§8 的官方实测里，同一个模型把并行从 TP2/EP4/PP2 改成 TP4/EP2/PP2，单步耗时变成基线的 2.58 倍（慢了一倍半）；改成 TP2/EP4/PP1 反而快到 0.80 倍，但每卡显存涨了 88.5%。并行配置是带约束的优化问题：先满足显存约束，再在可行域里找最快的组合——这也是 §9 实验要让学员亲手摸到的东西。

4. 两条路线对照：ZeRO/FSDP 路线 vs Megatron 路线

要点：两条路线解决的是同一个显存问题，哲学不同——ZeRO/FSDP 是「在数据并行上做减法」（模型还是一份逻辑整体，把状态分片存放、用时再拼）；Megatron 是「把模型本身切开算」（TP/PP/EP 从算子与层级动刀）。ms-swift 两条路线都支持，本讲主线是 Megatron 模式。ZeRO 分级定义来自 ms-swift《预训练与微调》；Megatron 侧的实测对照数据来自 ms-swift《Megatron-SWIFT 快速开始》Benchmark 一节；对比表为 Muse 整理。

4.1 ZeRO/FSDP 路线：不切模型，切状态

回到 §2 的显存账：静态占用的大头其实不是权重本身，而是优化器状态（12 字节/参数）。ZeRO 的思路是：DP 每台设备本来就存了一整份权重、梯度、优化器状态，纯属重复——把它们分片，每台只存 1/N，用到时再通过通信取回。

ZeRO-2：对优化器状态、梯度分片；
ZeRO-3：在 ZeRO-2 基础上，再对模型参数分片，最省显存，但通信更多、速度更慢（来源：ms-swift《预训练与微调》「分布式训练」一节，该节同时列出 ms-swift 普通模式支持的分布式方式：DDP、device_map 简易模型并行、DeepSpeed ZeRO2/ZeRO3、FSDP，并提醒 DeepSpeed 省显存但会略降速度）。

FSDP 是 PyTorch 原生的同类实现，理念与 ZeRO-3 接近。对照素材：上海人工智能实验室的新一代训练引擎 XTuner 即基于 PyTorch FSDP 构建，其 FP8 训练文档提到用 FP8 通信缓解「FSDP 通信量大」的固有瓶颈（来源：上海人工智能实验室 XTuner《FP8 训练》）——说明这条路线的痛点与优化方向都在通信上。

代价一句话：ZeRO/FSDP 用通信换显存，编程模型最简单（几乎还是单机写法），是「模型略大于单机、卡数不多」时的默认首选；规模越大、模型越深，它的拼装通信越吃紧。

4.2 Megatron 路线：把并行写进模型

Megatron 路线从一开始就把 TP/PP/SP/CP/EP 做进模型的每一层：权重天生是分片存储的，注意力与 MLP 的切分方式写死在实现里，再配合 Transformer Engine 的融合算子与 FP8 支持，把通信与计算的 overlap 做到极致。它的默认搭配还包含一层 ZeRO 思想——ms-swift 官方说明：Megatron-SWIFT 的并行是 zero1（默认开启分布式优化器）+ 各种并行技术的组合（来源：ms-swift《Megatron-SWIFT 快速开始》训练技巧），即两条路线并非互斥，Megatron 在 DP 维度上同样借用了 ZeRO-1 的优化器分片。

官方 Benchmark（来源：ms-swift《Megatron-SWIFT 快速开始》，注意环境是 A800 集群，只作量级参照，不是对 Spark 的预期）：

场景	Megatron-LM	DeepSpeed-ZeRO2	DeepSpeed-ZeRO3
稠密 Qwen2.5-14B 全参、8K 上下文、单机 8×A800	9.04 s/it，8×64 GB	10.32 s/it，8×80 GB	10.56 s/it，8×58 GB
MoE Qwen3-30B-A3B 全参、8K 上下文、双机 16×A800	9.6 s/it，16×60 GiB	OOM	91.2 s/it，16×80 GiB

两组数据读出的信息：稠密模型上 Megatron 速度领先、显存介于 ZeRO2 与 ZeRO3 之间；MoE 模型上差距被放大到数量级（原文注明 DeepSpeed 该结果有 transformers 版本口径，细节以原文为准）。

4.3 怎么选（Muse 整理）

维度	ZeRO/FSDP 路线	Megatron 路线
心智模型	单机程序 + 状态分片	模型按并行组重构
上手成本	低（`swift sft` + deepspeed 配置）	高（权重格式、并行参数、转换/桥接）
显存效率	ZeRO-3 最高一档	靠 TP/PP/EP 组合，可与 zero1 叠加
速度上限	中	高（尤其 MoE、大规模、长上下文）
典型场景	中小规模全参微调、快速实验	大模型预训练、MoE、追求 MFU 的生产训练
ms-swift 入口	`swift sft/pt/rlhf` + `--deepspeed`	`megatron sft/pt/rlhf` 子命令

公司的选择逻辑：第一阶段的 SFT 课用的是 ZeRO 友好的生态（LLaMA-Factory），量级在单机可控范围；进入进阶阶段、要碰公司同款 MoE 大模型的训练方法论，必须补上 Megatron 这条线——§8 的官方最佳实践就是完全长在 Megatron 上的。

5. 混合精度与稳定性：训得稳，比训得快更重要

要点：BF16 是当前训练的默认精度，FP8 是在 Hopper 之后架构上继续压榨算力与通信的进阶项；稳定性靠三件事——预热、梯度裁剪、损失缩放（FP16 时代），以及一条能看懂的诊断清单。混合精度与优化器口径来自 Datawhale《So Large LM》第 6 章；FP8 数据来自 XTuner《FP8 训练》与 ms-swift 文档对 FP8 训练的支持说明；诊断清单为 Muse 整理（锚点逐项标注）。

5.1 精度路线图

FP32：老默认。数值范围大但慢且占显存，现仅保留在优化器主权重等关键位置。
混合精度（FP16/BF16）：主权重存 FP32，其余计算走低精度，存储减半；FP16 数值下限问题（小于 2⁻²⁴ 的值变 0）靠损失缩放（放大 loss 把梯度拉回可表示范围）解决（来源：So Large LM 第 6 章 6.2.4 节）。BF16 指数位与 FP32 相同、动态范围大，不需要损失缩放，是当前大模型训练的事实默认，ms-swift 全部官方脚本都以 --torch_dtype bfloat16 起步（来源：ms-swift《快速开始》《Megatron-SWIFT 快速开始》）。
FP8：Hopper 架构引入的 8 位浮点。XTuner 文档总结其三项收益：降低通信量（对 FSDP 路线尤其关键）、提升矩阵乘效率、降低计算图显存（保存 FP8 张量而非 BF16）；同时强调要用细粒度量化保证精度。XTuner 的对照数据：256 卡、序列 65536、tp1/ep1/pp1 下，BF16 为 32.77 s/it、2000 tokens/GPU/s，FP8 为 26.75 s/it、2450 tokens/GPU/s，吞吐提升约 22%（来源：上海人工智能实验室 XTuner《FP8 训练》Benchmark）。ms-swift 的 Megatron 模式同样把 FP8 训练列为全方法支持项（来源：ms-swift《Megatron-SWIFT 快速开始》方法支持表）。
对 GB10 的提醒（Muse 整理）：存档文档的 FP8 叙述以 Hopper 及之后的数据中心架构为语境；GB10 上 FP8 训练链路（Transformer Engine 等）是否完整可用，属于 §9 冒烟验证要回答的问题，不预设结论。

5.2 稳定性三件套

学习率预热（warmup）：Transformer 训练必须先用一小段步数把学习率从低值爬升到目标值，否则早期极易不稳定；So Large LM 第 6 章给出的解释是预热可防止 LayerNorm 相关梯度问题导致 Adam 训练失稳（来源：So Large LM 第 6 章 6.2.5 节）。ms-swift 官方脚本对应参数 --lr_warmup_fraction 0.05（见 §7）。
梯度裁剪（gradient clipping）：按全局范数封顶梯度，防止个别坏批次把参数打飞。GPT-3 的公开训练配置即包含梯度裁剪、余弦衰减、权重衰减 0.1、Adam β₁=0.9 / β₂=0.95 等一整套「稳定配方」（来源：So Large LM 第 6 章 6.2.6 节）。
调度与衰减：预热后用余弦等方式衰减到一个小值（官方脚本 --min_lr 即衰减下限），避免训练末期震荡。

5.3 训崩诊断清单（Muse 整理）

训崩不要慌，按「先看曲线形态、再查数据与配置」的顺序排查：

症状	优先怀疑	第一动作
开局几步 loss 爆炸 / NaN	学习率过高、没预热	降 lr、确认 warmup 生效，小数据复现
训练中途 loss 突然尖峰后不恢复	坏数据批次、梯度未裁剪	定位尖峰步的数据分片；确认梯度裁剪开启
loss 平稳但不下降	学习率过低、数据/模板错误	对照第一阶段 SFT 经验，先查数据与 template
显存随步数缓慢爬升后 OOM	序列长度分布不均、长样本后置	查数据长度分布；开启 packing/长度分组（§5.4）；调重计算
第 1 步就 OOM	静态账算错（§2）	回到显存账：降 micro batch、开重计算、加切分
多机训练启动后卡住不动	多机数据预处理不一致	确认 `MODELSCOPE_CACHE` 指向共享存储（ms-swift 官方明确警告：不设此项多机可能因数据不一致卡住，来源：ms-swift《Megatron-SWIFT 快速开始》环境准备）
各 rank 步时差严重、整体被拖慢	样本长度不均衡，最慢 rank 决定步时	packing + 按长度分组采样（见 §5.4）
只有部分 rank 有日志、误以为没启动	Megatron 日志只在 last rank 打印	看 last rank 日志为准（来源：ms-swift《Megatron-SWIFT 快速开始》训练技巧）

5.4 一个容易被忽视的稳定性因素：数据侧的均衡

步时由最慢的 rank 决定——如果各 rank 分到的数据长度分布不均，短序列的 rank 算完只能等。XTuner 的数据流设计专治这个问题：先分布式缓存并统计每条样本的 token 数（meta 信息），再用 packing 把短样本拼满、减少 pad 浪费（SoftPack/HardPack 两种策略），最后用 LengthGroupedSampler 按计算开销分组分发，使各 rank 的每步耗时接近（来源：上海人工智能实验室 XTuner《训练数据流》）。ms-swift 侧对应的提速手段同样包括 packing（官方训练技巧第一条，来源：ms-swift《Megatron-SWIFT 快速开始》）。记住：并行效率一半在模型切分，一半在数据分发。

6. MFU 与训练成本账：怎么算、怎么读

要点：MFU（模型算力利用率）= 实际达成的训练 FLOPs ÷ 硬件峰值 FLOPs，是把「训得快不快」压缩成一个可比数字的口径。本节公式与算例为 Muse 整理；锚点数据来自公司实测与 §4、§8 的官方实测表。

6.1 MFU 怎么算

实际训练 FLOPs/s ≈ 6 × 有效参数量 × 每秒训练 token 数 MFU = 实际训练 FLOPs/s ÷ 峰值 FLOPs/s

其中每秒 token 数直接从训练日志读：global_batch（以 token 计）÷ 每步耗时，或用框架打印的 tokens/s。峰值则取硬件口径值——注意必须注明是哪种精度、哪种测法，不同口径的「峰值」不可比。

算例（Muse 整理）：7B 稠密模型，日志显示稳态 750 tokens/s；则实际算力 ≈ 6 × 7×10⁹ × 750 ≈ 3.15×10¹³ FLOPs/s ≈ 31.5 TFLOPS。以公司实测 GB10 矩阵乘约 90 TFLOPS 为分母，MFU ≈ 35%。经验参照（Muse 整理）：调优良好的大规模稠密训练 MFU 常在 40%–55% 区间；小规模、多机跨节点、MoE 路由不均衡等都会把它拉低。MFU 低不等于「算错了」——先看瓶颈在通信、数据还是空泡，再对症下药（对照 §3、§5.4）。

6.2 成本账：把训练折算成时间与钱

公司场景的成本账分两层（Muse 整理）：

时间成本：总步数 × 每步耗时 = 墙钟时间。用 §2 的公式先估，再用实测 s/it 校准；§4 的官方表就是现成的校准参照（例如 14B 全参 8K 上下文在 8×A800 上约 9 s/it 量级）。
机会成本：双机 Spark 是公司的共享资产——训练占用期间，现行 vLLM 服务要停（见 §9 前置）。一次实验的真实成本 = 占用时长 × 服务不可用窗口，所以实验设计要「一次把变量测全」，这也是 §9 要求同一脚本跑完所有对照配置的原因。

折算示例：§2 中 10 亿 token 的继续训练，单机 MFU 35% 时约 15 天；若通过并行与调优（双机 + MFU 提升到 45% 且并行效率 85%）折算，墙钟 ≈ 15 ÷ 2 ÷ 0.85 ×（35/45）≈ 6.9 天。数字不重要，重要的是这套折算方法：任何「要不要训、训多久」的决策，都应该先在纸上完成这笔账（课后练习第 1 题就是练这个）。

6.3 读官方实测表的正确姿势

§8 的最佳实践实测表是本讲最值得细读的数据，读法示范（细节见 §8）：同一模型、同一数据下，只动一个变量，看显存与耗时两个方向的变化幅度与方向是否符合 §3 的机理预期。能解释「为什么 TP4/EP2/PP2 反而慢 2.58 倍」「为什么关掉重计算省了时间却爆了显存」，才算把 §3–§6 打通。

7. ms-swift Megatron 模式实战导读

要点：Megatron 模式在 ms-swift 里是与普通模式平行的子命令体系（megatron sft / pt / rlhf），数据集与模板处理与普通模式共用。它支持 CPT/SFT/GRPO/DPO/KTO/RM/GKD 等全部任务形态，且全参数、LoRA、MoE、多模态、FP8 均在支持矩阵内（来源：ms-swift《Megatron-SWIFT 快速开始》方法支持表）。本节命令全部摘自该存档原文，版本号与参数以开课时官方文档复核为准。

7.1 环境准备：四个额外组件

除 ms-swift 本体外，Megatron 模式需要（来源：ms-swift《Megatron-SWIFT 快速开始》环境准备）：

# transformer_engine（安装出错可参考官方 issue #3793）
pip install --no-build-isolation transformer-engine[pytorch] --no-cache-dir
pip install pybind11

# apex（可选：不装 apex 时设置 --gradient_accumulation_fusion false 亦可运行）
git clone https://github.com/NVIDIA/apex
cd apex
pip install -v --disable-pip-version-check --no-cache-dir --no-build-isolation \
    --config-settings "--build-option=--cpp_ext" \
    --config-settings "--build-option=--cuda_ext" ./

# mcore-bridge
pip install mcore-bridge -U

# flash_attn（版本勿高于 transformer_engine 的上限要求）
MAX_JOBS=8 pip install "flash-attn==2.8.3" --no-build-isolation

两个必须记住的环境纪律：

多机训练必须设置 MODELSCOPE_CACHE 为共享存储路径，保证数据集缓存共享，否则可能因各节点数据预处理不一致导致训练卡住（官方原文重点标注，来源：同上）。
官方推荐版本基线（节选）：python 3.12、cuda 12.8/13.0、torch 2.8.0/2.11.0、transformer-engine 2.16.0、megatron-core 0.18.0、mcore-bridge 1.6.0、flash-attn 2.8.3（来源：同上「推荐运行环境」表）。官方也提供整套容器镜像（含 swift 4.x 的 modelscope 镜像）作为环境捷径——在 GB10 上，优先考虑容器路线：公司已有实测表明 GB10 的算力表现对 torch 构建来源敏感（vLLM 官方镜像自带 torch 与 pip 直装 torch 在矩阵乘上曾有数量级差距，公司实测数据），环境问题先怀疑构建来源，再怀疑代码。

7.2 传统三步流 vs Mcore-Bridge（推荐）

传统方式分三步（来源：ms-swift《Megatron-SWIFT 快速开始》快速入门案例，环境为 2×80 GiB A100、Qwen2.5-7B-Instruct 自我认知微调）：

# 第一步：HF 权重 → Megatron 格式
CUDA_VISIBLE_DEVICES=0 \
swift export \
    --model Qwen/Qwen2.5-7B-Instruct \
    --to_mcore true \
    --torch_dtype bfloat16 \
    --output_dir Qwen2.5-7B-Instruct-mcore \
    --test_convert_precision true

# 第二步：训练（脚本见 7.3）
# 第三步：Megatron 权重 → HF 格式，再用 swift infer 推理
CUDA_VISIBLE_DEVICES=0 \
swift export \
    --mcore_model megatron_output/Qwen2.5-7B-Instruct/vx-xxx/checkpoint-xxx \
    --to_hf true \
    --torch_dtype bfloat16 \
    --output_dir megatron_output/Qwen2.5-7B-Instruct/vx-xxx/checkpoint-xxx-hf \
    --test_convert_precision true

注意：--test_convert_precision true 会做转换精度校验，但对 MoE 大模型耗时长、内存大，官方提示可酌情去掉；另外转换环节的并行数不必纠结——Megatron-SWIFT 在 mcore 端用 torch_dist 存储格式，训练时可以再调整并行数，不需要在权重转换时指定（来源：同上训练技巧）。

Mcore-Bridge 方式（官方推荐）免去显式转换：训练命令直接以 --model 指向 HF 模型、加 --save_safetensors true，其余参数与传统方式相同（来源：同上）。本讲实操统一走 Bridge 路线。

补充：预训练把子命令换成 megatron pt（使用生成式 template）；Megatron 模式与普通模式共用同一套 dataset/template 处理，packing、loss_scale、agent 训练等能力都在（来源：同上）。

7.3 训练脚本逐段走读

以下为官方快速入门脚本（Mcore-Bridge 版，2 卡、TP=2），按参数组拆解（脚本来源：ms-swift《Megatron-SWIFT 快速开始》；分组讲解为 Muse 整理）：

PYTORCH_CUDA_ALLOC_CONF='expandable_segments:True' \
NPROC_PER_NODE=2 \
CUDA_VISIBLE_DEVICES=0,1 \
megatron sft \
    --model Qwen/Qwen2.5-7B-Instruct \
    --save_safetensors true \
    --dataset 'AI-ModelScope/alpaca-gpt4-data-zh#500' \
              'AI-ModelScope/alpaca-gpt4-data-en#500' \
              'swift/self-cognition#500' \
    --tensor_model_parallel_size 2 \
    --sequence_parallel true \
    --micro_batch_size 16 \
    --global_batch_size 16 \
    --recompute_granularity full \
    --recompute_method uniform \
    --recompute_num_layers 1 \
    --finetune true \
    --cross_entropy_loss_fusion true \
    --lr 1e-5 \
    --lr_warmup_fraction 0.05 \
    --min_lr 1e-6 \
    --num_train_epochs 1 \
    --output_dir megatron_output/Qwen2.5-7B-Instruct \
    --save_steps 100 \
    --max_length 2048 \
    --system 'You are a helpful assistant.' \
    --dataloader_num_workers 4 \
    --no_save_optim true \
    --no_save_rng true \
    --dataset_num_proc 4 \
    --model_author swift \
    --model_name swift-robot

参数组	关键参数	怎么读
启动环境	`NPROC_PER_NODE=2`、`CUDA_VISIBLE_DEVICES=0,1`、`PYTORCH_CUDA_ALLOC_CONF='expandable_segments:True'`	每节点进程数 = 参与的设备数；expandable_segments 是缓解显存碎片的常用设置
模型与产出	`--model`、`--save_safetensors true`、`--finetune true`	Bridge 路线直接吃 HF 模型并存 safetensors；传统路线此处是 `--mcore_model`
并行组	`--tensor_model_parallel_size 2`、`--sequence_parallel true`	本例 TP=2、SP 随 TP 开；未显式给的 PP/DP 由框架按总进程数推导（具体推导与更多参数以官方 Megatron 命令行参数文档为准）
批次组	`--micro_batch_size 16`、`--global_batch_size 16`	全局批次 = micro_batch × 数据并行度 × 梯度累积步数；本例两者相等即无额外累积。改并行度时必须连带核对这一组
重计算组	`--recompute_granularity full`、`--recompute_method uniform`、`--recompute_num_layers 1`	用算力换激活显存的开关组，是 §2 显存账的调节阀；§8 实测显示它对速度/显存的影响幅度可达数十个百分点
优化组	`--lr 1e-5`、`--lr_warmup_fraction 0.05`、`--min_lr 1e-6`、`--cross_entropy_loss_fusion true`	§5.2 三件套的落点：全参 SFT 的 lr 量级（对比 §8 LoRA 用 1e-4）；损失融合是纯收益项
数据组	`--dataset ...#500`、`--max_length 2048`、`--dataset_num_proc 4`、`--dataloader_num_workers 4`	`#500` 表示每数据集取 500 条；多机时别忘了 §7.1 的 `MODELSCOPE_CACHE` 纪律
保存组	`--save_steps 100`、`--no_save_optim true`、`--no_save_rng true`	教学/微调场景关掉优化器与随机状态保存，显著减小 checkpoint 体积；要断点续训则不能这么关

官方训练技巧中与本脚本直接相关、值得背下来的四条（来源：ms-swift《Megatron-SWIFT 快速开始》训练技巧）：① 提吞吐的手段排序——packing、增加 DP、减少重计算、加大计算通信 overlap，MoE 还可以丢弃 token 加速；② DP 最快但最占显存，其他并行都是为降显存而引入；③ TP/EP 尽量不跨节点，跨节点优先 PP/DP；④ 日志只在 last rank 打印，排查「没输出」先想到这一条。

8. 贯穿案例：Qwen3.8-Flash-Next 官方最佳实践拆解

要点：这是本讲的「公司实境锚点」——ms-swift 官方为公司现行服务同款模型写的 Megatron 训练最佳实践（来源：ms-swift《Qwen3.8-Flash-Next 最佳实践》，本节全部数据出自该文档）。它把 §3–§6 的概念全部落到了一个 125B MoE 的真实配置上。

8.1 先对上号：模型与公司的对应关系

维度	官方最佳实践	公司现行环境
模型	Qwen3.8-Flash-Next，125B 总参数（含 51B N-gram 嵌入表），每 token 激活约 6B	同款模型，线上为 NVFP4 量化 + vLLM 推理
架构要点	GDN + QSA 混合（每 4 层中 3 层 Gated DeltaNet 压缩历史、1 层 Qwen Sparse Attention 做长程检索，QSA 预算 2048 token）；Gated Residual（每层 4 路残差分支）；原生上下文 262,144 token	推理侧已领教其 MoE 稀疏性（每步只激活约 6B，是 decode 带宽账的关键输入，第一阶段已算过）
训练侧新信息	N-gram 嵌入表可 offload 到主机内存；训练走 Megatron SFT + GRPO 两套官方脚本	为第二阶段 A2 讲（GRPO/蒸馏深化）与本讲实操提供官方锚点

一个对 GB10 特别有共鸣的点：这张 51B 的 N-gram 嵌入表在 BF16 下约 95 GiB，并且只能沿 TP 切分——单机装不下又切不开时，官方给的解法是整表卸载到 CPU 主内存（统一内存架构的 Spark 对这类「权重放主机内存」的玩法天然不陌生，推理侧已有类似经验）。

8.2 SFT 脚本拆解：每个参数都在解一道题

官方 8 卡 LoRA 微调脚本（节选核心参数，完整脚本见存档原文）：

# 8*70G
PLE_CPU_OFFLOAD=1 \
CUDA_VISIBLE_DEVICES=0,1,2,3,4,5,6,7 \
NPROC_PER_NODE=8 \
PYTORCH_CUDA_ALLOC_CONF='expandable_segments:True' \
megatron sft \
    --model Qwen/Qwen3.8-Flash-Next \
    --dataset 'swift/Chinese-Qwen3-235B-2507-Distill-data-110k-SFT#2000' \
    --tuner_type lora --lora_rank 8 --lora_alpha 32 \
    --target_modules in_proj out_proj linear_proj linear_qkv \
    --tensor_model_parallel_size 2 \
    --expert_model_parallel_size 4 \
    --expert_tensor_parallel_size 1 \
    --pipeline_model_parallel_size 2 \
    --decoder_first_pipeline_num_layers 12 \
    --sequence_parallel true \
    --moe_permute_fusion true \
    --recompute_granularity full --recompute_method uniform --recompute_num_layers 1 \
    --padding_free true \
    --max_length 8192 \
    --micro_batch_size 1 --global_batch_size 8 \
    --lr 1e-4 \
    --save_steps 500 \
    --output_dir output

逐项对应回前面的章节（Muse 整理，参数与数值均出自上述官方脚本）：

并行组合 TP2 / EP4 / ETP1 / PP2：§3.2 的组合直觉在一个脚本里全齐了——注意力侧 TP=2，专家侧 EP=4 而 ETP=1（正是「专家层用 EP 不用 ETP」的官方规则落地），层间 PP=2 分摊权重；
--decoder_first_pipeline_num_layers 12：全模型层数在两个 PP stage 间不均分（stage 0 只放 12 层）。官方解释：PLE 层（第 2 层）落在 stage 0，它的激活与查表开销都压在该 stage，按 24/24 均分会两边不均——这是 §3 里 PP「切分不均则瓶颈在最重 stage」的真实注脚，调 PP 先看每 stage 的实际负载，不看层数平均；
PLE_CPU_OFFLOAD=1：把 95 GiB 的 N-gram 表卸到 CPU。代价官方写明：开启后该表冻结不训练——LoRA 本来就不训它，无影响；但全参训练下这部分权重会「静默地不参与训练」，属于必须知道的行为变更（列入 §10 坑清单）；
LoRA 目标模块 in_proj out_proj linear_proj linear_qkv：对应 GDN/QSA 混合架构的线性层命名，与稠密 Qwen 的 all-linear 写法不同——换模型时 target_modules 必须按架构核对，不能抄旧脚本；
--padding_free true + --moe_permute_fusion true：前者是 packing 思想在 Megatron 侧的落地（去掉 pad 浪费，呼应 §5.4），后者是 MoE 置换融合的算子级优化。

8.3 实测表精读：本讲最重要的一张表

官方实测条件：8 卡、LoRA rank 8、TP2/EP4/PP2、micro_batch 1、global_batch 8、等长合成数据；显存为每卡峰值，耗时以 seq=2048 基线为 1.00×（相对值，越大越慢）。下表节选关键行（来源：ms-swift《Qwen3.8-Flash-Next 最佳实践》实测数据表）：

变量	配置	每卡显存	单步耗时（相对）	读出的机理
基线	seq=2048，重计算 full	75.6 GiB	1.00×	—
序列变长	seq=8192	93.3 GiB（+23.4%）	1.32×	激活随序列长度膨胀（§2 显存账的激活项）
PLE 卸载	seq=8192 + offload	77.7 GiB（仅 +2.8%）	1.27×	95 GiB 级大表卸载后，长序列显存几乎回到基线
重计算改 selective	seq=4096	92.1 GiB（+21.8%）	0.75×	少算一遍激活换速度，显存是代价
关重计算	seq=4096	92.1 GiB（+21.8%）	0.74×	与上行同理：重计算本质是「显存换时间」
并行改 TP4/EP2/PP2	seq=8192	105.7 GiB（+39.8%）	2.58×	并行改错方向，通信反噬（§3.3）
并行改 TP2/EP4/PP1	seq=8192	142.5 GiB（+88.5%）	0.80×	去掉 PP 更快，但显存爆炸——先有余量才配谈速度

精读结论（Muse 整理）：① 所有旋钮都是交换，没有免费的午餐；② 显存不够时先动重计算与卸载，速度不够时先看并行组合与 padding/packing，而不是无脑加卡；③ 这张表是在 8 卡数据中心环境测的，绝对值与 Spark 无关、机理与 Spark 有关——实操（§9）就是要在双机上复现出属于我们自己的小号版本表。

8.4 GRPO 脚本（A2 预告，只点关键差异）

同一文档的 GRPO 脚本与 SFT 共用同一套并行与卸载配置，差异点：megatron rlhf --rlhf_type grpo；rollout 用 colocate 模式的 vLLM（--use_vllm true --vllm_mode colocate，推理与训练同机分时复用），并配 --sleep_level 2、--offload_model true、--offload_optimizer true 在采样与训练阶段间腾挪显存；奖励函数 --reward_funcs accuracy、每题采样 --num_generations 4、学习率 5e-5（来源：ms-swift《Qwen3.8-Flash-Next 最佳实践》GRPO 一节）。这正是 A2 讲的主战场，本讲只需建立印象：推理引擎在 RL 训练里是 rollout 工厂，训练与推理的边界在 GRPO 里是糊的——这也是进阶专题把训练与推理放在同一模块序列里的原因。

9. 实操：双机并行对照实验

总原则（Muse 整理）：先冒烟、后对照；一次占用、测完全部变量。ms-swift 在 GB10/ARM 上官方未明示支持（其硬件清单为 NVIDIA CUDA 系 / AMD / 国产 NPU 等，未列 GB10），所以本实操的第一步不是训练，而是回答「这条链路在 Spark 上通不通」；不通就走降级路径，不在环境问题上无限耗时间。

9.0 前置（运维纪律）

约维护窗口：训练实验需停现行 vLLM 服务（容器 vllm-fn，占约 96 GB 内存），实验结束按原流程恢复并做健康检查（承接第一阶段运维课的变更纪律）。
两台 Spark 系统与驱动版本对齐，时钟同步；预留磁盘给 checkpoint。
全程留痕：所有命令、版本、日志、记录表存入实验目录，验收以记录表为准。

9.1 第一步：环境冒烟验证清单（预计 30–40 分钟，硬性时间盒）

逐项执行，任一项失败先记录原始报错，再按 9.4 决策是否降级——不在单点死磕超过 15 分钟。

#	检查项	做法	通过标准
1	架构与设备基线	记录系统架构、驱动、可用内存；跑一遍第一阶段的带宽/矩阵乘微基准	数值与公司基线（带宽 224–226 GB/s 量级）无数量级偏差
2	隔离环境	新建独立 venv/容器（优先官方容器镜像路线，见 §7.1），不污染现行服务环境	环境可复现（留 requirements/镜像名）
3	ms-swift 安装与导入	`pip install ms-swift -U`（版本以开课时为准）；导入 swift、torch 并打印版本与设备可用性	无导入错误，torch 能识别 GB10 设备
4	Megatron 组件安装	按 §7.1 依次装 transformer-engine、mcore-bridge、flash-attn（apex 可选）；记录每步结果	三件套导入成功；某件失败则记录——FP8/TE 相关失败直接标记「FP8 线索关闭」，不阻塞主线
5	普通模式 10 步训练	用 ms-swift《快速开始》的 LoRA 脚本骨架改小数据量跑 10 步：模型 Qwen3-4B 级别、数据集 `swift/self-cognition#160`、`per_device_train_batch_size 1`、`gradient_accumulation_steps 16`（全局批次 16 × 10 步 = 160 条）（脚本骨架来源：ms-swift《快速开始》）	完成 ≥10 个优化步；loss 为有限值且无 NaN；checkpoint 正常保存；记录峰值内存
6	Megatron 模式最小跑通	以 §7.3 官方脚本为骨架，改单机单进程：`NPROC_PER_NODE=1`、`--tensor_model_parallel_size 1`、小模型（Qwen2.5-0.5B 级别，以开课时模型库为准）、数据集取 `#500` 子集、1 个 epoch	训练启动并完成；日志在 last rank 正常打印（本例即本进程）；产出 checkpoint 可被 `swift infer` 加载
7	双机连通预检	两机互通、共享目录可见；在一台上准备好 `MODELSCOPE_CACHE` 共享路径（§7.1）	共享路径双机可读写

冒烟结论只有三种：全通（进 9.2）、主线通、FP8/TE 不通（进 9.2，实验中关闭 FP8 相关项）、主线不通（进 9.4 降级）。

9.2 第二步：基线与变量对照（预计 30–40 分钟）

固定项（全程不许动）：模型 Qwen2.5-7B-Instruct、LoRA（参数口径参照 §7.3 与官方快速入门）、数据集 alpaca-gpt4-data-zh#500 + alpaca-gpt4-data-en#500 + self-cognition#500、max_length 2048、1 个 epoch、同一随机种子、同一日志采样口径。多机启动方式以官方多机示例为准（ms-swift 在 examples/megatron 提供多机等案例，来源：ms-swift《Megatron-SWIFT 快速开始》；普通模式多机脚本见 ms-swift《预训练与微调》所引 examples/train/multi-node）。

配置	内容	变量
E0 单机基线	单台 Spark、Megatron 模式、TP=1、无跨机通信	基线
E1 双机 DP	双机各持完整模型副本做数据并行（Megatron 侧以 DP 维度扩展、并行参数只开 DP）	跨机通信模式 = 每步梯度 AllReduce
E2 双机 TP	双机 TP=2（`--tensor_model_parallel_size 2 --sequence_parallel true`，与 §7.3 官方脚本同构，只是把同机双卡换成双机各一卡）	跨机通信模式 = 每层 AllReduce
E3（选做）双机 PP	双机 PP=2，按层各半	跨机通信模式 = 边界激活传递

预期（先写假设、再看数据）：E2 的每层通信走跨机链路，大概率被通信拖住；E1 通信集中在步末，效率应更高；E3 通信最少但要注意两 stage 负载均衡。假设写在实验开始前，结论以实测为准——如果数据打脸假设，分析为什么（这本身就是最好的学习材料）。

9.3 第三步：记录表与成本账

每组配置跑完立即填表（模板如下），并按 §6 公式补算 MFU（峰值口径注明所用数值来源）：

配置	并行参数	稳态 s/it	tokens/s	每步 token 数	峰值内存/台	MFU 估算	异常与备注
E0	TP1
E1	DP2
E2	TP2+SP
E3	PP2

收尾产出（一页纸）：① 哪种配置最快、快多少；② 显存分别花在哪（对照 §2 的账解释）；③ 若明天要真训一个 7B LoRA，你选哪组配置、为什么；④ 本次实验的 MFU 水平与官方 A800 数据（§4）差在哪、可能差在哪一环。

9.4 降级路径：Colab A100 执行版

触发条件：冒烟 9.1 第 5/6 项主线不通，或双机多机启动无法在时间盒内跑通。

Colab（AI Pro）执行：在 A100 上跑 E0 与 E2'（单机双卡不可得时，用单卡 TP1 基线 + 「重计算开/关、packing 开/关」两个变量组替代跨机对照——变量换了，但「单变量对照 + 填表 + 算 MFU」的方法不变）；官方快速入门案例本身就是 2×A100-80GiB 口径，在 Colab 上可近乎原样复现（来源：ms-swift《Megatron-SWIFT 快速开始》）。
Spark 只做观察与数据对照：复测 §2 两笔账的输入（带宽、矩阵乘、统一内存占用曲线），把自测峰值代入 MFU 公式，与 Colab 实测、官方 A800 表三方对照，写差异分析。
降级不降标准：记录表、成本账、一页纸结论照常交付，并在报告头注明执行环境与降级原因（这份记录本身就是下一轮 GB10 兼容性排查的输入）。

9.5 验收标准

[ ] 冒烟清单 7 项逐项有结论（通过/失败+原始报错），无「没测」项；
[ ] ≥3 组配置完成对照（降级路径 ≥2 组 + 三方数据对照），记录表无空格；
[ ] 每组配置有 MFU 估算且注明峰值口径；
[ ] 一页纸结论能回答「双机 Spark 上 7B 级 LoRA SFT 选哪种并行、为什么」，且引用了自己的实测数字；
[ ] 实验结束现行 vLLM 服务已恢复并通过健康检查。

10. 常见坑清单

来源标注：官方文档明示的坑标「文档明示」，公司环境特有的标「公司实境」。

多机训练卡在启动（文档明示）：没设 MODELSCOPE_CACHE 共享路径，各节点数据预处理结果不一致。开训前先检查这个环境变量（ms-swift《Megatron-SWIFT 快速开始》）。
flash-attn 装了最新版反而报错（文档明示）：flash-attn 版本不能高于 transformer-engine 的上限要求，按官方指定版本装（同上）。
没装 apex 训练起不来（文档明示）：apex 是可选的，缺它时加 --gradient_accumulation_fusion false 即可（同上）。
以为训练没启动（文档明示）：Megatron-SWIFT 日志只在 last rank 打印，其他 rank 沉默是正常现象（同上）。
大模型权重转换慢到怀疑人生（文档明示）：--test_convert_precision true 在 MoE 大模型上耗时且吃内存，可酌情去掉；优先走 Mcore-Bridge 免转换路线（同上）。
开了 PLE offload 后全参训了个寂寞（文档明示）：offload 的 N-gram 表被冻结，全参训练下静默不更新——用之前先想清这部分参数到底要不要训（ms-swift《Qwen3.8-Flash-Next 最佳实践》）。
PP 均分层数、stage 0 累死（文档明示）：含重型早期层的模型（如 PLE 层在第 2 层）要手动调 --decoder_first_pipeline_num_layers 拉平负载（同上）。
QLoRA 训完没法合并部署（文档明示）：QLoRA 模型无法 Merge LoRA，官方建议部署导向的微调别用 QLoRA，用 LoRA/全参训完再量化（ms-swift《预训练与微调》）。这条在第一阶段 SFT 课已强调，进阶阶段继续算数。
DDP + 梯度检查点报 ready only once（文档明示）：加 --gradient_checkpointing_kwargs '{"use_reentrant": false}' 或改用 DeepSpeed（同上）。
GB10 上装出来的 torch 慢一个数量级（公司实境）：pip 直装 torch 与优化构建的差异在 GB10 上被放大（公司矩阵乘实测对比）。环境冒烟第 1、3 项就是为它设的——数值不对，先换构建来源，别改训练参数背锅。
把官方 A800 的 s/it 当成 Spark 的预期（Muse 整理）：官方 Benchmark 与最佳实践实测都是数据中心集群数据，在本讲只作机理与量级参照；Spark 的数字只能来自 §9 自己的实验。
并行度越加越慢还继续加（文档明示的反例）：§8 实测 TP4/EP2/PP2 比基线慢 2.58 倍。调并行的正确顺序是：先算显存账定下限，再小步单变量试，每步留记录。

11. 课后练习与延伸阅读

11.1 课后练习

纸面账：为 Qwen3-32B 级别模型做全参 AdamW 训练估算——静态显存多少？公司双机在 ZeRO-3、LoRA 两种路线下分别缺什么？给出你的判断与依据（口径见 §2、§4）。
MFU 练习：给定一段（虚构）训练日志：14B 模型、global batch 折合 65,536 token/步、稳态 9.0 s/it、运行于 8 卡且单卡峰值按 312 TFLOPS（BF16）计——算总 MFU，并说明这个数字为什么不能直接和 §6 的 GB10 算例比（口径见 §6.1）。
读表练习：回到 §8.3 的实测表，若显存预算卡在每卡 80 GiB、目标 seq=8192，你选哪一行配置？写出取舍理由（提示：先筛显存可行域，再比速度）。
选型练习：一个 30B MoE 模型要在 16 卡单机房集群上全参训练，用 §3.2 与官方选型规则给出一组 TP/EP/PP/DP 组合并逐项说明放置位置（哪些不跨节点）。
数据侧练习：读 XTuner《训练数据流》后，用自己的话解释「为什么最慢的 rank 决定步时」以及 LengthGroupedSampler 的解法，并指出 ms-swift 侧的对应手段。

11.2 延伸阅读（逐条标来源）

Datawhale《So Large LM》第 8 章《分布式训练》（存档 datawhale/07-SoLargeLM-分布式训练.md）：本讲 §3 的理论底本，章末延伸阅读指向 OneFlow《常见的分布式并行策略》。
Datawhale《So Large LM》第 6 章《模型训练》（存档 datawhale/06-SoLargeLM-模型训练.md）：Adam、混合精度、学习率与 GPT-3 训练配方的完整推导；章末附 Lilian Weng 混合精度长文等链接。
ms-swift《Megatron-SWIFT 快速开始》（存档 modelscope/04-Megatron并行训练快速开始.md）：本讲 §7 的原文；其引用的 Megatron 命令行参数文档与 Mcore-Bridge 文档已于 P1 补抓存档（modelscope/10-Mcore-Bridge.md、modelscope/11-Megatron命令行参数.md、modelscope/09-Megatron-LoRA训练.md），细读以存档为准、版本以官方文档站当前版本为准。
ms-swift 官方 examples/megatron 目录（GitHub，ms-swift 仓库）：packing、多机、32K 上下文、DPO、MoE、预训练等完整脚本，§9 多机启动以此为准。
ms-swift《Qwen3.8-Flash-Next 最佳实践》（存档 modelscope/03-Qwen3.8-Flash-Next最佳实践.md）：§8 原文，含 GRPO 完整脚本（A2 讲主素材）。
上海人工智能实验室 XTuner《训练数据流》（存档 internlm/05-XTuner-训练数据流.md）与《FP8 训练》（存档 internlm/06-XTuner-Float8训练.md）：FSDP 路线的数据工程与 FP8 实践对照读物。
NVIDIA NCCL 集合通信官方文档（user guide，collectives 一节）：AllReduce 等原语的权威定义，So Large LM 第 8 章亦引用此文档；属一手官方来源，以官网当前版本为准。

讲义版本：v1（2026-10-20）。已知待复核项：ms-swift 版本基线与参数（开课时按官方文档站复核）；GB10 上 ms-swift / Transformer Engine / flash-attn 的实际可用性（由 §9.1 冒烟清单回答，结论回填本讲义后发布 v1.1）。

🎓 AI 培训讲义 · Wiki