vLLM v0.25.0发布：MRv2成为所有稠密模型默认执行路径，删除PagedAttention
新版本包含 558 个提交，新增LLaVA-OneVision-2、Unlimited OCR等模型，Transformers后端性能追平原生vLLM，并强化流式解析引擎。
AI解读：日常跑vLLM的用户只要加载稠密模型，就会自动走上一条更统一、维护更积极的代码路径，以前需要手动切换或依赖旧后端的行为都会成为历史。新版本还让Transformers建模后端跑得和原生vLLM一样快，并加入FP8 MoE支持——对想用HuggingFace生态但担心性能损失的用户来说，这降低了迁移成本。
新增的Streaming Parser Engine统一了工具调用和推理内容的解析，专门适配了Kimi、DeepSeek V4等模型，对做智能体或流式输出的开发者会更顺手。开发团队还报告了多项性能优化，比如GLM-5.2/DeepSeek相关的内核融合能带来 1.9% 到 3.3% 的端到端吞吐提升。
但这次更新也移除了Baichuan、Grok等模型支持，如果生产环境在跑这些模型，升级前需要先确认替代方案。整体来看，这次改动主要影响两类人：一是自己部署vLLM的开发者，升级后应做回归测试以验证MRv2和新解析器是否兼容现有工作流；另一类是依赖旧API或已删除模型的用户，需要关注迁移路径。普通应用层用户可能暂时感受不到变化，不必急着升级。
vLLM项目发布v0.25.0版本，包含 558 个提交，来自 232 位贡献者，其中 64 位是首次参与。
据发布说明，Model Runner V2（MRv2）现已成为所有稠密模型的默认执行路径，并新增了EVS、实时嵌入、Mamba混合模型的prefix caching、多模态prefix双向注意力，以及与完整CUDA graphs兼容的动态投机解码支持。
PagedAttention被删除，Transformers后端提速
发布说明称，旧的PagedAttention注意力实现已被移除，因为V1/MRv2后端已成为标准路径。
Transformers建模后端现在与原生vLLM性能相当，并新增FP8 MoE支持、CUDA graph和嵌入缩放修复，以及GPTBigCode/Starcoder2和RoBERTa的迁移。
新模型与流式解析引擎
新版本新增了LLaVA-OneVision-2、Unlimited OCR、MOSS-Transcribe-Diarize、openai/privacy-filter和Hy3模型。GLM-5 / DeepSeek-V3.2加入模型库，MiniMax-M3获得流水线并行和NVFP4支持。
新的Streaming Parser Engine提供了统一的工具调用/推理解析框架，包含新的Kimi k2.5/k2.6/k2.7解析器，以及seed_oss和DeepSeek V4的移植。
性能与硬件优化
针对GLM-5.2和DeepSeek，多个Triton内核融合带来了 1.9% 至 3.3% 的端到端吞吐提升，reduce-scatter MoE all-reduce优化提升 3.1% 至 3.2%，DeepSeek-V4的token索引缓存实现了 5 至 6 倍内核加速。
硬件支持方面，覆盖NVIDIA Blackwell、AMD ROCm、Intel XPU、CPU、RISC-V和POWER平台，包括ROCm迁移到torch 2.11稳定ABI、AArch64加速的未量化MoE等。
API、安全与移除项
OpenAI兼容API新增Responses API tools、Chat/Completions响应的指标字段等。Rust前端继续成熟，支持HTTPS/mTLS、DP supervisor和profiler控制路由。
安全方面修复了图像解压炸弹导致的OOM拒绝服务、NaN音频样本引起的死循环等问题。
移除的模型包括Baichuan、Aquila、Grok、Tarsier/Tarsier2、AyaVision/MusicFlamingo和Mantis。