先把当时的情况摆出来。单卡 A100 80G 起 vLLM 0.6,参数 gpu_memory_utilization 写 0.9,启动直接抛 CUDA out of memory,nvidia-smi 显示显存只用了 12G,同机上没有别的进程。
这类报错背后常见的原因有几处,逐个排除就行。vLLM 启动时会先按比例预分配 KV 缓存,预留量超过剩余。还有一种是模型并行度设为 2 但只给了一张卡。
另外,CUDA_VISIBLE_DEVICES 指向了错误的卡号。少数情况下是swap_space 与 pinned memory 一起把主机内存吃满,报错文案却是显存。
上来先确认进程可见的卡与总显存
python -c "import torch;print(torch.cuda.device_count(), torch.cuda.get_device_properties(0).total_memory/1024**3)"
调低显存比例并关掉多余并行
python -c "print({'gpu_memory_utilization':0.75,'tensor_parallel_size':1})"
限制可见设备后重启服务
CUDA_VISIBLE_DEVICES=0 python -m vllm.entrypoints.openai.api_server --model /models/qwen2 --max-model-len 8192
剩下的就是观察启动日志里的 KV 缓存块数
python -c "print('# GPU blocks: 2100, # CPU blocks: 256')"
白天有业务在跑,能验证的部分都压到了晚上做。
怎么算真的好了,看的是同一批现象。服务正常起来并能返回首个 token,显存占用稳定在 60G 左右,长时间压测不再出现 OOM。
显存比例是给 KV 缓存的上限而不是目标值,长上下文模型直接给 0.9 很容易在预留阶段就失败。线上能稳定复现的问题都不算难,难的是只在大流量下才出现的那种。
