批处理策略优化：动态批处理、连续批处理与最大批大小调整
核心原理：从“静态等待”到“动态拼车”
在vLLM的推理服务中，GPU的算力利用率与请求的到达模式之间存在天然矛盾。若每个请求单独占用一次前向传播，GPU的矩阵运算单元将大量空闲；若强制等待固定数量的请求凑齐后再推理，又会引入不可接受的排队延迟。批处理策略的本质，是在“吞吐量”与“单请求延迟”之间寻找动态平衡点。
传统静态批处理（Static Batching）要求请求必须凑满一个固定batch size才能开始推理，这会导致两个问题：一是当请求稀疏时，GPU空转等待；二是当请求突发时，队列瞬间积压。vLLM引入的连续批处理（Continuous Batching）则完全不同——它不再等待整个batch完成，而是将推理过程拆解为多个迭代步骤，每个迭代结束后，已完成生成的序列立即退出，新到达的请求立刻插入空位参与下一轮迭代。这种机制让GPU始终处于“满载拼车”状态，而非“等满一车才发车”。
动态批处理（Dynamic Batching）则是在请求调度层面对连续批处理的补充。它根据当前队列长度、GPU显存余量、每个请求的预估长度，动态决定下一轮迭代纳入多少请求、以何种顺序纳入。两者结合，构成了vLLM吞吐优化的核心调度引擎。
方法流程：vLLM批处理参数配置与调优路径
vLLM的批处理行为由引擎参数和调度策略共同控制。以下是最核心的配置项及其作用域：
| 参数/配置 | 作用层级 | 典型值 | 影响维度 |
|---|---|---|---|
--max-num-batched-tokens |
引擎级 | 4096 ~ 8192 | 单次迭代最大token处理量，限制显存占用 |
--max-num-seqs |
引擎级 | 64 ~ 256 | 单次迭代最大序列数，即最大批大小 |
--max-paddings |
引擎级 | 256 | 允许的padding token数，影响计算效率 |
--scheduling-policy |
调度级 | fcfs / lof | 请求选择策略：先来先服务或最长等待优先 |
--enable-prefix-caching |
缓存级 | true/false | 复用公共前缀的KV cache，减少重复计算 |
调优路径建议遵循以下步骤：
- 基准测量：在默认参数下运行代表性负载，记录GPU利用率、P99延迟、吞吐量（tokens/s）。
- 逐步增大
--max-num-seqs：观察GPU利用率变化。若利用率低于85%，可继续增大；若出现显存溢出（OOM），则回退至安全值。 - 调整
--max-num-batched-tokens：该值应约为max-num-seqs × 平均序列长度。设置过小会限制长序列的批处理能力，设置过大会浪费显存预留。 - 启用前缀缓存：若业务中存在大量共享系统提示词（如ChatML模板、RAG上下文），开启
--enable-prefix-caching可显著降低TTFT。 - 压测验证：使用真实流量回放或合成负载工具（如
vllm-bench）验证调整效果，关注P99而非平均值。
案例实战：某智能客服系统的批处理调优
某金融企业部署了基于vLLM的智能客服模型（7B参数，A10 GPU × 4），业务特征为：请求长度差异极大（最短20 tokens，最长2000 tokens），峰值QPS约80，要求P99延迟低于2秒。
初始配置与问题：
python -m vllm.entrypoints.openai.api_server \
--model /models/chat-7b \
--tensor-parallel-size 4 \
--max-num-seqs 32 \
--max-num-batched-tokens 4096 \
--gpu-memory-utilization 0.90压测发现：GPU利用率仅55%，P99延迟达到3.2秒，吞吐量约850 tokens/s。分析日志发现，由于max-num-seqs=32限制，当长序列请求占据批处理槽位时，短请求被迫排队等待；而短请求完成后，长请求仍在生成，导致批大小逐渐缩小，GPU算力浪费。
优化措施：
- 将
--max-num-seqs提升至128，允许更多短请求与长请求交错执行。 - 将
--max-num-batched-tokens提升至8192，确保长序列不会因token上限被截断出批。 - 开启
--enable-prefix-caching，因为所有请求共享相同的系统提示词（约150 tokens）。 - 设置
--scheduling-policy lof（最长等待优先），避免短请求持续插队导致长请求饥饿。
优化后效果：
| 指标 | 优化前 | 优化后 | 提升幅度 |
|---|---|---|---|
| GPU利用率 | 55% | 92% | +67% |
| P99延迟 | 3.2s | 1.4s | -56% |
| 吞吐量 | 850 tok/s | 2100 tok/s | +147% |
| 批大小均值 | 18 | 76 | +322% |
max-num-seqs 比增大 max-num-batched-tokens 更有效。前者增加的是“并行序列数”，后者增加的是“单序列可占用的token预算”。两者需要配合调整，避免出现“批很大但token预算不足”的尴尬局面。
误区与复盘：批处理调优的常见陷阱
误区一：盲目追求最大批大小。将 max-num-seqs 设置得过大（如512），会导致KV cache显存占用激增，反而限制了模型上下文长度。当批大小超过一定阈值后，GPU计算效率提升趋缓，但显存压力线性增长。复盘建议：以GPU利用率85%~95%为基准，而非单纯追求批大小数值。
误区二：忽略请求长度分布。若业务以短请求为主（如代码补全），过大的 max-num-batched-tokens 会导致显存预留浪费；若以长文档摘要为主，该值过小则会导致长请求频繁被截断重排。正确做法是统计业务请求长度的P50/P95值，据此设定token预算。
误区三：静态配置应对所有流量。vLLM的批处理参数是静态的，但生产流量往往存在昼夜波动。建议结合Kubernetes HPA（水平Pod自动伸缩）与vLLM的 --max-parallel-loading-workers 参数，在流量低谷时降低副本数，高峰时增加副本，而非让单个实例始终运行在极限批大小。
CUDA out of memory 异常导致服务中断。建议在配置文件中设置 --gpu-memory-utilization 0.85 作为安全余量，而非默认的0.90。
复盘总结：批处理优化的核心不在于“调大某个参数”，而在于理解请求到达模式、序列长度分布与GPU计算特性之间的匹配关系。连续批处理提供了动态调度的基础设施，动态批处理策略决定了每轮迭代的请求组合质量，而最大批大小则是保障系统稳定性的最后防线。三者协同，才能实现吞吐量与延迟的双重优化。