推理服务重启时，最慢的一段往往不是进程拉起，而是模型从磁盘读取、量化并重新铺进多张GPU。vLLM在10月5日发布0.31.0稳定版，把新的Preload权重缓存守护进程、KV压力下的准入控制和更严格的多模态请求默认值放进同一版本。它试图同时回答三个生产问题：怎样更快恢复、怎样不让队列压垮引擎，以及怎样把客户端可控参数关回服务端边界。

权重不下GPU，引擎重启改为重新映射

vllm preload为每张GPU启动守护进程，先从磁盘加载、完成量化后处理并保留本卡对应的权重分片。新引擎以IPC cache方式启动时，不再重复搬运同一批权重，而是通过本机Unix socket取得CUDA IPC句柄并映射现有显存。官方称这能把权重加载从分钟级降到秒级；默认零拷贝模式下，重启不会再额外复制一份GPU权重。

这不是无条件加速。Preload目前只支持CUDA与ROCm，可配合张量、专家和数据并行，也可跨节点使用，但不支持pipeline parallelism。守护进程与引擎必须在同一节点、同一用户下运行，并在模型、精度、量化、并行布局和vLLM版本上匹配；守护进程不可用或指纹不符时默认回退磁盘加载。实际恢复时间仍取决于模型大小、量化方式、GPU拓扑和存储。

准入上限与KV优先级瞄准压力下的活性

0.31.0新增--max-num-active-seqs，把真正进入RUNNING状态的序列上限与整体max_num_seqs分开。等待队列还会优先调度已经持有KV block的请求，减少被换出后又重新分配的浪费。版本同时修复KV connector与多Token预测在KV压力下的死锁，以及分块预填充被抢占时的活锁。

这些改动的价值不在空载峰值，而在拥塞时能否继续前进。企业应分别观察活动序列、等待队列、KV命中、抢占、首Token尾延迟与超时率，尤其要用长短请求混合、多租户突发和节点重启压测。只看平均吞吐，可能掩盖少量长请求把队列锁住，或缓存优先级让新请求长期等待。

安全默认值收紧，也带来一串升级断点

每请求传入的mm_processor_kwargs与media_io_kwargs现在默认返回错误，只有服务端显式设置--trust-request-mm-kwargs才会接收。LoRA路径被纳入prefix-cache block hash，额外缓存键也标记来源，避免不同来源的键碰撞；陈旧的多模态接收缓存不能再覆盖新payload。这些变化把模型处理参数和缓存身份重新放回服务端控制。

代价是兼容性。tokenizer_mode=slow被移除，Mamba前缀缓存参数更名，在线FP8量化入口调整，AllSpark INT8 W8A16后端移除；--enforce-eager现在也会关闭JIT kernel预热，XPU graph则默认开启并删除旧环境变量。升级前要逐项扫描启动参数、镜像、量化配置、指标采集和请求客户端，不能只确认服务进程能启动。

小编判断：把重启演练和流量回放放在同一张验收表

0.31.0还提供实验性的vllm snapshot create/restore，用CRIU恢复已初始化的TP1引擎，但它与Preload成熟度不同，也不能覆盖通用并行部署。Preload的“分钟到秒”同样来自官方能力描述，没有统一硬件、模型与重复次数，不能直接写进生产SLA。

更稳妥的迁移方式，是复制线上流量做影子测试：先记录磁盘冷启动、Preload命中与指纹回退三条路径的恢复时间，再比较P50/P95首Token延迟、吞吐、KV命中、抢占、错误码和单位请求成本；随后注入守护进程退出、版本不一致、节点重启、长请求突发与不可信多模态参数。只有快重启没有牺牲队列公平、安全默认值和故障可解释性，这次升级才算真正进入生产。