把推理服务从 vLLM 0.30 升到 0.31，跑了一轮对比测试，记录实际数据。
测试环境与方法
用真实请求集，不是合成负载。分三种负载形态测：长上下文、高并发短请求、小批量。
第一组收益：KV cache
0.31 的 FlashMLA mega-attention 配合 NVFP4 压缩 KV cache，是 SM100 上的默认配置。
长上下文场景下收益最明显：同样的显存能容纳的并发数有明显提升。这符合预期——长上下文的瓶颈就在 KV cache 容量。
高并发短请求和小批量场景下，收益就小很多。因为这两种负载本来就不是显存受限。
第二组收益：冷启动
新增的 vllm preload CLI 守护进程，实测让引擎重启时间大幅缩短。
这对我们的多租户弹性调度意义很大。之前每次冷启都要等几十秒，用户体验很差。
CRIU 快照（vllm snapshot create/restore）是实验特性且限 TP1，只在测试环境试了，恢复速度确实快，但不敢上生产。
踩到的点
第一，NVFP4 是 SM100 默认项。我们在另一批非 SM100 的卡上跑，行为和预期不一致，需要实测确认精度影响。
第二，Model Runner V2 的迁移影响自定义 logits processors。我们的有自定义逻辑，接口改了，需要适配。
第三，SWA bounded replay 改变了 prefix caching 的行为。滑动窗口 KV 不再进 prefix cache，之前的缓存命中率数据不可比，要重新基线。
结论
值不值得升，取决于负载形态。长上下文为主的服务，收益明显，建议升。短请求高并发的服务，收益有限，但要评估冷启动优化的价值。
通用的经验
vLLM 的收益和请求形态强相关。看别人的 benchmark 没用，必须用自己的真实流量测。三种负载跑下来，我们的结论和官方宣传的重点并不完全一致。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。