报错是这么冒出来的。vLLM 0.6.4 部署 7B 模型，把 --block-size 从 16 改成 32 后显存占用多了 2GB，吞吐没有变化，启动日志里 KV cache 的 block 数反而变少。
中间走过弯路，把「前缀缓存按 block 对齐，块大导致命中粒度变粗」当成主因，改完现象没变。
这类报错背后常见的原因有几处，逐个排除就行。block 变大后每条序列尾部浪费的空间变多。另一种情况是短请求居多时大 block 的利用率低。
还有一种情况，改完没有重启，读到的还是旧进程的参数。
第一件事是确认当前进程的真实参数
ps -ef | grep block-size随后改回 16 并重启服务
python -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2.5-7B-Instruct --block-size 16再往下看启动日志里的 KV cache 块数
grep -i kv_cache vllm.log等前面都确认过，再用相同请求对比显存与吞吐
python bench.py --concurrency 16 --requests 200别只看报错消失，验证要多做一步。显存回到改动前的数值，KV cache 块数增加，P99 延迟不高于改动前。
提醒一点。block_size 影响的是显存碎片与前缀命中粒度，短请求场景保持默认 16 就行，别为了吞吐盲目加大。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。