问题出现得很突然，日志倒是留得挺全。vLLM 0.6.3 在 48G 的 L20 上跑 Qwen2.5-32B-AWQ，max-model-len 8192，max-num-seqs 设 256，启动报 No available memory for the cache blocks。
刚开始盯着「AWQ 反量化缓冲在启动时额外占用」，折腾了半个多小时，排掉了。
真正麻烦的地方在于，几个原因的现象几乎一样。并发序列数乘上下文长度后 KV 需求超过剩余显存。另一种情况是gpu_memory_utilization 设得过高，权重加载后没有余量。
另外，max-model-len 按模型上限给，实际请求远小于此。
动手时先看启动日志里的 KV 块数
python -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2.5-32B-AWQ --max-model-len 8192 --max-num-seqs 64 2>&1 | grep -i 'kv cache'降并发并留出显存余量
python -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2.5-32B-AWQ --max-model-len 8192 --max-num-seqs 32 --gpu-memory-utilization 0.90压测找吞吐拐点
python bench.py --url http://localhost:8000/v1/completions --concurrency 32 --num-prompts 200末了看运行时的缓存使用率
curl -s localhost:8000/metrics | grep -i 'gpu_cache_usage'改之前先确认了最近有没有人动过配置，避免白查一遍。
这次没动代码，只在配置和运行环境上找原因。
隔了一天再看，现象没变，说明不是偶发。
改完先别撤，确认这几项。服务能稳定启动，32 并发下无 OOM，吞吐比 16 并发高 40% 以上。
这里还有个坑。max_num_seqs 是显存预算的上限而不是目标，先按 KV 块数反推，再拿压测定值。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。