连续批处理Continuous Batching技术原理与vLLM推理引擎吞吐量优化实战

连续批处理Continuous Batching核心机制解析

连续批处理（Continuous Batching）是vLLM、TGI等大模型推理引擎实现高吞吐量的核心技术。传统静态批处理在推理过程中无法动态调整批次，导致GPU利用率低至30%以下。Continuous Batching通过迭代级调度（iteration-level scheduling）在每个推理步骤完成后立即插入新请求或移除已完成的请求，将GPU利用率提升至80%以上。

大模型推理引擎的吞吐量瓶颈不在计算本身，而在于批处理调度策略。vLLM通过Continuous Batching配合PagedAttention分页注意力机制，实现了显存碎片率低于4%的内存管理，使得同一GPU上可并发处理的请求数量提升3-5倍。

传统静态批处理与连续批处理差异对比

静态批处理的工作方式是：收集一批请求，统一送入模型推理，等待所有请求生成完毕后返回结果。问题在于不同请求的生成长度差异很大——一个10 token的短回答和一个500 token的长回答放在同一批次中，短回答生成完成后GPU处于空转状态，等待长回答完成。

Continuous Batching的做法截然不同。在每个解码步骤（decoding step）之后，引擎检查哪些请求已完成生成，将其移出批次，同时将等待队列中的新请求插入当前批次。这种动态调度使得GPU在每个步骤都在处理满负载的batch，消除了等待造成的浪费。

以vLLM的实现为例，调度器维护一个waiting队列和一个running队列。每个decode iteration结束后：

# vLLM调度器伪代码
while True:
    # 1. 执行当前running队列的forward pass
    outputs = model.forward(running_batch)
    
    # 2. 检查已完成请求
    for req in running_batch:
        if req.is_finished():
            running_batch.remove(req)
            results.append(req.output)
    
    # 3. 尝试从waiting队列补充新请求
    while waiting_queue and can_schedule():
        new_req = waiting_queue.pop()
        running_batch.add(new_req)
    
    # 4. 无请求时退出
    if not running_batch and not waiting_queue:
        break

关键在于can_schedule()的判断逻辑：vLLM通过PagedAttention机制精确追踪每个请求占用的KV Cache block，只有当剩余block数足够容纳新请求的最大序列长度时才允许调度。这种基于物理block的内存管理方式避免了传统预分配方案中约60%的显存浪费。

vLLM中Continuous Batching的配置与部署

vLLM提供了多个参数控制Continuous Batching的行为，合理配置这些参数直接影响推理吞吐量和延迟。以下是关键配置项：

from vllm import LLM, SamplingParams

llm = LLM(
    model="meta-llama/Llama-3-70B",
    # 最大batch size，控制并发请求数量
    max_num_seqs=256,
    # 最大序列长度，影响KV Cache预分配
    max_model_len=4096,
    # GPU内存利用率上限，默认0.9
    gpu_memory_utilization=0.9,
    # tensor并行度，多GPU场景下使用
    tensor_parallel_size=4,
    # 是否启用预填充与解码分离
    enable_chunked_prefill=True,
    # chunked prefill的最大token数
    max_num_batched_tokens=2048,
)

max_num_seqs是最核心的参数。设置过小无法充分利用GPU并行能力，设置过大则可能导致显存不足触发OOM。推荐的初始值为GPU显存除以单个请求平均KV Cache占用量的80%。

enable_chunked_prefill是vLLM 0.4.x引入的特性，允许将长prompt的prefill阶段拆分为多个chunk，与decode阶段交错执行。这解决了长prompt请求阻塞短请求的问题。启用后，一个4096 token的prefill可以拆分为4个1024 token的chunk，每个chunk执行完毕后插入一轮decode，确保已生成的请求不会因新请求的长prefill而卡顿。

吞吐量与延迟的量化评估方法

部署Continuous Batching后需要量化评估效果。vLLM提供了内置的benchmark工具，可以从吞吐量（tokens/s）、首token延迟（TTFT）、端到端延迟三个维度评估：

# 启动benchmark
python -m vllm.entrypoints.openai.api_server     --model meta-llama/Llama-3-70B     --max-num-seqs 256     --gpu-memory-utilization 0.9     --tensor-parallel-size 4     --port 8000

# 使用benchmark脚本测试
python benchmarks/benchmark_serving.py     --backend vllm     --base-url http://localhost:8000     --model meta-llama/Llama-3-70B     --num-prompts 1000     --request-rate 20

benchmark结果中关注几个关键指标：successful requests数量（应等于num-prompts），throughput（tokens/s，越高越好），mean TTFT（首token平均延迟，影响用户体验），mean ITL（inter-token latency，流式生成时每个token的间隔）。在实际部署中，A100 80GB GPU运行Llama-3-70B模型，max_num_seqs设置为128时，吞吐量可达约2000 tokens/s，TTFT控制在200ms以内。

生产环境的常见问题与排查

OOM（显存不足）是最常见的问题。排查方法：首先降低max_num_seqs到64甚至32，确认是否能正常运行。如果仍OOM，检查gpu_memory_utilization是否设置过高（某些场景下0.9会导致与CUDA context竞争），调低到0.85。使用nvidia-smi监控显存使用，如果空闲显存不足10%但模型已加载完成，说明KV Cache block分配过大，调低max_model_len。

首token延迟过高通常由长prompt的prefill阶段引起。解决方案：启用chunked prefill，将max_num_batched_tokens设置为1024-2048。另外检查GPU是否启用了flash attention，vLLM默认启用FlashAttention-2，但如果安装不正确可能回退到naive attention，导致prefill速度下降5倍以上。

吞吐量不达预期时，通过vLLM的–enforce-eager参数排查是否因CUDA Graph未启用导致。默认情况下vLLM使用CUDA Graph优化decode阶段，减少kernel launch开销约40%。如果强制eager模式后性能大幅下降，说明CUDA Graph优化生效正常，需要检查其他瓶颈点。