连续批处理如何提升大模型吞吐量？读懂调度、延迟与显存限制

连续批处理（continuous batching）允许共享 GPU 在生成步骤之间接纳新请求，避免短任务完成后，空出的容量仍被长任务所在的批次占住。Yu 等人发表于 OSDI 2022 的 Orca 论文，奠定了这种调度方式的基础。它能在并发请求下提高总 token 吞吐量，但服务器更忙，并不意味着每位用户都能更快拿到回答。

对共享模型服务而言，真正有用的目标是：在响应时间要求内完成更多工作。吞吐量曲线如果没有对应的延迟目标，就无法说明服务器能在体验良好的前提下服务多少用户。

下文涉及的服务端支持情况和控制参数，已于 2026 年 10 月 25 日对照各厂商的在线文档核实。文中的调度示例仅用于说明原理，并非硬件基准测试。

连续批处理是如何工作的？

连续批处理允许在生成尚未结束时，调整正在执行的请求集合。 已完成的请求退出；只要调度器还有容量，等待中的请求就可以加入。这种方式也称为 in-flight batching 或 iteration-level batching（迭代级批处理）。

大语言模型（LLM）先在**预填充（prefill）阶段处理提示词，再在解码（decode）**阶段生成后续文本。在常规自回归解码中，每个活跃请求会在一次生成步骤中产出下一个 token，也就是一个文本片段。调度器负责决定哪些请求参与下一步计算。LLM 推理指南对这些阶段有更详细的介绍。

可以把它想成一张多人共用的餐桌。固定批次的做法是，等这一桌人全部吃完，再让下一拨入座。连续批处理则是有空椅子就让下一位入座，不必等其他人吃完。大家共用餐桌，但各自的餐食仍然独立。

这个比喻也有局限：GPU 调度器还要安排提示词处理和内存分配。有空位，并不代表每个排队请求都能立刻进入。

Orca 论文的关键贡献是什么？

Orca 把调度边界从整个请求缩小到了一次迭代。 Gyeong-In Yu 及其同事的 OSDI 2022 论文提出，让执行引擎先运行一次模型迭代，再重新决定批次的组成。

与之配套的选择性批处理（selective batching）会对选定的模型操作进行批处理，同时适应注意力计算所需的不同历史上下文。注意力负责将当前 token 与此前的上下文关联起来。这两种技术结合后，服务系统便能交错处理长度不同的请求。论文还将批大小和可用的键值缓存内存列为调度约束。阅读 Orca 论文。

改变的是模型外围的推理服务系统，并不需要训练模型，让它在同一段对话里同时回答多个人。

静态批处理、动态批处理与连续批处理有何区别？

关键在于：新请求何时能加入已经开始的计算。 服务器能够接受并发 HTTP 连接，并不能证明模型执行采用了连续批处理。

NVIDIA 的 Triton 批处理文档介绍了常规动态批处理，包括批大小和队列等待时间控制。这与在 LLM 生成过程中替换批次成员，是两个不同层面的调度问题。

vLLM 的“动态批处理”：要看实际的调度边界

LLM 推理服务引擎 vLLM 在文档中明确支持连续批处理。 相比之下，“动态批处理”这个名称不够精确。Hugging Face 在其连续批处理介绍中，也用 dynamic scheduling 或 dynamic batching 来描述生成期间替换已完成请求的机制。判断时，应确认引擎是否在生成步骤之间接纳新请求，而不是只看名称。

流式输出又是另一回事。服务器可以持续向客户端发送 token，同时让执行批次的成员保持不变。这里讨论的收益在于：已完成请求释放的容量，可以供新请求使用。

用一个调度示例看清差别

长任务还在运行时，短任务就可能腾出可用容量。 假设一台服务器有两个解码位置。请求 A 还需 2 步，B 还需 4 步，排队中的 C 需要 2 步。这个示例忽略预填充、调度开销，以及每一步耗时的变化。

如果批次成员固定，A 和 B 一起开始。A 完成后，C 仍要等 B 结束，才能随下一批开始。采用连续批处理时，A 一完成，C 就可以接替它的位置，与 B 一起继续执行。

这个例子说明的是更早接纳请求，而非实测加速幅度。客服聊天机器人同时处理简短回答和长篇摘要时，也存在同样的调度机会；实际收益取决于请求、硬件和服务配置。

吞吐量为何会提高，KV 缓存又如何限制它？

批处理让同一次模型权重搬运支撑更多有效计算。 模型权重是模型通过训练学到、用于计算回答的数值参数。使用同一模型的多个请求，可以共享权重在 GPU 内存中搬运的开销，从而更充分地利用可用算力。随着请求陆续完成，连续调度有助于维持有效的批次规模。NVIDIA 解释了批处理、内存数据搬运与 GPU 利用率之间的关系。

即使批次效率不高，GPU 也可能一直很忙。关键是这些计算完成了多少有效的请求工作，而不是利用率曲线是否拉满。

但每个活跃请求也需要工作内存。KV 缓存，即键值缓存（key-value cache），保存已处理 token 的注意力状态。并发请求越多、历史上下文越长，内存压力就越大。KV 缓存详解说明了这类状态与可复用的提示词缓存有何不同。

PagedAttention 如何提高内存利用效率？

连续批处理决定运行哪些请求；PagedAttention 改变注意力状态的存储方式。 Woosuk Kwon 及其同事的 2023 年 vLLM 论文介绍了如何将 KV 状态拆分为固定大小的块，而这些块不必占据相邻的物理内存。块映射负责维持序列的逻辑顺序。

这样可以减少内存碎片和不必要的重复存储所造成的浪费。内存安排得更紧凑，就能容纳更多请求的工作集，让调度器有更多可执行的请求。论文明确指出，这种内存管理方式与 Orca 的调度方式相互补充。

物理容量仍是硬限制。内存利用率再高，也不可能容纳无限多段长对话。在 vLLM 中，KV 空间不足可能触发抢占（preemption）：暂停某个请求，稍后再重新计算其状态。这可能拉长请求完成时间。其优化文档介绍了这一行为。

连续批处理会怎样影响延迟？

连续批处理可以缩短排队时间，但批次变大或负载更拥挤，也可能让请求进入执行后变慢。 应分别跟踪以下阶段：

• 首 token 延迟（Time to First Token，TTFT）： 用户从发起请求到开始看到输出，需要等待多久。
• token 间延迟： 流式输出开始后，相邻 token 之间的时间间隔。
• 端到端延迟： 整个请求完成所需的时间。

新请求不必再等一个固定批次全部结束。但处理新到达的长提示词，会与已经进入解码阶段的请求争抢资源。**分块预填充（chunked prefill）**将提示词处理拆成较小的块，使调度器能将其与正在进行的生成任务交错执行。

例如，vLLM 文档说明了每次迭代 token 预算的权衡：较小的值有助于保障 token 间延迟；较大的值则可以处理更多预填充工作，改善 TTFT。因此，预算应根据实际负载决定，而不是盲目调到最大。参见 vLLM 调优指南。

低负载和高负载下，连续批处理的效果有何不同？

低负载时，可能没有多少请求可以组成批次；持续过载时，队列依然存在。 每次只发送一个请求的开发者，不应期待获得与面向用户、同时处理重叠请求的服务相同的收益。反过来，如果接纳的工作量超过 GPU 的持续处理能力，等待时间最终仍会变长。

对于交互式应用，除了中位数，还要关注 p95，也就是第 95 百分位数。漂亮的平均值可能掩盖少数会话的缓慢体验。先根据产品体验确定可接受的 TTFT 和流式输出间隔，再衡量这些限制内能承受的容量。

哪些 LLM 服务端支持连续批处理，有什么限制？

下面四款服务端均在文档中支持连续批处理或 in-flight batching。 具备这一共同能力，不代表它们的调度器、内存预算和模型支持可以相互替代。

vLLM 连续批处理

vLLM 将连续请求调度与分页 KV 缓存管理结合起来。 文档明确列出了这两项能力。对运维人员而言，真正有用的控制项是最大序列数和每次迭代调度的 token 数，而不只是希望同时维持多少个 API 连接。

限制来自内存压力：提高并发量可能触发抢占和重算，而非增加可用容量。应根据实际流量构成和延迟目标调优，比较不同设置时保持模型与硬件不变。

SGLang

SGLang 支持连续批处理，并提供明确的请求接纳控制参数。 其服务端参数文档定义了 --max-running-requests、--chunked-prefill-size，以及由 --mem-fraction-static 控制的模型权重与 KV 池内存预算。

这些参数解决的是不同问题：有多少请求可以同时运行、一个分块中处理多少提示词，以及如何分配内存。调高请求数量上限，并不会消除其他限制。选择引擎时，可以先看 vLLM 与 SGLang 对比，再测试实际准备部署的模型和请求组合。

NVIDIA TensorRT-LLM

NVIDIA TensorRT-LLM 明确将 in-flight batching、continuous batching 和 iteration-level batching 视为同一概念。 其功能文档说明，这种方式可以同时处理上下文阶段与生成阶段的序列；文档所述实现使用打包后的输入张量。

请求数量上限和 token 预算是两种不同的约束。其 PyTorch 调度器文档还区分了两个环节：先预留包括 KV 容量在内的资源，再从满足条件的请求中选择要执行的请求。无法通过容量检查的工作，in-flight 调度器也不能接纳。

Hugging Face Text Generation Inference

Hugging Face Text Generation Inference 支持连续批处理，但项目的维护状态会影响新部署的选择。 文档表示，项目目前接受小幅修复、文档改进和轻量维护，并建议后续采用 vLLM、SGLang 等下游引擎。

已经部署的 TGI 不会因此失去批处理能力。如果要搭建新的推理服务栈，我会先评估仍在积极开发的替代方案。如果现有部署已经达到目标，则应围绕具体的支持需求或能力缺口安排迁移。

关于连续批处理，哪些说法被夸大了？

连续批处理并没有一个放之四海而皆准的加速倍数。 Orca 和 PagedAttention 论文评估的是特定系统和负载。不能把其中的结果提炼成一个通用增益，再套到任意模型、GPU 或服务商接口上。

它也不会消除等待。排队中的请求仍然需要处理提示词、获得内存，并按调度策略等到执行机会。长提示词、高并发需求和缓存压力，依然构成限制。

最后，总 token 速率提高，不代表聊天产品的体验变好了。如果用户要更久才能看到第一个 token，或者流式输出频繁出现明显停顿，那么增加的服务器吞吐量可能已经超出了产品可接受的运行范围。

实际部署时，下一步该怎么做？

开发者应在请求存在重叠时评估共享推理服务；运维人员应在延迟约束内调优；评估服务商时，应要求提供资源竞争下的测量结果。 偶尔发起请求的单人工具可以暂缓考虑。存在用户排队、回答长短不一的服务，则有明确理由开始行动。Ollama 与 vLLM 对比介绍了从本地使用转向共享推理服务时的选择。

1. 1

   先明确体验要求，再提高并发

   针对实际工作流程，写清楚可接受的首 token 延迟、流式输出间隔和完成时间。后台摘要任务与实时客服助手，需要不同的验收标准。

2. 2

   回放有代表性的请求组合

   保持模型、硬件、提示词长度、输出上限和缓存条件具有可比性。纳入简短回答、长提示词和长篇生成请求。保留真实的请求到达模式，避免用空闲时的单用户测试代替繁忙服务的表现。

3. 3

   同时记录吞吐量、队列和延迟

   测量总输出吞吐量（每秒 token 数）、已完成请求数、等待请求数、失败情况、TTFT 和 token 间隔。vLLM 在其生产环境指标文档中提供了对应指标，包括 vllm:num_requests_waiting、vllm:time_to_first_token_seconds 和 vllm:inter_token_latency_seconds。

4. 4

   找出仍能达标的最高负载

   每次只调整一个调度或内存控制参数。当延迟超出限制，或内存压力导致反复重算时，就停止提高并发。向服务商索取预期并发量下同样完整的吞吐量与延迟数据，并确认所用容量是共享还是预留。

最终应得到一个经过测量的运行上限：在保证预期用户体验的前提下，接口能够持续承受多大的负载。这样，批处理能力才能成为部署决策的依据。

想了解 AI 基础设施的实用原理，以及技术栈中哪些地方值得调整，欢迎订阅通讯。