▶ 原文链接

扩展到数千个GPU的训练：并行策略全解析

来源： YouTube | Nouamane Tazi (Hugging Face) | May 11, 2026 播客： Stanford Online 分类： 其他 原文发表： May 11, 2026 纪要生成： 2026-06-22

---

嘉宾/话题简介

Nouamane Tazi 是 Hugging Face 的核心开发者，主导了《超大规模训练手册》（Ultra-Scale Playbook）的撰写，并且是 Hugging Face 开源分布式训练库 Nanotron 的核心开发者。他深度参与了 StarCoder 2、Small LLM 3 等模型的开发，并致力于 Mixture of Experts (MoE) 的扩展研究。他的核心使命是让大规模训练变得实用且易于获得。本集内容系统性地回顾了从单GPU到成千上万个GPU集群上训练大型语言模型所涉及的核心并行策略，从理论基础、工程实现到前沿挑战。

---

分节详述

00:00 训练规模化的挑战与基础动机

本节重点

• 模型规模与智能程度正相关，万亿参数模型成为新常态。
• 大规模训练带来的核心基础设施瓶颈：数据加载、训练迭代速度、单卡显存限制、checkpoint保存。
• 单GPU训练下的解决方案及其局限：梯度累积受限于模型大小和串行速度。

详细精要

• 模型规模追求持续增长的动力：研究表明，更大的语言模型通常表现出更高的智能水平。
• 举例：本周发布的 Kimi K2.6 模型参数量已达到 一万亿 (1 trillion) 参数级别，该级别模型配合 15万亿 (15 trillion) 训练Token， 以及长达 一百万 (1 million) 的上下文长度已成为趋势。
• 这种规模的数据和模型对基础设施构成巨大压力。
• 大规模训练的基础设施挑战全景：训练万亿参数模型，不仅需要持续地从存储系统加载海量数据，每次训练迭代（一次前向+后向传播）也必须在极短时间内（如约1秒）完成，同时还需周期性保存检查点（checkpoints）。
• 最核心的限制是每个 GPU 或 TPU 上可用的 显存（VRAM） 大小。
• 单GPU训练的局限与梯度累积：面对 全局批次大小 达到数百万甚至5000万Token的需求，单个GPU无法一次性处理。
• 梯度累积 是基础解决方案：将全局批次切分为多个较小的微批次，依次进行前向和反向传播，并串行累加梯度，最后执行一次参数更新。
• 此方法的前提假设是模型本身能完全装入单个GPU的显存，这对万亿参数模型显然不成立。
• 串行处理每个微批次将导致训练时间极长，无法接受。

💬 精华片段（中文）

“这些天的模型达到一万亿参数甚至更大。它们会在15万亿的训练Token上进行训练，上下文长度可达一百万。” "Models of these days are one trillion parameter large, or even larger. They get trained on 15 trillion training tokens and for context lengths as far as one million."

03:41 数据并行（Data Parallelism, DP）原理、优化与局限

本节重点

• 数据并行通过复制模型、分片数据并用AllReduce同步梯度来加速训练。
• 通过 bucket 机制可以实现通信与计算的重叠以隐藏延迟。
• DP的三大致命缺陷：优化器步骤冗余、全局批次随GPU数线性扩展的物理上限、以及基础DP要求模型必须装入单卡显存。

详细精要

• 数据并行的基本工作流程：将不同的数据微批次（micro-batches）分发到多个GPU上，每个GPU持有模型的完整拷贝。
• 每个GPU根据其独有的数据计算出不同的梯度。
• 通过 AllReduce 这一集合通信操作，对所有GPU上的梯度进行分布式求和，确保所有模型副本最终获得相同的平均梯度，从而保持同步。
• PyTorch的 DDP (Distributed Data Parallel) 类封装了此过程，在 loss.backward() 时自动完成 AllReduce。
• 提升DP效率的关键：通信计算重叠：最朴素DDP实现中，反向传播计算和梯度AllReduce是串行的，导致GPU计算单元出现空闲（idle time）。
• 使用 torch.profiler 可以可视化 CPU流 与 GPU流 的时序，发现通信与计算之间的空隙。工程目标就是让 GPU计算流 始终保持满载。
• 改进方法：Bucket化AllReduce。无需等待所有层梯度计算完毕，每当反向传播过程计算出某个层（或一组层）的梯度时，即可立即对该梯度桶（gradient bucket）启动异步AllReduce。
• 通过 bucket_cap_mb 参数可以控制桶的容量，以微调通信与计算的重叠程度。
• 数据并行的优点与致命缺陷：
• 优点：实现简单，模型无关（可包裹任何 nn.Module），通信重叠高效。
• 缺陷一：优化器步骤冗余。每个GPU持有完整模型，意味着所有GPU都重复进行相同的优化器步骤（如SGD/Adam），这是计算浪费。
• 缺陷二：全局批次大小限制。数据并行的维度越高，全局批次大小就必须等比例增加，以保持每个GPU上微批次大小不变。但全局批次有上限（数千万Token级别），无法无限扩展。
• 缺陷三：显存墙。最基础的DP要求模型及其优化器状态、激活值必须能完全放入单张GPU的显存。

💬 精华片段（中文）

“所以当你有大量GPU时，你肯定希望高效地重叠你的计算与通信，避免GPU计算流的任何空闲时间，并充分利用GPU的张量核心。这就是本次演讲的最终目标。” "So when you have a lot of GPUs, you definitely want to overlap efficiently your computation with communication so that you avoid any idle time here for the GPU computation and to benefit of the tensor cores of GPUs. So this is the end goal of this presentation."

11:24 ZeRO优化器：深度优化内存，突破显存墙

本节重点

• ZeRO-1 通过将优化器状态分片到各GPU，并用 reduce-scatter + all-gather 替代 AllReduce，消除冗余计算。
• ZeRO-2 在 ZeRO-1 基础上进一步丢弃非分片部分的梯度，节省更多显存。
• ZeRO-3 / FSDP 极致地将模型参数也分片，并通过运行时按需聚合、预取下一层的方式，将模型显存占用降低到 1/N (N为GPU数)。

详细精要

• ZeRO-1：消除优化器状态冗余：核心思想是将优化器状态（如Adam中的动量和方差）分片（shard）到不同GPU上，每个GPU只负责更新一部分参数，从根本上解决DP中优化器步骤的冗余工作。
• 关键通信技巧：将AllReduce操作拆解为 reduce-scatter 和 all-gather 两步。首先reduce-scatter梯度的分片，使得每个GPU只获得它负责优化的那部分参数对应的完整梯度。执行优化器步骤后，再通过all-gather将更新后的完整参数广播给所有GPU。
• 意义：总通信量不变（AllReduce = reduce-scatter + all-gather），但省去了冗余的优化器计算，并降低了优化器状态的显存占用。
• ZeRO-2：梯度分片的锦上添花：在reduce-scatter后，每个GPU得到了它负责更新的参数分片的梯度，其余部分的梯度在该GPU上便不再需要。ZeRO-2 会将这些不再需要的梯度丢弃，从而进一步节省显存。
• 实践注意事项：实施精细的丢弃操作在工程上较为繁琐，很多实践者会停留在ZeRO-1，或者使用适配全张量梯度需求的优化器（如 Muon）。对于Muon这类需要完整张量进行计算的优化器，分片时不能简单地展平所有参数，而应按完整张量的粒度分配。
• ZeRO-3 / FSDP：完全分片数据并行，颠覆性节省模型显存：ZeRO-1/2 节省了优化器和梯度的显存，但模型本身的参数显存仍然是瓶颈。ZeRO-3将模型参数本身也分片到各GPU。
• 运行机制：在训练各阶段，模型参数并非始终聚合。每个GPU仅永久存储其拥有的参数分片。当需要执行某层的前向或后向计算时，它通过all-gather操作，临时从其他GPU收集该层完整的参数。
• 实现高效的关键 - 预取：为了掩盖all-gather的通信延迟，ZeRO-3在计算当前层时，会预取下一层所需的全部参数。计算完成并传递激活后，立即释放当前层的非分片参数。
• 结果：在最优情况下，任意时刻每个GPU内存中最多只保存两个模块（FSDP units）的完整参数，实现显存占用的数量级降低。
• FSDP1 vs FSDP2：PyTorch 中的两个实现版本。
• FSDP1：倾向于将参数展平再分片，这与一些需要完整张量结构的优化器（如Muon）不兼容。
• FSDP2：使用 DTensor，确保分片后每个GPU上的参数仍然是完整的张量，同时能更好地与未来的张量并行等其他并行策略结合。
• 选择ZeRO级别的决策智慧：通信量与节显存效果成正比。如果模型能用 ZeRO-1 就装入单个GPU，绝不要用 ZeRO-3，因为后者的按需all-gather会引入更多通信开销，导致训练更慢。仅在显存不足时，才使用更高等级的ZeRO。

💬 精华片段（中文）

“很多人只是把FSDP2套在所有模型上，这不是一个好主意。因为如果你的模型能用ZeRO-1就装进GPU，你就不需要ZeRO-3，ZeRO-3会增加更多通信，让你的训练变慢。所以，只在需要节省显存时才使用相应级别的ZeRO，因为除此之外没有别的好处。” "A lot of people just throw FSDP2 on all of their models. And this is not a good thing. Because if your model fits on GPUs with ZeRO 1, you don't need ZeRO 3 because ZeRO 3 you're going to add more communications than you're going to make your training slower. So just use the ZeRO degree that you need to save memory, because there is no other benefits."

23:33 张量并行（Tensor Parallelism, TP）与序列并行（Sequence Parallelism, SP）

本节重点

• 张量并行的核心是将矩阵乘法按列/行切分至多个GPU，并用AllReduce同步中间结果，实现单个样本的计算横向扩展。
• TP内部依赖“相同输入”假设，这要求非TP区域内的参数必须保持跨GPU同步。
• 序列并行通过将AllReduce拆为reduce-scatter/all-gather，把激活分片维从隐藏维度转为序列维度，解决了TP中非分片区域的激活冗余和同步难题。

详细精要

• 张量并行的动机与矩阵乘法范例：当数据并行的全局批次达到瓶颈时，需要在样本内扩展。TP让多个GPU协同处理同一个输入样本，分片模型参数，共同完成一次前向/反向。
• 基础：两个矩阵乘法的TP。假设计算 Y1 = X * W1 和 Y2 = Y1 * W2。将 W1 按列分片（W1 = [A1 | A2]），则两个GPU分别计算 X * A1 和 X * A2。为了匹配，将 W2 按行分片（W2 = [B1; B2]）。每个GPU紧接着计算自己那部分与B的乘积。最后，通过一次 AllReduce 将两个GPU的结果相加，得到与单GPU计算等价的输出 Y2。
• 反向传播同理，基于相同的上游梯度，执行相同的分片矩阵乘法后，再通过 AllReduce 得到正确的参数梯度。
• TP两大核心前提：“相同输入”与“相同上游梯度”：上述数学等价性建立在所有GPU在TP区域开始前看到的是复制（replicated）的相同激活（输入），并在TP区域结束后产生复制的相同输出（上游梯度）。
• 这对Transformer中的层标准化等操作提出挑战。这些属于非TP区域的操作，其内部参数必须在所有GPU间保持完全同步，否则会破坏等价假设。实践中，这一点通过AllReduce这些参数的梯度来实现，但理论上不完美的同步会因数值精度漂移而失控。
• TP如何应用于MLP和Attention：
• MLP块：天然的两个线性层，直接应用上述列/行分片策略。第一个线性层按隐藏维度分片（列线性），第二个按行分片。
• Attention块：存在QKV投影（输入层）和输出投影（输出层），两者构成两轮矩阵乘法，同样可应用TP。核心分片维度选择是沿着头数目进行切分。这是因为自注意力头之间是独立的，这样切分不会影响Softmax计算的正确性。如果沿隐藏维度分片，会改变 Q*K^T 的维度，导致Softmax结果错误。
• 序列并行（SP）：解决TP的激活冗余：在纯TP中，MLP或Attention之间的非TP区域（如LayerNorm前后的激活）是全量复制的，形状为 (s, b, h)，造成显存浪费。
• SP原理：利用 AllReduce = reduce-scatter + all-gather 的分解。将离开TP区的 AllReduce 替换为先沿序列维度 s 做 reduce-scatter。这使下游的LayerNorm等操作处理的激活张量在各GPU上沿序列维度分片，而非全量。
• 恢复：在进入下一个TP区前，再通过一次all-gather，将分片从序列维度聚合回隐藏维度。
• 优雅之处：总通信量不变。神奇的副作用是，在反向传播中，reduce-scatter 和 all-gather 互为逆操作，它们产生的梯度同步（reduce-scatter）恰好天然地解决了非TP区域（如LayerNorm）参数的梯度同步问题，无需再手动AllReduce。
• TP/SP的优缺点总结：
• 优点：显存高效，将模型和激活都分片了；样本高效，不增加全局批次。
• 缺点：通信极重，每个Attention和MLP块都涉及至少一次AllReduce等通信；实现极其复杂，改变模型架构困难；无TP区域的参数同步问题依然需要关注。
• 实践指导：由于通信代价高昂，强烈建议将TP限制在单个节点（如8卡NVLink节点）内使用。

38:16 并行策略的组合与流水线并行（Pipeline Parallelism, PP）

本节重点

• 并行策略正交组合的哲学：在一个计算网格（mesh）上，不同维度的并行互不干扰。
• 流水线并行通过层间切分模型，但其天生存在GPU空闲“泡沫”，需要复杂的调度策略来缓解。
• 从简单AFAB到DeepSeek的DualPipe，调度演进旨在通过交错正向/反向传播和双向注入数据来最小化气泡。

详细精要

• 并行策略的组合：3D并行网格：各种并行策略在逻辑上是正交的。例如，一个GPU组可以同时属于一个DP组（共同负责某些数据）和一个TP组（共同负责模型的一部分）。通过定义多维度的并行网格，可以自由调用不同组内的通信操作。
• 代码实现：在 TorchTitan, Megatron, Nanotron 等库中，首要步骤是初始化所有进程组，然后根据每个张量或操作的并行维度，指定其在哪个进程组上进行 AllReduce 等通信。
• 流水线并行的核心思想：按模型的层垂直切分，将不同的连续层放置在不同的GPU上。数据像流水线一样，依次经过各GPU进行计算。
• 挑战：存在严重的前后依赖。后一个GPU必须等待前一个GPU完成正向计算并传来激活，导致了大量的流水线气泡（pipeline bubble）——GPU空闲等待时间。
• PP调度器的演进：为填充气泡而设计。
• 全正向-全反向（AFAB）：注入多个微批次，先让所有GPU完成所有微批次的正向传播，再进行反向传播。气泡依然存在且很大。
• 1F1B（一次正向一次反向）：在完成一定正向步数后，交叉执行反向传播，尽早开始释放内存，但主要还是为了优化内存，气泡并未消除。
• DualPipe (DeepSeek)：目前最高级的解决方案。将模型层以轮询（Round-Robin）方式分配给所有设备，意味着首尾GPU都可能拥有模型的第一层。可从流水线两端同时注入两个不同批次的数据，完美交错正反向传播，理论上可以大幅消除气泡。这种实现极为复杂。
• PP的优缺点总结：
• 优点：通信负担极轻，只需相邻设备间点对点传输激活和梯度，无冗余AllReduce；模型无关，易于理解；分片高效，每个设备只保存模型的一段。
• 缺点：需要保存大量微批次的中间激活，导致显存压力（常与激活重计算/CPU卸载配合）；必须增加微批次数量来隐藏气泡，这实质上强制扩大了全局批次大小；高级调度器（如DualPipe）的实现极其困难。

46:05 上下文并行与专家并行：解决长序列和MoE架构瓶颈

本节重点

• 上下文并行是唯一有效解决长序列训练中激活爆炸的并行策略，其核心是沿序列维度切分并使用环注意力（Ring Attention）。
• 专家并行专为MoE模型设计，通过All-to-All通信完成Token到专家的分发，但受困于沉重的通信和CPU-GPU同步开销。
• 结合EP与PP，利用流水线气泡内的时间完成All-to-All通信，是目前实际应用中的优化手段。

详细精要

• 上下文并行（Context Parallelism，CP）：当序列长度扩展到极大（如百万Token）时，单个样本计算图的中间激活会爆炸，超出任何单卡显存。此时需要对单个样本的时间维度进行切分。
• 原理：将序列切分到不同GPU上。但这样无法计算完整的全局注意力。解决方法是环注意力。
• 环注意力：类似于FlashAttention的在线Softmax计算方式。每个GPU持有部分查询（Q），并轮转式地从其他GPU接收键（K）和值（V）块，增量计算并更新softmax，最终得到与全局注意力等价的结果。
• 优缺点：是唯一能高效切分长序列显存的并行策略；但通信极重，每个注意力块内都需要传输KV；且因GPU看到不同数据，需要AllReduce梯度。仅在长上下文训练时才会使用。
• 专家并行（Expert Parallelism，EP）：用于解决MoE模型中专家的扩展问题。将不同的专家层放置在不同的GPU上，但所有GPU共享相同的自注意力层。
• 核心操作：全对全通信（All-to-All）。这是一种n对n的复杂通信模式。首先路由器决定每个Token应发往哪个专家，然后通过一次All-to-All（dispatch）将Token下发到对应专家的GPU；专家计算完成后，再通过一次All-to-All（combine）将Token送回原始序列位置。
• 核心瓶颈：CPU-GPU同步。为了发起高效的All-to-All，CPU必须知道每个专家收到了多少Token，这需要等待GPU完成路由计算（dispatch preprocess）。这个路由计算-通信准备的同步停顿是MoE训练慢的核心原因。
• 解决方案：依赖特定硬件和网络特性，如InfiniBand的IBGDI和RDMA，允许网络卡直接访问GPU显存编排通信，绕过CPU。DeepSeek的DeepEP等库即建立在此类硬件之上，在不支持的硬件上将面临严重性能瓶颈。
• 与其他并行的组合实践：EP与PP结合可以有效隐藏通信开销。在PP的流水线气泡（当某批次数据在注意力块时），并行地执行另一批数据在MoE层的All-to-All通信。Megatron等库已通过特定配置选项支持此功能。

54:42 并行策略组合全景图与总结

本节重点

• 所有五种并行策略可以并且正在实践中组合使用。
• 没有自动一键部署的最佳并行配置，硬性约束来自模型大小、剩余网络带宽、全局批次大小。
• 最终的选择取决于具体的硬件环境，特别是加速器互连方式。

详细精要

• 五大并行策略的组合全景：数据并行（DP）、张量并行（TP）、流水线并行（PP）、上下文并行（CP）和专家并行（EP）可以无缝组合。在一个训练步骤中，不同部分会触发不同形式的通信：
• EP：仅应用于MoE层，不触及自注意力。
• CP：仅触及自注意力层。
• TP/SP：控制MLP和注意力内部的模型分片。
• PP：控制模型层间的流动。
• DP：在最外层对数据进行分片。
• 选择并行策略的决策依据 - “无银弹”：是否存在自动确定最佳并行组合的方法？没有普适解。决策高度依赖具体场景：
• 模型大小：是万亿参数还是仅有数十亿？
• 数据量：训练数据总量。
• 任务约束：全局批次大小是多大？
• 硬件约束（最关键）：网络互联是决定性因素。例如，在带宽极高的 NVLink 域内（如一个4-GPU、8-GPU或最新的72-GPU pod），可以承受TP这类通信密集型操作。而在更慢的跨节点网络上，则必须依赖PP或HSDP。
• 总结与行动呼吁：
• 提出一份来自《超大规模训练手册》的速查表，帮助根据GPU数量做出初步的并行选择。
• 推荐关注底层基础设施的《小型训练手册》。
• 对TPU视角感兴趣可阅读Jax Scaling Book。
• 欢迎向 Nanotron、TorchTitan、Megatron-LM 等开源库贡献代码。
• 最后强调社会责任：当扩展至数千GPU时，必须关注其巨大的能源消耗，并负责任地使用计算资源。

---

专业术语注释

术语	解释
AllReduce	一种集合通信操作，对多个进程中的数据进行归约（如求和）后，将结果广播回所有进程。在数据并行中用于同步梯度。
Reduce-Scatter	一种集合通信操作，对多个进程中的数据进行归约（如求和），然后将结果分片，每个进程只获得一个分片。是AllReduce的前半部分。
All-Gather	一种集合通信操作，每个进程提供一份数据，被收集拼接后，广播给所有进程，使得每个进程获得完整数据集。是AllReduce的后半部分。
梯度累积	一种训练技巧，将全局批次拆分为多个微批次，多次前向/反向计算并累加梯度，最后执行一次参数更新，模拟更大批次训练。
全局批次大小	在执行一次优化器步更新前，所有数据并行进程处理的样本总数。等于每个GPU上的微批次大小乘以数据并行的路数再乘以梯度累积步数。
FSDP	完全分片数据并行 (Fully Sharded Data Parallel)，对应ZeRO-3，将模型参数、梯度和优化器状态全部跨GPU分片，运行时按需聚合。
DTensor	PyTorch中的一个分布式张量工具，描述了张量在多设备上的分片方式，使得FSDP2等可以与其它并行策略（如TP）正交组合。
TP (张量并行)	一种模型并行策略，将单个算子（如矩阵乘法）的计算切分到多个GPU上，共同处理同一个输入数据。
SP (序列并行)	张量并行的补充策略，通过将中间激活从沿隐藏维分片转为沿序列维分片，解决了TP中非并行区域的激活内存冗余问题。
PP (流水线并行)	一种模型并行策略，将模型按层垂直切分到不同GPU，数据像流水线一样依次流经各设备，通过处理多个微批次来隐藏设备间的等待。
CP (上下文并行)	一种专门用于长序列训练的并行策略，将单个序列切分到不同GPU上，并使用环注意力（Ring Attention）实现跨设备分片的完整注意力计算。
EP (专家并行)	一种专门用于Mixture of Experts (MoE)模型的并行策略，将不同的专家层放置在不同GPU上，通过 All-to-All 通信进行Token路由。
All-to-All	一种复杂的集合通信操作，每个进程向所有其他进程发送不同数据，并从所有其他进程接收不同数据。在MoE中用于分发和汇总Token。
IBGDI / RDMA	InfiniBand GPUDirect RDMA 的缩写，允许网络卡（如InfiniBand）直接读写GPU显存，无需CPU参与数据拷贝，极大降低通信延迟和同步开销。对高效的专家并行至关重要。
DualPipe	DeepSeek提出的一种高级流水线并行调度算法，通过模型层轮询分配和双向流水注入，旨在完全消除流水线气泡，实现计算最大化。
NVLink	NVIDIA开发的一种高速GPU互联技术，提供远超PCIe的带宽和更低的延迟，使得在单个节点内的高带宽域中可以高效运行张量并行。
MoE	Mixture of Experts (混合专家模型)，一种神经网络架构，由多个“专家”子网络和一个门控路由器组成，每次只激活部分专家参数进行计算，实现模型容量增大而计算量不显著增加。

---

延伸思考

• 全自动并行策略选择器的可行性：业界一直在探索自动化选择最佳并行策略的算法。面对复杂多变的硬件（如不同的NVLink域大小、网络拓扑）和模型结构（尤其是动态架构如MoE），如何构建一个能实时根据效率和显存优化目标，分配/调整并行配置的“编译器”，仍是一个开放且极具价值的课题。
• DeepSeek方案的可复现性鸿沟：本次内容明确指出，DeepSeek在EP/PP组合上的高效方案（如 DualPipe, DeepEP）极度依赖 InfiniBand 的 IBGDI 等先进硬件特性。这为资源有限的实验室和开源社区设立了很高的硬件壁垒。探索在RoCE等更通用网络上实现类似高效MoE训练的方案，是主流社区追赶的关键。
• 负载均衡的深层挑战：尽管有辅助损失或自适应偏置等技术，但在动态多变的数据分布下，保证MoE模型的Token在各专家间绝对均匀分布以避免“专家崩溃”，依然是一个理论上的“完美均衡”与实际工程“近似最优化”之间的博弈。对于超大规模MoE模型，这直接关系到训练稳定性和计算效率。
• ZeRO-3 (FSDP) 与 TP 的实际权衡点：两者都能有效解决大模型显存问题。演讲者强调如模型能用 ZeRO-1/2 即可单卡放下就无需用 ZeRO-3，这个决策边界在实践中依然模糊，尤其是在计算紧耦合与通信松耦合的频谱中，如何量化评估 ZeRO-3 的预取通信开销与 TP 的 AllReduce 开销，是架构师需要反复进行benchmark的系统工程。
• 训练可持续性的度量：演讲最后提到对数千GPU能源消耗的关切。未来在考虑训练效率时，是否应该将每焦耳产生的智能提升作为与每秒算力同样重要的核心指标？这不仅是道德呼吁，也可能在未来成为云厂商成本核算和法规限制的一部分。

原文发表：May 11, 2026  ·  纪要生成：2026-06-22