vLLM 连续批处理下的显存与吞吐取舍

vLLM 连续批处理的核心取舍不是“并发越高越快”，而是让调度器在显存能承受的范围内持续填充请求。实际配置应同时限制序列数和批次 token 数：先给模型权重与运行时留出余量，再逐级增加并发，观察吞吐、首 token 延迟（TTFT）、单 token 延迟（ITL）和显存峰值。只看一个 tokens/s 数字，很容易把排队延迟和 OOM 风险藏起来。

官方地址：https://docs.vllm.ai/

先把显存预算拆成权重、KV Cache 与运行余量

启动时，显存首先要容纳模型权重；请求进入后，prompt 和已生成 token 的 KV Cache 会随序列数、上下文长度和输出长度增长。vLLM 用 PagedAttention 管理 KV Cache block，能减少连续内存分配带来的浪费，但它不会让显存变大。调高显存利用率只是在实例预算中给执行器更多空间，仍然需要为 CUDA 工作区、通信和波动留下余量。

排查显存问题时先区分三种现象：服务启动就失败，通常是权重或并行配置不够；运行一段时间后 OOM，重点看 KV Cache 与最大上下文；显存没有打满但延迟上升，则可能是批次 token 预算、CPU 调度或请求排队造成的。不要看到显存还有几百 MiB 就直接把并发翻倍。

用序列数与批次 token 数共同限制连续批处理

max-num-seqs 限制同一批最多容纳多少条请求，适合控制并发数量；max-num-batched-tokens 限制一次调度可处理的 token 总量，适合防止长 prompt 把短请求挤出调度窗口。两者取更严格的那个边界：即使序列数没有达到上限，只要 token 预算耗尽，也不能继续塞入请求。

# 先用保守值启动，再按压测结果逐级上调并发
vllm serve Qwen/Qwen3-8B \
  --gpu-memory-utilization 0.88 \
  --max-model-len 8192 \
  --max-num-seqs 16 \
  --max-num-batched-tokens 4096 \
  --enable-chunked-prefill
# 长 prompt 触发 OOM 时，优先降低 token 预算或上下文上限
# 不要只提高 gpu-memory-utilization 来掩盖 KV Cache 不足

短请求占比高时，可以先提高序列数；长 prompt 或输出较长时，先控制 token 预算更稳。V1 调度器可以把 prefill 和 decode 放在同一调度步骤中，但它们的压力不同：prefill 更偏计算，decode 更依赖显存带宽和 KV Cache。参数改变后必须用与线上相近的输入长度分布复测。

用分阶段压测找到吞吐拐点

压测不要直接把并发拉到很大。固定模型、采样参数、输入长度分布和输出长度分布，按 1、2、4、8、16、32 的阶梯增加并发，每档等待服务稳定后记录总吞吐、TTFT、ITL、p95 延迟和显存峰值。vLLM 官方 CLI 提供 vllm bench serve 进行在线服务吞吐测试；离线批量场景则使用 vllm bench throughput。

# 用固定随机长度比较不同并发档位，避免只凭主观感受调参
vllm bench serve \
  --model Qwen/Qwen3-8B \
  --host 127.0.0.1 --port 8000 \
  --random-input-len 1024 \
  --random-output-len 256 \
  --num-prompts 128 \
  --request-rate 8
# 每次只改变一个变量，并记录 p95 TTFT、ITL 与 GPU 显存峰值

当并发继续增加而总吞吐增长很小、p95 延迟陡升或出现 preemption 时，就到达当前硬件和输入分布的拐点。生产值应选在拐点左侧，而不是选最高 tokens/s 的档位；如果 SLA 要求首 token 快，通常还要给 decode 请求保留调度预算。

生产配置要保留降级路径

建议把“正常档”和“保护档”作为两份可回滚配置。突发长 prompt 时，先限制入口的最大输入 token 或降低 max-num-batched-tokens；KV Cache 压力持续时，再考虑启用更低精度的 KV Cache 数据类型，但要对输出质量和兼容性做单独验证。chunked prefill 能把长 prompt 拆成更小的调度片段，不能替代请求限流。

上线清单至少记录：触发 OOM 或 p95 超阈值的指标、先调哪个参数、回退到哪组值、如何恢复正常档。这样显存与吞吐的取舍才是可运营的配置，而不是一次性的启动命令。

相关问题

显存利用率调到 0.95 就一定更快吗？

不一定。它可能增加 KV Cache 空间，但也减少运行时余量，导致峰值波动时 OOM；只有在压测确认余量足够时才值得上调。

应该优先提高 max-num-seqs 还是 max-num-batched-tokens？

短请求密集时优先观察序列数，长 prompt 或长输出时优先控制 token 总量；最终以 TTFT、ITL、p95 和显存峰值共同决定。

为什么并发提高后 tokens/s 不再增长？

常见原因是显存带宽、KV Cache block、CPU 调度或输入长度分布已经成为瓶颈。降低并发并观察延迟曲线，通常比继续堆参数更容易定位问题。