LLaMA 3 70B 训练实操:几张卡、几天、几美元

24 分钟阅读

LLaMA 3 70B 训练实操:几张卡、几天、几美元

前情说明:技术深度 D2。《读 JAX Scaling Book》系列第 4 篇。

前三篇把工具箱备齐了:Roofline 回答一个 kernel 该多快,Sharded Matmul 回答怎么切,Transformer Math 回答该算多少。这一篇把工具全用上,算一次真实的 LLaMA 3 70B 训练预算:

  • 选 DP / FSDP / TP / PP 的哪种组合?
  • 具体切成几份(比如 TP=8 还是 TP=16)?
  • 每种方案什么时候 comms-bound,什么时候 compute-bound?
  • 多少张 H100、多少天、多少美元?

原书的例子基于 TPU v5p;我把数字替换成 H100 做实战对标,并补充 Meta 实际用 16K H100 训练 15T tokens 的真实数据。学完这篇,面试被问“你会怎么训一个 70B”能当场在白板上算出来。


一、什么叫 Scaling 得好

先定义目标。理想是“硬件翻倍 → 吞吐翻倍”(strong scaling)。但 N 张卡拼在一起时有两个敌人:

   敌人 1: 显存压力
     参数 + 梯度 + 优化器 + 激活 加起来 >> 单卡 HBM
     解法 → 分片

   敌人 2: 通信开销
     分片之后一定有 collective (AllGather/ReduceScatter/AllReduce)
     卡越多 → 单卡算得越少 → 越难把通信时间藏进计算里

关键洞察:单卡性能看 "memory bandwidth vs FLOPs"(Roofline);集群性能看 "inter-chip comms vs FLOPs"——通信能不能被计算 overlap 掉。

本文全程围绕一个判据:

  T_math > T_comms   →   compute-bound  (好)
  T_math < T_comms   →   comms-bound    (坏,硬件在等通信)

四种并行方案,每种都有自己的 T_math / T_comms 公式。核心任务是判断什么时候临界。


二、四种并行方案的记号

全程用一个简化 Transformer 层(忽略 attention 和 gating,因为 MLP 主导 FLOPs):

  输入:  In[B, D]            B = batch 的 token 总数
                             D = d_model
  权重:  Win[D, F]           F = d_ff (通常 4D 或 8D/3)
         Wout[F, D]
  输出:  Out[B, D]

四种方案(用 Sharded Matmul 的 [IX, JY] 记号):

  方案 1: Data Parallelism (DP)
    In[B_X, D] · Win[D, F] · Wout[F, D] → Out[B_X, D]
    ─────────────────────────────────────────────────
    batch 切 X,权重完全复制
    fwd 零通信,bwd 一次 AllReduce 梯度

  方案 2: FSDP (ZeRO-3)
    In[B_X, D] · Win[D_X, F] · Wout[F, D_X] → Out[B_X, D]
    ─────────────────────────────────────────────────
    batch 切 X,权重也沿 X 切,用之前 AllGather,用完丢
    fwd AllGather 权重,bwd AllGather + ReduceScatter

  方案 3: Tensor Parallelism (TP / Megatron)
    In[B, D_Y] · Win[D, F_Y] · Wout[F_Y, D] → Out[B, D_Y]
    ─────────────────────────────────────────────────
    F 维度切 Y,activations 不切 batch
    每层 fwd: AllGather 输入 + ReduceScatter 输出

  方案 4: Pipeline Parallelism (PP)
    把 L 层按层数切,每张卡只持有部分层
    micro-batch 流水过所有卡
    每个 stage 之间只传 activation (单跳)

后续分析全部围绕每种方案的 T_math / T_comms 比较展开。


三、Data Parallelism:最简单也最早撞墙

3.1 通信账本

  每层:
    fwd: 零通信
    bwd: 2 次 AllReduce (对 Win 和 Wout 的梯度)
         每次 AllReduce 的量 = DF 参数 = 2DF bytes (bf16)
         AllReduce cost = 2 × bytes / W  (= AG + RS)

  每层 bwd comms = 2 × 2 × 2DF / W = 8DF / W

  每层 bwd FLOPs = 4BDF / X (两个 matmul,bwd 是 fwd 的 2x,每卡批次是 B/X)
  每层 bwd FLOPs 时间 = 8BDF / (XC)   注: ×2 因两个 matmul

  compute-bound 条件:
    8BDF/(XC) > 8DF/W   ⇒   B/X > C/W

3.2 关键临界值 C/W

  C = per-chip FLOPs/s     W = 双向互联带宽

  硬件              C (bf16)        W                    C/W
  ──────────────────────────────────────────────────────────
  TPU v5p           4.59e14         1.8e11               2550
  H100 (NVLink)     989e12          900e9                1099
  H100 (IB 400Gbps) 989e12          50e9                 19780

面试锚点:"compute-bound 需要 per-device batch > C/W" 这个判据来自"计算随 batch 线性增长,但通信跟 batch 无关(传的是权重)"。

3.3 多轴加速

当有多个 mesh axis(比如 TPU pod 的 3D mesh 或 H100 节点内的 NVSwitch),通信可以同时用多个轴:

  M 个轴 → 等效带宽 ×M → 临界 B/X ÷M
  ─────────────────────────────────────
  TPU v5p 3D pod: 临界降到 2550/3 = 850
  H100 节点内 (1 个 NVSwitch 域): M=1,仍是 1099

3.4 DP 的致命伤:显存

  纯 DP 时每卡要存:
    bf16 权重      : 2 × 70e9 = 141 GB
    bf16 梯度      : 2 × 70e9 = 141 GB
    fp32 Adam m    : 4 × 70e9 = 282 GB
    fp32 Adam v    : 4 × 70e9 = 282 GB
    fp32 master w  : 4 × 70e9 = 282 GB
    ─────────────────────────────────────
    合计          : 16 bytes/param = 1128 GB

  H100 单卡 80 GB → 根本放不下!

结论:纯 DP 只能训小模型。TPU v5p 单卡 96 GB,极限约 9B 参数(96/10)。H100 单卡 80 GB,极限约 8B 参数。70B 必须换方案。


四、FSDP:同样的通信代价,但显存降 N 倍

FSDP 的核心 trick:不要让每卡都存完整参数,只存一片;需要时临时拉完整,算完立刻丢。

4.1 FSDP 的时间线

  fwd 每层:
    AllGather Win  (可和上一层计算 overlap)
    算 In · Win    (零通信)
    discard Win    (立刻丢!)
    AllGather Wout (可和上一步计算 overlap)
    算 ... · Wout  (零通信)
    discard Wout

  bwd 每层:
    梯度不再 AllReduce,改成 ReduceScatter
    (每卡只保留自己那片参数对应的梯度)

4.2 为什么通信代价和 DP 完全一样

  关键恒等式: AllReduce = AllGather + ReduceScatter

  纯 DP :  2 AllReduce / layer = 2 × (AG + RS)
  FSDP  :  fwd 2 AllGather + bwd 2 AG + 2 RS = 2 AG + 2 (AG+RS)
  ─────────────────────────────────────────────────
  字节数差不多(严格说 FSDP fwd 多出一轮 AG,但相对 bwd 可忽略)

结论:FSDP 通信量 ≈ DP,但显存降到 1/N(每卡只存一份优化器状态)。

所以几乎没有理由选纯 DP 而不是 FSDP——除非你的 cluster 实现不支持 FSDP。

4.3 compute-bound 条件完全相同

  B/X > C/W

  但多了显存优势!
  per-device 显存 ≈ 16B/N (N 卡) 而不是 16B

4.4 Llama 3 70B 的 FSDP 极限

Meta 实际用 BS = 4M tokens 训练(早期阶段,后期扩到 16M):

  想在 8960 卡上纯 FSDP (比如 TPU v5p pod):
    per-device batch = 4e6 / 8960 = 468 tokens
    临界 (3 轴) = 2550/3 = 850
    ─────────────────────────────────
    468 < 850 → comms-bound! 跑不动纯 FSDP

  想在 H100 侧跑 (假设有 8960 卡,但 M=1,因为 NVLink 只在节点内):
    临界 = 1099 (单 NVLink 域)
    468 < 1099 → 还是 comms-bound!

所以 70B 单纯用 FSDP 在 8K+ 卡上必然撞墙,得混合方案。


五、Tensor Parallelism:动的不是权重是激活

5.1 TP 的通信账

  TP syntax: In[B, D_Y] · Win[D, F_Y] · Wout[F_Y, D] → Out[B, D_Y]

  每层 fwd:
    AllGather In     ← 这里要通信,量 = 2BD bytes (bf16)
    算 In · Win      ← 零通信 (Case 1: contract 维都没切)
    算 Tmp · Wout    ← Case 3 (都切了 contract),产生 unreduced
    ReduceScatter Out  ← 量 = 2BD bytes

  每层 fwd comms = 2 × 2BD = 4BD
  每层 fwd FLOPs = 4BDF/Y
  compute-bound 条件:
    4BDF/(YC) > 4BD/W   ⇒   F > Y × C/W

5.2 关键结论:TP 的 Y 不能太大

  TPU v5p: Y_max = F / 2550
  H100:    Y_max = F / 1099

  Llama 70B (F=28672):
    v5p : Y_max = 11
    H100: Y_max = 26

  但实际 TP=8 不是公式决定的!是物理决定的:
    NVSwitch 域内 = 8 GPU(DGX H100 节点)
    跨节点 IB 带宽只有 50 GB/s → alpha_ib = 19780
    → 跨节点 TP 需要 F > 16 × 19780 = 316480,根本不可能

  → TP 永远不要跨节点
  → TP ∈ {1, 2, 4, 8}

5.3 和 batch 无关是优点也是缺点

  TP 临界条件 F > Y·C/W 不依赖 batch size
  ─────────────────────────────────────────────
  优点: batch 很小也能跑(推理时也有用!)
  缺点: 想继续加卡,F 得变大(模型得更宽)

面试锚点:为什么 TP 必须机内,而 FSDP 可以跨节点?因为 TP 搬 activation(每层都发),FSDP 搬权重(一个 micro-batch 共享一次 AllGather)。activation 吞吐频率高 10-100 倍。


六、混合 FSDP + TP:最优配比的数学

单独用 FSDP 或 TP 都撞墙时,组合起来可以把临界 batch 继续往下压。

6.1 核心公式

  设 X = FSDP 轴, Y = TP 轴, XY = N (总卡数)
  F = d_ff,  α = C/W

  混合方案的通信时间:
    T_FSDP_comms ∝ F·X/N  (FSDP 搬权重,X 越大越慢)
    T_TP_comms   ∝ B/X    (TP 搬 activation,X 越大 batch 越小越快)

  总通信时间 = max(两者)
  ──────────────────────────────────────
  两者相等时达到最小!

6.2 最优 X_opt

两者相等解方程得:

  X_opt = sqrt(B/F × M_X/M_Y × N)

解读:

  • B 大 → 更多 FSDP(因为每卡 batch 大,TP 的 AllGather 代价大)
  • F 大 → 更少 FSDP(模型宽,TP 更划算)
  • N 大 → 更多 FSDP(但按根号增长,不是线性)

6.3 混合方案的临界 batch

  compute-bound 条件(代入 X_opt):

    B/N > α² / (M_X · M_Y · F)

对比:

  纯 FSDP (3 轴): B/N > C/W / M = 2550/3 = 850
  混合   (3 轴, F=28672): B/N > 2550²/(2·28672) = 113

  → 混合方案能把临界 B/N 降 7.5 倍!

6.4 Llama 3 70B 实际配置

用公式算一次:

  B = 4M tokens, N = 8960 卡, F = 28672

  X_opt = sqrt(4e6/28672 × 2/1 × 8960)
        = sqrt(2498)
        ≈ 1618

  → FSDP ≈ 1024 ~ 2048
  → TP   ≈ 4 ~ 8

结论:Meta 实际用的 DP=1024, SP=2, TP=8 几乎就是公式最优解。

  ┌──────────────────────────────────────────────┐
  │  Llama 3 70B @ 8960 卡最优配置                │
  │  ─────────────────────────────────────────   │
  │  FSDP (DP+SP) = 2048                          │
  │  TP           = 4~8  (NVSwitch 域内)          │
  │  per-device batch ≈ 2000 tokens              │
  │  高于临界 113,安全 compute-bound             │
  └──────────────────────────────────────────────┘

七、Pipeline Parallelism:为什么 GPU 更需要它

7.1 PP 的本质

  把 L 层按层切到 N 张卡
  每卡只持有 L/N 层参数
  数据以 micro-batch 的形式流过所有卡
  stage 之间只传 activation (单跳 point-to-point)

7.2 为什么 PP 对 GPU 更重要

  TPU: ICI 全互联,带宽充足,TP 跨机不是问题
  GPU: NVLink 只在节点内 (8 卡),跨节点 IB 带宽骤降 20 倍

  → GPU 必须 TP ≤ 8
  → 剩下的大模型切分压力必须靠 PP + FSDP
  → 这就是 Megatron-LM 发明 3D (TP+PP+DP) 并行的根本原因

7.3 Pipeline Bubble

  传统 pipeline schedule (每 stage 一个 micro-batch):

    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 (GPU 0 空闲)  └────┘ bubble

  bubble 比例 = (N-1) / (N + M - 1)
             N = pipeline stages
             M = micro-batches

减小 bubble 的方法:

  1. Micro-batching:增大 M → bubble 占比降低(但 M 太大显存爆)
  2. 1F1B schedule:前面做 bwd 时后面继续 fwd,减少中间 activation 显存
  3. Interleaved pipeline(Megatron):把每层拆成多段,穿插排布
  4. DualPipe(DeepSeek V3):把 AllToAll 塞进 bubble 里,通信免费

7.4 面试锚点:为什么 TPU 没流行用 PP

  TPU v5p pod = 8960 卡,通过 ICI 全互联
  节点内外带宽差异小
  → TP + FSDP 够用,不需要 PP

  H100 cluster
  → NVSwitch 域 = 8 卡
  → 跨节点带宽暴跌
  → TP≤8, 剩下的 scale 靠 PP + FSDP

八、跨 Pod 怎么扩

单个 TPU v5p pod 最大 8960 卡,再大就得跨 pod 走 DCN(数据中心网络)。H100 侧类似——跨节点必须走 IB。

  典型架构:
    pod 内:  FSDP + TP (ICI/NVLink 高速)
    pod 间:  纯 DP (DCN/IB 低速)

  跨 pod DP 临界条件:
    per-pod batch > C/W_dcn

  TPU v5p:
    C/W_dcn = 4.59e14 / 6.25e9 = 73,440 tokens/pod
    pod 内有 8960 卡 → 每卡至少 ~8 tokens → 极低门槛

  H100:
    一个 DGX 节点 = 8 卡,IB 400 Gbps
    C/W_ib = 989e12 / 50e9 = 19,780 tokens/node
    每卡 ~2500 tokens → 还是容易达到

结论:跨 pod/节点扩规模很容易,只要每 pod 的 batch 足够大就行。

8.1 Llama 3 70B 多 pod 训练

Meta 实际在 16K H100 (2K 节点) 上训:

  BS = 16M tokens 最终阶段
  per-node batch = 16e6 / 2000 = 8000 tokens
  per-GPU batch  = 1000 tokens

  跨节点要求 per-node > 19780? 不够!
  ──────────────────────────────────────
  但 Meta 用的 schedule 允许多个 DP 轴
  跨节点 DP ring 可以有 M=4 甚至更多轴 → 临界降为 ~5000

实际做法:节点内 TP=8,节点间 FSDP,再把 FSDP 拆成 "intra-pod FSDP + inter-pod DP",三级嵌套。


九、Llama 3 70B 完整预算核算

把前面所有公式用上,算一次真实训练预算。

9.1 FLOPs 总量

  参数 = 70.55 B (前文算过)
  tokens = 15 T (Meta 公开数据)

  总训练 FLOPs = 6 × 70.55e9 × 15e12 = 6.35e24

  = 6.35 yottaFLOPs

9.2 时间估算

  H100 bf16 峰值 = 989 TFLOPs/s
  MFU = 40% (大 cluster 真实值)
  有效 = 395 TFLOPs/s per GPU

  不同规模对比:
  ────────────────────────────────────────
  8960 H100 : 6.35e24 / (8960 × 395e12 × 86400) = 20.7 天
  16000 H100: 6.35e24 / (16000 × 395e12 × 86400) = 11.6 天
  32000 H100: 6.35e24 / (32000 × 395e12 × 86400) = 5.8 天

Meta 公开数据:16K H100 跑了 ~54 天(含评估、checkpointing、重试,实际有效时间约 12 天,和上面 11.6 天估算几乎一致!)

9.3 美元成本

  总 GPU 小时 = 6.35e24 / (989e12 × 0.4) / 3600
             ≈ 4.46 M GPU-hours

  云端 (lambda / coreweave) @ $2/卡时:  约 $8.9 M
  自建 (折旧 $0.6/卡时)              :  约 $2.7 M

  Meta 实际成本据估 (含数据/人力/多次迭代): $30-50 M

9.4 显存账本

8960 卡 FSDP+TP=4 配置下:

  per-GPU 显存:
    权重 (fp32 master w, bf16 copy): 2+4 = 6 bytes/param
      分片到 FSDP=2048 → 70.55e9 × 6 / 2048 / 4 (TP) = 51 MB (极小)

    梯度 (bf16): 2 × 70.55e9 / 2048 / 4 = 17 MB

    优化器 Adam m+v (fp32): 8 × 70.55e9 / 2048 / 4 = 69 MB

    激活 checkpoints (2/layer, BS=2048 per GPU):
      2 × 2048 × 8192 × 80 × 2 bytes / 4 (TP) ≈ 1.3 GB

    合计: ~1.5 GB/GPU

  H100 80GB 显存 → 利用率 ~2%

关键洞察:大规模训练并不是显存瓶颈,而是 FLOPs 瓶颈!我们用 8960 卡不是因为显存不够,而是因为要快——117 张 H100 技术上就能装下 70B,但要训 10 年。


十、决策流程图

现在把所有判据组装成一个决策流程:

                 START: 要训一个 N 参数模型
                        BS = B, 卡数 = K
                              │
                              ▼
            ┌─────────────────────────────┐
            │ 单卡能放下 N 吗?            │
            │ (显存 > 16N bytes, Adam fp32)│
            └──────┬──────────────────────┘
                   │
          Yes      │           No
         ┌─────────┴──────────┐
         ▼                    ▼
    ┌────────────┐    ┌──────────────────┐
    │  纯 FSDP   │    │ FSDP + TP 混合   │
    │ (或纯 DP)  │    │                  │
    └────┬───────┘    └────┬─────────────┘
         │                 │
         ▼                 ▼
    B/K > C/W?          B/K > α²/(2F)?
         │                 │
     Yes │ No         Yes  │ No
         │                 │
         ▼                 ▼
    ✓ compute-bound   ⚠ 还要加 PP
                          (大模型跨节点)

Llama 3 70B 走流程:

  1. 单卡放不下 (80GB << 1128GB) → 进 FSDP+TP 混合分支
  2. B/K = 4e6/8960 = 468
  3. α²/(2F) = 1099²/(2·28672) ≈ 21
  4. 468 >> 21 → compute-bound,无需 PP
  5. X_opt = sqrt(4e6/28672 × 2 × 8960) ≈ 1618
  6. 四舍五入: FSDP=2048, TP=4 (NVSwitch 域内)
  7. 时间 = 6×70e9×15e12 / (8960×989e12×0.4) = 20 天

整个过程纯机械,这就是公式系统的威力。


十一、面试锚点

Q1: 四种并行方案(DP/FSDP/TP/PP)的本质区别?

A: 用 [IX, JY] 记号看最清晰:

  • DP: In[B_X, D] · Win[D, F]——切 batch,权重复制
  • FSDP: In[B_X, D] · Win[D_X, F]——同时切 batch 和权重,临时 AllGather
  • TP: In[B, D_Y] · Win[D, F_Y]——切权重的 F 维度,activation 的 D 维度
  • PP: 按层切,与前三者正交

关键区别:DP/FSDP 搬权重,TP 搬 activation,PP 搬 inter-stage activation。

Q2: FSDP 和纯 DP 通信量差不多,为什么还要用 FSDP?

A: 显存。DP 每卡要 16 bytes/param(Adam),FSDP 分到 N 份变成 16/N。通信量相同是因为 AllReduce = AllGather + ReduceScatter——FSDP 只是把 bwd 的 AllReduce 拆成两步并把 AllGather 挪到 fwd。只有极端小模型且 N 小,DP 更简单才用。

Q3: TP 为什么必须机内?

A: TP 每层都要搬 activation(AllGather + ReduceScatter)。频率极高。只有 NVLink(900 GB/s)或 TPU ICI 的带宽才能让 T_comms < T_math。跨节点 IB 带宽 50 GB/s,C/W = 19780,F 要大于 16·19780 = 316K 才能跑 TP=16——现实模型 F 都远小于这个数。

Q4: 为什么 TP 的临界条件不依赖 batch?

A: TP 搬的是 activation 的 [B, D] 矩阵,而 FLOPs 是 [B, D] × [D, F/Y]——两者都跟 B 成正比,B 在比值中消去。所以 TP 的 F > Y·C/W 条件和 batch 无关。推论:TP 对小 batch 场景(推理 decode)极友好。

Q5: FSDP+TP 的最优配比怎么选?

A: 公式 X_opt = sqrt((B/F)·(M_X/M_Y)·N)。直觉:

  • B 大 → 多 FSDP(per-chip batch 大,TP AllGather 贵)
  • F 大 → 少 FSDP(模型宽,TP 划算)
  • N 大 → 多 FSDP,但按 √N 增长

Llama 70B @ 8960 卡,BS=4M → X_opt ≈ 1618 → 实际 FSDP=1024/2048, TP=4/8。

Q6: Pipeline Parallelism 为什么对 GPU 比对 TPU 重要?

A: TPU 的 ICI 全互联、带宽均匀,TP 跨机也没问题。GPU 的 NVLink 只到节点内(8 卡),跨节点带宽暴跌 20 倍 → TP ≤ 8 是物理上限。70B 以上模型必须靠 PP + FSDP 继续切。这就是 Megatron 发明 3D(TP+PP+DP)并行的根本原因。

Q7: Pipeline Bubble 怎么减小?

A: 四种方法:

  1. Micro-batching:bubble 占比 = (N-1)/(N+M-1),M 增大 → bubble 减小
  2. 1F1B schedule:降低峰值 activation 显存,让 M 能更大
  3. Interleaved pipeline(Megatron):每层拆多段穿插
  4. DualPipe(DeepSeek V3):把 AllToAll 塞进 bubble,通信免费

Q8: Meta 用 16K H100 训 70B 要多久?

A: 总 FLOPs = 6 × 70e9 × 15e12 = 6.3e24。16K H100 @ MFU 40% → 6.3e24 / (16000 × 989e12 × 0.4) = 11.6 天(算力纯值)。加上评估、重启、checkpoint,实际公开数据约 54 天 wall-clock。

Q9: 70B 训练到底卡的是显存还是算力?

A: 算力。显存上 117 张 H100 技术上就能装下 70B(含优化器 + 激活)。但训 10 年。我们用 16K 卡只是为了把算力攒够,时间压到可接受。显存利用率反而只有 2-5%——分片之后每卡状态极少,大头全是 activation(可 checkpoint 控制)。

Q10(进阶): 为什么 DualPipe 这类"bubble-free"方案是算法突破而不是工程优化?

A: 它改变了 pipeline 的核心公式。传统 bubble 比例 ∝ (N-1)/M,靠加 M 减小,但 M 受显存和 micro-batch 带宽上限。DualPipe 让 fwd matmul、dL/dx matmul、dL/dW matmul 三者相互 overlap(每个都足够 FLOPs 密集),把原本 idle 的时间填满。本质是把 bubble 从时间维度上消除,而不是减小。配合 MoE 的 AllToAll 塞进去,通信真的完全免费。


十二、一张速查卡

  ┌───────────────────────────────────────────────────────────┐
  │  并行方案临界速查 (bf16, H100 NVLink α=1099, IB α=19780)    │
  ├───────────────────────────────────────────────────────────┤
  │  方案            │ 临界条件           │ Llama 70B 极限      │
  ├──────────────────┼────────────────────┼─────────────────────┤
  │ 纯 DP            │ B/N > α            │ N·1099 tokens/batch │
  │ FSDP (单轴)      │ B/N > α            │ 同上                 │
  │ TP               │ F > Y·α            │ Y ≤ 8 (NVSwitch 域) │
  │ FSDP+TP (混合)   │ B/N > α²/(2F)      │ B/N > 21 (极低!)    │
  │ 跨 pod DP        │ B/pod > C/W_ib     │ > 19780 tokens/pod  │
  └───────────────────────────────────────────────────────────┘

  决策口诀:
    1. 单卡放不下 → FSDP (总是)
    2. B/N 还是不够 → 加 TP (机内,≤8)
    3. 模型超大跨节点 → 加 PP
    4. 跨 pod → 继续 DP (外层)

  Llama 3 70B 典型配置:
    8960 卡  : FSDP=2048, TP=4, 20 天, $2.7-8.9M
    16000 卡 : FSDP=4000, TP=4, 12 天 (Meta 实际)
    32000 卡 : FSDP=8000, TP=4, 6 天 (但 B 要加大才不 comms-bound)

一句话记住这一篇

训大模型的核心是用公式机械算出"每种并行方案什么时候 comms-bound"。四条判据:DP/FSDP → B/N > α; TP → F > Y·α; 混合 → B/N > α²/(2F); 跨 pod → B/pod > C/W_dcn。Llama 70B @ 16K H100 走流程得出 FSDP=2048 + TP=4、训 12 天、费 $5M——这个数字 Meta 公开数据对得上。不要再凭直觉选 TP=8 或 PP=4,把公式套上去,答案是唯一的。


系列下一篇预告(也是最后一篇):《TPU vs GPU:硬件 roofline 与架构抉择》——为什么同样 989 TFLOPs 的 H100 和 918 TFLOPs 的 TPU v5p 跑同一个模型差距这么大?NVSwitch 域 vs ICI pod、HBM3 vs HBM3e、SRAM 大小的差异如何决定你能跑什么规模的 batch。

配套阅读:JAX Scaling Book Ch5 + Ch6 原书章节。相关文章:Roofline 分析、Sharded Matmul、Transformer Math 精算、分布式 Transformer 深度解析。

Zoe

Written by

Zoe

AI Infra Engineer · LLM Serving · GPU/RDMA · 造工具的偏执狂

评论