批量推理提升服务吞吐量

可视化演示

动态演示批量推理提升服务吞吐量的核心机制，通过概览/流程/对比/趋势四种模式展示关键概念与交互流程。

批量推理原理

经营快递站的第一课，就是别让货车空着跑。假设你手头有 10 个包裹要送到同一个片区，最笨的办法是派 10 趟车；聪明人会把它们装进一辆车，一趟送完。大模型推理服务面对的处境一模一样：用户请求像包裹一样不断涌来，如果每个请求都单独触发一次模型计算，GPU 这座“货车”大部分时间都在空转。批量推理（Batching）的核心思想，就是把这些散装请求“装车”——拼成一个批次，让模型一次前向计算同时处理多个请求。

为什么模型能一次处理多个请求？这要从深度学习的计算方式说起。大模型的前向传播，本质上是一连串矩阵乘法。假设输入是一句话，它会被编码成一个形状为 [1, seq_len] 的矩阵；如果用批量推理，输入变成 [B, seq_len]，其中 B 就是这次拼接的请求数。GPU 的矩阵运算单元对第 0 维（batch 维）天然并行——计算 B 个序列的耗时，只比计算 1 个序列多一点。这就好比货车拉 10 个包裹和拉 1 个包裹，油费差别不大，但送达数量差了 10 倍。

用吞吐量来衡量这种收益。吞吐量的定义是单位时间处理的请求数。假设每批处理耗时是 t_batch，批大小是 B，那么模型平均每个单位时间能处理 B / t_batch 个请求。对比串行处理的 1 / t_single，只要 t_batch 不比单请求耗时大太多，吞吐量就近似随 B 线性增长。在实际部署中，B=16 时吞吐量常常能提升 5~10 倍。

所以批量推理的本质，就是提高货车的“满载率”。GPU 这台昂贵的货车，一旦满载运行，单位成本骤降、吞吐翻倍。理解了这一点，接下来要解决的，就是“什么时候发车、装多少货”这两个现实问题。

动态批处理

快递站随时都有包裹进来，但不可能每来一件就发一趟车。经验丰富的调度员会盯着门口的包裹堆：攒得差不多了就喊司机发车；如果某个包裹等得太久，就算没攒够，也会先送这一趟。动态批处理（Dynamic Batching）就是这样一个“智能调度员”。

在线服务的请求到达时间完全随机：有时一秒来 100 个，有时 10 秒才来 1 个。动态批处理的思路是：维护一个请求队列，新请求先入队等待；当队列中的请求数达到预设阈值 N（例如 16），或者最早请求的等待时间超过阈值 T（例如 100ms），就触发一次模型计算，把队列里所有请求打包处理。两个条件用“或”连接——流量大时靠数量触发，流量小时靠时间兜底。

一个关键参数是触发阈值的选择。从排队论角度看，攒够 N 个请求的平均等待时间约为 N/(2λ)，其中 λ 是请求到达速率。如果 λ 大（并发高），很快就能攒够一批，等待时间短；如果 λ 小，就得依靠时间阈值 T 来兜底，避免请求饿死。这也是为什么动态批处理特别适合流量波动大的在线场景——它让批大小自适应流量，忙时大、闲时小。

调度员不会死等，也不会乱发。动态批处理用“数量 + 超时”两个旋钮，让货车在满载和时效之间自动找平衡。实时聊天、AI 客服这类流量忽高忽低的服务，靠它把空闲 GPU 利用起来，是最常见的落地方式。

静态批处理

和随机应变的调度员相反，有些物流公司走的是“班车制”：早上 8 点、下午 2 点、晚上 6 点，不管有没有货，准时发车。货多就多装几车，货少就空着跑一段。静态批处理（Static Batching）就是这么“固执”——批大小在启动前就定死了。

静态批处理预先指定 batch size = B，所有请求在进入服务前先被收集成固定大小的批次，再依次送入模型。它不关心请求什么时候到、到了多少，只是机械地按 B 个一组执行。这种“固执”在特定场景反而成了优点：批次形状固定，模型推理路径完全确定。

固定批大小带来两个实际好处。一是可以配合 CUDA Graph 等编译优化，把整个批处理的计算图提前编译成 GPU 指令序列，运行时省去大量内核启动开销，单批耗时更短、更稳定。二是吞吐量可预期：给定 N 个请求，总时间就是 ⌈N/B⌉ 乘以每批耗时，方便做容量规划。代价是流量波动时，要么批次不满浪费算力，要么请求排队时间随机，所以它更适合离线、批量的任务形态。

班车制的好处是规律和可控：什么时间发车、成本多少，早就写在表上。离线数据标注、批量评测、夜间数据回放，这类不差时间的任务，静态批处理能最大化吞吐、把 GPU 榨干。

批大小设置

货车装货不是越多越好。装到顶棚，引擎爬不动坡；装得太少，路费摊到每个包裹上又太贵。老司机跑几趟就知道这辆车的“经济载重”。batch size 也一样，太小并行度不足，太大则显存爆掉或延迟失控。

batch size 的上限由硬件资源决定。每个请求在推理时会占用显存，主要来自两部分：中间激活值（activations）和 KV Cache。一张 A100 有 80GB 显存，如果每个序列平均占 2GB，那么 batch size 最大只能开到约 40。下限则由吞吐目标决定——批太小，GPU 计算单元喂不饱，吞吐上不去。

工程上的标准做法是“压测扫描”：从 batch size = 1 开始，按 2 的幂次倍增（2、4、8、16、32……），记录每个取值下的吞吐量和 p95 延迟。通常你会看到吞吐量先快速爬升，到达某个拐点后增速放缓甚至下降——这个拐点附近就是最佳工作区。再结合延迟预算（例如要求 p95 < 2 秒），在预算内选最大的 batch size，就是最终参数。

找到“经济载重”不是拍脑袋，而是用公式定上限、用压测找拐点。batch size 这个数字，直接决定了你的货车是满载飞奔，还是超载趴窝。

吞吐延迟权衡

货车司机都懂一个矛盾：等满货再走，单车成本最低，但急件可能等上半天；立刻发车，时效最好，但空驶率飙升。吞吐量和延迟，就是物流世界里这对永恒的矛盾。

在批量推理里，二者的矛盾体现在：batch size 越大，GPU 利用率越高、吞吐量越大，但请求在队列里的等待时间和单批计算时间都在增加，端到端延迟随之上升。一个请求的完整生命周期包括：排队等待 W_q、本批计算 t_batch、网络传输等。其中 W_q 随批大小和队列长度增长，t_batch 也随批大小增长（尽管是亚线性的）。

实际工作中，我们很少追求“最大吞吐”，而是在满足延迟约束（SLO）的前提下最大化吞吐。SLO 通常以分位数定义，例如“99% 的请求延迟低于 2 秒”。这意味着你可以容忍少数慢请求，只要绝大多数达标。优化目标写成一个带约束的优化问题：让吞吐量最大，同时保证 p95 延迟不超过红线。调 batch size、调触发阈值，本质都是在解这个优化问题。

就像快递公司会承诺“同城当日达”，用时效红线换成本效率。批量推理的调优，就是在延迟红线和吞吐收益之间走出来的一条钢丝。记住：优化的目标永远不是某个单一指标，而是“在约束内做到最好”。

适用场景分析

不同的货物，有不同的物流策略。生鲜冷链走专车、当日达；普通快递走班车、三四天到货。聪明的快递站不会用一套方案服务所有客户。批量推理也是一样，得看业务到底在不在乎那几秒钟。

先看在线业务：聊天机器人、实时问答、AI 搜索。这类服务对延迟极其敏感，用户按一下回车就要看到回复。适合动态批处理 + 小 batch + 短超时（比如 batch 上限 8、超时 50ms），既保证响应速度，又能在流量峰值时吃到批量收益。

再看离线业务：数据标注生成、批量评测、内容审核。这些任务不关心单个请求等多久，只关心总体成本——适合静态批处理 + 大 batch（32 甚至 64），把吞吐量顶到极限。还有一种混合场景：同一个服务里既有实时交互请求，又有后台批量任务。可以用优先级队列把实时请求插队到批头，或用两个推理实例分别承载两种流量，避免互相干扰。

用对场景，批量推理是提效利器；用错场景，可能适得其反。判断方法很简单：问一句“用户等得起吗？”等不起，走动态；等得起，上静态，把每一分 GPU 算力都换成钱。

AI 应用场景

Python 演示

import math  def simulate_serial(requests, per_request_time):    """串行处理：一个请求算完再算下一个"""    total = 0.0    for _ in range(requests):        total += per_request_time    return total  def simulate_batch(requests, batch_size):    """批量处理：一批请求一次前向传播"""    num_batches = math.ceil(requests / batch_size)    total = 0.0    for _ in range(num_batches):        # 每批耗时随 batch_size 亚线性增长（并行带来的收益）        batch_time = 0.03 + 0.05 * math.log2(batch_size + 1)        total += batch_time    return total  def main():    total = 200    per_req = 0.05     serial_time = simulate_serial(total, per_req)    print("=== 串行处理 ===")    print(f"总耗时: {serial_time:.3f}s")    print(f"吞吐量: {total / serial_time:.1f} req/s")    print()     print("=== 批量处理 ===")    for bs in [1, 2, 4, 8, 16, 32, 64]:        batch_time = simulate_batch(total, bs)        throughput = total / batch_time        avg_latency = batch_time / math.ceil(total / bs)        print(f"batch={bs:>3} 总耗时={batch_time:>7.3f}s "              f"吞吐={throughput:>7.1f} req/s 平均延迟={avg_latency:.3f}s")  if __name__ == "__main__":    main()

1. num_batches = math.ceil(requests / batch_size)向上取整算出要跑几批，最后一个不满批也算一次。
2. batch_time = 0.03 + 0.05 * math.log2(batch_size + 1)用对数函数模拟批处理耗时亚线性增长：批越大，每请求均摊成本越低。
3. throughput = total / batch_time总请求数除以总耗时，得到每秒吞吐量，这是衡量收益的核心指标。
4. avg_latency = batch_time / math.ceil(total / bs)把每批耗时摊到每个请求上，近似估算单请求平均延迟。

常见误区

面试题