1. 从“单打独斗”到“排队上车”：GPU Serving效率困境的根源

如果你最近在折腾大模型推理，或者任何需要GPU加速的在线服务，大概率会碰到一个让人头疼的问题：GPU利用率上不去，但延迟却下不来。你看着监控面板上那根在20%到30%之间徘徊的GPU利用率曲线，再看看用户反馈里抱怨的“响应慢”，心里可能充满了疑惑——我这可是最新的H100/A100啊，怎么感觉跟用了个寂寞一样？

这种困境的根源，往往不在于GPU本身不够快，而在于我们使用它的方式太“奢侈”了。想象一下，你开着一辆能载50人的大巴车（GPU），但每次只接一位乘客（一个推理请求），跑一趟。虽然车开得飞快，但绝大部分座位都是空的，燃油（算力）被白白浪费在来回的路上（数据搬运、内核启动开销）。更糟糕的是，城市里（服务器）有成千上万个这样的请求，每个都要求一辆专车，结果就是交通严重拥堵（高延迟），而大巴车的运力（GPU算力）却远未发挥。

这就是传统“请求-响应”式GPU Serving的典型写照。每个请求独占整个GPU的计算资源，哪怕它只用了其中一小部分。GPU强大的并行计算能力，在这种“串行”的服务模式下被严重束缚。而“Batching”（批处理），正是打破这一困局，让GPU这辆“大巴车”真正坐满乘客、高效运转的第一性原理。它不是众多优化技巧中的一个，而是决定GPU Serving能否经济可行的基石。不理解Batching，所有的GPU加速服务都像是在沙地上盖楼。

2. 深入GPU计算核心：为什么“排队”比“插队”更高效？

要理解Batching为什么是“第一性原理”，我们需要暂时抛开软件框架，深入到GPU的硬件执行层面去看。GPU的设计哲学天生就是为了大规模并行。它拥有成千上万个流处理器（CUDA Core），这些核心就像工厂里的流水线工人，最擅长的是重复执行相同的指令，但处理不同的数据（SIMD，单指令多数据流）。

当我们执行一个模型推理时，例如一个Transformer层的前向传播，GPU上启动的是一系列高度优化的内核（Kernel）。这些内核执行矩阵乘法（GEMM）、激活函数等操作。这里存在几个关键的开销，是Batching主要攻克的对象：

2.1 内核启动开销（Kernel Launch Overhead）每次启动一个CUDA内核，CPU都需要向GPU驱动程序发送指令，GPU需要分配资源、配置执行网格和线程块。这个过程虽然很快（微秒级），但当每秒要处理成千上万个请求时，频繁的内核启动就会累积成巨大的开销。Batching将多个请求的计算合并到一次内核启动中，平摊了这部分固定成本。

2.2 内存带宽与数据复用这是Batching带来性能提升最显著的地方。以矩阵乘法Y = X @ W为例：

• X是输入数据，形状为[batch_size, hidden_dim]
• W是权重矩阵，形状为[hidden_dim, output_dim]
• Y是输出，形状为[batch_size, output_dim]

当batch_size=1时，我们为了计算一个[1, hidden_dim]的向量和[hidden_dim, output_dim]矩阵的乘积，需要从显存中读取整个巨大的W矩阵，但只产生一个向量的结果。内存带宽被严重浪费，计算强度（FLOPs/Byte）极低。

当batch_size=N时，我们一次性读取W矩阵，但用它来计算N个输入向量。W矩阵的数据在高速缓存（如GPU的L2 Cache）中被重复利用了N次。这极大地提升了数据复用率，让昂贵的内存带宽被更有效地利用，计算强度成倍增加，从而让GPU的计算单元“吃饱”，利用率飙升。

2.3 硬件利用率与上下文切换现代GPU有复杂的流水线、张量核心（Tensor Cores）等专用硬件。小批量或单样本计算无法填满这些硬件的计算窗口，导致流水线停顿、张量核心闲置。批量计算能提供足够多的并行工作项，让硬件始终处于忙碌状态。此外，避免在大量微小任务间频繁切换，也减少了上下文管理的损耗。

用一个简单的类比：去超市购物。单请求模式就像你每次只买一瓶可乐，就开车回家一趟，再出来买一包薯片。Batching模式则是你把所有需要的东西列个清单，一次采购齐全。后者显然大大减少了“上路-停车-结账”这个固定流程的重复次数，运输工具（GPU）的载货效率也达到了最高。

3. Continuous Batching：应对LLM时代长尾延迟的终极武器

传统的静态Batching（Static Batching）在图像分类、传统NLP任务上效果显著。它简单粗暴：收集一定数量（或等待一定时间）的请求，凑成一个批次，然后一起送入GPU计算，全部完成后统一返回。但这套机制在服务大语言模型（LLM）时，遇到了严峻挑战。

LLM推理有两个致命特点：1. 生成式、自回归：输出是一个token一个token生成的，每个token的生成都依赖前序所有token。2. 请求间差异巨大：用户A可能只问“你好”，需要生成10个token；用户B可能要求写一篇报告，需要生成1000个token。

静态Batching在这里会引发灾难性的“队头阻塞”（Head-of-Line Blocking）。假设一个批次里混入了一个需要生成长文本的请求，那么其他早已完成短回复的请求，也必须苦苦等待这个长请求全部生成完毕，才能被释放返回给用户。短请求的延迟被长请求无限拉高，用户体验极差。

Continuous Batching（连续批处理，也被称为迭代级批处理或流式批处理）正是为此而生的革命性技术。它的核心思想是：将批处理的粒度从“整个请求”细化到“每个生成步骤（迭代）”。

3.1 Continuous Batching 的工作原理想象一个动态更新的白板（GPU显存）：

1. 初始化：当一批新请求到达时，系统为它们分配空间，并并行地执行所有请求的提示词处理（Prompt Processing）。这是一个标准的静态批处理。
2. 迭代生成：提示词处理完成后，每个请求都生成了第一个token。此时，系统会立刻检查：哪些请求已经达到了停止条件（如生成了<eos>结束符，或达到了最大生成长度）？
3. 动态更新批次：将已完成的请求从当前计算批次中“移除”（标记为完成，释放其部分显存）。同时，检查是否有新的请求在等待。将新请求和尚未完成的老请求的下一个生成步骤，重新组合成一个新的批次，进行下一次前向传播。
4. 持续循环：重复步骤2和3，直到所有请求都完成。已完成请求的结果可以立即流式返回给用户，无需等待整个批次。

这个过程就像是一个不断有人下车、也有人上车的公共汽车。车一直在开（GPU一直在计算），到站（生成结束）的乘客随时下车，新乘客随时在车站（请求队列）排队上车。车的座位（GPU计算资源）利用率始终很高，且每个乘客的等待时间都只和自己的路程有关，不会被其他长途乘客耽误。

3.2 关键技术实现与考量实现Continuous Batching并非易事，它需要推理引擎在底层进行精巧的设计：

• 内存管理：需要实现高效的显存分配与释放，因为每个请求的KV Cache（键值缓存，用于存储注意力机制中的历史信息）长度是动态增长的。类似vLLM、TGI等框架采用的PagedAttention技术，就是将KV Cache像操作系统管理内存一样进行分页管理，允许非连续存储和高效复用，这是支撑Continuous Batching的关键。
• 调度策略：如何调度新请求加入？是优先保证延迟（来一个加一个），还是优先保证吞吐（攒一攒再加）？这需要在延迟和吞吐之间做权衡。高级的调度器甚至会考虑模型的“宽度”（参数量）和“深度”（层数），进行更智能的调度。
• 计算图优化：动态变化的批次大小，要求计算图能够适应这种变化。框架需要能够动态地重新编译或调整内核的执行参数。

在实际部署中，我们通常需要配置两个关键参数：max_batch_size（最大批次大小，受限于显存）和max_queue_size（最大队列长度）。当新请求到达时，如果当前运行批次未满且有空闲计算资源，可能会立即加入；否则进入队列等待。一个好的调度策略是平衡的秘诀。

4. 实战：从理论到指标，构建高效的Batching策略

理解了原理，我们如何在真实的项目中应用并优化Batching呢？这绝不仅仅是把batch_size参数调大那么简单，而是一个需要综合考虑吞吐量、延迟、成本和服务质量（QoS）的系统工程。

4.1 核心性能指标与权衡首先，我们必须明确要优化什么，以及它们之间如何相互制约。

• 吞吐量：单位时间内处理的Token数或请求数。这是衡量硬件利用率和成本效益的核心指标。Batching是提升吞吐量的最主要手段。
• 延迟：从请求发出到收到第一个token（TTFT，Time To First Token）和最后一个token（TLT，Time To Last Token）的时间。直接影响用户体验。
• 成本：主要体现为GPU的显存占用和计算时间。更大的Batch Size通常需要更多显存来存储中间状态（尤其是KV Cache）。

这三者构成一个“不可能三角”。单纯追求高吞吐（极大Batch Size），会导致队列等待时间变长，增加延迟（尤其是TTFT）。单纯追求低延迟（Batch Size=1），会严重牺牲吞吐，拉高单位请求的成本。我们的目标是在给定的SLA（服务等级协议，如P99延迟<2秒）约束下，最大化吞吐，从而最小化单位服务成本。

4.2 寻找最佳Batch Size：一个动态过程最佳Batch Size不是一个固定值，它随着请求负载的分布（输入/输出长度）、模型结构、甚至GPU型号而变化。一个基本的实践方法是进行压力测试与 profiling：

1. 基准测试：使用一个具有代表性的请求数据集（模拟真实流量分布）。
2. 参数扫描：在固定的并发请求数下，逐步增加batch_size，观察吞吐和延迟的变化。
   • 初期：随着batch_size增加，吞吐线性上升，延迟增长不明显（因为计算效率提升抵消了队列等待）。
   • 中期：吞吐增长曲线变缓，延迟开始显著上升。这是因为GPU计算资源逐渐饱和，更大的批次带来的效率提升边际递减，而队列等待时间成为延迟的主要部分。
   • 后期：吞吐达到峰值甚至下降（可能因为显存溢出导致数据交换），延迟急剧恶化。
3. 确定甜蜜点：绘制吞吐-延迟曲线。那个在满足你延迟SLA的前提下，吞吐量最高的batch_size，就是当前配置下的“甜蜜点”。

下表展示了一个简化的测试结果示例（假设场景）：

在这个例子中，如果SLA要求P99 TLT < 1.5秒，那么Batch Size=16可能是一个不错的选择，它在可接受的延迟内提供了较高的吞吐。如果对TTFT极其敏感（如对话场景），则可能需要选择Batch Size=8。

4.3 高级策略与框架选择在实际生产环境中，我们还需要更精细的策略：

• 自适应批处理：系统实时监控队列长度、请求特征和当前延迟，动态调整批处理策略。例如，在低峰期自动减小batch_size以降低延迟，在高峰期增大以提升吞吐。
• 优先级队列：并非所有请求都平等。可以为高优先级用户或实时交互请求设置优先队列，减少他们的等待时间。
• 基于预测的调度：如果能预测请求的输出长度（这很难），可以实施更优的调度，避免长短请求相互阻塞。

框架的选择至关重要。像vLLM、TensorRT-LLM、TGI等现代推理框架，已经将Continuous Batching作为其核心特性，并做了大量底层优化。以vLLM为例，其PagedAttention和高效的调度器，使得它能在同等硬件下，相比未优化的推理方式，实现数倍甚至数十倍的吞吐提升。我的经验是，在大多数LLM服务场景下，直接采用这些成熟框架，远比从零开始实现自己的批处理逻辑要可靠和高效得多。

5. 避坑指南：Batching实践中的常见陷阱与优化技巧

即使理解了原理，选对了框架，在实际部署中依然会踩到很多坑。下面分享一些从真实项目中总结出的教训。

5.1 显存管理：OOM的幽灵更大的Batch Size首先冲击的就是显存。除了模型参数和激活值，LLM推理中最大的显存消耗者是KV Cache。其大小与batch_size * sequence_length * 2 * hidden_size * num_layers成正比。

• 坑1：静态分配导致浪费：为每个请求按最大可能长度分配KV Cache，在请求长度变化大时极其浪费。
• 解决：使用支持PagedAttention的框架（如vLLM），它像操作系统一样按需分配和回收显存页，能支持比物理显存大得多的“虚拟”序列长度，显著提升吞吐。
• 坑2：忽略中间激活峰值：某些模型结构（如MoE的专家路由）或操作（如大尺寸的Scatter/Gather）会产生临时的显存峰值，可能在你认为安全的Batch Size下触发OOM。
• 解决：进行极端情况下的压力测试，并使用torch.cuda.max_memory_allocated()来监控峰值显存，留出足够的安全余量（通常建议是总显存的20%）。

5.2 长尾延迟与公平性Continuous Batching解决了平均延迟，但P99或P999延迟（最慢的那1%或0.1%的请求）可能依然很高。

• 原因：一个非常长的请求可能会在多次迭代中始终占据批次的一个位置，虽然不影响其他请求的迭代，但新请求需要等待这个“长跑者”腾出位置才能加入计算，影响了新请求的TTFT。
• 缓解策略：
  1. 设置最大服务时长：强制中断生成时间过长的请求，返回已生成的部分，并提示用户“响应过长”。
  2. 使用抢占式调度：对于更高优先级的请求，可以临时暂停长请求的计算（保存其状态到内存），先服务高优请求。但这实现复杂，且会引入额外的状态保存/恢复开销。
  3. 请求分桶：根据输入长度或预估输出长度，将请求分配到不同的推理实例或队列中。例如，短问答一个实例，长文生成另一个实例，进行物理隔离。

5.3 冷启动与流量突增模型第一次加载时，或长时间无请求后突然来一波流量，系统表现会很差。

• 冷启动：加载模型、编译计算图（对于TorchScript或TRT）需要时间。这期间请求会堆积。
• 流量突增：如果初始批次设置较小，突增的流量会导致队列瞬间变长，第一个批次的请求需要等待队列凑满，TTFT飙升。
• 优化技巧：
  1. 预热：服务启动后，主动用一些模拟请求“预热”模型，触发内核编译和缓存。
  2. 弹性伸缩：结合监控系统，在队列长度持续超过阈值时，自动扩容新的推理实例。
  3. 动态调整初始批次：监控系统可以学习流量模式，在预期的高峰期提前调大max_batch_size。

5.4 监控与可观测性没有监控，优化就是盲人摸象。必须建立完善的监控体系：

• 业务指标：请求速率、平均/分位延迟（P50, P90, P99）、错误率。
• 系统指标：GPU利用率（SM Util）、显存使用率、Tensor Core利用率、内核执行时间。
• 框架特定指标：批次大小分布、队列长度、缓存命中率（对于PagedAttention）、调度等待时间。
• 关键动作：将延迟与批次大小、队列长度进行关联分析。当你发现延迟升高时，要能快速区分是计算慢了（GPU瓶颈），还是等待久了（调度/队列瓶颈）。

6. 超越Batching：与其他优化技术的协同

Batching是基石，但绝非孤岛。在实际的高性能GPU Serving系统中，它需要与其它优化技术紧密协同，才能发挥最大效力。

6.1 与量化（Quantization）结合量化将模型权重和激活值从FP16/BF16降低到INT8甚至INT4，能大幅减少显存占用和内存带宽压力。这直接带来了两个好处：

1. 在相同显存下，支持更大的Batch Size。这是最直接的协同效应，量化省出的显存可以用于容纳更多请求的KV Cache。
2. 提升计算速度：在支持低精度计算（如INT8 Tensor Core）的GPU上，量化本身也能加速计算。更快的单次迭代，意味着Continuous Batching的调度周期可以更短，整体吞吐更高。

6.2 与FlashAttention等优化内核结合FlashAttention通过优化GPU显存访问模式，大幅降低了注意力计算的开销和显存占用。更快的注意力计算意味着每次迭代时间更短，更低的显存占用同样为更大的Batch Size创造了条件。vLLM等项目就将PagedAttention与FlashAttention的思想深度融合。

6.3 与模型并行/张量并行结合对于超大规模模型（如千亿参数），单个GPU无法放下整个模型。此时需要将模型切分到多个GPU上（模型并行）。Batching在这里面临新的挑战：如何在不同GPU间高效地同步和传输批处理数据？

• 流水线并行：将模型按层切分，每个GPU负责一部分层。一个批次的数据像流水线一样在不同GPU间传递。这里需要精细的“微批处理”来填充流水线，减少气泡（GPU空闲等待时间）。
• 张量并行：将单个层的计算（如矩阵乘）切分到多个GPU上。这要求每个GPU都持有完整的批次数据，但只处理其中一部分计算，最后通过集合通信（如All-Reduce）聚合结果。通信开销与批次大小成正比，因此过大的批次可能会使通信成为瓶颈。

在这种分布式场景下，Batching策略需要与并行策略共同设计。通常，会在单个计算节点（如一台8卡服务器）内部采用较大的Batch Size以充分利用节点内高速NVLink带宽，而在节点间采用相对较小的Batch Size或更灵活的调度来避免跨节点通信成为瓶颈。

从我过去部署百亿参数模型的经验来看，一个有效的组合拳是：使用量化降低单卡负载 -> 在单卡/单节点内利用Continuous Batching最大化吞吐 -> 对于更大模型，采用张量并行在节点内扩展，并谨慎调整节点间的批处理策略。这个过程中，持续的性能剖析（Profiling）至关重要，你需要用Nsight Systems这类工具看清楚时间到底花在了计算、内存拷贝还是通信上，才能找到真正的瓶颈并进行针对性优化。

GPU Serving的世界里，没有银弹，但Batching无疑是最重要的那块压舱石。它从GPU硬件的基本工作原理出发，通过将离散的请求转化为规整的批量计算，真正释放了硬件的潜力。而Continuous Batching的演进，更是让这项技术在LLM时代焕发了新生。理解它、用好它，是构建任何高效、经济AI服务的必经之路。这一切的起点，就是改变思维：不要再把GPU看作一个为单个请求服务的“加速卡”，而是把它看作一个需要被持续、饱满喂养数据的“并行计算工厂”。你的工作，就是设计最好的物流系统（调度与批处理），让原料（请求）源源不断，让生产线（GPU）永不空闲。