Global Batch Size

在大语言模型训练里，batch size 至少有三种不同口径：

• micro batch size 决定一次 forward/backward 有多大
• gradient accumulation 决定在更新参数前重复多少次 forward/backward
• global batch size 则表示一次 optimizer update 汇总了多少训练数据

三者不能混用。Global batch size 主要影响优化算法和数据并行规模；真正决定激活显存、单次矩阵形状和 FSDP 计算通信 overlap 窗口的是每个 rank 的 microbatch token 数。

基本概念

Micro Batch Size

Micro batch size 是单个 data-parallel rank 在一次 forward/backward 中处理的数据量。论文和训练框架有时按 sequence 数表示，有时直接按 token 数表示。

假设每个 rank 一次处理 2 条长度为 4096 的 packed sequence：

1
2
3
4
5
6
7
8
9

单个 GPU / data-parallel rank

┌──────────────────────────┐
│ Sequence 0: 4096 tokens  │
│ Sequence 1: 4096 tokens  │
└──────────────────────────┘
             │
             ▼
      Forward + Backward

$T_{\mathrm{micro}}$ 直接决定：

• 单次 forward/backward 的激活显存；
• GEMM 和 grouped GEMM 的矩阵形状；
• 每次参数 AllGather 之后有多少计算；
• 层间通信可用于 overlap 的时间窗口。

Gradient Accumulation

Gradient accumulation 是连续处理多个 microbatch，把梯度累积起来，中间不更新参数，最后只执行一次 optimizer.step()。

1
2
3
4
5
6
7

Microbatch 0: Forward → Backward → grad += g0
Microbatch 1: Forward → Backward → grad += g1
Microbatch 2: Forward → Backward → grad += g2
Microbatch 3: Forward → Backward → grad += g3
                                      │
                                      ▼
                               Optimizer.step()

若 accumulation steps 为 $A=4$，最终用于更新的平均梯度近似为：

它在优化语义上近似于把四个 microbatch 合成一个大 batch，但不需要同时保存四份激活。代价是完整执行四次 forward/backward，相关的参数通信也可能重复四次。

Global Batch Size

Global batch size 是所有 data-parallel rank 在相邻两次 optimizer update 之间处理的数据总量。在 LLM 预训练中，最清楚的口径是 tokens per optimizer update。

设：

当每条 sequence 等长且被完整 pack 时：

如果序列长度不同，或者 batch 中有 padding，应直接统计所有 rank、所有 accumulation step 中真正参与 loss 的有效 token：

一个完整例子

假设：

1
2
3
4

Micro batch size       = 2 sequences/rank
Sequence length        = 4096 tokens
Data parallel degree   = 4
Gradient accumulation  = 3

单个 rank 一次 microbatch 处理：

单个 rank 在一次 optimizer update 前处理：

整个训练集群的 global batch 是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

                         一个 Optimizer Step

                  Gradient accumulation step
                  0             1             2
              ┌────────┐    ┌────────┐    ┌────────┐
DP Rank 0     │ 8,192  │    │ 8,192  │    │ 8,192  │ ──┐
              └────────┘    └────────┘    └────────┘   │
                                                        │
              ┌────────┐    ┌────────┐    ┌────────┐   │
DP Rank 1     │ 8,192  │    │ 8,192  │    │ 8,192  │ ──┤
              └────────┘    └────────┘    └────────┘   │
                                                        ├─ Gradient
              ┌────────┐    ┌────────┐    ┌────────┐   │  Reduce
DP Rank 2     │ 8,192  │    │ 8,192  │    │ 8,192  │ ──┤
              └────────┘    └────────┘    └────────┘   │
                                                        │
              ┌────────┐    ┌────────┐    ┌────────┐   │
DP Rank 3     │ 8,192  │    │ 8,192  │    │ 8,192  │ ──┘
              └────────┘    └────────┘    └────────┘
                                           │
                                           ▼
                                    Optimizer.step()

每个格子包含 8192 tokens，一共有 $4\times3=12$ 个格子，因此总量为 98304 tokens。

相同 Global Batch 的不同实现

保持 $D_{\mathrm{DP}}$ 不变时，相同 global batch 可以由不同的 microbatch 和 accumulation 组合实现：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

配置 A：小 microbatch，大 accumulation

4K ─ F/B ─┐
4K ─ F/B ─┤
4K ─ F/B ─┤
4K ─ F/B ─┤
4K ─ F/B ─┤── Optimizer.step()
4K ─ F/B ─┤
4K ─ F/B ─┤
4K ─ F/B ─┘


配置 D：大 microbatch，无 accumulation

32K ───────────── F/B ─────────────┐
                                    └── Optimizer.step()

两者可能具有相同的优化语义，却有完全不同的显存、kernel shape 和通信行为。训练系统调参的一个常见方向，是在保持 global batch 不变的前提下，尽量增大能够放入显存的 microbatch，并相应减少 gradient accumulation。

Data Parallel 与 Model Parallel

Global batch 只乘以处理不同数据的 data-parallel degree，不能直接乘总 GPU 数。TP、PP、CP 和 EP rank 通常在共同处理同一批 token，并没有产生新的训练样本。

假设总 GPU 数为 1024，并行配置为：

1
2
3
4
5
6

TP = 8
PP = 8
EP = 8
DP = 2

8 × 8 × 8 × 2 = 1024 GPUs

Global batch 只乘 $D_{\mathrm{DP}}=2$：

而不是乘 1024。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

                         一份 Microbatch
                               │
               ┌───────────────┼───────────────┐
               ▼               ▼               ▼
           TP ranks         PP stages       EP ranks
         切权重矩阵          切模型层         切 experts
               │               │               │
               └──────── 共同处理同一批 token ────┘


                          Data Parallel
               ┌───────────────────────────────┐
               ▼                               ▼
          DP replica 0                    DP replica 1
         处理 token 集合 A                 处理 token 集合 B

在复杂 mesh 中，应先确定有多少份完整 model-parallel replica 在处理不同数据，再计算 global batch。

Pipeline Parallelism 中的 Microbatch

Pipeline Parallelism 会把一个 local batch 切成多个 pipeline microbatch，让不同 stage 同时工作：

1
2
3
4
5
6

时间 ─────────────────────────────────────────────────────►

PP Stage 0:  F0   F1   F2   F3                 B0   B1   B2   B3
PP Stage 1:       F0   F1   F2   F3       B0   B1   B2   B3
PP Stage 2:            F0   F1   F2   F3  B0   B1   B2   B3
PP Stage 3:                 F0   F1   F2   F3   B0   B1   B2   B3

其中 F0...F3 表示不同 microbatch 的 forward，B0...B3 表示对应的 backward。microbatch 数量越多，流水线气泡通常越小，但需要保存或重算更多 in-flight activation。

不同框架中的 micro_batch_size 可能指每个 DP rank 的 microbatch，也可能特指 pipeline schedule 的一个 microbatch。阅读配置时必须同时确认单位是 sequences 还是 tokens，以及它是否已经包含 gradient accumulation。

Gradient Accumulation 为什么不一定改善 FSDP Overlap

以 forward 后立即 reshard 的 FSDP 为例，每个 microbatch 都可能重新执行参数 AllGather：

1
2
3
4

Accumulation 0:  AllGather → 4K compute → reshard
Accumulation 1:  AllGather → 4K compute → reshard
Accumulation 2:  AllGather → 4K compute → reshard
Accumulation 3:  AllGather → 4K compute → reshard

把 accumulation 从 2 增加到 4，只会增加重复次数。每次通信之后仍然只有 4K tokens 的计算窗口，AllGather 与计算的比例没有改变。

真正有利于 overlap 的是增大同一次参数 materialization 中处理的 token 数：

1

AllGather → 16K compute → reshard

另一种方法是让完整参数跨多个 accumulation microbatch 保持 unshard：

1
2
3
4
5
6
7
8
9

AllGather
    │
    ├── Microbatch 0: Forward + Backward
    ├── Microbatch 1: Forward + Backward
    ├── Microbatch 2: Forward + Backward
    └── Microbatch 3: Forward + Backward
                       │
                       ▼
                    Reshard

但这要求完整参数常驻更长时间，会增加峰值显存。某些实现的 no_sync 可以延迟梯度 ReduceScatter，却不会自动消除 forward 之前所需的参数 AllGather；同时延迟同步通常还需要保存更大的未分片梯度。

因此，对 FSDP overlap 真正重要的是：

而不是 accumulation 之后得到的 $B_{\mathrm{global}}$。

2024–2026 年主流模型的 Global Batch Size

下面只比较预训练阶段，每个数都表示一次 optimizer update 汇总的全局 token 数。闭源模型和未披露精确配置的开源模型不做推测。

DeepSeek-V2/V3 的 token 数按 packed 4096-token sequence 换算：

公开资料呈现出的数量级变化是：

从 Llama 3 后期的 16M 到 DeepSeek-V4-Pro 的 94.4M，公开最大值增加了近 6 倍。不过，这不能简单解释为 batch 可以无限增大。模型规模、训练 token 预算、优化器、数据分布和训练阶段都在变化，横向比较只能反映数量级趋势。

为什么 Global Batch 不能无限增大

若总训练 token 数为 $N$，global batch 为 $B_{\mathrm{global}}$，optimizer update 次数为：

训练 1T tokens 时，4M-token global batch 对应约 25 万次更新，32M-token global batch 只有约 3.1 万次更新。模型看到的 token 总量相同，但参数更新次数减少到原来的 $1/8$。

增大 batch 最初能够降低梯度噪声、提高数据并行度和硬件吞吐；超过 critical batch size 之后，新增样本提供的边际梯度信息下降，所需 optimizer steps 不再随 batch 增大而同比减少。继续增大可能带来：

• 固定 token budget 下更新次数不足，validation loss 变差；
• 为保持更新幅度而增大学习率，引入 loss spike 或训练发散；
• Adam moment、warmup、weight decay 等以 step 为单位的时间尺度需要重新调整；
• 达到相同 loss 所需的训练 token 增加，time-to-quality 反而变差。

这也是 Llama 3、DeepSeek-V2/V3/V4 普遍采用 batch-size schedule 的原因：训练早期使用较小 batch 保留 token efficiency，后期随着训练稳定性和 gradient noise scale 改变，再逐渐扩大 batch 以提高系统效率。

如何同时看算法与系统

评估一套训练配置时，至少应同时记录：

并分别回答：

1. 算法侧：这个 global batch 是否超过当前训练阶段的有效 critical batch？达到目标 loss 需要多少 token 和多少 optimizer step？
2. 显存侧：microbatch activation、unshard 参数、梯度和 prefetch buffer 能否同时放入显存？
3. 计算侧：microbatch 是否足以形成高效 GEMM，MoE 中每个 expert 能分到多少 token？
4. 通信侧：每次参数 materialization 实际处理多少 token，AllGather / ReduceScatter 有多少暴露在关键路径上？
5. 端到端：最终应该比较 validation loss–token 曲线和 time-to-quality，而不能只看 MFU 或通信覆盖率。

一句话总结：Global batch size 决定一次参数更新汇总多少数据，micro batch size 决定一次 forward/backward 有多少计算，gradient accumulation 在不增加单次激活显存的情况下把多个 microbatch 合成一次更新。对优化算法看 global batch，对 FSDP overlap 则必须看单次 microbatch 的本地 token 数。