vLLM连续批处理调度器：突破LLM推理性能瓶颈的核心技术

1. 项目概述：从“排队等餐”到“流水线生产”的思维跃迁

如果你最近在折腾大语言模型（LLM）的推理服务，大概率会频繁听到一个词：Continuous Batching，或者它的中文译名“连续批处理”。而vLLM Scheduler，正是将这一思想发挥到极致的杰出代表，它几乎以一己之力，重新定义了现代LLM推理服务的性能基准。这不仅仅是一个技术优化，更是一次服务架构范式的根本性转变。简单来说，它把LLM推理从过去那种“一个请求一个坑，排队等结果”的原始餐馆模式，升级成了“请求像食材一样在流水线上动态组合、并行处理”的现代化中央厨房模式。

为什么说它是核心？因为LLM推理，尤其是生成式任务，有一个天生的矛盾：极高的计算成本与极不均衡的请求负载。每个请求的输入长度（Prompt）可能从几个词到上万token不等，而输出长度（Generation）更是完全未知，从一句回复到一篇长文都有可能。传统的静态批处理（Static Batching）在面对这种场景时束手无策——要么为了等一个长请求而让整个批次空转，造成GPU算力浪费；要么为了快速响应而使用极小的批次，导致GPU利用率低下。Continuous Batching就是为了解决这个核心矛盾而生的，它允许在一个批次内，不同请求处于生成过程的不同阶段，新请求可以随时加入，已完成输出的请求可以即时退出，从而让GPU这个昂贵的“厨师”永远处于忙碌状态。

vLLM项目正是敏锐地抓住了这一点，其内置的调度器（Scheduler）将Continuous Batching与其另一项王牌技术——PagedAttention（分页注意力）——深度结合，实现了近乎极致的吞吐量和极低的延迟。对于任何需要部署LLM服务，关心成本、性能和稳定性的开发者、算法工程师或架构师而言，理解vLLM Scheduler和Continuous Batching的工作原理，不再是“锦上添花”，而是“必修课”。这直接决定了你的服务是能以1台机器承载1000 QPS，还是需要10台机器才能勉强应付。

2. 核心困境：传统LLM服务为何“又慢又贵”

要理解Continuous Batching为何是救星，我们得先看清它要解决什么问题。在LLM服务中，尤其是在自回归（Autoregressive）生成场景下，传统的服务模式主要面临以下三重困境，这些困境共同导致了服务“又慢又贵”的现状。

2.1 静态批处理的固有缺陷

最原始的批处理方式是静态的。服务端会等待收集到一定数量（比如batch_size=8）的请求后，将它们拼成一个大的张量，一次性送入模型进行计算。计算完成后，整个批次的结果再一起返回。

问题立刻浮现：

1. 尾部延迟（Tail Latency）灾难：假设8个请求中，7个都只需要生成10个token，但第8个请求需要生成1000个token。那么，前面7个请求在生成完10个token后，必须空等第8个请求完成剩下的990个token。对于前7个用户而言，他们的延迟被这个“慢速请求”无限拉长。这在用户体验上是致命的。
2. 批次利用率低下：为了控制尾部延迟，实践中往往会设置一个超时时间，比如100毫秒。如果在100毫秒内只等来了2个请求，那么批次大小就只有2，GPU的强大算力无法被充分饱和，利用率可能只有20-30%。这相当于用跑车的引擎在市区开20码，极度浪费。
3. 无法应对动态输入/输出：LLM请求的输入长度不一，输出长度未知。静态批次需要预先分配一个固定的最大长度（max_seq_len），比如2048。对于大部分短请求，这会造成巨大的内存浪费（存储大量无效的填充token）；而对于极少数长请求，又可能因为超过最大长度而失败。

注意：静态批处理在训练阶段是高效且标准的，因为训练数据长度相对固定或可被填充至统一长度。但在推理阶段，请求的随机性和对低延迟的要求，使得静态批处理变得不再适用。

2.2 请求级并发的资源孤岛

另一种常见的模式是“请求级并发”，即每个请求独立占用一个模型实例（或一个CUDA Stream）。这类似于为每个顾客单独开一个厨房。虽然解决了尾部延迟问题（每个请求互不干扰），但带来了更严重的问题：

1. GPU内存爆炸：每个模型实例都需要在GPU上加载一份完整的模型权重和KV缓存（Key-Value Cache，用于存储注意力机制中的历史信息，避免重复计算）。一个70亿参数（7B）的模型，仅权重就可能占用约14GB显存。如果同时服务10个请求，KV缓存再占用几十GB，显存需求会变得不可承受。
2. 计算资源碎片化：GPU的SM（流多处理器）擅长并行处理大量相同的计算任务。当多个独立请求交错执行时，GPU的调度开销增大，无法形成有效的计算波阵面，整体吞吐量甚至会低于一个优化良好的小批次。

2.3 KV缓存的内存墙

这是LLM推理特有的一个瓶颈。为了加速自回归生成，模型会缓存之前所有生成步骤的Key和Value向量，避免在生成下一个token时重复计算整个历史序列。这个KV缓存的大小与批次大小 * 序列长度 * 模型层数 * 隐藏维度成正比。

在静态批处理中，你必须为批次内所有请求的最大可能序列长度预分配KV缓存。例如，设定max_seq_len=2048，batch_size=8，那么即使大部分请求实际长度只有100，你为它们预留的1904个token的缓存空间也被白白占着，无法被其他请求使用。这种内部碎片化是显存利用率低下的最主要原因，通常超过50%的显存可能被浪费在“预留但未使用”的空间上。

正是这三座大山——静态批处理的延迟与利用率矛盾、请求并发的内存与计算效率矛盾、KV缓存的内部碎片矛盾——使得高效的LLM服务成为一个极具挑战性的工程问题。而Continuous Batching，正是为了推倒这三座大山而设计的系统性解决方案。

3. Continuous Batching 原理深度拆解：动态流动的算力流水线

Continuous Batching，有时也被称为迭代级调度（Iteration-level Scheduling）或流式批处理。它的核心思想非常直观：将调度和执行的粒度从“整个请求”细化到“单个生成迭代（一个token）”。

3.1 核心工作流程：一个生动的类比

想象一个快餐店的流水线。顾客（请求）陆续到来，点单（输入Prompt）。厨师（GPU）不是等凑齐8个订单才一起做，而是：

1. 第一个顾客点了一个汉堡（短请求），厨师立刻开始做汉堡的第一道工序（编码Prompt）。
2. 此时第二个顾客来了，点了一份复杂的套餐（长请求）。厨师在完成汉堡第一道工序的间隙，立刻开始处理套餐的第一道工序。
3. 汉堡进入第二道工序（生成第一个token），同时套餐也在进行它的第一道工序。
4. 汉堡做好了（生成了<eos>结束符），立刻打包送出。这个位置（GPU计算单元和对应的缓存）立刻被释放。
5. 此时第三个顾客来了，点了一份薯条。这个新请求立刻被安排到刚刚空出的“汉堡位”上，开始处理。

在这个流程中：

• 批次（Batch）是动态的：每一轮迭代（生成一个token），参与的请求列表都可能发生变化。
• 请求状态是独立的：每个请求都有自己的“进度条”，记录着已经生成了多少token，是否已结束。
• 资源是实时回收的：一旦某个请求结束，它占用的计算槽位和显存（特别是KV缓存）立即被回收，用于新的等待请求。

3.2 关键技术实现：调度与执行的解耦

要实现上述动态流程，需要一个精巧的调度器（Scheduler），这也是vLLM的核心。其工作通常分为两个阶段：

1. 调度阶段（Schedule）： 调度器维护着多个队列：

• 等待队列（Wait Queue）：新到达的请求在此排队。
• 运行队列（Running Queue）：当前正在参与计算的请求列表。
• 暂停队列（Swap-out Queue，可选）：在显存不足时，将某些请求的KV缓存暂时交换到CPU内存。

在每一轮迭代开始前，调度器做决策：

• 哪些运行中的请求在本轮需要计算？（已结束的跳过）。
• 是否有等待队列的请求可以加入运行队列？（取决于是否有空出的计算槽位和足够的显存）。
• 是否需要将某些请求换出到CPU？（根据缓存淘汰策略，如LRU）。

决策完成后，调度器会生成一个本次迭代要执行的“微批次”（Micro-batch）列表，并准备好相应的数据块（如拼接好的输入token id，以及每个请求在KV缓存中的逻辑位置映射）。

2. 执行阶段（Execute）： GPU接收这个“微批次”和调度信息，进行一次前向传播。这里的关键是，物理上连续的KV缓存空间，在逻辑上对应着多个不同请求的不同位置。这需要模型计算内核（Kernel）的支持，能够根据调度器提供的映射关系，正确地访问分散的缓存数据。计算完成后，每个请求得到下一个token的概率分布，采样后得到新token，更新各自的状态。

3.3 与PagedAttention的珠联璧合

vLLM之所以将Continuous Batching的效果发挥到极致，离不开其独创的PagedAttention技术。它借鉴了操作系统虚拟内存中“分页”的思想来解决KV缓存的内存碎片问题。

• 传统方式：每个请求的KV缓存是一整块连续内存。就像你为每个程序分配一块固定大小的连续内存，容易产生碎片。
• PagedAttention：将每个请求的KV缓存划分为多个固定大小的“块”（Block），例如每个块存储16个token的KV。这些块在物理显存中可以不连续存放，由一个“块表”（Block Table）来记录每个请求使用了哪些物理块。

这种设计的优势与Continuous Batching完美契合：

1. 高效的内存共享：对于多个请求中相同的系统提示词（System Prompt），其对应的KV块可以被所有请求共享，只需存储一份，节省大量显存。
2. 消除内部碎片：请求按需申请块，短请求占用少量块，长请求占用更多块。块是固定大小的，几乎没有浪费。新请求可以充分利用已结束请求释放的块。
3. 支持灵活的缓存交换：当显存不足时，可以将某些请求的不活跃“页”（块）换出到CPU，需要时再换入，实现了类似虚拟内存的机制，极大地扩展了服务容量。

Continuous Batching负责动态调度请求的生命周期，而PagedAttention负责高效、精细地管理这些请求所依赖的KV缓存内存。两者结合，实现了从计算到内存的全链路优化。

4. vLLM Scheduler 的实战解析与配置要点

理解了原理，我们来看看在vLLM中，如何具体使用和配置这个强大的调度器。vLLM的Scheduler提供了多种策略和参数，以适应不同的服务场景。

4.1 核心调度策略

vLLM主要实现了两种Continuous Batching策略，通过--scheduler-policy参数指定：

1. FCFS (First-Come-First-Served)

   • 工作方式：严格按照请求到达的先后顺序将其加入运行批次。只有当前批次中有请求结束，空出位置后，才会从等待队列的头部取出新请求加入。
   • 优点：公平性最好，保证了请求的等待时间与其到达时间相关。
   • 缺点：可能因为一个长请求卡在队列头部，导致后面大量短请求被阻塞，影响整体平均延迟。这是vLLM默认的策略，因为它最直观且稳定。

2. Maximal Throughput (或类似优先短请求的策略)

   • 工作方式：调度器会优先选择那些预计剩余生成时间短的请求加入运行批次。这通常意味着优先选择输出长度短、或已经生成了大部分内容的请求。
   • 优点：可以显著提升系统整体吞吐量（Throughput），因为GPU更频繁地完成请求并释放资源，单位时间内处理的请求数更多。
   • 缺点：牺牲了公平性。一个晚到达的短请求可能会“插队”到一个早到达的长请求前面，导致长请求的延迟变得不可预测，甚至饿死（Starvation）。

实操心得：选择哪种策略，取决于你的服务SLA（服务等级协议）。如果强调公平性和每个请求的可预测延迟（如对话API），FCFS更合适。如果追求在固定资源下服务尽可能多的请求（如离线批量处理任务），吞吐量优先策略更好。在实际生产环境中，可以对不同优先级的请求使用不同的队列，实现混合调度。

4.2 关键配置参数详解

启动vLLM服务时，以下参数直接影响Scheduler的行为和性能：

• --max-num-batched-tokens

  • 这是最重要的参数之一。它限制了单次前向传播中，所有参与请求的token总数上限。这包括所有请求的输入token和本轮要生成的新token。
  • 如何设置：这个值需要小于你的GPU内存能承受的最大值。设置得太小，会限制并行度，GPU利用率不足；设置得太大，可能导致OOM（内存溢出）。一个经验法则是，根据你的模型大小和显存，通过压测找到一个稳定运行的峰值。例如，对于7B模型在24G显存的GPU上，可以尝试设置为2048或4096。
  • 与batch size的关系：它动态决定了每一刻的实际“批次大小”。例如，该值设为1000，如果当前有5个请求，每个请求本轮需处理200个token，那么它们可以组成一个批次。如果来了一个需要处理600个token的大请求，它可能就得独自占一个批次，或者等待其他请求结束。

• --max-num-seqs

  • 限制同时处于运行状态（即在批次中）的最大请求数量。
  • 这是防止调度器过度调度、导致每个请求分到的计算资源过少的保护性参数。通常可以设置为比max-num-batched-tokens / 平均序列长度稍大的值。

• --block-size(PagedAttention相关)

  • 定义KV缓存中每个“块”（Block）能容纳的token数量。默认是16。
  • 调优建议：较小的块（如8）内存利用率更高，但管理开销（块表）会增大。较大的块（如32）管理开销小，但对于短请求可能造成块内碎片。通常16是一个较好的平衡点，除非你有非常特殊的长度分布。

• --gpu-memory-utilization

  • 目标GPU内存利用率，默认0.9（90%）。vLLM会尝试将KV缓存等内存使用维持在这个水位线以下。
  • 不建议设置为1.0，需要为模型权重、激活值等留出余量。

4.3 一个典型的服务启动与监控示例

# 启动一个vLLM API服务，使用FCFS调度策略 python -m vllm.entrypoints.api_server \ --model meta-llama/Llama-3.2-3B-Instruct \ --tensor-parallel-size 1 \ --max-num-batched-tokens 2048 \ --max-num-seqs 64 \ --scheduler-policy fcfs \ --block-size 16 \ --gpu-memory-utilization 0.9 \ --served-model-name llama-3.2-3b

服务启动后，监控其日志和性能指标至关重要：

• 吞吐量（Tokens/s, Requests/s）：这是衡量效率的核心。
• 延迟（Time to First Token, Time per Output Token）：特别是TTFT，影响用户体验。
• 批次大小变化：观察current_batch_size如何动态波动，这直接反映了Continuous Batching的工作状态。
• GPU利用率与显存使用：使用nvidia-smi或更细致的nvtop查看，目标是在高吞吐的同时保持高利用率（>70%）和稳定的显存占用。

5. 性能对比与场景化选型指南

理论很美好，但实际效果如何？我们通过一组对比数据来直观感受Continuous Batching带来的变革性影响，并探讨不同场景下的技术选型。

5.1 性能量化对比：Continuous Batching vs. Static Batching

假设场景：使用单张A100（80GB）GPU服务Llama-3.2-3B模型，请求流符合泊松分布，输入输出长度混合（短：输入50/输出20，长：输入500/输出200）。

结果解读：Continuous Batching不仅在峰值吞吐量上实现了数倍提升，更重要的是，它极大地改善了延迟分布，特别是对用户体验至关重要的尾部延迟。同时，它让昂贵的GPU硬件从“间歇性忙碌”变为“持续饱和工作”，直接降低了单位请求的服务成本。

5.2 不同服务场景下的架构选型

Continuous Batching并非银弹，它的价值在不同场景下有所差异。

1. 高并发在线API服务（如ChatGPT接口）

   • 特点：请求随机到达，对首次token延迟（TTFT）和整体响应延迟极其敏感，流量有潮汐现象。
   • 选型：Continuous Batching是绝对首选。vLLM、TGI（Text Generation Inference）等框架是标准方案。应优先选用FCFS调度策略以保证公平性，并设置合理的max-num-batched-tokens以避免长请求垄断资源。同时，需要配合请求排队与超时机制，在过载时优雅降级。

2. 离线批量推理任务（如对百万文档进行摘要）

   • 特点：所有任务已知，对单个任务延迟不敏感，追求在最短时间内处理完所有任务（总完成时间）。
   • 选型：Continuous Batching依然有效，但可以更激进。可以采用Maximal Throughput调度策略，并适当增大max-num-batched-tokens，让GPU满负荷运转。甚至可以按任务长度排序（短任务优先），进一步压缩总完成时间。此时，vLLM的吞吐量优势将完全转化为成本优势。

3. 低延迟、交互式应用（如实时翻译、代码补全）

   • 特点：请求频率可能不高，但要求毫秒级响应，且输入是流式的（如打字过程中的连续补全）。
   • 选型：Continuous Batching仍有价值，但挑战在于极致的TTFT。需要优化调度器，让新请求能够几乎无等待地插入当前批次。此外，需要框架支持流式输出和中间结果返回。vLLM在此场景下表现优异，因为它能快速调度新请求并流式返回每个token。

4. 混合负载场景（同时有在线和离线任务）

   • 特点：需要同时满足在线API的低延迟和离线任务的高吞吐。
   • 选型：这是最复杂的场景。可以考虑分级调度或资源隔离。
     • 方案A（队列隔离）：部署两个独立的服务实例，一个配置为低延迟模式（小max-num-batched-tokens， FCFS）服务在线请求，另一个配置为高吞吐模式处理离线队列。
     • 方案B（优先级队列）：使用一个vLLM实例，但实现自定义调度器，为在线请求分配更高优先级，使其能抢占资源。这需要更深入的定制开发。

5.3 与其他优化技术的协同

Continuous Batching是LLM服务优化的核心，但不是全部。它需要与其他技术协同工作：

• 量化（Quantization）：将模型权重从FP16/BF16转换为INT8/INT4，能直接减少显存占用和内存带宽压力，使得在相同资源下，Continuous Batching能调度更多的请求。vLLM支持GPTQ、AWQ等量化方案。
• FlashAttention：优化注意力计算本身，降低计算开销和显存占用。更快的核心计算意味着调度器每轮迭代时间更短，整体吞吐更高。vLLM已集成。
• 张量并行（Tensor Parallelism）：对于超大模型（>70B），单卡放不下，需要多卡并行。Continuous Batching的调度器需要感知多卡间的通信，协调各卡上的微批次执行。vLLM支持此功能。
• 推测解码（Speculative Decoding）：用一个“小模型”先草拟多个token，再由“大模型”快速验证。这改变了生成token的粒度，需要调度器与之适配。这是前沿优化方向。

注意事项：引入任何新技术时，都要评估其与动态调度器的兼容性。例如，某些激进的显存优化可能会干扰PagedAttention的块管理逻辑。在生产环境部署前，务必进行充分的集成测试和压力测试。

6. 常见问题、排查技巧与实战心得

即使理解了原理，在实际部署和运维vLLM服务时，你依然会遇到各种问题。以下是我在实战中积累的一些常见问题排查技巧和经验心得。

6.1 性能调优问题排查清单

当你的vLLM服务吞吐量不达预期或延迟过高时，可以按照以下清单进行排查：

6.2 高级技巧与实战心得

1. 预热（Warming Up）：在流量洪峰到来前，向服务发送一些预热请求，让模型完成初始加载，并使调度器进入稳定状态。这能避免第一个真实请求遭遇“冷启动”的高延迟。
2. 动态参数调整：可以考虑根据实时监控的队列长度和GPU利用率，动态微调max-num-batched-tokens。例如，当等待队列很长时，适当调大该值以提升吞吐；当队列空时，调小该值以优化延迟。
3. 理解“计算边界”与“内存边界”：LLM推理可能受限于计算速度（Compute-Bound）或内存带宽（Memory-Bound）。对于较小的模型（如7B），在A100上通常是内存带宽受限。此时，Continuous Batching通过提高计算密度（让更多请求共享一次内存加载的数据）来提升效率，效果尤为明显。对于超大模型，可能转为计算受限。
4. 日志与指标收集：务必详细记录每个请求的生命周期事件（入队时间、开始计算时间、结束时间）以及系统的批次统计信息。这些数据是分析性能瓶颈、调整调度策略的黄金依据。可以集成Prometheus和Grafana进行可视化。
5. 测试一定要用真实分布：性能测试时，请求的长度分布必须模拟真实场景。如果只用固定长度的请求测试，会严重高估Continuous Batching的收益。使用一个符合你业务场景的长尾分布进行压测，结果才可信。

最后，我想分享一个最深的体会：Continuous Batching的成功应用，标志着LLM服务从“模型为中心”转向了“服务与效率为中心”。早期我们只关心模型精度，后来关心推理速度，现在我们必须关注在动态、不可预测的负载下，如何让整个系统高效、稳定、经济地运转。vLLM Scheduler及其背后的Continuous Batching思想，正是这个新时代的基石。它不是一个可选的优化项，而是构建生产级LLM应用必须掌握的底层逻辑。当你下次看到服务吞吐量翻了几倍而成本大幅下降时，你会明白，这一切都源于那个让请求像流水一样动起来的精巧设计。