集群训练系统：把模型铺到一千张卡上

破除误解：并行策略不是越碎越好#

把万卡训练理解成“把模型复制 16384 份”，会立刻撞上显存。一张 H100 80GB 装不下 405B 的参数、梯度、优化器状态与激活。Meta 公开说过，405B 预训练要放下权重与激活，内存需求超过 700 TB。所以必须切。

切的方式不是一种。数据并行把不同样本分给不同卡，末尾做梯度同步；ZeRO / FSDP 再把优化器状态、梯度、乃至参数本身分片，避免每张卡存全量副本。张量并行把一层里的矩阵乘切开，卡之间要频繁交换激活。流水线并行把层的深度切开，用微批次填满气泡。上下文并行把超长序列的注意力切开。Llama 3 的生产经验把四者按拓扑排序：张量并行贴着最高带宽的近端互连，数据并行放在最外层、可以容忍更长的延迟。

气泡是流水线的税，不是调参边角。P 个 stage、M 个微批次，空转大致随 \((P-1)/M\) 出现：切得越深，越要靠更多微批次去摊薄等待。M 不能无限加，因为它抬高激活内存，并拉长一次优化器步进。交错的 1F1B 把每个 rank 上的层再切成虚拟块，用更碎的前向–后向去填洞，代价是更碎的通信。Narayanan 等人（SC 2021）把张量、流水线、数据并行合在一起测量，正是因为气泡、集合通信与互连层级必须同时看见。把“能跑起来”写成已结束的工程，会漏掉这张仍开放的调度面。

ZeRO-3 把参数也分片，理论上最省显存，却多通信，并与流水线互相干扰。Llama 3 的并行论文写明：生产里选的是 ZeRO-1/2 加上张量与流水线，而不是把 ZeRO-3 推到极限。开放问题是配置空间本身——同一堆卡，切法不同，有效算力可以差出成倍。没有一张对所有模型都正确的表。

现场：算力利用率，以及故障成为一等公民#

NVIDIA 的 Megatron-LM 把三维并行做成可复现的基线；DeepSpeed 的 ZeRO（Rajbhandari 等，SC 2020）把优化器状态从“每卡一份”改成“按数据并行度分片”。Narayanan 等人（SC 2021）在 GPU 集群上把流水线气泡与通信重叠写成可操作的配方。这些是 2020 年代前半的“能跑起来”。

2024 年的现场换成了“能跑完”。ByteDance 的 MegaScale（NSDI 2024）报告在 12,288 张 GPU 上训练 175B 模型，模型浮点利用率（MFU）55.2%，相对当时的 Megatron-LM 基线约 1.34 倍。他们强调：许多稳定性问题只在这个规模上出现，深度可观测是定位掉队者与故障的前提。有效训练时间与自动恢复被写成生产指标，而不只是实验室的最终损失。

网络拓扑决定切法是否诚实。Meta 用 RoCE 互联的大规模训练集群（公开讨论过 24k GPU 量级）去跑 Llama 3 一类作业。张量并行若跨过交换机跳数，延迟会把矩阵乘的重叠窗口打穿。所以并行维度的顺序是网络问题，不是超参数搜索的边角。掉队者（straggler）同样：同步屏障上最慢的那张卡决定一步的时间。诊断工具必须看见是计算、拷贝还是网卡在拖，而不能只看平均 GPU 利用率。

通信与计算重叠是 MFU 真正被挤出来的地方。张量并行的集合通信必须和矩阵乘叠在同一个内核时间线上；数据并行的梯度归约必须和下一层的反传叠。重叠失败时，硬件峰值还在，MFU 却掉到“在等网卡”。MegaScale 把算子融合、流水线气泡、网络拥塞控制写成全栈问题，正是因为单改模型代码看不见这些等待。激活重计算（checkpointing）用时间换显存：反传时重算一部分前向，少存激活。万卡上它还改写故障面——重计算拉长一步的时间，也就拉长了一步里遇到 GPU 错误的窗口。没有免费的显存。

计划内打断与意外打断必须分开读。Llama 3 的 47 次计划内来自自动化维护；419 次意外才是故障系综。把两者加总再除以天数，会把运维纪律误读成硬件不可靠。反过来，只报“我们用了 16k 卡”而不报意外密度，等于隐瞒同步作业的真实成本。公开到“哪一类组件、多少次、要不要人”这一档的，仍然极少。

谁在做，做到了哪一步#

PyTorch FSDP 把分片数据并行做成框架默认路径之一，降低了“只有内部框架能跑大模型”的门槛。它没有取消拓扑：把 FSDP 的通信模式套到错误的网络直径上，仍然会把 MFU 打穿。Google 的 TPU Pod 与 JAX/XLA 是另一条硬件栈，公开数字更少，不能直接与 H100 的 MFU 对拍。

xAI 等机构后来公布过更大规模的 GPU 集群。规模放大不会线性放大故障间隔——组件数上升，同步作业的脆弱性上升。没有公开、可复核的同等粒度故障表之前，外推只能停在定性：自动化恢复从可选项变成训练能否完成的条件。

软件栈的另一条线是把切法从研究框架搬进默认运行时。PyTorch FSDP（以及后续的 FSDP2 工作）让分片数据并行不再等于必须使用 DeepSpeed 配置文件；Megatron-Core / NeMo 则把张量与流水线做成可组合的模块。这降低了复现门槛，也制造了新的对照困难：同样报 70B，FSDP 全分片与 Megatron 三维并行的通信体积、故障恢复语义都不一样。论文若只给模型名与卡数，不给并行维与切分策略，MFU 不可比。

还有一个常被模型论文省略的层：数据管道。万卡训练的一步若在等 tokenizer 或远程读样本，MFU 同样会掉，却不会出现在 NCCL 计数器里。MegaScale 把数据管道写成全栈的一截，是因为它在 1 万卡上已经和计算一样能拖死同步屏障。开放问题是：数据侧的掉队与 GPU 侧的掉队，在自动化恢复里是否该走同一条路径。两者的失败语义不同——前者往往可跳过或重读，后者常常必须回检查点。

代价与争议#

同步是效率，也是单点。 数据并行的一步要等全体梯度。一张卡的 HBM 出错，整步作废，作业回到最近的检查点。检查点太密，浪费带宽；太疏，一次故障回退数小时。Llama 3 的数字说明：故障率高并不可耻，可耻的是没有自动化。争议在于，公开论文很少把“检查点间隔、恢复路径、有多少次是静默数据损坏”写全，外部无法判断 90% 有效时间是否可迁移。

MFU 不是科学产出。 它测量的是相对硬件峰值用了多少矩阵乘，不测量数据质量、评测污染或下游能力。把 MFU 当研究目标，会奖励更容易切的模型形状，而不是更好的学习目标。MegaScale 把自己定位为系统论文，这是诚实的；媒体把它读成“更大一定更强”，不是作者的定理。

能耗与故障同源。 H100 量级加速器的热设计功耗约 700 W，HBM 故障在 Llama 3 表上不是零星事件。可持续计算讨论的是电网与 PUE；训练系统讨论的是同一张卡的热与纠正。两者必须对读，不能各报各的。

检查点走存储、集合通信走互联，两条带宽预算互相抢。恢复要快，就得把状态写得足够密；写得密，训练步里就会出现“GPU 在等磁盘”的新掉队。这不是运维口诀，而是同步系统在两个不同直径的图上同时求最短路。公开论文极少同时报这两张图的利用率。

未知的边界#

• 异步或局部同步能否在不毁掉收敛的前提下，把“一卡死、全体停”这条耦合拆开？
• 检查点能否低到秒级，而不把互联打满？
• 以太网 RoCE 与 InfiniBand 在 10k 卡以上的尾延迟，会不会把张量并行的可行半径锁死？
• 稀疏 MoE 的 all-to-all 与稠密模型的 all-reduce，故障模式是否已经不是同一张表？
• 静默数据损坏（算对了校验却错了的数）在万卡上的发生率，公开测量几乎是空白。

跨域连接#

• 图论：集群是一张有带宽与直径的图，并行维度是图上的嵌入：近端边给张量并行，远端边给数据并行。一次 all-reduce 的时间由生成树或环的最慢边决定，不是由平均带宽决定。所以“加卡”若加在错误的割上，有效算力可以下降。训练系统的前沿有一半是图嵌入，不是优化器公式。
• 热力学定律：每张加速器把电能几乎全部变成热，故障表里的 HBM 与热应力是同一条账。同步作业的效率上限，最终要碰到散热与供电能同时稳定的功率密度，而不是只碰到算法的 MFU。PUE 量的是机房；这里量的是芯片能不能在额定功耗下连续跑几十天而不把纠错预算用尽。
• 玻尔兹曼统计力学：万卡上的意外打断更像稀有事件统计：组件多、时间长，故障到达接近泊松。有效训练时间是“存活概率 × 恢复速度”的积分，不是一次幸运的长跑。把 54 天里的 419 次意外当成异常，是看错了系综——在这个粒子数下，意外才是平衡态。
• 国家能力：能把 1 万张以上加速器维持在高有效时间的，是同时拥有电力、网络工程、自动化运维与芯片供应链的组织。这不是算法论文能单独复制的能力：公开的切法可以下载，故障分布、备件与调度纪律不能。算力集中因此不只是资本门槛，也是一种把物理基础设施当成可调度资源的组织能力。
• 纳什均衡：多租户集群里，每个作业都想独占高带宽域、把检查点写到最近的存储。若调度只看即时利用率，均衡是拥塞与掉队。拓扑感知的放置等于改博弈规则：把通信密集的并行维锁在低直径子图里，才不让局部最优把全局同步拖垮。没有这层规则，MFU 会在争抢中塌缩。

参考文献#

• Grattafiori, A. et al. The Llama 3 Herd of Models. arXiv:2407.21783 (2024).
• Jiang, Z. et al. MegaScale: Scaling Large Language Model Training to More Than 10,000 GPUs. NSDI 2024.
• Rajbhandari, S. et al. ZeRO: Memory Optimizations Toward Training Trillion Parameter Models. SC 2020. DOI: 10.1109/SC41405.2020.00024.
• Narayanan, D. et al. Efficient Large-Scale Language Model Training on GPU Clusters Using Megatron-LM. SC 2021. DOI: 10.1145/3458817.3476209.
• Chu, W. et al. Scaling Llama 3 Training with Efficient Parallelism Strategies. ISCA 2025. DOI: 10.1145/3695053.3731410.

延伸阅读#

• Shoeybi, M. et al. Megatron-LM: Training Multi-Billion Parameter Language Models Using Model Parallelism. arXiv:1909.08053 (2019).
• Meta. Scheduling and Sharding Considerations for Network Efficiency. At Scale Conference.