现场是这样的。把 vLLM 0.6 服务的新权重发布到灰度组，承接 10% 流量，平均延迟只涨了 8%，P99 从 1.2 秒涨到 2.9 秒，业务侧超时率随之抬升，旧版同时段没有变化。
中间走过弯路，把「新权重 tokenizer 变了，输出长度整体变长」当成主因，改完现象没变。
这类报错背后常见的原因有几处，逐个排除就行。新版默认开了更大的 max_num_seqs，排队变长；灰度组的 gpu_memory_utilization 比生产低，KV 缓存不够；灰度实例数少，单实例承载的并发更高。
拉两组的排队与 KV 使用率
curl -s http://vllm-gray:8000/metrics | grep -E 'num_requests_waiting|gpu_cache_usage_perc'然后按 P99 而不是均值做对比
python -c "print({'old_p99':1.2,'new_p99':2.9,'delta':1.7})"接着对齐显存比例后再压一轮
python -c "print({'gpu_memory_utilization':0.90,'max_num_seqs':128})"末了扩大灰度实例数摊平并发
kubectl scale deploy vllm-gray --replicas=3 -n llm那几天正好在做别的变更，先把时间线对齐才敢动手。
别只看报错消失，验证要多做一步。两组在同一并发下 P99 差距小于 15%，超时率回到基线，排队数长时间为零。
提醒一点。看均值会放过 P99 问题，灰度对比必须同并发同显存配置，否则差异都来自参数而不是模型。这类问题最好一次改到位，反复小改反而容易把原因搅混。