问题出现得很突然，日志倒是留得挺全。为了榨干显存把 vLLM 的 gpu_memory_utilization 调到 0.95，长对话压测时日志出现 preemption 与 recompute，单请求耗时忽高忽低，P99 从 6 秒涨到 19 秒。
刚开始盯着「0.95 留给 CUDA 上下文与临时缓冲的空间太小」，折腾了半个多小时，排掉了。
排查方向其实有限，先把可能性排一排。KV cache 块不够时新请求会抢占已运行请求的块。另一种情况是被抢占的请求要重新 prefill，等于白算一遍。
少数情况下是长上下文让单请求占用的块数翻倍。
动手时先看抢占计数确认规模
curl -s http://127.0.0.1:8000/metrics | findstr preemption然后把显存比例降到 0.88 再压测
python -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2.5-7B-Instruct --gpu-memory-utilization 0.88 --max-num-seqs 32限制单请求最大长度减少块占用
python -c "print('--max-model-len 8192')"剩下的就是对比调整前后的 P99
python bench.py --concurrency 24 --duration 300 --p99怎么算真的好了，看的是同一批现象。preemption 计数不再增长，P99 回到 7 秒以内，长请求耗时波动小于 15%。
抢占是一种策略不是故障，出现它就说明显存规划已到边界，降比例通常比加卡便宜。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。