vLLM 0.11.0 发布：架构统一、性能跃迁与多模态能力全面进化

在大模型推理系统持续演进的今天，一个核心挑战始终摆在开发者面前：如何在不牺牲稳定性的前提下，持续引入前沿优化技术？vLLM 0.11.0 的发布给出了明确答案——通过彻底重构底层架构，为高性能、高扩展性的现代 AI 服务铺平道路。

这一版本不再只是功能叠加，而是一次“由内而外”的蜕变。最显著的变化是 V0 引擎正式退出历史舞台，全代码库完成向 统一 V1 架构 的迁移。这不仅意味着维护负担的大幅降低，更标志着 vLLM 进入了一个以可组合性、可扩展性和生产就绪为核心的设计新阶段。

本次更新共合并了 538 次提交，来自 207 名贡献者（其中 65 名为首次贡献的新成员），社区活跃度达到历史新高。这种广泛参与的背后，是对 vLLM 作为开源推理引擎领导地位的认可，也反映出业界对高效、灵活部署方案的迫切需求。

---

架构重塑：告别碎片化，迈向统一调度

过去，vLLM 同时维护着两套并行的执行路径——老旧的 V0 引擎和实验性的 V1 引擎。这种双轨制虽然保证了兼容性，但也带来了沉重的技术债：重复逻辑、接口分裂、调试困难。0.11.0 版本果断砍掉了所有与 AsyncLLMEngine、LLMEngine 和 MQLLMEngine 相关的组件，将整个系统重心完全聚焦于新一代调度器之上。

现在的 vLLM 是一个真正意义上的单体架构：

• 所有请求都由统一的 V1 调度器管理；
• 注意力后端实现全面标准化；
• 分布式执行流程基于一致的状态机模型；
• 高级特性如推测解码、KV 缓存卸载均可无缝集成。

对于大多数用户而言，API 层面几乎无感变化——你依然可以用熟悉的 LLM.generate() 方式调用模型。但如果你曾直接操作过 V0 的内部类或私有方法，则需要尽快迁移到公开支持的 V1 接口体系。这不是简单的命名替换，而是思维方式的转变：从“控制引擎”转向“声明意图”。

📌 实践建议：避免依赖任何以下划线开头的方法或模块。vLLM 团队正逐步强化公共 API 边界，未来非公开接口可能随时调整。

---

性能跃迁：不只是数字提升，更是体验升级

如果说架构统一是“打地基”，那本轮性能优化就是实实在在的“盖高楼”。vLLM 在多个关键路径上实现了质的突破，尤其体现在首 token 延迟（TTFT）和整体吞吐之间的平衡能力上。

CUDA Graph 默认启用 FULL_AND_PIECEWISE 模式

长久以来，CUDA graph 的使用一直是个“甜蜜的烦恼”：它能显著减少 kernel 启动开销，提升吞吐，但在面对动态长度输入或复杂控制流时又极易失败。vLLM 0.11.0 引入了更智能的捕获策略 —— FULL_AND_PIECEWISE，默认开启。

它的运作机制如下：

graph LR
    A[请求进入] --> B{是否满足 full capture 条件?}
    B -- 是 --> C[启用 Full-mode<br>最大化吞吐]
    B -- 否 --> D[降级至 Piecewise-mode<br>分段捕获保障稳定性]

这意味着像 Qwen3-VL 这类包含视觉编码、文本生成混合流程的模型，现在可以在保持高吞吐的同时，灵活应对不同分辨率图像带来的序列长度波动。实测显示，在高并发场景下，该策略使平均延迟降低了约 18%，且几乎没有出现因 graph 捕获失败导致的服务中断。

内核级加速：FlashInfer + Triton 双轮驱动

真正的性能飞跃来自于底层计算的精细化打磨。本版本重点优化了 RoPE（Rotary Position Embedding）相关操作：

• FlashInfer RoPE 内核重写：通过更高效的内存访问模式和寄存器利用率，某些场景下提速达 2 倍；
• Q/K apply_rope 融合：将两个独立的 RoPE 应用合并为一次 kernel 调用，减少 launch 开销和 cache miss，attention 计算成本下降 11%；
• inputs_embeds 避免复制：当用户直接传入嵌入向量时，不再默认将其拷贝到 GPU，有效缩短 TTFT，并节省显存。

这些看似微小的改动，叠加起来却能带来可观的整体收益。例如 GLM-4.1V 模型在启用融合 RMSNorm 和 Triton M-RoPE 后，TTFT 平均减少了 916ms，这对对话类应用来说几乎是“肉眼可见”的响应速度提升。

此外，DeepGEMM 已设为默认启用，利用 NVIDIA TMA（Thread Memory Access）技术优化矩阵乘法流程，整体吞吐再提 5.5%。这类硬件感知优化正成为 vLLM 区别于通用框架的关键优势。

---

多模态支持：不只是“能跑”，更要“跑得好”

随着多模态模型成为研究热点，推理系统的角色也从“纯语言处理器”转变为“跨模态协调中枢”。vLLM 0.11.0 显著增强了对视觉语言模型（VLM）、视频理解、OCR 和工具调用的支持能力。

新增主流多模态架构支持

模型	特性亮点
Qwen3-VL / Qwen3-Next	支持 MoE 结构、工具调用、XML 输出解析
InternVL	高效图文对齐，适合检索增强任务
OLMo3	AI2 开源生态新成员，透明训练数据
LongCat-Flash	极长上下文处理 + 函数调用闭环
Dots OCR	文档图像识别专用模型

特别是 Qwen3 系列，vLLM 不仅实现了完整功能覆盖，还针对其 XML 格式的工具调用输出开发了专用解析器，确保结构化内容可被下游系统准确提取。

视觉编码效率大幅提升

以往处理高分辨率图像常受限于视觉编码器的串行瓶颈。此次更新中，vLLM 引入了 视觉编码器数据并行（DP）支持，允许多卡协同完成图像特征提取，大幅缩短预填充阶段耗时。

同时，针对视频输入场景，新增 EVS 视频 token 剪枝机制，可根据帧间相似度自动压缩冗余 token，防止上下文无限膨胀。这对于监控分析、视频摘要等长视频应用至关重要。

媒体缓存机制上线

另一个实用改进是 Media UUID 缓存。相同图片或视频文件上传后会被赋予唯一 ID 并缓存特征，后续请求若引用同一资源，可直接复用已有 embedding，无需重复计算。

# 示例：通过 media_id 引用已上传媒体
messages = [
    {
        "role": "user",
        "content": [
            {"type": "image", "media_id": "img_abc123"},
            {"type": "text", "text": "描述这张图"}
        ]
    }
]

此功能不仅节省带宽和算力，也让构建持久化多模态会话成为可能。

---

分布式推理：从“可用”走向“高效”

面对百亿乃至千亿参数模型的部署需求，vLLM 在大规模服务方面也取得了实质性进展。

KV Cache CPU 卸载 + LRU 管理

超长上下文处理一直是资源消耗大户。vLLM 0.11.0 正式推出 KV Cache 到主机内存的卸载机制，结合 LRU（Least Recently Used）策略进行智能管理：

• 不活跃序列的 page 表项可被换出至 RAM；
• 当再次激活时按需加载回 GPU；
• 可配置阈值控制卸载时机，兼顾性能与显存压力。

这一机制使得 Llama 3.1 405B 或 Mixtral 这类巨型模型在消费级硬件上的轻量部署成为可能。虽然访问 CPU 内存会有一定延迟代价，但对于低频交互或批处理任务来说，性价比极高。

双批次重叠（DBO）上线

为了进一步压榨硬件利用率，vLLM 引入了 双批次重叠机制（Dual Batch Overlap, DBO）：

• 在处理当前 batch 的 decode 阶段时，提前启动下一个 batch 的 prefill；
• 实现计算与通信的高度重叠；
• 尤其适用于连续对话流或 Agent 推理链场景。

配合 DeepEP（Deep Expert Parallelism）优化，可在不影响响应质量的前提下，将系统吞吐提升 30% 以上。

EPLB：专家并行负载均衡

MoE 模型的推理难点之一在于路由不均导致部分专家过载。vLLM 新增 Expert Parallel Load Balancing（EPLB） 功能，支持 Hunyuan V1、Mixtral 等主流 MoE 架构：

• 提供静态分配策略，减少运行时调度开销；
• 动态统计各专家负载，辅助决策最优路由；
• 整体推理延迟波动降低，P99 更加平稳。

这对追求 SLA 保障的企业级服务尤为重要。

---

跨平台与量化：让高性能触手可及

vLLM 正在摆脱“仅限高端 NVIDIA GPU”的刻板印象，积极拓展硬件边界。

多平台支持持续扩展

• AMD ROCm 7.0 全面适配：包括 MI300X 在内的 CDNA 架构获得针对性调优；
• Intel XPU 支持 Whisper ASR：语音识别模型可在 Intel GPU 上运行；
• ARM64 / RISC-V64 支持完善：为边缘设备和国产芯片生态提供基础支撑；
• PPC64le 加入支持列表：适配 IBM Power 架构服务器。

尽管性能尚未完全对标 CUDA，但这些努力让 vLLM 成为真正意义上的异构推理平台。

FP8 与 W4A8 量化落地

量化不再是“实验选项”，而是生产环境中的标配：

• FP8 KV Cache 全流程支持：从权重加载到缓存存储，全程使用 FP8 存储；
• 每 token 组量化支持：提升转换精度；
• torch.compile 集成 FP8：实现编译期图融合优化；
• NVFP4 支持 Llama 3.1 405B、Gemma3 等稠密模型；
• W4A8 预处理加速：缩短量化准备时间，加快上线节奏。

值得一提的是，FP8 解码已在 FlashInfer 中提速 1.14x，说明软硬协同正在释放真实红利。

---

API 与用户体验：贴近真实生产需求

除了底层能力增强，vLLM 也在不断提升易用性和可观测性。

OpenAI 接口深度兼容

• 支持返回所有提示词的 logprobs；
• logprobs=-1 表示返回全词表概率分布，便于做细粒度分析；
• 流式响应支持 MCP 工具事件输出，方便前端构建交互式 UI；
• /health 接口在引擎异常时返回 503，便于 K8s 探针判断状态。

这些细节虽小，却是构建可靠服务链路的基础。

CLI 与配置优化

• --enable-logging 控制日志输出粒度；
• --help 内容重新组织，更清晰易读；
• 移除误导性“量化未优化”警告；
• KV 缓存单位改为 GiB，符合行业惯例；
• 新增 NVTX profiling 支持，便于 CUDA 工具链追踪性能瓶颈。

推测解码配置开放

现在可通过配置文件指定起草模型参数，例如：

speculative_config:
  draft_model: "TinyLlama/TinyLlama-1.1B-Chat-v1.0"
  draft_model_quantization: "fp8"
  draft_model_tp_size: 2

这让高级用户可以更精细地控制系统行为，充分发挥 speculative decoding 的加速潜力。

---

安全与依赖：稳扎稳打，步步为营

• 修复安全漏洞 GHSA-wr9h-g72x-mwhm（涉及特定输入解析场景）；
• 升级 PyTorch 至 2.8 for CPU；
• FlashInfer 更新至 0.3.1，修复若干边界问题；
• 支持 CUDA 13 与 ROCm 7.0；
• 构建强制要求 C++17，提升代码一致性；
• TPU 后端弃用 xm.mark_step，改用 torch_xla.sync，更符合现代 XLA 最佳实践。

这些变更虽不炫目，却是保障生产环境长期稳定的基石。

---

写在最后

vLLM 0.11.0 不是一个渐进式更新，而是一次战略性的技术跃迁。它宣告了旧时代的终结，也为未来打开了更多可能性——无论是双批次重叠、推测解码批量并行，还是 FlexAttention、Mamba2 混合架构支持，都建立在这个更加干净、统一的 V1 基础之上。

更重要的是，vLLM 正在从“推理加速器”演变为“AI 应用运行时”。它不仅要快，还要稳；不仅要支持最新模型，还要适配多样硬件；不仅要提供强大能力，还要让开发者用得顺手。

无论你是想部署 LLaMA、Qwen、ChatGLM 等主流大模型，还是构建下一代多模态 Agent，vLLM 都已准备好成为你的核心基础设施。

立即体验 vLLM 推理加速镜像 与 官方文档，开启你的高性能 AI 服务之旅。