当前位置：首页 > 文章列表 > 科技周边 > 人工智能 > vLLM 连续批处理下的显存与吞吐取舍

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

来源：17golang原创 2026-10-10 23:38:59 0浏览收藏

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

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

要点速览

gpu-memory-utilization 是每个 vLLM 实例可使用的显存比例，不等于安全的 KV Cache 容量。
max-num-seqs 控制请求条数，max-num-batched-tokens 控制一次调度的 token 总预算，两者必须一起调。
生产环境以延迟预算为门槛，用并发阶梯压测找拐点，并保留长 prompt 和突发流量的回退配置。

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

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

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

vLLM 连续批处理的模型权重、KV Cache、运行余量与显存上限结构说明图 — 图1：vLLM 显存预算说明图，展示模型权重、KV Cache 与运行余量的边界关系。

用序列数与批次 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。参数改变后必须用与线上相近的输入长度分布复测。

vLLM 连续批处理按序列数与 token 总预算调度 prefill 和 decode 的结构说明图 — 图2：连续批处理调度说明图，展示序列数上限与 token 总预算如何共同约束 prefill、decode。

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

压测不要直接把并发拉到很大。固定模型、采样参数、输入长度分布和输出长度分布，按 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 超阈值的指标、先调哪个参数、回退到哪组值、如何恢复正常档。这样显存与吞吐的取舍才是可运营的配置，而不是一次性的启动命令。