微批次Micro-batch技术

可视化演示

动态演示微批次Micro-batch的核心机制，通过入门/进阶/实战/优化四种模式展示关键概念与交互流程。

初识微批次

食堂老板把 128 份套餐切成 8 批、每批 16 份，这个“16 份一摞”就是微批次。在分布式训练的世界里，一个大的训练 Batch（比如 1024 条样本）如果直接交给流水线并行的多卡系统，就会像前面说的那样——第一张卡算到天荒地老，后面的卡闲得发慌。所以，我们需要先把大 Batch 切成若干个更小的 Batch，每个小 Batch 就叫一个微批次（Micro-batch）。

微批次是流水线并行的基本调度单位。假设我们有 4 张 GPU（相当于 4 个打菜窗口），把 1024 条样本切成 16 个微批次（每个 64 条），那么 GPU1 处理完微批次 1 后，立即把结果传给 GPU2，同时自己开始处理微批次 2。这样一来，四张卡都能“手中有活”，系统的整体吞吐量大幅提升。

微批次的本质是把“大而整”的计算任务拆成“小而碎”的独立单元，让流水线的每一级都能以最短的等待时间接续工作。它不改变总计算量，但改变了计算在时间和空间上的分布方式——这正是“切小份”魔力的来源。

1. 大 Batch 切分：将原始 Batch 分成等份小段

$$\text{Batch} = \text{Micro-batch} \times \text{chunks}$$

2. 依次送入流水线：每个微批次独立经过所有流水线级

$$\text{M}_1 \to \text{M}_2 \to \cdots \to \text{M}_k$$

3. 各卡并行计算：不同微批次在不同 GPU 上同时处理

$$\text{GPU}_i \text{ processes } \text{M}_j \text{ at time } t$$

回到食堂：切得越小，每个窗口手里的活越碎，但传送带上的“在途”份数也越多，需要更多的台面空间（显存）来临时存放半成品。这个权衡，就是微批次调优的核心。

微批次大小选择

食堂老板发现：如果每批只切 4 份，传送带上虽然跑得勤快，但每传一次都要“吆喝一声”（通信开销），窗口频繁切换反而手忙脚乱；如果每批切 64 份，又回到最初“第一个窗口累死”的窘境。所以微批次大小的选择，是一场“切多碎才顺手”的工程权衡。

从吞吐量角度看，微批次越大，每个 GPU 上计算密度越高，算术效率（计算资源利用率）越好。因为 GPU 擅长“吃大块肉”，小块肉会让它的并行单元饿肚子。但微批次太大会导致流水线内各个阶段的负载不均衡——前一个阶段算得太久，后面就干等，气泡变大。

从显存角度看，微批次越大，每个微批次需要的中间激活值（前向传播中暂存的结果）越多，显存压力越大。因此微批次大小通常受限于单卡显存容量。实践中的常见做法是：在显存允许的范围内，尽量选较大的微批次，同时保证微批次数目不少于流水线级数的 2 倍，以减小气泡占比。

1. 吞吐计算：总吞吐与微批次大小正相关

$$\text{Throughput} \approx \frac{\text{micro-batch size}}{\text{time per micro-batch}}$$

2. 气泡占比：气泡率与流水线级数和微批次数相关

$$\text{Bubble Ratio} = \frac{p-1}{p-1+m}$$

3. 显存约束：激活值占用正比于微批次大小

$$\text{Memory} \propto \text{micro-batch size}$$

食堂老板的经验总结：窗口（GPU）喜欢“大块肉”，但台面（显存）有限；传送带（流水线）喜欢“勤传递”，但吆喝（通信）太频也累。最优解永远是跑几轮实验，找到那个“肉够大、台面放得下、传送带不闲着”的甜蜜点。

气泡形成与消除

流水线最让人头疼的，就是气泡（Bubble）——GPU 无事可做的空闲时间。食堂刚开门时：第一个窗口做好第一批菜，第二个窗口才能开工；等第一个窗口做到第三批时，第四个窗口才第一次开火。这段时间里，后面的窗口都在干等，这就是“前向气泡”。收工阶段：最后一个窗口还在处理最后一批，前面的窗口已经无菜可做，这就是“排空气泡”。

气泡率（Bubble Ratio）是衡量流水线并行效率的关键指标。假设流水线有 p 级（4 个 GPU），共 m 个微批次，那么理想情况下气泡占比为：

可以看到：微批次数 m 越大，气泡占比越小。当 m=16、p=4 时，气泡率只有约 3/18 ≈ 16.7%；如果 m=4，气泡率高达 3/7 ≈ 42.9%。这就是为什么实践中要求微批次数远大于流水线级数。

食堂老板的解法是：多切几批！虽然开门和收工时总有些窗口空闲，但只要中间“满负荷运转”的时间足够长，空闲的比例就被摊薄了。这就像高速公路收费站——打开的车道越多、排队的车越多，每条车道的“闲置率”就越低。

显存影响分析

食堂的台面空间（显存）是有限的，上面要同时摆放：正在下锅的菜（当前微批次的激活值）、切好的备菜（参数和梯度）、以及各种调料配方（优化器状态）。微批次技术之所以好用，恰恰是因为它把大 Batch 切成小份后，每次只需要在显存里放一小份菜的“中间状态”。

具体来说，激活值（Activations） 是显存占用的头号大户。在流水线并行中，为了在反向传播时计算梯度，需要保留前向传播的中间结果。如果微批次很大，激活值就占得特别多；微批次越小，需要的激活值显存就越少。这是微批次能降低显存峰值的关键机制。

不过，微批次的数量增多，也意味着每个 GPU 上需要为多个“在途”微批次保留激活值。所以显存开销的完整公式是：

食堂老板的策略是“小份多批”：每一份菜占的台面小了，但台面上同时摆的份数多了。如果台面实在不够，还可以把部分“半成品”（激活值）存到仓库、用时再取——这就是后文要讲的重计算（Recomputation） 技术。

填充策略设计

食堂老板发现，即使切了 16 批菜，开门时最后两个窗口依然要空等好一会儿。于是他想到一个新招：有些菜（比如凉菜）可以先做好放在边上，等主菜出锅的间隙先递出去——这就是填充策略（Padding） 的思路。

填充策略的核心是：在正式的前向/反向传播开始之前，用一些“虚拟的微批次”把流水线预填充（Prefill），让每个 GPU 在正式计算开始时都有活干。这样，气泡不发生在开头和结尾，而是被均匀地“挤”到了计算间隙中。

常见的填充方案有两种：零填充（Zero Padding） 和跨批次填充（Cross-batch Padding）。零填充是简单地在头部补几个空批次，牺牲一点点计算量减少气泡；跨批次填充则是把下一轮迭代的微批次提前塞进空闲时段，让流水线几乎没有空转。后者的气泡率理论上可以逼近 0，但实现复杂度更高，对内存也有额外要求。

1. 零填充：在流水线头部插入空批次

$$\text{Pad} = (p-1) \times \text{empty micro-batches}$$

2. 跨批次填充：从下一迭代借微批次

$$\text{Pad} = \text{next iteration's micro-batches}$$

3. 气泡下降：有效气泡率随填充而降低

$$\text{Bubble}_{\text{pad}} \approx 0$$

填充策略就像餐厅的“预摆盘”：不等客人点完菜再备料，而是提前把常用食材放在备餐台上，客人一下单就能开火。虽然牺牲了一点“台面空间”（显存），但换来了所有厨师（GPU）的满负荷运转。

梯度累积配合

在大模型训练中，我们通常希望用较大的 Batch Size 来保证梯度估计的稳定性。但显存和流水线效率又不允许单次塞进太大 Batch——怎么办？食堂老板的答案：梯度累积（Gradient Accumulation）。

梯度累积的思路是：每个微批次独立计算梯度，但暂时不更新权重，而是把梯度“攒起来”；攒够若干个微批次后，再用累积的总梯度统一更新一次权重。这样，从数学上看，最终等效于一次处理了一个大 Batch；从物理上看，显存里始终只有一个小微批次的激活值。

食堂老板明白了：与其让所有客人一次性点一大桌菜（大 Batch 撑爆后厨），不如让客人分几次下单（微批次），后厨把“备菜要求”（梯度）记在本子上，最后一次性把全套菜（权重更新）做出来。味道一样，后厨却不慌不忙。

工程调优要点

微批次技术真正落地时，还有一些工程细节需要关注。食堂老板的最终心得，浓缩成三条黄金法则：

第一，负载均衡。每个 GPU 分到的层（流水线级）计算量要相近，否则算得快的 GPU 会空等算得慢的 GPU，产生“木桶效应”（全局气泡由最慢的卡决定）。在切分模型层时，要尽量让每一级的计算量均衡。

第二，通信隐藏。GPU 之间的数据传递（通信）是有时间开销的。优秀的实现会把通信和计算重叠起来——在计算当前微批次的同时，预取下一个微批次的通信数据。这就像食堂老板在炒菜的同时让服务员先把下一桌的菜单递过来。

第三，混合使用。微批次不是孤立技术，它和重计算（Recomputation）、激活检查点（Activation Checkpointing）等技术搭配使用效果更好。比如用微批次降低激活值占用后，再用重计算进一步压显存，可以支撑更大的微批次，反哺吞吐量。

1. 均衡负载：各流水线级计算时间趋于一致

$$\text{time}_{stage_1} \approx \text{time}_{stage_2} \approx \cdots$$

2. 重叠通信计算：通信时间被计算时间覆盖

$$\text{total\_time} \leq \text{compute\_time} + \text{comm\_time}$$

3. 综合收益：气泡率与显存的联合优化

$$\text{Efficiency} = f(\text{bubble}, \text{memory}, \text{comm})$$

食堂老板的总结：开一家高效的流水线食堂，光知道“切小份”还不够，还得让每个窗口工作量差不多（负载均衡）、让传菜和炒菜同时进行（通信隐藏）、并且灵活搭配各种工具（技术协同）。做到这三点，你的流水线食堂就能永远客满、永不空转。

AI 应用场景

Python 演示

def bubble_ratio(stages, micro_batches):    """计算流水线并行的气泡率"""    return (stages - 1) / (stages - 1 + micro_batches) def throughput_score(stages, micro_batches, batch_size, peak_mem_limit):    """估算吞吐量得分（越高越好），考虑显存约束"""    micro_batch_size = batch_size // micro_batches    # 显存占用估算：每级需要保存的激活值大致与微批次大小成正比    mem_per_mb = micro_batch_size * stages    if mem_per_mb > peak_mem_limit:        return 0.0    # 计算效率：微批次越大，GPU 算术效率越高，设为 0.6 ~ 0.95    compute_eff = min(0.95, 0.6 + 0.01 * micro_batch_size)    bubble = bubble_ratio(stages, micro_batches)    return compute_eff * (1 - bubble) def simulate():    """模拟不同微批次配置的效果"""    stages = 4    batch_size = 1024    mem_limit = 128  # 单位：MB     best_config = (0, 0.0)    for micro_batches in [2, 4, 8, 16, 32, 64, 128]:        ratio = bubble_ratio(stages, micro_batches)        score = throughput_score(stages, micro_batches, batch_size, mem_limit)        print(f"微批次数={micro_batches:3d} | "              f"气泡率={ratio:.2%} | 吞吐得分={score:.3f}")        if score > best_config[1]:            best_config = (micro_batches, score)     print(f"\n最佳配置：微批次数={best_config[0]}，"          f"最高得分={best_config[1]:.3f}") if __name__ == "__main__":    simulate()

1. def bubble_ratio(stages, micro_batches)定义气泡率计算函数，对应文中的公式 (p-1)/(p-1+m)
2. mem_per_mb = micro_batch_size * stages估算多级流水线同时驻留的激活值显存占用
3. compute_eff = min(0.95, 0.6 + 0.01 * micro_batch_size)模拟 GPU 计算效率随微批次增大而提升
4. score = compute_eff * (1 - bubble)综合考虑计算效率和气泡的吞吐得分
5. if score > best_config[1]寻找给定显存约束下的最佳配置

常见误区

面试题