章节导航 第 8 章 / 共 16 章
第 8 章 第二部分：预训练

分布式训练工程

数据并行、模型并行、流水线并行——在数千张 GPU 上训练大模型的工程实践

分布式训练 数据并行 模型并行 流水线并行 通信

为什么需要分布式训练

一个 70B 参数的模型，仅权重就需要 140GB（BF16 格式）。加上优化器状态（mm 和 vv，各占 280GB）、梯度（140GB）和激活值，单卡（即使 80GB H100）完全无法装下。

更重要的是训练时间。以 2T tokens 训练 70B 模型为例：

FLOPs≈6×N×D=6×70×109×2×1012=8.4×1023\text{FLOPs} \approx 6 \times N \times D = 6 \times 70 \times 10^9 \times 2 \times 10^{12} = 8.4 \times 10^{23}

一张 H100 的 BF16 算力约为 990 TFLOPS，但实际 MFU（Model FLOPs Utilization）通常在 40-50%：

时间=8.4×1023990×1012×0.45≈1.89×109 秒≈60 年\text{时间} = \frac{8.4 \times 10^{23}}{990 \times 10^{12} \times 0.45} \approx 1.89 \times 10^9 \text{ 秒} \approx 60 \text{ 年}

一张卡需要 60 年。用 2048 张卡，约 11 天。这就是为什么大模型训练必须是分布式的。

并行策略全景

现代分布式训练通常组合使用多种并行策略（3D 并行 甚至 4D/5D 并行）：

            ┌─────────────────────────────────┐
            │           3D+ Parallelism        │
            │                                  │
            │  ┌──────┐  ┌──────┐  ┌───────┐  │
            │  │ Data  │  │Tensor│  │Pipeline│  │
            │  │Parallel│ │Parallel│ │Parallel│ │
            │  └──────┘  └──────┘  └───────┘  │
            │     +                             │
            │  ┌──────────┐  ┌──────────────┐  │
            │  │  Expert   │  │  Context/    │  │
            │  │ Parallel  │  │  Sequence    │  │
            │  │  (MoE)    │  │  Parallel    │  │
            │  └──────────┘  └──────────────┘  │
            └─────────────────────────────────┘

数据并行（Data Parallelism）

基本 DP

最简单的并行策略：每张卡都持有完整的模型副本，各自处理不同的数据 batch，然后同步梯度。

gglobal=1K∑k=1Kgkg_{global} = \frac{1}{K}\sum_{k=1}^{K} g_k

使用 AllReduce 操作在所有 GPU 间同步梯度。

ZeRO（Zero Redundancy Optimizer）

DeepSpeed ZeRO（Rajbhandari et al., 2020）是数据并行的革命性优化。核心思想：DP 中每张卡都存了完整的优化器状态、梯度和参数——这是巨大的冗余。

ZeRO 分三个阶段消除冗余：

阶段分片内容每卡显存（70B 模型）
无 ZeRO全部~1120 GB
ZeRO-1优化器状态~560 GB
ZeRO-2+ 梯度~420 GB
ZeRO-3+ 参数~280/K GB（K 卡）

ZeRO-3 将所有内容均匀分片到 K 张卡上，需要时再通过通信获取。

FSDP（Fully Sharded Data Parallel）

PyTorch FSDP 是 ZeRO-3 在 PyTorch 中的原生实现。核心 API：

from torch.distributed.fsdp import FullyShardedDataParallel as FSDP

model = FSDP(
    model,
    sharding_strategy=ShardingStrategy.FULL_SHARD,
    mixed_precision=MixedPrecision(param_dtype=torch.bfloat16),
    auto_wrap_policy=transformer_auto_wrap_policy,
)

上面展示的是 FSDP1 的 API。PyTorch 2.5+ 引入了 FSDP2，基于 DTensor 重构，带来了几个关键改进：

  • Per-parameter sharding：每个参数独立分片，而非 FSDP1 的 flat_param（将多个参数拼接再分片）。这使得分片边界与参数边界对齐，简化了调试和混合精度配置。
  • 与 TP/CP 原生组合：DTensor 统一了数据并行和张量并行的分片逻辑，FSDP2 + TP 不再需要手动处理两者的交互。
  • 更灵活的内存管理：可以按层控制是否分片，对 MoE 等非均匀结构更友好。

TorchTitan（Liang et al., 2024）是 PyTorch 官方推荐的端到端分布式训练系统，原生集成了 FSDP2、Zero-Bubble PP 和 Context Parallelism，作为统一的 3D+ 并行训练平台。

MatrixFSDP：矩阵优化器的 ZeRO-3 兼容方案

MatrixFSDP（Ming Gao et al., 2026-07-07）解决了第六章推荐的 Muon/SOAP 等矩阵优化器与 ZeRO-3 参数分片的根本冲突：

问题：Muon/SOAP/Shampoo 需要在 2D 权重矩阵上运行正交化/预条件计算，但 ZeRO-3 将参数均匀分片到所有 GPU——每个 rank 只持有权重的 1/K 行。传统方案要么每步通过 all-gather 重建完整矩阵（FSDP2-Muon，巨大通信开销——8 节点下优化器步延迟达 5 秒），要么牺牲 ZeRO-3 内存效率降级到 ZeRO-1。

MatrixFSDP 方案：改变分片归属——owner-shaped sharding：每个 2D 权重矩阵的 owner rank 持有完整矩阵，其他 rank 留空。梯度归约后直接本地计算 Newton-Schulz 迭代，无需 all-gather 重建。

效果（64 A100 实测）：

  • 优化器步延迟：单节点 4.2×、8 节点 54.6× 加速
  • 端到端吞吐量：最高 2.15× 加速
  • 支持 32B 参数模型 / 10GB per rank
  • 数值等价于 DDP Muon（无精度损失）

意义：MatrixFSDP 让 Muon/SOAP 在大规模 ZeRO-3 训练中从”可选但贵”变为”默认可用”。随着第六章推荐的矩阵优化器成为主流，MatrixFSDP 是连接优化器和分布式系统的关键基础设施。

张量并行（Tensor Parallelism）

基本原理

Megatron-LM（Shoeybi et al., 2020）提出的方法：将模型内部的权重矩阵沿特定维度切分到多张卡上。

MLP 层的切分：

对于 Y=XW1⋅W2Y = XW_1 \cdot W_2，将 W1W_1 按列切分，W2W_2 按行切分：

W1=[W1(1),W1(2)],W2=[W2(1)W2(2)]W_1 = [W_1^{(1)}, W_1^{(2)}], \quad W_2 = \begin{bmatrix} W_2^{(1)} \\ W_2^{(2)} \end{bmatrix}

每张卡计算 Y(i)=XW1(i)W2(i)Y^{(i)} = X W_1^{(i)} W_2^{(i)}，然后做 AllReduce 得到最终结果。

Attention 层的切分：

按 head 维度切分——每张卡计算一部分 attention heads。

通信开销

张量并行每一层都需要两次 AllReduce 通信（前向 + 反向各两次）。因此张量并行只适合在高带宽互连（如 NVLink）的卡之间使用，通常限制在同一节点内的 4-8 张卡。

如果非跨节点不可，可以先砍位宽。上面这个限制之所以越来越像一种被迫的妥协，原因值得说清：TP 的 all-reduce 夹在两个有依赖的矩阵乘之间，所以它既无法被计算掩盖，又会随着”算力增速快于互连带宽”而持续恶化。降低位宽本来是最直接的解法——4-bit 替代 16-bit 能把通信量砍到近 1/4——但 all-reduce 必须求和，每次调用都会注入一次舍入误差，而模型质量取决于这些误差跨层如何累积，现有方法逐个调用各自处理，不控制累积。

Echo（arXiv:2610.14277，2026-10）给出了一条误差受控的 4-bit 路径：4-bit 传数据、高精度求和（任意 GPU 数下每个值每次调用最多被量化两次）；求和过程把注入的误差显式暴露出来并反馈到后续调用，让旧误差相互抵消而非累积；论文证明了累积误差的上界与网络深度无关。

实测（A100）：1 GB 消息上比 16-bit NCCL all-reduce 快 2.09×；空闲互连下 TTFT 最高 1.16×、训练步最高 1.09×，有背景流量时分别升到 1.44× / 1.38×；Qwen3-8B 上 7 个基准的平均精度与 16-bit 推理相差 不到 0.4 分；100 亿 token 预训练的最终 loss 比 16-bit 训练高不到 0.9%。

✅ 一条容易被漏掉的限定：Echo 不需要 FP8/FP4 硬件。这意味着它不是”等下一代硬件”的方案，在 A100 这一代就能落地——这点比加速比本身更值得记住。

⚠️ 成熟度与口径提示：2026-10 的单篇预印本，无独立复现；上述加速比与精度损失均为作者自评。训练侧的 loss 数字是 100 亿 token 规模，与本章 Kimi K2 的万亿 token 案例不可直接比较；“1.38ד依赖背景流量的设定，可复现性弱于”2.09ד那条原语级数字。

流水线并行（Pipeline Parallelism）

基本思想

将模型的不同层分配到不同的 GPU 上，形成”流水线”：

GPU 0: Layer 0-7    → GPU 1: Layer 8-15  → GPU 2: Layer 16-23 → GPU 3: Layer 24-31

Bubble 问题

简单的流水线会产生大量的”气泡”（bubble）——某些 GPU 空闲等待上游/下游的数据：

GPU 0: [F1][F2][F3][F4]                    [B4][B3][B2][B1]
GPU 1:     [F1][F2][F3][F4]            [B4][B3][B2][B1]
GPU 2:         [F1][F2][F3][F4]    [B4][B3][B2][B1]
GPU 3:             [F1][F2][F3][F4][B4][B3][B2][B1]
                                ^^^^bubble^^^^

Bubble 比例约为 (P−1)/(P−1+M)(P-1)/(P-1+M)，其中 PP 是 pipeline 阶段数，MM 是 micro-batch 数。

1F1B 调度

PipeDream 提出的 1F1B（One Forward One Backward）调度策略大幅减少 bubble：

GPU 0: [F1][F2][F3][F4][B1][F5][B2][F6][B3][B4][B5][B6]
GPU 1:     [F1][F2][F3][B1][F4][B2][F5][B3][F6][B4][B5][B6]
...

交替执行前向和反向，显著减少了空闲时间。

Zero-Bubble Pipeline

Qi et al. (2024) 提出了零气泡流水线并行，通过更精细的调度几乎消除了 bubble。核心思想是将反向传播拆分为输入梯度计算和权重梯度计算两个阶段，更灵活地调度。

上面两条都是层间流水线。序列维度上也有对应的工作：BSIPipe（arXiv:2610.14935，2026-10）针对现有序列级方法单向调度子序列的吞吐上限，改为在子序列级协同调度两条反向的 V 形交错流水线；用 basic-unit 拼接使激活显存与子序列数无关，用拓扑感知设备映射加通信计算重叠消除双向调度的死锁风险，并可与 TP 组合。GPT 与 LLaMA3 上相对 SOTA 序列级基线平均 1.11×–1.13×。增益偏小且为单篇预印本，此处只作线索，不作工程选型依据。

序列并行（Sequence/Context Parallelism）

当序列很长时（如 128K tokens），单卡可能无法装下完整的激活值。序列并行将长序列切分到多张卡上。

Ring Attention

Ring Attention（Liu et al., 2023）是最优雅的序列并行方案：

  1. 将序列切分为 KK 段，分配给 KK 张卡
  2. 每张卡计算自己的 Q 与当前 K、V 的 Attention
  3. 以环形方式传递 K、V 给下一张卡
  4. 经过 KK 轮环形传递后，每张卡都计算了完整的 Attention

通信与计算可以重叠（pipeline），实现近线性扩展。

DeepSpeed Ulysses

DeepSpeed Ulysses 使用 AllToAll 通信在序列维度上分片：

  1. 每张卡持有序列的一部分，但所有 attention heads
  2. AllToAll 交换 → 每张卡持有所有序列，但部分 heads
  3. 计算 attention
  4. AllToAll 交换回来

Expert 并行（MoE 专用）

MoE 模型引入了独特的并行维度——不同专家可以放在不同的 GPU 上。

All-to-All 通信

每个 token 需要路由到其被选中的专家所在的 GPU。这需要 All-to-All 通信：

Token 1 → Expert 3 (GPU 1)
Token 2 → Expert 7 (GPU 3)
Token 3 → Expert 1 (GPU 0)
Token 4 → Expert 5 (GPU 2)

All-to-All 的通信模式不规则，对网络带宽和拓扑敏感。这句话可以换成量化的说法：在每节点 8 张 AMD MI300X 的集群上，EP32 + top-2 时 all-to-all 占训练步时间的 45%，top-6 时占到 60%（arXiv:2610.09372，2026-10）。专家数越多、top-k 越大，这个占比越接近”训练步里有一大半在等通信”——这正是本章前面”专家数增长使 EP 从可选变为常态”这一趋势的代价数字。

DeepSeek 的 EP 策略演进

DeepSeek V3 的 256 个专家分布在 8 个节点上，每个节点 32 个专家。为减少跨节点通信：

  1. 限制跨节点路由：每个 token 最多路由到 kk 个不同节点的专家
  2. 节点内共享专家：1 个共享专家在所有 GPU 上都有副本
  3. 负载均衡 loss：训练时添加辅助 loss 促进均匀路由

V4-Pro 的变化，以及一个前提的反转。到 V4-Pro，每层路由专家数从 V3 的 256 提高到 384，而每 token 激活的专家数从 8 降到 6（整体更稀疏）；NVIDIA 的参考训练配置要求 EP64，跨 64 个节点共 512 张 H100。这意味着上面”尽量减少跨节点”这套策略的前提已经改变：当专家数达到数百个时，专家权重本身就必须靠 EP 分散到多个节点，跨节点 EP 已是常态而非可选优化项。

来源等级提示：上述 V4-Pro 配置（384 路由专家 / 激活 6 / EP64 跨 64 节点）来自百度 LoongForge 团队的公开工程博客（2026-09）对 NVIDIA 参考训练配置的转述，非 DeepSeek 官方技术报告的一手数据，引用时请注明。

由此产生的新问题：一旦 EP 域跨出单节点，“把热点专家复制到哪张空闲 GPU”就不再是等价选择——节点内走 NVLink、跨节点走 InfiniBand，搬运一次热点专家权重的成本可能差一个数量级。这正是下一节的主题。

路由相关性：从源头减少跨节点分配

前面两节是”V3/V4-Pro 怎么限跨节点”与”热点出现后怎么搬专家”，中间还缺一层：有没有办法让”跨节点”这件事从一开始就发生得更少。

答案是利用路由相关性。Expert Coupling（arXiv:2610.09372，2026-10）先给了一个此前没人用的观测：预训练早期路由器就已经学会了相关模式——top-2 下某一层中仅 0.8% 的专家对，就被 42% 的 token 同时选中；而且一个 token 在本层选的专家，可以预测它在下一层会选的专家。这两个规律一个在层内、一个跨层，都能拿来减少搬运：

  1. 相关性放置：把经常被同时选中的专家放到同一张 GPU，配合”每个 token 对每张 GPU 只发一次”的 dispatcher，最多消掉 58% 的 dispatch 行。
  2. token 重排：当序列并行把 token 分片到 EP 组时，借 attention 之后那次 reduce-scatter 顺手把 token 挪到”预测下一层会用到的专家”所在的 GPU。单节点内”token-专家分配命中本地 GPU”的比例从 12.5% 提到 59%。

在 Megatron-LM 上、EP 度 8–64、top-2 与 top-6 路由下，两者把 all-to-all 时间降低 1.16–2.63×，端到端 step time 最高降低 1.41×。

🔑 与下一节方法的根本区别：这两个手段不改变路由决策与专家参数，模型在数学上完全等价。而”动态副本 / 负载均衡”类方法会改变 token 到专家的映射，属于另一种妥协。等价性意味着它可以直接叠加在负载均衡之上。

两句结构性提醒。第一，本章后面讲的 TAOT / LPLB / Echo 都是”热点已经发生之后如何重新均衡”，本节的手段是”让热点少跨节点”——前者削峰，后者减少搬运需求，两者不在同一层，可以叠加。第二，本章上一节那句”两份均衡质量几乎相同的放置方案，实际通信开销可能天差地别”，在本节第一次有了可量化的实现：所谓”差多少”，就是本地命中率 12.5% 对 59% 这个差距。

⚠️ 成熟度提示：单篇预印本，无独立复现；实测平台是 AMD MI300X（8 卡/节点），NVLink / InfiniBand 拓扑下的迁移性未经验证。作者只说相关性在预训练早期就已学会，未说明它在训练全程是否稳定——而这一点决定了这个方案能不能直接用在已经训了一半的模型上。

热点专家与动态副本放置

MoE 的路由热点不可预测，且专家越细越多，路由长尾越难预估。一旦少数专家成为热点，承载它们的 rank 步时被拉长，其他 rank 算完后空等——MoE 训练慢的根因往往不是 GPU 不够快或网络不够宽，而是负载能否被及时重新均衡。

基本手段：动态副本。在轻载 rank 上预留空槽（guest slot），把热点专家的权重复制过去，让空闲 GPU 分担 token 计算。代表性工作包括 FasterMoE、Megatron 的 Echo、DeepSeek 的 LPLB、以及 ICML 2026 的 LLEP。

被忽视的代价：这类方法大多只优化”削峰”这一个目标，隐含把空闲容量当成同质资源。但如前节所述，EP 域跨出单节点后，两份均衡质量几乎相同的放置方案，实际通信开销可能天差地别——跨节点搬运的代价甚至可能超过均衡本身的收益。

TAOT 的解法（arXiv:2608.03676，2026-08，百度）：把热点 rank 的过载与轻载 rank 的余量建模为带通信代价矩阵的熵正则化最优输运问题，用 Sinkhorn-Knopp 迭代求解得到 rank 级流量提示，再结合整数副本匹配与 token 分配生成可执行调度；系统层面把 guest 权重传输与 home 专家计算重叠以隐藏通信。论文报告端到端 MoE 训练加速 1.43×，均衡质量不劣于或优于现有 SOTA，加权专家通信成本在所有配置下最低，最高降低 74%。开源实现见 LoongForge。

⚠️ 成熟度提示：TAOT 为 2026-08 的新论文，尚无独立复现，1.43× 与 74% 均为作者自评，请按”论文报告”而非定论对待。

工程要点：评估这类方案时不要只看负载均衡度指标。加权专家通信成本才是跨节点 EP 下的关键量——只优化均衡度的方法，在 EP 域跨节点时可能反而抬高总训练成本。

显存这一侧：MoE 的峰值显存由谁主导

前面三节都在谈通信，容易留下一个印象：MoE 的瓶颈就是 all-to-all。显存是另一个瓶颈，而且峰值显存由 MoE 块主导，不是 attention——原因是 dispatch 流水线里的每一个中间 buffer 都会被 top-k 独立放大，而标准的 all-to-all dispatcher 一次性发完所有路由 token，要求一次性构造出完整的 top-k 展开 buffer。专家数越多、top-k 越大，这个展开就越贵。

RelayMoE（arXiv:2610.07333，2026-10）改成环形执行：专家权重或 token 在环上流动时就地计算，规避完整展开；按通信量在”专家路由 / token 路由”之间自适应选择，并把传输与计算重叠。环形结构还天然支持逐跳重计算——每一跳重建专家中间量、算完梯度、立刻释放，再进入下一跳。

在 30B–57B 生产级 MoE 与多种专家配置上：单层实验相对 Megatron-LM 平均 2× 加速；同等 GPU 显存预算下全模型训练吞吐最高 +2.02×，可训练的最长序列长度延长最多 2.85×。

💡 二阶效应（读者最容易漏的一句）：省下来的显存有两个去处——换更长序列 / 更大 batch，或者保留更多 attention 激活以减少 attention 重算。后者是一条”MoE 省显存 → attention 提速”的间接路径：一个专门优化 MoE 块的改动，最终收益可能落在 attention 上。

⚠️ 成熟度提示：单篇预印本，无独立复现；实验规模为 30B–57B，不是本章 Kimi K2 那种万亿参数量级，外推需谨慎。

通信拓扑与硬件

GPU 互连层次

现代 GPU 集群的互连通常有多个层次：

层次带宽示例
GPU 内存 ↔ GPU 计算~3.35 TB/sHBM3e
GPU ↔ GPU（节点内）900 GB/sNVLink 5.0 (H100)
GPU ↔ GPU（跨节点）400 GbpsInfiniBand NDR
节点 ↔ 节点400-800 GbpsRoCE / IB

并行策略映射：

  • 张量并行 → NVLink 内（节点内，高带宽）
  • 流水线并行 → 跨节点（对延迟敏感但带宽要求低）
  • 数据并行 → 跨节点（AllReduce，通信与计算可重叠）

通信原语

原语用途复杂度
AllReduceDP 梯度同步O(M)O(M)（M 为数据量）
AllGatherFSDP 参数恢复O(M)O(M)
ReduceScatterFSDP 梯度分片O(M)O(M)
AllToAllMoE 专家路由O(M)O(M)
P2P Send/RecvPP 层间传递O(M/P)O(M/P)

NCCL

NVIDIA NCCL（NVIDIA Collective Communications Library）是 GPU 集群通信的事实标准。它自动处理 NVLink/PCIe/IB 之间的拓扑感知路由。

训练精度演进

分布式训练的”算力需求”不仅取决于模型大小和数据量，还取决于训练时使用的数值精度。精度越低，同样的硬件可以完成更多计算。

精度GPU 支持显存计算吞吐现状
FP32所有1x基线已基本弃用（仅 loss 计算/优化器状态）
BF16Ampere+0.5x~2x当前主流训练精度
FP8 (E4M3/E5M2)Hopper H1000.25x~4x已被 DeepSeek V3 等模型验证
FP4 (NVFP4)Blackwell B200/Ultra0.125x~3x vs Hopper FP8已工业验证（MLPerf v5.1）；缩放格式选择仍在演进（UE5M3 可省去 RHT 与末层豁免，见下文）

BF16 混合精度训练已是默认做法——权重和激活用 BF16 计算，优化器状态保持 FP32。

FP8 训练在 Hopper GPU 上成为可能。NVIDIA 的 MXFP8 最佳实践使用 per-tensor scaling factor 保证精度，DeepSeek V3 证明了 FP8 训练在万亿参数规模下的可行性。

FP4 训练是下一个前沿。Quartet（2025）在 Blackwell GPU 上证明 FP4 原生训练可以达到接近 BF16 的效果。NVFP4 已在 MLPerf Training v5.1 中通过工业基准测试验证——Blackwell Ultra 在 LLaMA 3.1 405B 预训练中使用 5120 张 GPU 实现比 Hopper 快 3x 的训练速度，512→5120 GPU 扩展效率达 85%。Quartet II 进一步提出 MS-EDEN 无偏量化例程，量化误差比随机舍入低 2x 以上，在 Blackwell GPU 线性层上比 BF16 快 4.2x（端到端训练吞吐 >2.4x）。

⚠️ 但 NVFP4 配方的复杂度可能不是必需的。上述稳定手段（每步张量缩放、随机 Hadamard 变换、BF16 末层）都增加了 FP4 矩阵乘之外的工作量。Graphcore Research 的技术报告（arXiv:2609.02846，2026-09）提出换一个思路：不改配方，改缩放格式——给 E2M1 载荷配无符号 E5M3（UE5M3）块缩放，把有符号 E4M3 缩放的符号位改作第 5 个指数位，最大有限缩放从 448 提升到 61,440（约 137 倍更宽）。缩放范围宽了之后，张量缩放可以周期性刷新（每 50 个优化器步一次）而非每步重算，RHT 可以省略，末层也可以不豁免。在 Nemotron-H 8B、近 1887 亿 token 的预训练中，相对 Transformer Engine NVFP4：最终窗口训练损失 2.3090 vs 2.3474，held-out 验证 NLL 2.32230 vs 2.32592，三个下游聚合指标全部更高；去掉 RHT 与 BF16 末块豁免后，模型主体 token 吞吐 +21.2%。

这条证据的意义不在于”又多了一个 FP4 方案”，而在于它把”FP4 稳定训练需要哪些工程手段”从一个既定事实变回了一个开放问题——答案可能取决于缩放格式而非配方复杂度。

⚠️ 证据等级：厂商技术报告（Graphcore，NVIDIA 的竞争对手），非同行评审；且这是端到端软件仿真的 FP4 预训练，核心比较基于一个软件仿真的 FP4 GEMM 模拟器，并非全部跑在原生硬件上。UE5M3 目前也不是硬件原生支持的格式，论文结尾将其作为”具体的硬件目标”提出。引用时请按厂商自评 + 软件仿真对待。

配方里到底哪一步值钱？

上面三段是按方案罗列的：NVFP4 靠每步张量缩放 + RHT + BF16 末层，Quartet II 靠 MS-EDEN，UE5M3 靠改缩放格式。读者会得到”几个配方在比谁更好”的印象，却不知道配方的哪个部分在起作用。2026 年 9–10 月的两篇工作把这个黑箱拆开了（注意后一篇编号为 2610，但 abs 页 citation_date 是 2026/09/04——编号月份不等于提交月份）。

第一，前向比反向更敏感。 Mixed Precision Scaling Laws（arXiv:2610.17637，2026-10）把 NVFP4 与 Quartet II 的配方拆成前向分量与反向分量单独排列组合，在 Qwen3 430M（非嵌入参数）、12.8B token 上逐格跑（下表为论文表 1，损失增量相对 BF16 基线 3.245）：

前向反向验证损失增量是否进拟合网格
BF16BF163.245—✓
BF16MS-EDEN3.257+0.36%✓
BF16RHT + SR3.255+0.32%✓
BF16SR3.268+0.72%✓
4/6 + 1D scalingBF163.275+0.94%✓
4/6 + 1D scalingMS-EDEN3.280+1.07%✓
4/6 + 1D scalingRHT + SR3.282+1.14%✓
4/6 + 1D scalingSR3.291+1.42%✓
2D scalingBF163.284+1.22%✗
2D scalingRHT + SR3.291+1.41%✗
2D scalingSR3.300+1.69%✗

读这张表要抓住两件事。一是只量化反向（前向保持 BF16）的代价是 +0.32% ~ +0.72%，而只量化前向（反向保持 BF16）是 +0.94% ~ +1.22%——前向比反向更敏感。二是 Quartet II 相对 NVFP4 的优势主要来自前向分量（4/6 + 1D 对 2D），不是来自反向；这正好解释了本章前面写的 MS-EDEN 为什么值钱。

⚠️ 读表注意：2D scaling（NVFP4 原配方的前向分量）的三行在原文中标记为不进入 scaling law 的拟合网格。也就是说，上面给的这张分解表与论文最终拟合出来的 law 并不是同一批数据，引用具体数值时要带上这个限定。

第二，精度本身变成了可分配的优化变量。 在这张分解表的基础上，论文建立了一个混合精度 scaling law：把量化对模型容量与对优化效率的影响分开，显式建模前向与反向量化带来的持续性优化误差。它的预测误差比现有 law 低最多 11 倍 MSE，并且可以直接求解”给定硬件算力预算下，计算最优的模型规模 / token 数 / 前向与反向各自该用什么精度”，还能扩展到逐层混合精度。

由此得到的结论反直觉，值得单独记一句：这套 law 预测最优精度会随着算力预算上升而提高。也就是说算力越充裕，越不该把精度压到最低——“要不要上 FP4”在这里已经不是一个二值决策，而是一个可计算的分配问题。

第三，系统侧同样决定成败。 Format-Aware Fusion（arXiv:2610.00053，[v1] 2026-09-04）指出，量化生产者必须与”缩放域 + 消费者布局”协同设计（native mxfp / global nvfp / CTA-local nvfp）。在同一块加速器上做 Llama-3 系 8B、1600 亿 token 预训练：BF16 是 18.8K tokens/s/GPU，Transformer Engine 的 nvfp 是 27.6K，最快的定制路径是 37.9K——同样的 FP4 格式，执行路径不同可以差到 2 倍。

⚠️ 必须记住的一个反例：下游任务的排序与训练损失的排序不一致。mxfp 路径跑到 37.2K tokens/s/GPU（86.3% BF16 MFU），看起来是最优解，训练损失却比 BF16 高 2.11%；而 TE 配方加末 4 块 BF16 在只有 27.1K 的吞吐下，损失只高 0.87%。在 FP4 下，“吞吐最高”和”模型最好”不是同一个方案。 用训练损失选配方、用下游指标验收，两者顺序不能颠倒。

⚠️ 成熟度提示：2610.17637 的分解实验规模为 430M 参数 / 12.8B token，外推性未证；2610.00053 为单作者预印本，“37.9K”为作者自评。两篇均为 2026 年 9–10 月的新工作，无独立复现。

🔗 跨章联动：本条与第五章的 scaling law 存在口径耦合。第五章的 scaling law 默认”精度固定”，此处把精度变成了可分配资源——两处的”计算最优”定义会不一致。若第五章后续要加”精度维度”，两处须同轮改。

万亿参数训练实战：Kimi K2 案例

MoonshotAI 的 Kimi K2 是目前公开详细技术报告的最大规模 MoE 训练案例之一，为万亿参数分布式训练提供了工业级参考：

模型配置：

  • 1T 总参数 / 32B 激活参数 MoE
  • 15.5T tokens 训练数据
  • H800 GPU 集群

弹性并行策略：

  • 支持任意 32 倍数的节点数，解决”动态资源可用性”问题
  • 选择性重计算：LayerNorm / SwiGLU / MLA 上投影 + MoE 下投影，减少激活内存

优化器：MuonClip + 分布式实现，全程零 loss spike

后训练加速：QAT + INT4 权重量化，实现 ~2x 生成加速

Kimi K2 的核心启示：万亿参数 MoE 训练的并行策略需要”弹性”——不是所有团队都能一次性锁定数千卡集群，支持动态节点数的弹性并行是实际工程需求。MuonClip 解决了大规模训练中 attention logits 爆炸的稳定性问题，使得万亿参数全程零 spike 训练成为可能。

补充案例：MoP（arXiv:2607.01844）：MoP（Xuan-Phi Nguyen et al., 2026-07）从另一个角度推进了万亿 MoE 训练的边界——用更少的硬件做更多的事。仅需 12 个 8×H200 节点即可无损训练万亿参数 MoE，每 GPU 吞吐量 4.7-8.2× 于高度调优的 FSDP2 基线。最突出的突破：主流框架在 64-128K 上下文即 OOM，MoP 可持续到 1M 上下文——8 倍长度跳跃。与 Kimi K2 的大集群路线互补，MoP 验证了”弹性并行”在资源受限场景的价值。

低通信训练范式

上述所有并行策略都假设一个前提：GPU 之间有高带宽互连（NVLink + InfiniBand）。但如果 GPU 分布在不同的数据中心呢？

DiLoCo 与 DiPaCo

DiLoCo（Distributed Low-Communication）（Google DeepMind，2023）和 DiPaCo（Distributed Path Composition）（Google DeepMind，2024）探索了一个激进的方向——将通信量降低 100-500 倍，使跨数据中心训练成为可能。

DiLoCo 的核心机制：

  1. 每个 worker 在本地用标准 SGD 训练若干步（如 500 步）
  2. 周期性地同步外部优化器梯度（使用 Nesterov momentum）
  3. 同步频率极低——每 500 步一次，通信量仅为每步 AllReduce 的 1/500

DiPaCo 在 DiLoCo 基础上引入模块化路径——模型被拆分为多条路径（path），不同路径可以在不同的数据中心训练。推理时通过路由选择路径，类似 MoE 的思路。

局限性：DiPaCo 目前仅在 1B 规模验证，百亿级以上的大规模实验尚未公开。这条路径的工业化还有距离，但它打开了”互联网级分布式训练”的想象空间。

训练框架

主流框架对比

框架特点适用场景
Megatron-LMNVIDIA 官方，性能最优，3D 并行大规模预训练
DeepSpeedZeRO 系列，易用性好通用训练
FSDP2 (PyTorch 2.13+)PyTorch 原生，DTensor 基础，per-parameter sharding，通信重叠 + torchcomms 容错后端中到大规模训练
TorchTitanPyTorch 官方推荐的 3D+ 并行统一平台大规模预训练（替代 FSDP+Megatron 拼装）
Megatron-DeepSpeed结合两者优点大规模预训练
veScale字节跳动开源，自动并行，内部大规模验证易用+高性能
NeMo端到端训练平台企业级训练

MFU（Model FLOPs Utilization）

MFU 是衡量分布式训练效率的核心指标：

MFU=实际模型计算 FLOPs/s硬件峰值 FLOPs/s\text{MFU} = \frac{\text{实际模型计算 FLOPs/s}}{\text{硬件峰值 FLOPs/s}}

规模典型 MFU说明
单卡/8卡50-60%NVLink 内通信开销小
64-256 卡40-50%跨节点通信开始成为瓶颈
1K-8K 卡35-45%需要精细的通信优化
10K+ 卡30-40%故障恢复成本也变大

新一代硬件的扩展效率提升：MFU 绝对值受模型架构和软件栈影响大，跨代比较不够公平。扩展效率是更稳定的指标——从同一系统小规模扩展到大规模时的性能保留率。

  • MLPerf v5.1：Blackwell Ultra 从 512 卡扩展到 5120 卡（10x），性能线性度达 85%
  • 2026 奇点智能技术大会：Blackwell + Cerebras CS-3 + InfiniBand-XD 网络，2048 卡实现 92.7% 线性加速比（较 2024 年提升 14.3 个百分点），异步分层流水线并行 (ALP) 和梯度压缩 + 误差补偿机制有贡献

故障恢复

在数千张 GPU 的集群上训练数天/数周，节点故障是常态而非意外。

检查点恢复：定期保存模型状态、优化器状态、数据位置等。关键是异步检查点保存——保存检查点不应该阻塞训练。

弹性训练（TorchElastic）：TorchElastic 支持节点动态加入/退出，无需重启整个训练任务。

抢占容错（Bamboo）：若训练跑在可抢占实例（spot 实例，价格远低于按需实例，但随时可能被回收）上，故障模型就从”偶发故障”变成”频繁抢占”——这与现有检查点技术所针对的常规集群故障有本质区别。传统检查点在这种场景下开销极大：论文实测在 64 个 EC2 spot 实例上训练 GPT-2 时，高达 77% 的训练时间花在重启与重做已有工作上。Bamboo（NSDI 2023）的解法不是把检查点做得更快，而是把冗余计算填进流水线气泡：在 PP 个节点的流水线中，每个节点额外承担其后继节点的层，作为后者的”影子”；后继被抢占时立即接管，无需系统级重启与昂贵的状态恢复。它采用 Eager FRC / Lazy BRC 策略——前向冗余计算在气泡中主动完成，反向冗余计算仅在抢占真正发生时才做，兼顾恢复速度与常态开销。实测训练吞吐比传统检查点高 3.7×，相比按需实例成本降低 2.4×。

两者的区别在于：TorchElastic 解决的是集群成员变化（扩缩容、节点替换），Bamboo 解决的是同一批节点被反复抢占。前者假设节点数可变，后者假设节点随时会消失但会被即时替补。把两者并列陈述容易掩盖这个差别——弹性伸缩的代价是重新切分流水线，抢占容错的代价是常态多算一份冗余。

第三种情况：卡不够，而不是卡坏了。前面两种故障模型都默认”节点数会变回来”——TorchElastic 等它回来，Bamboo 用冗余计算顶住它消失的那一瞬。但还有一种更常见也更难的场景：总资源就是不够，你只能拿到比规划少得多的卡，而且不知道什么时候能补齐。本章 Kimi K2 案例开篇就说”不是所有团队都能一次性锁定数千卡集群”——需求写出来了，答案此前没给。

TRANSIT（arXiv:2610.07593，2026-10，IBM 系）是一个透明缩容（scale-in）框架：训练时把 CPU DRAM 当作 GPU 显存的延伸，通过用户态 interposition 层实现，不修改应用、训练框架、集群调度器、设备驱动或操作系统，并用零拷贝 CPU-GPU 通路提高效率。

在最多 64 张 H100、多种并行配置、RoCE 网络上的 dense 与 MoE 实测：(a) 每 GPU 吞吐比 TorchTitan / ZeRO-Offload / ZeRO-Infinity 分别高 68% / 59% / 42%；(b) 用少 50% 的 GPU 训练，仍能保持基线每 GPU 吞吐的 90% 以上；(c) 每节点网络流量降低最多 33%；(d) 通信受限场景下每 GPU 吞吐提升最多 35%。

三条边界可以这样记：

方案应对的问题隐含假设
TorchElastic集群成员变化（扩缩容、节点替换）节点数会变回来
Bamboo同一批节点被反复抢占节点会消失但会被即时替补
TRANSIT总资源变少，只能少用卡节点数就是不够，且不保证补齐

⚠️ 别写错的类比：TRANSIT 不是 ZeRO-Offload / ZeRO-Infinity 的同款替代。后两者是框架管理的 offload，需要框架配合且数据路径经过框架；TRANSIT 是透明的（应用与框架都不知道发生了 offload）且零拷贝。实测差距 42–59%，正是这条差别的量化。

⚠️ 成熟度提示：单篇预印本，无独立复现；单环境实测（H100 + RoCE），IB 或 NVLink 域内的表现未验证。

下一章预告：预训练完成后，模型具备了强大的语言能力但还不会”听话”。第九章我们将进入后训练的世界——SFT、RLHF、DPO，让模型对齐人类意图。