gpu_memory_utilization 是 vLLM 启动时用来指定显存使用上限的参数，它并不直接定义并发批处理大小，而是通过限制 KV cache 的可用空间，间接影响动态批次能容纳的请求数和 token 总量。调整这个参数前，需要先理解 vLLM 的 continuous batching 机制，否则容易遇到启动报错或显存浪费。
这个参数决定 KV cache 分配上限，进而影响并发批处理容量。调得过高可能引发显存溢出，调得过低会压低吞吐。配置时应结合模型参数量、max_num_seqs 和 max_model_len 一起验证，不能单独下调。观察启动日志和运行期显存占用，是确认参数是否合理的可靠方式。
参数如何影响并发批处理
vLLM 在处理请求时，会将多个请求的 token 拼成一个动态批次，每个请求的 token 数会被同步推进，但是批次中累计的 token 数受 KV cache 空间限制。gpu_memory_utilization 设置的比例决定了预留多少显存给 KV cache，以及运行时其他缓冲区。模型权重加载后，剩余显存越多，KV cache 就越大，单个批次能容纳的序列数和总 token 数也越多。
batch 大小并不是由该参数直接指定的，而是根据当前请求长度动态计算。同一个参数配置下，短请求和长请求表现会完全不同。短请求可以容纳更多并发序列，而长请求会更快占满 KV cache。所以这里不存在一个固定的并发批处理大小。
与 max_num_seqs 和 max_model_len 的关系
max_num_seqs 是显式限制并发序列数量的上限，max_model_len 是单个请求允许的最大 token 长度。gpu_memory_utilization 则是显存预算，它通过 KV cache 总容量进一步约束实际可并发处理的 token 总量。这三个参数会相互制约：即使 max_num_seqs 设得很大，如果 KV cache 不够，实际并发仍会被卡住；反过来，如果 KV cache 充足，但 max_num_seqs 设得小，并发也会被限制。
所以在调整 gpu_memory_utilization 时，需要同时检查 max_num_seqs 和 max_model_len 是否匹配。例如，当调大 gpu_memory_utilization 后，启动日志显示 KV cache 变大，但 max_num_seqs 仍是最初的小值，那么并发瓶颈可能仍在 max_num_seqs 上。
过载保护的边界
过载保护在这里指的是：当动态批次中的 token 数接近 KV cache 上限时，vLLM 会停止向当前批次添加新请求，新请求进入等待队列，直到有空间释放。这样能防止已有请求因显存不足而中断。但这并不代表 gpu_memory_utilization 越大安全性越高。
该参数只是显存分配的预算，不承担防 OOM 的责任。如果设置过高，比如接近 1.0，模型权重加载后没有足够余量给 KV cache 或激活，可能在启动阶段就报错，也可能在运行中遇到临时峰值而 OOM。因此，过载保护的真实能力来自这个参数与物理显存之间的差值，以及 vLLM 调度器对批次空间的判断。
配置建议与验证方法
通常建议先设置 0.85 作为起点，如果模型权重本身占用较大，可以调低到 0.8 附近；如果显存容量远大于权重，且请求以短文本为主，可以尝试 0.9 左右。不要直接设置 0.95 以上，因为在多线程和碎片化场景下容易触发显存分配失败。
下面是一个以 OpenAI 兼容服务方式启动 vLLM 的通用示例，实际路径和参数以当前使用版本为准：
python -m vllm.entrypoints.openai.api_server `--model` /path/to/model `--gpu-memory-utilization` 0.85 `--max-num-seqs` 128 `--max-model-len` 4096调整后可以通过以下方式验证：
- 启动日志：查看 KV cache 分配大小和剩余显存信息，确认没有异常警告。
- 运行期监控：使用 nvidia-smi 观察显存占用是否长期接近物理上限。
- 压测对比：用一组请求样本，改变参数后观察吞吐和排队延迟，注意不是跑一轮就下结论。
- 故障注入：提高并发数，确认是否出现 CUDA out of memory，如果有就降低参数或收紧 max_num_seqs。
由于每台机器的 GPU 型号、驱动、模型结构和请求长度分布都不一样，以上建议只能作为起点，最终参数需要结合当前环境的实际日志和监控指标来调整。
常见问题
gpu_memory_utilization 设高为什么还会 OOM？
因为该参数只定义分配预算，不保证物理显存充足。如果模型权重和其他进程已经占用较多显存，即使比例低于 100%，KV cache 分配仍可能失败。另外，显存碎片化也可能导致实际可用空间小于预算。
这个参数与 max_num_seqs 有什么区别？
gpu_memory_utilization 控制显存预算，决定 KV cache 能有多大；max_num_seqs 是并发序列的数量上限。前者是隐性约束，后者是显式硬限制。两者都限制并发，但调节方式不同，需要配合使用。