2026年6月，vLLM项目发布了一个看似普通的版本号更新——从v1.4跃升到v2.0.0。
版本号这东西，在开源世界里向来玄学。有的项目一年能蹦三个大版本，有的万年停在0.x死活不肯动。但vLLM这次不一样。它不是一个”又加了一堆新功能”的常规升级，它是一次底层架构的自我推翻与重建。
过去两年，vLLM几乎是”大模型推理”的代名词。PagedAttention、连续批处理、前缀缓存——这些现在人人挂在嘴边的技术术语，大部分是vLLM率先提出并落地的。一个LLM服务框架能有多火？Meta、Mistral AI、IBM在用，DeepLearning.AI专门出了合作课程，Oracle把它的生产部署堆栈写进了官方教程。
但火的代价是什么？是代码里积累的技术债务。
vLLM V1的设计初衷是”快”。过去一年，社区往里面塞了异步调度、投机解码、各种新模型支持，每一样在孤立场景下都很香，但拼在一起，整个模型运行器变成了一个脆弱的、难以理解和扩展的巨兽。持久批处理的状态管理混乱、异步执行需要”极其复杂且不自然的逻辑”才能共存、CPU端的输入准备成了性能瓶颈。
vLLM团队做了一个艰难但正确的决定：推倒重来，但让用户完全无感知。
这就是v2.0的真正含义——你用的API还是那个API，你敲的vllm serve还是那个命令，但底下跑的那套东西，已经换了心脏。
第一层：从”CPU记流水账”到”GPU自己管自己”
vLLM V1时代有一个核心设计叫”持久批处理”。
什么意思？连续两个推理批次之间，大部分请求其实是相同的，你不需要每一步都重新构建所有输入张量。增量更新缓存状态，远比重新构建划算。这个思路本身没问题，问题出在实现上——V1把持久状态直接当作模型和采样器的输入，这导致了一系列连锁反应：布局约束、复杂的状态记录、脆弱的请求重排序逻辑。每加一个新功能，代码就变得更拧巴一点。
v2.0通过Model Runner V2彻底重构了这套逻辑。
新架构的核心思路是：解耦。持久化的请求状态与每步的模型输入分离。每个活跃请求在生命周期内占据一个固定的状态表行，每步运行器根据当前请求顺序从持久状态中”按需取用”，而非直接操作状态本身。
更狠的改动在”谁来做记录”这件事上。
V1时代，大量的输入准备（input_ids、positions、seq_lens这些张量的构建）是在CPU端完成的。每次请求进来，CPU要忙活一大堆Python循环和张量操作，然后再把数据搬到GPU。当GPU算力越来越强，CPU端的这些”杂活”就成了跑不动的瓶颈。
MRV2把输入准备搬到了GPU上用Triton内核做。请求状态主要驻留在设备内存里，张量直接在GPU上构建。好处是显而易见的：CPU开销大幅降低、代码复杂度下降、异步调度和投机解码的兼容性天然变好。
这是一次”事务下放”：以前CPU记的流水账，现在GPU自己管自己了。
第二层：从”能跑”到”能扛”——长上下文的工业化
vLLM V2.0的技术升级，不仅仅是代码洁癖发作。
它背后有一个更现实的业务驱动：长上下文正在成为主流工作负载。
智能体AI（Agentic AI）把推理上下文从几万token一路推到了百万级。一个Agent要读完整份代码库、回顾整段聊天历史、分析几十页文档，然后才回答问题。KV缓存的体量随着上下文长度线性膨胀，而GPU显存是有限的。
传统张量并行（TP）在这种场景下面临一个尴尬：分组查询注意力（GQA）模型只有少量KV头，TP最多把KV缓存拆到每个GPU一个头；多头潜在注意力（MLA）更惨，它只有一个KV头，TP下KV缓存在每个GPU上完整复制一份。
复制的KV缓存吃掉大量显存，能同时服务的请求数量锐减，吞吐量下滑，单token成本飙升。
vLLM V2.0押注的解决方案叫解码上下文并行（Decode Context Parallelism, DCP） 。核心逻辑很简单：把KV缓存沿序列维度切分到各个GPU，每个GPU只存和读自己那一块。不复制、不浪费、不打架。
实测数据验证了这套逻辑的实战价值。在一个智能体长上下文跟踪数据集上（中位数约68K token，长尾到1M），DCP加持下的部署方案显著提升了KV缓存的利用率峰值，在同等并发请求下能装下更多、更长的上下文。
这不再是”跑得更快”的问题，这是”跑得动和跑不动”的问题。
第三层：从”大一统”到”专业分工”
v2.0的另一个底层逻辑变化，藏在vLLM生态的系统架构里——分离式服务（Disaggregated Serving）的成熟。
这是一个技术路线的根本转向：把计算密集的Prefill阶段和内存带宽密集的Decode阶段拆成独立的服务池。
为什么要拆？因为两者的资源需求和优化目标完全不一样。Prefill吃计算，需要高吞吐的GPU算力；Decode吃内存带宽和延迟控制，需要快速响应单个用户。强行绑在同一个池子里，必然有一方在妥协。
vLLM V2.0做的，是在保持整个调度、API、前缀缓存生态不变的前提下，让Decode池变得可插拔。你仍然用vLLM做Prefill、做调度、做API网关，但Decode后端可以换成专门为”低延迟单用户解码”设计的TileRT引擎。
这个架构的巧妙之处在于：你不需要在”选vLLM”和”选TileRT”之间做非此即彼的抉择。同一个Prefill实例可以同时服务两种Decode后端——原生vLLM解码池处理高吞吐批处理任务，TileRT池处理延迟敏感的交互式流量，两者共享同一套调度和KV传输机制，互不干扰。
vLLM从一个”大一统的推理引擎”，正在进化为“一个开放的推理生态平台”——核心调度和基础能力是稳定的公共底盘，Prefill/Decode各自的最优解可以通过标准化接口接入。
这和操作系统的演变路径惊人地相似：最初是”一个内核干所有事”，后来是”微内核+可插拔服务”。而v2.0，恰好站在了这个转折点上。
所以，vLLM V2.0到底在交付什么？
不是一个更快一点的推理框架。
它是一整套解决”大模型推理如何工业化”的工程方法论。 从PagedAttention的内存管理，到MRV2的GPU原生执行，到DCP的长上下文承载，到分离式服务的灵活架构——每一个技术决策背后，都是同一个问题在驱动：
当模型的规模、任务的复杂度、用户的并发量同时增长一个数量级时，什么架构会崩，什么架构能扛？
v2.0给出的答案是：能扛的架构，一定不是靠打补丁，而是靠底层设计时就承认”状态管理””解耦””异步””专业化”是核心问题，而非可有可无的优化点。
你可以继续把vLLM当”调个接口就能用的推理服务”来用，这没问题，API完全兼容。
但如果你想搞明白，为什么同样的硬件配置、同样的模型权重，有的人只能跑50并发，有的人能跑500并发——那v2.0的每一行架构决策，都值得你仔细读一遍。
