企业官网建设流程全解析

深入理解LLM中的Batch Size：从原理到实践

本文从GPU执行机制出发，系统梳理Batch Size在大语言模型训练与推理两个阶段中的真实影响，并给出工程实践中的权衡建议。

一、什么是 Batch Size？

Batch Size（批大小）指的是一次前向/反向传播（训练）或一次前向计算（推理）中同时处理的样本（token序列）数量。

在LLM的语境下，它有两种常见形态：

很多人把这两者混为一谈，但它们背后的瓶颈完全不同，下面分开讲。

二、底层原理：为什么Batch Size会产生影响？

2.1 GPU的"吃大锅饭"特性

GPU的核心并行单元（CUDA Core / Tensor Core）数量巨大（如H100有16896个CUDA Core），但它的启动开销（kernel launch overhead）是固定的。

• Batch=1 时：矩阵乘法变成矩阵×向量（GEMV），算力利用率极低，GPU大部分时间在"等数据"。
• Batch=64 时：变成矩阵×矩阵（GEMM），Tensor Core可以满负荷运转。

这引出了一个关键指标：算术强度（Arithmetic Intensity, FLOPs/Byte）。

AI=计算量 (FLOPs)访存量 (Bytes) \text{AI} = \frac{\text{计算量 (FLOPs)}}{\text{访存量 (Bytes)}}AI=访存量(Bytes)计算量(FLOPs)​

• AI 低于某个阈值 →Memory-Bound（显存带宽是瓶颈）
• AI 高于阈值 →Compute-Bound（算力是瓶颈）

增大Batch Size最直接的作用，就是提升算术强度，把任务从Memory-Bound推向Compute-Bound。

2.2 Roofline模型视角

性能 ↑ │ _______________ Compute Roof（算力上限） │ / │ / ← 斜线区域：Memory Roof（带宽上限） │ / │ / └──────────────────────────→ 算术强度 (FLOPs/Byte) ↑ Batch增大 → 向右移动 → 性能提升直到撞上算力墙

三、训练阶段：Batch Size 的三重影响

3.1 梯度估计的方差（统计层面）

SGD的本质是用mini-batch的梯度去无偏估计全量数据的梯度：

g=1B∑i=1B∇θL(xi) g = \frac{1}{B}\sum_{i=1}^{B} \nabla_\theta \mathcal{L}(x_i)g=B1​i=1∑B​∇θ​L(xi​)

• Batch小：梯度噪声大 → 更新方向抖动 → 有"正则化"效果，有助于跳出尖锐极小值（sharp minima），往往泛化更好。
• Batch大：梯度更接近真实梯度 → 训练曲线平滑 → 但容易收敛到尖锐极小值，泛化可能变差。

这就是著名的“Generalization Gap”现象（Keskar et al., 2017）。

3.2 训练速度 vs. 样本效率（优化层面）

• 增大Batch → 每个step的GPU利用率↑ →墙钟时间（wall-clock）变快。
• 但同样的epoch数下，step数变少，模型"更新次数"减少。
• 经验规律：Batch扩大k倍，为保持收敛质量，通常需要：
  • 线性缩放学习率（Linear Scaling Rule, Goyal 2017）：lr × k
  • 或使用平方根缩放：lr × √k（对Adam类优化器更稳）
  • 配合Warmup避免初期梯度爆炸

3.3 显存占用（工程层面）

训练显存 ≈ 模型参数 + 梯度 + 优化器状态 +激活值（Activation）

其中激活值与Batch Size近似线性相关。这也是为什么：

• 显存不够时，第一反应是减小micro-batch；
• 用**梯度累积（Gradient Accumulation）**模拟大batch：

# 等效 Global Batch Size = micro_batch × accum_steps × GPU数fori,batchinenumerate(dataloader):loss=model(batch)/accum_steps loss.backward()if(i+1)%accum_steps==0:optimizer.step()optimizer.zero_grad()

⚠️ 注意：梯度累积能省显存，但省不了时间（前向反向还是要跑那么多次）。

四、推理阶段：Batch Size 的影响（重点！）

推理阶段的故事和训练完全不同，这里有一个核心概念：

4.1 自回归解码的两个Phase

LLM推理分为：

1. Prefill（预填充）：一次性处理整个prompt，Compute-Bound，算力利用率高。
2. Decode（逐token生成）：每步只生成1个token，本质是GEMV，严重Memory-Bound。

Decode阶段每生成一个token，都要把几十GB的模型权重从HBM读一遍，但只做一次矩阵×向量运算——算术强度极低。

4.2 Batching 是推理提速的核心手段

把多个请求凑在一起，权重只读一次，同时服务B条序列：

算术强度∝B \text{算术强度} \propto B算术强度∝B

Batch Size从1提到32，吞吐量往往能提升20~30倍，而单请求延迟增加不多。这就是为什么vLLM、TGI、SGLang等推理框架都极度依赖Batching。

4.3 Continuous Batching（连续批处理）

传统Static Batching的问题：一个batch里必须等最长的序列生成完才能释放，短请求被迫"陪跑"。

Continuous Batching（迭代级调度）：

• 每生成一个token就检查一次；
• 谁生成完谁退出，空位立刻塞入新请求；
• 配合PagedAttention（vLLM）解决KV Cache碎片化。

这让GPU利用率从~30%提升到80%+。

4.4 Batch Size 在推理中的权衡

KV Cache显存估算（以LLaMA-2 70B, FP16为例）：

KV/Token=2×nlayers×nkv_heads×dhead×2bytes \text{KV/Token} = 2 \times n_{layers} \times n_{kv\_heads} \times d_{head} \times 2\text{bytes}KV/Token=2×nlayers​×nkv_heads​×dhead​×2bytes
=2×80×8×128×2≈320KB/token = 2 \times 80 \times 8 \times 128 \times 2 \approx 320\text{KB/token}=2×80×8×128×2≈320KB/token

一条4096 tokens的序列 ≈ 1.3GB。这意味着80GB显存最多同时容纳几十条长序列——Batch Size的上限往往不是算力，而是KV Cache。

五、一张图总结

Batch Size 的影响 ┌──────────────────┴──────────────────┐ 训练阶段 推理阶段 │ │ ┌────┼─────┐ ┌────────┼────────┐ │ │ │ │ │ │ 梯度 收敛 显存 吞吐量 延迟 KV Cache 噪声 速度 占用 ↑↑↑ ↑ 硬瓶颈 ↓ ↑ ↑ (主收益) 正则 需调 线性 效果 LR 增长

六、实践建议（Cheat Sheet）

训练时：

• ✅ 显存允许的前提下，尽量用大micro-batch提高GPU利用率；
• ✅ 显存不够用梯度累积凑Global Batch Size；
• ✅ Batch翻倍记得同步调整学习率 + Warmup；
• ⚠️ 不要盲目追求超大batch（>32k），样本效率会显著下降，参考 Chinchilla / LLaMA 的batch schedule（训练后期才逐步增大batch）。

推理时：

• ✅ 永远开启Continuous Batching（vLLM / SGLang / TensorRT-LLM）；
• ✅ 在线服务关注P99延迟，给max_num_seqs设上限；
• ✅ 离线批处理任务把batch拉满，吞吐优先；
• ⚠️ 长上下文场景，Batch Size上限由KV Cache决定，可考虑FP8 KV Cache或MQA/GQA模型。

七、一句话总结

Batch Size的本质，是在"并行度 / 算术强度"与"显存 / 延迟 / 梯度噪声"之间做权衡。训练时它影响的是优化动力学，推理时它影响的是系统吞吐量——两者都源于同一个物理事实：GPU喜欢"一次吃一大口"。

参考：Keskar et al. 2017 (Large Batch Training); Goyal et al. 2017 (ImageNet in 1 Hour); Kwon et al. 2023 (vLLM/PagedAttention); NVIDIA Roofline Model 文档。