Micro-batch Micro-batch | Compassing AI 概念庫

Micro-batch（微批次）深度學習頁

3 秒看懂

Micro-batch 是分散式訓練中被切分後、在單個裝置（GPU/加速器）上一次完成前向與反向傳播的最小資料單元。 它是大批次（Global Batch）的子集——多張 GPU 各自處理一個 micro-batch，再通過梯度同步（AllReduce）或梯度累積來等價地訓練一個大 batch。在流水線並行中，micro-batch 還是填充流水線各階段、減小”氣泡”（bubble）的核心排程單位。

3 分鐘產業解釋

為什麼需要切 Micro-batch？

大型模型訓練有兩個硬約束在打架：

約束	原因
需要大 batch	大 batch 提高 GPU 利用率、減少通訊輪次、穩定訓練統計
單卡視訊記憶體有限	batch 越大，啟用值（activations）佔用視訊記憶體越多；單卡放不下

Micro-batch 就是解決這對矛盾的基本工具：

Global Batch Size = N_GPU × Micro-batch Size × Gradient Accumulation Steps

資料並行（DP）：每張卡分到一個 micro-batch，各自前向/反向，然後 AllReduce 梯度。
流水線並行（Pipeline）：將 micro-batch 序列依次注入流水線各階段，讓不同階段同時工作，最大化硬體利用率。
梯度累積：同一張卡序列跑多個 micro-batch，逐次累加梯度，最後做一次引數更新——等效於更大的單卡 batch。

產業關聯

Micro-batch 的大小直接影響：

視訊記憶體佔用：決定模型能在多少張卡上跑起來（切分策略的輸入引數）
訓練吞吐：micro-batch 太小 → GPU 算力閒置；太大 → 視訊記憶體 OOM 或 pipeline bubble 變大
通訊開銷：每個 micro-batch 反向完成後都要通訊，micro-batch 越多、通訊輪次越頻繁
超參調優：學習率 warmup、LAMB/LARS 等大 batch 最佳化器都與 effective batch size 直接掛鉤

它是訓練架構（Megatron-LM、DeepSpeed、Alpa、PyTorch FSDP）中最基礎的排程概念之一，也是叢集算力規劃時必須確定的核心引數。

15 分鐘專家深入

1. Micro-batch 在三種並行策略中的角色

(a) 資料並行（Data Parallelism, DP）

┌──────────────────────────────────────────────┐
│              Global Batch (B)                │
│  ┌────────┐ ┌────────┐     ┌────────┐       │
│  │ μB (GPU0)│ │ μB (GPU1)│ ... │ μB (GPUn)│       │
│  └────────┘ └────────┘     └────────┘       │
│      ↓          ↓               ↓           │
│   fwd+bwd    fwd+bwd        fwd+bwd        │
│      └─────────┼───────────────┘            │
│          AllReduce 梯度                      │
│          引數更新                             │
└──────────────────────────────────────────────┘

每張卡的 micro-batch = B / N_GPU
通訊模式：每個 micro-batch 完成後 AllReduce（或 ReduceScatter + AllGather，如 ZeRO）
micro-batch 越小 → 通訊越頻繁 → 通訊/計算比越大 → 吞吐下降

(b) 流水線並行（Pipeline Parallelism, PP）

這是 micro-batch 最核心的舞臺。一個 global mini-batch 被切成 m 個 micro-batch，依次注入 P 個流水線階段：

時間 →
Stage 0: [μB1][μB2][μB3][μB4]    [   ][   ][   ][   ]  ← 反向
Stage 1: [   ][μB1][μB2][μB3][μB4]    [   ][   ][   ]  ← 反向
Stage 2: [   ][   ][μB1][μB2][μB3][μB4]    [   ][   ]  ← 反向
Stage 3: [   ][   ][   ][μB1][μB2][μB3][μB4]    [   ]  ← 反向
         ▲                    ▲
         │  前向 warmup 泡泡   │  反向 cooldown 泡泡

經典氣泡率公式（GPipe 排程下）：

Bubble ratio = (P - 1) / (m + P - 1)

其中 P = 流水線階段數，m = micro-batch 數量。

而 1F1B 排程 可將氣泡率降低至：

Bubble ratio = (P - 1) / m

當 m >> P 時，bubble 趨近於零——這就是為什麼訓練大型模型時往往採用大量 micro-batch。
典型實踐：P = 8 時，m ≥ 64 可將 bubble 控制在 ~10% 以內。

(c) 梯度累積（Gradient Accumulation）

GPU 內部時間線：
[μB₁ fwd+bwd] → [μB₂ fwd+bwd] → [μB₃ fwd+bwd] → [μB₄ fwd+bwd] → [AllReduce + Update]
              ↑ 累積梯度 ↑       ↑ 累積梯度 ↑       ↑ 累積梯度 ↑

4 個 micro-batch 的梯度累加 → 等效 batch size = 4 × μB
作用：在視訊記憶體不足以容納大 batch 時，模擬大 batch 訓練效果
注意：梯度累積期間 BatchNorm 的統計量是按 micro-batch 計算的，可能與全域性 batch 統計量有差異（實踐中常用 GroupNorm/LayerNorm 替代）

2. Micro-batch 大小與視訊記憶體的關係

單張 GPU 上，micro-batch 引入的視訊記憶體佔用主要來自：

視訊記憶體項	與 μB 的關係	典型量級
啟用值（Activations）	線性正比（μB 越大，儲存的中間啟用越多）	通常是視訊記憶體大戶
模型引數	與 μB 無關	固定
最佳化器狀態	與 μB 無關	通常 ≈ 引數量 ×12（Adam，FP32 主副本 + 一階/二階矩）
梯度緩衝	與 μB 無關（梯度大小 = 引數大小）	固定
臨時計算緩衝	與 μB 弱相關	視運算元實現而定

關鍵公式（估算）：

啟用視訊記憶體 ≈ L × μB × s × h × bytes_per_element × recomputation_factor
          + 注意力矩陣視訊記憶體 (約 L × μB × num_heads × s² × bytes_per_element，長序列下顯著)

其中 L = 層數，s = 序列長度，h = 隱藏維度，num_heads = 注意力頭數。常見簡化估算僅涵蓋了線性項，忽略了與 s² 成正比的注意力得分矩陣（形狀 [μB, num_heads, s, s]）的視訊記憶體佔用；當序列長度較大（例如超過 32k tokens）時，該項可能成為記憶體瓶頸。開啟 activation recomputation（重計算）時，部分策略可選擇重計算注意力矩陣以消除或降低這項開銷，但具體實現需結合實際配置評估，計算量通常增加約 30%-40%。[來源：Megatron-LM / Chen et al. 2016, “Training Deep Nets with Sublinear Memory Cost”]

3. 1F1B 排程策略

為了減少 pipeline bubble 中的視訊記憶體峰值，Megatron-LM 等架構採用 1F1B（One Forward One Backward） 排程：

Stage 0: F1 F2 F3 F4 | B4 B3 F5 B2 F6 B1 ...
Stage 1:    F1 F2 F3 F4 | B4 B3 F5 B2 F6 B1 ...

先用 (P-1) 個 micro-batch 填充流水線 warmup 階段
然後交替執行前向和反向——始終只在流水線中保留有限個 micro-batch 的啟用值
相比 GPipe 的”全部前向→全部反向”，1F1B 將視訊記憶體峰值從 O(m × activation_per_μB) 降至 O(P × activation_per_μB)

[來源：Narayanan et al., “Efficient Large-Scale Language Model Training on GPU Clusters,” SC 2021]

4. Micro-batch 對訓練收斂性的影響

一個常被忽視的問題：

相同 global batch size 下，micro-batch 的切分方式會影響 BN 統計量和精度
如果使用 FP16 混合精度訓練，micro-batch 內的 loss scaling 也受 μB 大小影響
極小的 μB（如 = 1）可能導致梯度估計方差大、訓練不穩定
極大的 μB 受視訊記憶體限制，且可能需要更大的學習率（線性 scaling rule）

實踐中的典型 micro-batch 大小：

LLM 訓練（GPT 類）：通常 1-8 sequences / micro-batch
CV 大型模型（ViT 等）：通常 4-32 images / micro-batch
影片/多模態模型：因序列極長，往往 μB = 1

技術原理（最深）

核心機制

Micro-batch 本身不是一個”網路元件”或”運算元”，而是分散式訓練架構中的排程抽象。它的技術本質是：

將全域性資料流切分為可獨立執行前向/反向傳播的最小計算塊
在時間維度上錯開這些計算塊的執行，以實現並行或流水線化

Pipeline Parallelism 中的 Micro-batch 排程圖

          Micro-batch 流水線排程 (1F1B, P=4 stages, m=8 micro-batches)
時間步 →  t1    t2    t3    t4    t5    t6    t7    t8    t9   t10   t11   t12
Stage 0: [F1]  [F2]  [F3]  [F4]  [B4]  [F5]  [B3]  [F6]  [B2]  [F7]  [B1]  [F8]
Stage 1:       [F1]  [F2]  [F3]  [F4]  [B4]  [F5]  [B3]  [F6]  [B2]  [F7]  [B1]
Stage 2:             [F1]  [F2]  [F3]  [F4]  [B4]  [F5]  [B3]  [F6]  [B2]  [F7]
Stage 3:                   [F1]  [F2]  [F3]  [F4]  [B4]  [F5]  [B3]  [F6]  [B2]

F = 前向傳播    B = 反向傳播
[ ] = 一個 micro-batch 在一個 stage 上的一次計算

P2P 通訊：相鄰 stage 之間通過 point-to-point (send/recv) 傳遞啟用值（前向）和梯度（反向）
梯度同步：一個 micro-batch 的反向傳播完成後，梯度在資料並行維度上做 AllReduce

視訊記憶體分析公式（1F1B 穩態階段）

Peak Activation Memory = P × (activation_size_per_μB) + (P-1) × communication_buffer

對比 GPipe（先全部前向、再全部反向）：

Peak Activation Memory (GPipe) = m × (activation_size_per_μB)

當 m >> P 時，1F1B 視訊記憶體優勢極其顯著。

關鍵引數之間的約束關係

# 虛擬碼
global_batch_size = target_samples_per_step  # 由訓練配方決定
n_gpu = num_gpus                              # 叢集 GPU 總數
tp_degree = tensor_parallel_size              # 張量並行度
pp_degree = pipeline_parallel_size            # 流水線並行度
dp_degree = n_gpu / (tp_degree * pp_degree)   # 資料並行度

micro_batch_per_gpu = 1  # 通常從 1 開始嘗試
gradient_accum_steps = global_batch_size / (dp_degree * micro_batch_per_gpu)

# 視訊記憶體約束：
# activation_mem(micro_batch_per_gpu, seq_len, hidden_dim, n_layers)
#   + model_mem + optimizer_mem ≤ gpu_memory

# 吞吐約束：
# pipeline_bubble ≈ (pp_degree - 1) / (gradient_accum_steps + pp_degree - 1)
# bubble 應 &lt; 10-15%，否則浪費算力

Interleaved 1F1B（Virtual Pipeline Parallelism）

Megatron-LM 的進階方案：將每個 stage 的模型層拆成若干 virtual stages，micro-batch 在 virtual stages 之間交錯執行，進一步減小 bubble：

Bubble ratio (interleaved) ≈ (P-1) / (m × v)

其中 v = virtual stages per rank（每個 rank 內的虛擬階段數）。但代價是通訊量增加約 v 倍。

[來源：Korthikanti et al., “Reducing Activation Recomputation in Large Transformer Models,” MLSys 2023 (Megatron-LM 團隊)]

技術演進史

時間	里程碑	micro-batch 相關貢獻
2016	Chen et al., “Sublinear Memory Cost”	提出 activation checkpointing / recomputation，允許更小視訊記憶體下用更大的 μB
2018	Megatron-LM v1	系統化張量並行 + 資料並行，micro-batch 配置成為顯式訓練引數
2019	GPipe (Huang et al., Google)	首次在生產級模型中使用 pipeline parallelism + micro-batch 流水線排程，明確 bubble 公式
2019	PipeDream (Narayanan et al., Microsoft Research)	提出 1F1B 排程和非同步 pipeline，micro-batch 成為流水線核心排程單位
2020	DeepSpeed ZeRO (Rajbhandari et al.)	ZeRO-1/2/3 切分最佳化器狀態/梯度/引數，micro-batch 大小約束從”放得下模型+最佳化器”變為主要”放得下啟用”
2021	Megatron-LM v3 (Narayanan et al., SC’21)	提出 interleaved 1F1B (virtual pipeline)，進一步降低 bubble 率
2021	Alpa (Zheng et al., UC Berkeley)	自動搜尋最優的 micro-batch 切分 + 並行策略組合
2023	DeepSpeed-Ulysses / Ring Attention	超長序列場景下，將序列維度也切成 micro-segments 處理，micro-batch 概念向序列維度擴充套件
2023-24	FSDP2 (PyTorch) / Megatron-Core	micro-batch 配置與 activation recomputation、selective recomputation 深度耦合

技術路線對比

不同 Pipeline 排程策略中的 Micro-batch 行為

排程策略	Bubble Ratio	視訊記憶體峰值（啟用）	通訊模式	代表實現
GPipe（全前向→全反向）	(P-1)/(m+P-1)	O(m × act_μB)	批次 P2P	GPipe, early Megatron
1F1B（交替前向/反向）	(P-1)/m	O(P × act_μB)	流式 P2P	Megatron-LM, DeepSpeed
Interleaved 1F1B (V-Sched)	(P-1)/(m·v)	O(v × P × act_μB)	流式 P2P, 量 ×v	Megatron-LM v3
Zero Bubble Pipeline	趨近於 0	O(P × act_μB)	流式 P2P + 額外排程	Qi et al., 2023

注：所有公式為理想情況近似，實際 bubble 受計算時間不均勻、通訊延遲等因素影響。[來源：各原始論文]

Micro-batch vs. Mini-batch vs. Global Batch

術語	定義	典型大小 (LLM 訓練)
Sample	一個訓練樣本（一條文本序列等）	—
Micro-batch (μB)	單個裝置一次前向/反向的樣本數	1-8 sequences
Mini-batch	一次引數更新前的總樣本數（含梯度累積）	通常 = global batch
Global Batch	所有資料並行 rank × 梯度累積步數 × μB	數百~數百萬 tokens
Gradient Accumulation Steps	global_batch / (dp_degree × μB)	4-256

上下游

上游（Micro-batch 的依賴方）

硬體層:  GPU/TPU 視訊記憶體容量、HBM 頻寬、NVLink/NVSwitch 互聯頻寬
    ↓
系統層:  叢集拓撲、通訊庫 (NCCL)、排程器
    ↓
架構層:  並行策略 (TP/PP/DP/SP/EP)、activation recomputation 策略
    ↓
配方層:  seq_len、hidden_size、num_layers → 決定 activation_per_μB
    ↓
═══════════════════════════════════════
  MICRO-BATCH SIZE 的選擇
═══════════════════════════════════════

下游（Micro-batch 影響的環節）

MICRO-BATCH SIZE
    ↓
    ├──→ 視訊記憶體佔用 (activation memory) → 決定能否跑在現有硬體上
    ├──→ Pipeline bubble ratio → 影響 MFU (Model FLOPS Utilization)
    ├──→ 梯度統計精度 → 影響收斂性
    ├──→ 通訊頻率 → 影響 allreduce/P2P 開銷佔比
    ├──→ 學習率排程 → 與 effective batch size 聯動
    └──→ BatchNorm 統計量 (若使用) → 影響模型精度

關鍵指標

指標	定義	與 Micro-batch 的關係
MFU (Model FLOPs Utilization)	實際 FLOPS / 理論峰值 FLOPS	μB 太小→ GPU 利用率低 → MFU 下降；μB 太大→ 視訊記憶體受限、bubble 大
HFU (Hardware FLOPs Utilization)	含 recomputation 的總計算 / 理論峰值	如果 μB 過小需頻繁 recomputation，HFU ≠ MFU
Pipeline Bubble %	流水線中空閒時間佔比	bubble ≈ (P-1)/(m+P-1)，m = micro-batch 數
Activation Memory per Layer	單層單個 μB 儲存的啟用位元組數	線性正比於 μB 大小
Communication / Computation Overlap	通訊是否被計算掩蓋	μB 大 → 計算時間長 → 更容易掩蓋通訊
Tokens per Second per GPU	單卡吞吐	核心效能指標，受 μB 選擇直接影響

供需與市場資料

Micro-batch 如何影響算力供需

Micro-batch 的選擇看似是”調參細節”，但它直接決定了等效算力利用率，進而影響：

GPU 需求量：同樣的訓練任務，MFU 從 30% 提升到 50%，所需 GPU 數量減少 40%
訓練成本：以 LLM 訓練為例，MFU 每提升 1 個百分點，千萬美元級專案可節省數十萬美元
硬體規劃：HBM 容量（決定最小 μB 的啟用能否放下）、互聯頻寬（決定 pipeline 通訊能否掩蓋）是硬體採購的關鍵考量

行業實踐參考

模型/團隊	公開報告的配置	來源
GPT-3 (175B)	μB=2, TP=8, PP=~16, 1024 A100	[Brown et al., 2020; Megatron-LM 相關討論]
Llama 系列	μB=1~4 (序列級), 使用 gradient accumulation	[Touvron et al., 2023; Meta 公開技術報告]
典型 70B 模型訓練	TP=8, PP=4, DP=~16, μB=1-2, grad_accum=8-32	[行業估算, 基於公開 blog 和技術分享]

注：具體配置因叢集規模、架構版本、訓練階段而異。上表為公開資料中的典型案例，非精確推薦值。

代表公司與資本對映

層級	公司/專案	與 Micro-batch 的關係
架構	NVIDIA (Megatron-LM, Megatron-Core)	micro-batch 排程的工業級參考實現；1F1B / interleaved 1F1B 的主要推動者
架構	Microsoft (DeepSpeed)	ZeRO 系列優化了視訊記憶體分配，間接影響 μB 的可選範圍
架構	Meta (PyTorch FSDP)	FSDP 的 sharding 策略影響 activation memory，改變 μB 約束
架構	Google (JAX/Pax)	TPU 上的 pipeline parallelism 實現，micro-batch 概念類似但排程細節不同
自動化	Alpa (Anyscale/UC Berkeley 系)	自動搜尋最優 μB + 並行策略
硬體	NVIDIA (H100/H200/B100/B200)	HBM 容量直接決定 μB 上限；NVLink/NVSwitch 頻寬決定 pipeline 通訊延遲
硬體	AMD (MI300X)	192GB HBM → 允許更大 μB 或更少流水線切分
雲端廠商	AWS / Azure / GCP	叢集互聯拓撲影響 μB 的通訊成本，間接影響訓練效率

投資邏輯

核心觀點

Micro-batch 本身不是一個可投資的”技術賽道”，但它是理解以下投資邏輯的關鍵透鏡：

視訊記憶體即瓶頸 → HBM 和封裝技術的投資邏輯
- μB 的上限由 activation memory 決定 → 更大 HBM → 更大 μB → 更高 MFU → 算力更”值錢”
- SK 海力士/三星/美光的 HBM 產能直接影響 AI 訓練效率
- 先進封裝（如 CoWoS）的產能瓶頸同樣制約了大 HBM 晶片的供給
互聯頻寬 → 通訊效率的投資邏輯
- Pipeline parallelism 的 P2P 通訊延遲直接決定 μB 的計算/通訊比
- NVLink/NVSwitch 頻寬、InfiniBand/RoCE 叢集網路是關鍵
訓練效率軟體棧 → 架構價值
- 同樣的硬體，Megatron-Core vs. naive DDP 的 MFU 差異可達 2-3 倍
- 更好的 μB 排程 = 更低的訓練成本 = 架構的商業價值
推論側的 μB（micro-batch serving）
- 推論場景中，μB 概念延伸為 dynamic batching / continuous batching
- vLLM、TensorRT-LLM 等推論引擎的核心最佳化之一就是 micro-batch 排程

常見誤讀糾偏

❌ 誤讀 1：“Micro-batch 越大越好”

糾正：不是。μB 增大的限制包括：

視訊記憶體：activation memory 線性增長，可能 OOM
Pipeline bubble：在 pipeline 並行中，μB 數 m 與 bubble 率成反比，但 μB 大意味著 m 小（global batch 固定時），bubble 反而增大
收斂性：過大的 μB 配合錯誤的學習率可能導致訓練發散
最優 μB 通常是硬體約束（視訊記憶體、通訊）和軟體約束（bubble、收斂）的平衡點，需要實驗確定

❌ 誤讀 2：“Micro-batch 大小等價於 batch size”

糾正：三者完全不同。在分散式 + 流水線 + 梯度累積的設定下：

global_batch = data_parallel_degree × pipeline_micro_batches × gradient_accum_steps × μB

一個 μB=1 的配置，通過 DP×PP×accum 的乘數，可以實現 global batch 達數百萬 token 的訓練。混淆這些層次會導致對訓練配置的完全錯誤理解。

❌ 誤讀 3：“Pipeline parallelism 的 bubble 可以通過增大 μB 來消除”

糾正：增大 μB 並不直接減小 bubble——關鍵是增加 micro-batch 的數量 m。在 global batch 不變時，增大 μB 意味著 m 減小，bubble 反而增大。真正減小 bubble 的方式是：

增大 global batch（從而增加 m）
減少 pipeline 階數 P
採用 1F1B 或更先進的排程策略
採用 zero-bubble pipeline（將反向計算拆分為輸入梯度和權重梯度兩部分，填補空閒時段）

❌ 誤讀 4：“流水線並行中每個 micro-batch 獨立計算梯度”

糾正：在一個 pipeline iteration 中，所有 m 個 micro-batch 的梯度被累加後才做一次引數更新（同步 pipeline 如 GPipe/1F1B）。每個 μB 的反向傳播產出的是該 μB 對總 loss 的梯度貢獻，最終：

total_gradient = Σ(gradient_μBi) / m

只有非同步 pipeline（如 PipeDream-Flush 的變體）才會對不同 μB 使用不同版本的引數，但這也帶來了”stale gradient”問題。

學習路徑

入門 → 進階 → 專家

Level 1 (入門):
  ├─ 理解 batch / mini-batch / micro-batch 的區別
  ├─ 跑一次 PyTorch DDP 示例，觀察 grad_accum_steps 的效果
  └─ 閱讀: PyTorch Distributed Training 官方教程

Level 2 (進階):
  ├─ 精讀 GPipe 論文 (Huang et al., NeurIPS 2019)
  ├─ 精讀 Megatron-LM v3 (Shoeybi et al., 2020; Narayanan et al., SC 2021)
  ├─ 手推 bubble ratio 公式，理解 1F1B 排程流程
  └─ 在 Megatron-LM 程式碼中追蹤 micro-batch 的資料流

Level 3 (專家):
  ├─ 精讀 Alpa (Zheng et al., OSDI 2022) — 自動並行策略搜尋
  ├─ 精讀 Zero Bubble Pipeline (Qi et al., 2023)
  ├─ 精讀 "Reducing Activation Recomputation in Large Transformer Models" (MLSys 2023)
  ├─ 理解 μB 與 sequence parallelism / context parallelism 的互動
  └─ 實際在千卡叢集上調優 μB 配置並測量 MFU 變化