强项：增加吞吐
模型和激活能装下时，DP 保留较大的本地矩阵计算，通常是优先尝试的扩展方式。梯度可按 bucket 在反向过程中逐步通信，与计算重叠。
GUIDE / DISTRIBUTED TRAINING
模型怎样
跨过一张 GPU？
数据分给谁，矩阵切在哪，层之间怎样接力——通信的形状，决定了并行方式怎样落到网络上。
“资料平行”就是数据并行；“管路平行”通常称为流水线并行。
三者可以同时使用。网络拓扑决定通信成本，模型大小、激活占用、批量和目标吞吐共同决定组合。ZeRO 则在数据并行组内，进一步分摊训练状态的存储。
| 方式 | 分的是什么 | 每张卡做什么 | 主要通信 |
|---|---|---|---|
| DP · 数据并行 | 训练样本 / batch | 用相同模型处理不同数据 | 同步对应参数的梯度 |
| TP · 张量并行 | 同一层的矩阵 / 注意力头 | 合作计算同一批数据的一层 | 每层内的部分结果或激活 |
| PP · 流水线并行 | 模型的不同层 | 计算自己负责的一段网络 | 阶段边界的激活与其梯度 |
| ZeRO · 状态分片 | 参数、梯度、优化器状态 | 分摊状态；按阶段同步 / 聚合 | 梯度归约、参数聚合 |
DATA PARALLELISM
数据并行：四位老师，各批一叠作业
四位老师手里有同一份评分规则，分别看不同学生的作业，然后汇总修改意见，一起更新规则。对应到训练：每张卡有相同的模型参数，拿到不同样本，独立前向与反向；更新参数前，把对应参数的梯度归约并正确归一化。
- 相同起点
GPU 0–3 从一致的模型参数开始。
- 不同样本
每卡处理 8 个样本，合起来覆盖 32 个样本。
- 同步梯度
通过 All-Reduce 汇总各卡的梯度。
- 一致更新
用相同优化器规则更新，副本继续保持一致。
g = (g₀ + g₁ + g₂ + g₃) / 4
这里假定每卡样本数相同，且各卡 loss / 梯度已按相同方式平均。变长样本按 token 平均时要核对权重，不能一律“每卡平均一次”就认为等价。
代价：复制状态
朴素 DP 每卡都有完整参数、梯度与优化器状态。增加卡数不会自动降低单卡的模型状态占用；每步的数据并行同步仍可能受网络带宽限制。
全局 batch = 每副本 microbatch × 梯度累积次数 × DP 度数
TP 和 PP 是合作完成一个模型副本，不要把它们再次乘入独立样本数。增加 DP 度数时，既可以扩大全局 batch，也可以降低每副本 batch 来保持训练配方。来源：PyTorch DDP 设计说明。
TENSOR PARALLELISM
张量并行：一道大题，拆给几个人合作算
一层线性变换是 Y = XW。如果 W 很大，可以把同一层的矩阵分到几张卡，每张卡计算一部分。它们处理的是同一批样本，计算之间有直接依赖。
各自算一部分输出
W = [W₀ | W₁]
Y₀ = XW₀，Y₁ = XW₁
Y₀ = XW₀，Y₁ = XW₁
完整输出是 [Y₀ | Y₁]。若下一层支持这种分片，可以直接保留分片；需要完整输出时才 All-Gather。
各自算贡献，再求和
X = [X₀ | X₁]
Y = X₀W₀ + X₁W₁
Y = X₀W₀ + X₁W₁
两张卡分别算局部贡献，随后通常通过 All-Reduce 求和，或 Reduce-Scatter 留下分片输出。
Transformer 的 MLP 常把前一层的输出维切分与后一层的输入维切分配对，减少不必要的完整聚合；注意力也可按头等维度分配。但 TP 仍通常在很多层中反复通信，链路延迟和带宽都会进入关键路径。
所以 TP 常优先放进高速 NVLink / NVSwitch 域内。它可以减轻每卡参数与部分激活压力，但切得过细会让矩阵变小、通信次数占比变高；8 张卡不等于一定获得 8 倍速度。
实现依据：NVIDIA NeMo 并行机制。ZeRO-3 聚合一层参数后再计算，与 TP 始终以矩阵分片合作计算，是两种不同机制。
PIPELINE PARALLELISM
流水线并行：不同工位，接力完成模型
把 32 层模型分成四段：GPU 0 负责 1–8 层，GPU 1 负责 9–16 层，依次类推。前向时把阶段末端的激活传给下一段；反向时把激活的梯度传回上一段。
如果只送一批数据，其他工位会长时间等待。把一个 batch 拆成多个 microbatch，就能让第一段处理 B 时，第二段处理 A，让流水线逐渐填满。
“错开一点”究竟错开的是什么？
错开的是不同 microbatch 到达各阶段的时间，不是把模型参数错开，也不是让同一个样本跳过层。下面把时间横着展开：追着同一个字母看，它沿对角线依次经过所有阶段；竖着看某个时刻，不同阶段正在处理不同 microbatch。
| 阶段 / 时间 → | t₁ | t₂ | t₃ | t₄ | t₅ | t₆ | t₇ |
|---|---|---|---|---|---|---|---|
| 0 · 第 1–8 层 | A | B | C | D | 空闲 | 空闲 | 空闲 |
| 1 · 第 9–16 层 | 等待 | A | B | C | D | 空闲 | 空闲 |
| 2 · 第 17–24 层 | 等待 | 等待 | A | B | C | D | 空闲 |
| 3 · 第 25–32 层 | 等待 | 等待 | 等待 | A | B | C | D |
t₄ 的瞬间：四个工位一起忙，但忙的不是同一批数据。
阶段 0 算 D，阶段 1 算 C，阶段 2 算 B，阶段 3 算 A。A 仍花 4 个时间槽走完；收益是连续处理 A–D 的总时间从“每批做完再送下一批”的 16 槽，缩到 7 槽。提高的是连续工作的吞吐，不是让一批数据瞬间穿过所有层。
上图只讲前向，不是完整训练调度，也不能据此推算真实训练加速比。训练还需反向：梯度沿阶段 3 → 2 → 1 → 0 传回；同步训练通常在本步 microbatch 梯度累积和所需同步完成后更新参数。
普通流水线 ≠ 专指交错流水线
上图已经有“时间错开”。1F1B 是预热后交替安排一个前向和一个反向任务，两者可以属于不同 microbatch；它不是把同一张卡的前向、反向强行同时执行。
Interleaved 是再细分模型块
交错流水线让同一 GPU 持有多个虚拟阶段。例如 2 张卡：卡 0 放模型块 0、2，卡 1 放模型块 1、3；一批数据按 0 → 1 → 2 → 3 跨卡接力。它可能减少空泡，也会增加通信与调度复杂度，不是“错开一点”的唯一含义。
调度术语与实现参考：PyTorch Pipeline Parallelism · GPipe / 1F1B / Interleaved。这里的时间线是为解释依赖关系构造的教学例子。
通信集中在阶段边界
一个阶段内部可包含多层，因此跨机器通信频率通常低于把每层 TP 都跨机。PP 依然会传输大块激活，长序列、大 microbatch 或慢网络都能让它卡住。
要付出流水线空泡
填充、排空和负载不均会导致空闲。microbatch 数更多可摊薄空泡，但过小的 microbatch 会降低算子效率。1F1B 等调度还会交错前向与反向，以控制激活占用。
理想 GPipe 式调度：空泡比例 ≈ (p − 1) / (m + p − 1)
p 为阶段数，m 为 microbatch 数；假定各阶段均衡，忽略通信与调度开销。p=4、m=16 时约 15.8%。其他调度与不均衡层耗时会改变结果。参考：GPipe、流水线调度说明。
COLLECTIVE COMMUNICATION
先分清：拼起来、加起来、加完再分
| 动作 | 形象理解 | 结果放在哪里 | 训练用途 |
|---|---|---|---|
| All-Gather | 每人有一本书的不同章节，互相交换 | 每人拿到全部章节 | ZeRO-3 聚合本层参数 |
| All-Reduce | 大家对同一份表逐项相加 | 每人拿到完整汇总表 | 普通 DP 同步梯度、TP 合并贡献 |
| Reduce-Scatter | 先逐项相加，再分段保管 | 每人只留汇总表的一部分 | ZeRO-2/3 保留归约后的梯度分片 |
一个常见 All-Reduce 实现可分为 Reduce-Scatter + All-Gather。通信通常按 bucket 批量进行，既能减少小消息启动次数，也便于与计算重叠；不是每个参数都单独发一个网络包。NCCL 集合通信语义 ↗
ZERO REDUNDANCY OPTIMIZER
ZeRO：同样的工作，少存重复状态
普通 DP 的每张卡都保留同一套模型状态。ZeRO 让这些状态在数据并行组内分工保管：先切优化器，再切梯度，最后切参数。它保留数据并行的训练目标；浮点归约顺序等变化意味着不保证逐 bit 一致。
这 16 bytes 分别是什么？
P：低精度参数 2 B；G：低精度梯度 2 B；O：FP32 主参数 4 B ＋ Adam 一阶矩 4 B ＋二阶矩 4 B，共 12 B。这里是特定混合精度 Adam 假设，其他精度和优化器配方会改变数字。
动手算：每卡要保存多少模型状态？
| 阶段 | 每卡常驻状态 | 公式（N 参数、D 卡） | 每卡 GB |
|---|---|---|---|
| Baseline | P、G、O 全部复制 | 16N | 120.00 |
| Stage 1 | P、G 复制；O 分片 | 4N + 12N/D | 31.41 |
| Stage 2 | P 复制；G、O 分片 | 2N + 14N/D | 16.64 |
| Stage 3 | P、G、O 都分片 | 16N/D | 1.88 |
十进制 GB。7.5B 参数、64 卡时，Stage 3 为 1.875 GB，取一位小数即 1.9 GB。
每人保管一部分优化器账本
各卡仍有完整参数、按此基线也保留完整梯度。同步梯度后，每卡只更新自己负责的参数分片及其优化器状态，再同步更新后的参数，使下一步各卡仍能执行完整模型。
梯度汇总完，只交给对应负责人
计算梯度时，按分片进行归约，典型动作是 Reduce-Scatter。每卡长期保留的只有自己负责的归约后梯度；局部梯度和 bucket 仍可能短暂存在。更新后交换参数，完整低精度参数继续复制。
参数也分片，计算某层前临时拼齐
每卡只常驻自己的参数分片。执行一个层或模块前，用 All-Gather 获得本次计算所需参数；计算后按策略释放或保留，在反向需要时再次聚合。梯度归约后分片保留，各卡更新自己的状态。
- 聚合本层参数
All-Gather，通常可预取下一层。
- 计算本地样本
各 DP rank 对自己的 batch 做前向 / 反向。
- 归约梯度分片
Reduce-Scatter 交给对应参数的所有者。
- 更新并管理缓存
更新本地状态；按策略释放完整参数副本。
1.9 GB 是模型状态的理想分片占用，不是训练的总显存。
还要容纳激活、临时聚合的参数、预取与通信缓冲、算子工作区及分配器开销。64 卡共有的状态也没有缩成 1.9 GB；只是每卡分担一份。ZeRO-3 也不保证“算完立即释放所有参数”，实现会在显存与重复通信之间取舍。
原论文在理想通信模型下，Stage 1/2 可以保持与普通 DP 相同量级的通信量；Stage 3 的典型分析从约 2N 元素传输变成 3N，即约 1.5 倍。实际受 dtype、bucket、缓存、预取、梯度累积和拓扑影响，不能把这个比例直接当作耗时增加 50%。
来源：ZeRO 原论文 §3–7 与表 1；DeepSpeed ZeRO 文档。PyTorch FSDP 的完全分片策略与 ZeRO-3 在思想上相近，具体调度和实现不同；CPU / NVMe offload 又是额外的一层存储交换。
MAP COMMUNICATION TO THE FABRIC
把频繁的合作，放到最快的链路里
| 网络特征 | 影响 | 优先考虑的布局 |
|---|---|---|
| 机内 NVSwitch 全连接快域 | 适合频繁的大张量集合通信 | TP 留在域内；也可在域内做 ZeRO / FSDP 分片 |
| 跨机 InfiniBand 带宽足够 | 适合跨副本梯度同步，但总流量仍大 | 跨机器 DP；必要时加入 PP 或跨机分片 |
| 跨机明显慢于机内 | 每层参数聚合或 TP 同步可能暴露等待 | 评估 PP、机内分片＋跨机复制的混合分片 |
| NIC 少、共享上行、交换机超售 | 单端口快，不代表所有 GPU 同时通信仍快 | 按 GPU–NIC 邻近关系映射，检查并发与跨交换机流量 |
| 模型层耗时差异大 | PP 最慢阶段拖慢整个流水线 | 按实测时间切层，或评估更适合的分片组合 |
64 卡例子：8 台机器 × 每台 8 GPU
一种可评估的布局是 TP=8、PP=4、DP=2：每台机器内的 8 卡共同计算一个阶段；4 台机器组成一条完整模型流水线；两条流水线处理不同数据，并同步对应位置的梯度。
总卡数 = TP × PP × DP = 8 × 4 × 2 = 64
这里若 ZeRO 在 DP 维度分片，分片组只有 2 卡，不能把上面的 64 卡节省公式原样套过来。上面的 1.875 GB 示例假设全部 64 卡属于同一个 ZeRO 数据并行分片组。
这是一种候选映射，不是固定配方。模型能装下时也许 DP 加优化器分片更快；单层非常大时可能需要更高 TP；长序列激活占主导时还要考虑重计算或上下文并行。真正约束是显存、消息大小、通信频率和可重叠程度。
参考：NeMo 性能指南 · Parallel Mapping Strategies。NVLink 是互连，NVSwitch 是交换网络；InfiniBand 是跨节点网络体系。它们都不会自动把所有 GPU 显存变成具有本地访问成本的一块内存。
ONE MODEL TEAM, MANY REPLICAS
“剩下的卡，全做资料平行”怎么理解？
先组一支能完成完整模型的队伍，再复制这支队伍。
TP 把同一层的工作分给队友；PP 把前后不同层串成接力；DP 复制整支队伍，让不同队伍看不同数据。三者是同一批 GPU 的三个协作维度，不是把 GPU 分成“张量区、流水线区、数据区”。
为什么图里说 TP 最多 8 张？
这个“8”通常来自特定服务器的高速互连边界。例如 DGX H100/H200 采用 8 张 GPU，机内通过 NVLink / NVSwitch 互连；把频繁通信的 TP 组留在这个快域内，是常见的工程选择。但 TP≤8 不是算法上限，也不意味着有 8 卡就必须 TP=8。TP=2 或 4 也可能更合适；更大的高速域可以评估跨节点 TP，而仅有 8 张 PCIe 卡也不代表拥有同样的通信条件。
硬件依据：DGX H100/H200 系统说明。截图中的“先 TP、再切层、再 DP”适合理解某类大模型布局，不是所有训练的固定起手式；能装下且性能合适时，可直接从 DP 加状态分片开始。
64 张卡：TP=8、PP=4、DP=2
沿用 8 台 × 每台 8 GPU 的例子。先用 4 台机器组成一个完整模型副本：每台的 8 卡共同计算一个阶段，4 个阶段接起来才是完整模型。剩下 4 台机器，正好再组成一套同样的副本。
副本 0处理数据 A
机器 0阶段 0 · TP 8 卡模型前 ¼
机器 1阶段 1 · TP 8 卡模型第 2 段
机器 2阶段 2 · TP 8 卡模型第 3 段
机器 3阶段 3 · TP 8 卡模型后 ¼
DP 同步
↕ 对应分片
↕ 对应分片
↕ 对应分片
↕ 对应分片
副本 1处理数据 B
机器 4阶段 0 · TP 8 卡模型前 ¼
机器 5阶段 1 · TP 8 卡模型第 2 段
机器 6阶段 2 · TP 8 卡模型第 3 段
机器 7阶段 3 · TP 8 卡模型后 ¼
每个完整模型副本用卡 = TP × PP = 8 × 4 = 32
副本数 DP = 总卡数 / (TP × PP) = 64 / 32 = 2
副本数 DP = 总卡数 / (TP × PP) = 64 / 32 = 2
具体到一张卡：机器 0 的 TP 位置 3，与同机其余卡合作算阶段 0；它的对应 PP 通信沿其他阶段传递，实际消息路径取决于激活如何分片；它还与机器 4 的 TP 位置 3 同步相同参数分片的梯度。所有卡都在参与训练，不存在额外抽出 2 张卡“专门负责数据并行”。
这里 DP=2 意味着有 32 个两卡 DP 组（每个 PP 阶段、每个 TP 位置各一个），而不是一个随意包含两台机器全部 GPU 的归约组。“副本”描述完整模型计算的逻辑；若再启用 ZeRO-3，参数存储仍可能跨 DP 副本分片，并不保证每条流水线常驻全部参数。
是“大部分 TP+PP，少部分 DP”吗？
不能用卡数百分比这样分。下面都是 64 卡的候选布局，差别是每个模型副本有多大、能并排放多少个副本。同样的 TP=8、PP=4，如果总卡数增至 256，DP 就可以从 2 变成 8；并不需要先把 TP 再加大。
| TP | PP | 每副本用卡 | DP 副本数 | 可能适合的情况 |
|---|---|---|---|---|
| 1 | 1 | 1 | 64 | 单卡计算能承载；必要时结合 DP 维度的状态分片 |
| 4 | 1 | 4 | 16 | 需要适量层内切分，尚不需要流水线 |
| 8 | 2 | 16 | 4 | 每副本跨 2 台 8 卡机器接力 |
| 8 | 4 | 32 | 2 | 本节图示：每副本跨 4 台机器 |
| 8 | 8 | 64 | 1 | 全部卡合作完成一个副本，没有多副本 DP 扩展 |
公式 G = TP × PP × DP 适用于这里仅考虑这三个维度的规则布局；各维度必须与可用卡数、层和张量切分约束相容。引入上下文并行或专家并行后，应按框架的实际设备网格重新核算，不能随意把所有名称的度数直接相乘。混合实现示例：NeMo AutoModel · Mixed Parallelism Examples。
参数量会决定 DP 是多还是少吗？
会影响，但通常是通过单副本的显存与计算需求间接影响：固定总卡数、显存容量和训练配方时，模型更大，可能需要更大的 TP×PP，剩下可复制的份数 DP 就更少。它不是“参数超过多少，就必须用某种固定比例”。
参数与优化器状态
沿用前文每参数 16 bytes 的训练状态假设，且先不加 ZeRO、理想均分，单卡状态约为 16N / (TP×PP)。固定 TP=8、PP=4：7.5B 约 3.75 GB，70B 约 35 GB，175B 约 87.5 GB。最后一种连状态本身都超过 80 GB，必须改变分片或其他存储策略。
不止看总参数量
相同参数量，长序列、大 microbatch、更多未释放激活也会让显存吃紧；模型更宽与层数更多，适合的切法也不同。精度、全量训练或 LoRA、优化器、重计算和 ZeRO 阶段都会改变所需用卡。上面的状态数字不是训练峰值。
ZeRO 会改变“模型越大，DP 就越少”的简单推断。
DP 不只可以复制状态，也可以通过 ZeRO 分摊状态。如果采用理想 ZeRO-3、模型均分且全部 DP rank 都参加分片，单卡常驻状态近似 16N / (TP×PP×DP) = 16N/G；固定 G 时，它甚至不随三者的分解方式变化。但临时参数聚合、激活和通信代价仍然不同，所以同样“装得下”也可能快慢悬殊。
实际使用：先找瓶颈，再决定怎么扩
模型能运行，主要想多处理样本
先比较 DP 或 DP 加状态分片，不必为了有多卡而加入 TP、PP。扩 DP 时要检查每副本工作量是否足够，以及全局 batch 是否符合训练目标。
单层矩阵太大，或层内计算需要分摊
在高速互连域内评估 TP=2、4、8 等配置，验证维度可切、算子效率和通信开销；不是总把 8 用满。
整套模型仍放不下，且可以按层接力
评估 PP、ZeRO / FSDP、重计算等组合。PP 靠 microbatch 填满流水线；ZeRO / FSDP 是分片存储，不能把截图里的“shard”一概当成 PP 的同义词。
确定一支高效模型队伍后，再复制扩吞吐
按 DP = G/(TP×PP) 核算可用副本；这只是初始方案，仍应联合比较不同组合。固定全局 batch 时，DP 太高会压缩每副本 microbatch 数，可能影响 PP 空泡和本地计算效率。
全局 batch = 每个 microbatch 的样本数 b × 每副本本步 microbatch 数 m × DP
例如 b=2、m=16、DP=2，全局 batch 是 64 个样本，不再乘 TP=8 或 PP=4。这里 m 已包含本步的 microbatch 累积，不要再乘一次同义的梯度累积次数。布局选择参考：NeMo 并行映射指南（25.09 归档版）；数值案例均为本文的简化计算，不是模型部署门槛。
LATENCY IS NOT BANDWIDTH
从片内到机间：等多久，搬多快？
延迟是发出一次请求后多久能用到结果；带宽是持续传输时每秒能搬多少字节。缓存命中、GPU 指令读、DMA 拷贝、RDMA 消息与 NCCL 集合通信测的是不同路径，不能直接拿一个数互相替代。
一次消息的简化时间 ≈ α ＋ 数据量 S / 有效带宽 B
α 包含所采用路径的启动、协议与同步成本；集合通信还要考虑多轮交换、拓扑和拥塞。1 μs = 1000 ns；1 ms = 1000 μs；400 Gb/s ÷ 8 = 50 GB/s。
单次访问：片内与本地显存的实测案例
| 位置 | H800 PCIe 实测延迟 | 按 1.755 GHz 换算的示意 | 如何理解 |
|---|---|---|---|
| 寄存器 | 没有统一的“内存读取延迟” | 依赖具体指令与依赖链 | 操作数直接供执行单元使用；不能和 HBM load 同口径比较 |
| 片上 Shared Memory | 29.0 cycles | 约 16.5 ns | 线程块合作；bank conflict 会改变成本 |
| 片上 L1 Cache 命中 | 40.7 cycles | 约 23.2 ns | 每 SM 的缓存命中路径 |
| 片上 L2 Cache 命中 | 263.0 cycles | 约 149.9 ns | 跨 SM 共享的片上缓存 |
| 片外本地 HBM2e | 478.8 cycles | 约 272.8 ns | 测试数据大于 L2，TLB 已预热 |
来源：Hopper 微基准论文，表 III / IV。这是 H800 PCIe 的特定测试，不是所有 GPU 的通用常数；纳秒数由论文所列最高时钟换算，仅用于直觉，实际时钟会波动。下表采用 H100 SXM 与常见互连规格，属于不同来源，不是同一台机器上的整套实测。
跨层级传输：硬件带宽和软件访问边界
| 路径 | 代表带宽与口径 | 延迟该看什么 | 主要限制 |
|---|---|---|---|
| GPU 片内 SRAM / Cache | Shared 的 H800 案例约 127.9 B/cycle/SM | 上表的依赖访问 cycles | 每 SM 的局部吞吐，不能直接当作整卡外部链路 |
| GPU 芯片 ↔ 本卡 HBM | H100 SXM：3.35 TB/s，整卡显存峰值 | 缓存未命中时的 load 延迟；并行读能隐藏部分等待 | 访存布局、并发请求、缓存行为 |
| GPU ↔ GPU · NVLink 4 / NVSwitch | H100：900 GB/s 双向合计；约 450 GB/s 单向预算 | 远端 load、P2P copy、NCCL 启动各有不同数值，需实测 | 是每 GPU 多链路合计，不保证任意一对卡都达到此值 |
| GPU ↔ 主机内存 / PCIe 对端 | PCIe 5.0 ×16：约 63 GB/s 单向，协议开销前 | DMA 启动与远程 load 分开测；pageable 内存还可能需中转 | CPU DRAM、NUMA、PCIe root complex、链路共享及 P2P 支持 |
| 机器 ↔ 机器 · NDR InfiniBand | 单个 400 Gb/s 端口：50 GB/s 单向换算，协议开销前 | GPU–GPU 消息通常以 μs 测；旧 Selene 案例为 3.4 μs，不能套成 NDR 固定值 | GPU–NIC PCIe、NIC 数量、交换机层级、超售、拥塞 |
| 机器 ↔ 机器 · Ethernet / RoCE | 100 / 400 Gb/s：12.5 / 50 GB/s 每端口单向换算 | RDMA 与普通 TCP 软件路径不同，需分别测延迟 | 拥塞控制与网络配置；RoCE 是 Ethernet 上的 RDMA |
规格与口径：H100、NVLink 双向带宽、PCI-SIG、ConnectX-7。3.4 μs 来自 2020 年 NVIDIA Selene 跨节点 GPU–GPU MPI 测试；它展示软件路径的影响，不与上述缓存测试直接排名。
GPUDirect RDMA 省掉的是主机中转，不是物理距离。
典型跨机路径是 GPU 显存 → 本地 PCIe / NIC → 网络交换机 → 对端 NIC / PCIe → 对端 GPU 显存。NIC 可直接访问 GPU 内存，避免先拷到 CPU 内存；网络带宽、延迟和同步仍然存在。NVLink-C2C 连接 CPU 与 GPU 的系统又不同于这里的传统 PCIe 主机路径。
相同的数据量，仅传输时间相差多少？
下面只算 S/B，不含启动、读写两端开销和集合通信多轮交换；不能当作真实 memcpy 或训练耗时。
| 参考路径 | 单向计算预算 | 仅 S/B |
|---|---|---|
| 本卡 HBM 读取 | 3350 GB/s | 0.321 ms |
| NVLink 聚合链路 | 450 GB/s | 2.386 ms |
| PCIe 5.0 ×16 | 63 GB/s | 17.044 ms |
| 400 Gb/s 单端口 | 50 GB/s | 21.475 ms |
| 100 Gb/s 单端口 | 12.5 GB/s | 85.899 ms |
1 GiB = 1,073,741,824 bytes；GB/s 使用十进制。100% 是理想预算，不代表实际能跑满。
小消息常被 α 主导：只传几 KiB 时，S/B 很小，启动与同步却不会消失。大消息则更容易暴露带宽瓶颈。把很多小消息合并、预取下一层参数、让通信与独立计算重叠，都在减少关键路径上真正需要等待的部分。
A PRACTICAL DECISION ORDER
先能装下，再让关键路径更短
拆开显存账单
分别统计参数、梯度、优化器状态、激活和临时缓冲。状态占主导时评估 ZeRO；激活占主导时还要调 microbatch、重计算或序列相关并行。
画出真实连接
核对 NVLink 快域、GPU–NIC 邻近、PCIe 分叉、每机端口数与交换机超售。不要只看“有 InfiniBand”或“有 8 张卡”。
建立一个可比较基线
先测能运行的 DP / 分片方案，再比较 TP、PP 组合。固定有效全局 batch、序列长度、精度和质量目标，区分扩 batch 的吞吐收益与固定工作量的加速。
用实际消息大小测通信
用 nvbandwidth 检查 P2P 路径，用 nccl-tests 检查 All-Reduce / All-Gather / Reduce-Scatter，用网络 perftest 检查 RDMA。记录 API、大小、单向 / 双向和并发方式。
回到端到端时间线
观察通信是否暴露、流水线是否空闲、阶段是否均衡、参数聚合是否撞上显存峰值。最终比较 tokens/s、step time 和峰值显存，而不只比较链路峰值。
同一台机房，不同模型也可能选择不同的并行组合。
最合适的方案，取决于能否把该模型最频繁、最难隐藏的通信放进足够快的网络域，同时保留足够大的本地计算和可承受的显存占用。
PRIMARY SOURCES & FIGURE NOTES
继续阅读与复现
PAPERZeRO · 原始状态分片与通信分析↗DOCSDeepSpeed · ZeRO Stage 1–3↗DOCSPyTorch · DistributedDataParallel↗GUIDENeMo · Parallel Mapping Strategies↗PAPERGPipe · 流水线与 microbatch↗DOCSNCCL · 集合通信↗PAPERHopper 微基准 · 访问延迟和吞吐↗TOOLNVIDIA nvbandwidth · 路径带宽与延迟↗TOOLNCCL Tests · 集合通信测试↗
三张配图为 AI 生成的教学示意，用于帮助理解分工与通信关系；精确数值、假设和公式以正文表格及所引来源为准。本文没有对用户机房进行硬件测试。