vLLM v0.26.0：推理服务开始进入 DeepSeek-V4 和 KV 分层时代
vLLM v0.26.0 不是一个普通版本号。它更像是服务端推理栈的一次阶段信号：大模型部署的难点正在从“高吞吐生成”变成“多模型、多硬件、长上下文、KV 分层和成本稳定性”。
这次 release 有 411 个 commits，212 位 contributors。亮点很多，但最值得看的是四条线。
第一条线是 DeepSeek-V4。vLLM 对 DeepSeek-V4 做了跨硬件性能推进，包括 specialized routing kernel、fused_topk_bias、减少 repeat/copy、ROCm prefill compressor、sparse decode/prefill 优化，以及 AMD 和 XPU 上的 DSpark speculative decoding。这说明 DeepSeek-V4 这种大 MoE、长上下文模型已经不是“能不能支持”的问题，而是要在不同硬件后端上抠 TPOT 和成本。
第二条线是 speculative decoding。v0.26.0 加了 runtime draft weight update、hybrid drafters、qwen-eagle3 SWA support、Gemma4 DSpark draft model、DSv4 DSpark 等。推理服务以后会越来越像一个调度系统：主模型、草稿模型、不同 attention 模式、不同 KV cache dtype 之间动态配合。
第三条线是 KV offloading 与 tiered secondary storage。vLLM 这次补了 offloading metrics、tier-owned event handling、object-store secondary tier、DP-replica-aware tiering、encoder-cache connector 和 CPU offloading。长上下文模型最贵的不是只有参数，还有持续增长的 KV cache。KV 如何从 GPU 到 CPU、再到对象存储分层，决定了长会话、Agent 任务和高并发服务能不能撑住。
第四条线是 hybrid attention backend。vLLM 支持按 KV-cache group 选择不同 attention backend，并把 sliding-window 变成显式 backend capability。这对混合架构模型很关键。未来模型不会只有一种规整 attention 模式，推理框架必须能处理不同层、不同 cache、不同窗口策略。
这次还值得注意 Rust frontend：多模态 video/audio、Seed-OSS tool parser、native vllm-bench。推理服务正在同时向多模态和 OpenAI-compatible API 靠拢，不再只是一个 text generation server。
对开发者来说，vLLM v0.26.0 给出的选型信号很明确：
- 如果你要跑 DeepSeek-V4、Qwen、MiniMax 这类 MoE/长上下文模型，推理框架支持程度会显著影响成本。
- 如果业务有长会话 Agent，KV offloading 不是高级功能，而是容量规划的一部分。
- 如果你在多硬件环境部署，ROCm、XPU、CPU、macOS arm64 这些后端的成熟度会影响供应链弹性。
- 如果你只用小模型做轻量服务，版本更新不一定急；但如果你做生产长上下文或 Agent 服务，vLLM 的这些底层变化很值得跟。
我的判断是，2026 年下半年推理服务会变成 AI 应用公司的核心基础设施。模型越来越大，Agent 调用越来越长，用户对响应时间越来越敏感，简单的 OpenAI-compatible server 只是起点。真正的竞争在 KV、cache、spec decode、路由、观测和硬件适配。