vLLM 的本质，是一个把“显存管理”这个操作系统层面的老问题，用分页虚拟内存的思路在 GPU 上重新解了一遍的推理引擎。 它之所以能在短短两三年内成为开源 LLM 推理的事实标准，不是因为某个单点技术惊艳，而是因为它精准地击中了自回归推理中最昂贵的瓶颈——KV 缓存，并把“省显存”直接转化成了“高并发”和“低延迟”。

---

它要解决的真问题：KV 缓存把显存吃光了

在自回归解码中，每生成一个新 token，模型都需要读取此前所有 token 的 Key 和 Value。如果不缓存，每一步都要重算全部历史，计算量随上下文长度呈二次增长；如果缓存，KV 占用的显存又随并发数和序列长度线性膨胀。

传统做法是连续内存预分配：为每个请求预留一段足够长的连续显存，按最大可能长度分配。问题在于，模型无法预知输出会有多长，于是产生了高达 60%—80% 的显存碎片与浪费。显存看似还有剩余，却因为碎片化而无法分配给新请求，GPU 的并发能力被严重压制。vLLM 的起点，就是把这个“连续预分配”的逻辑彻底推翻。

---

PagedAttention：把操作系统的分页搬上 GPU

PagedAttention 是 vLLM 的基石，它的灵感直接来自操作系统的虚拟内存分页。核心设计可以拆成三层：

逻辑块与物理块解耦。 把每个请求的 KV 缓存切成固定大小的逻辑块（典型 BLOCK_SIZE 为 16 个 token），逻辑上连续，但物理上可以分散在显存的任意非连续位置。一个请求的完整上下文由一组逻辑块拼接而成，不再要求一块连续的物理显存。

页表映射（Block Table）。 维护一张从逻辑块索引到物理块地址的映射表，Attention 核函数在计算时通过这张页表间接寻址，找到每个 token 对应的 KV 数据实际存放在哪里。这套间接寻址是 PagedAttention 的性能关键，也是它区别于传统连续 Attention 实现的核心。

按需动态分配。 随着自回归生成推进，只有当当前逻辑块被填满时，才申请新的物理块。不再需要为未知长度的输出提前预留空间，显存浪费被压缩到“最后一个未填满的块”这一级别。配合引用计数和写时复制，多个请求共享相同前缀（如系统提示词）时，物理块可以安全复用，进一步放大显存效率。

在核函数层面，PagedAttention 的实现需要精细的并行策略：每个 warp 处理一个 query token 与一个完整物理块内 key token 的计算，多个 warp 协作覆盖整个上下文；Grid 的形状按 (num_heads, num_seqs, max_num_partitions) 组织，每个 thread block 只负责一个 head、一个 sequence、一个 partition 的计算。vLLM 还维护了多个 Attention 后端（FlashAttention、FlashInfer、Triton Attention 等），以适应不同硬件和 Attention 模式；其中 Triton 后端的战略意义在于性能可移植性——用 Python 编写、编译到多种 GPU，避免为每个硬件平台维护数百个专用核函数。

---

连续批处理：在“空间”解决之后，再解决“时间”

PagedAttention 解决的是显存的空间效率，连续批处理（Continuous Batching）解决的是计算的时间效率。两者合在一起，才是 vLLM 吞吐量提升两个数量级的完整解释。

传统静态批处理要等一个批次里所有请求都生成完毕，才能释放显存、接纳下一批。但不同请求的输出长度差异巨大，短请求早已结束，长请求还在生成，GPU 在等待中被浪费。连续批处理则在每次迭代粒度做调度：每一步解码结束后，已经完成的请求立即释放其 KV 块，等待队列中的新请求可以马上插入当前批次，与仍在生成的请求一起推进。调度器不区分 Prefill 和 Decode 阶段，统一用 token 预算来管理每一步的计算负载，这使首 token 延迟（TTFT）显著平抑，系统并发吞吐提升 2—4 倍。

---

V1 引擎：从“能跑得快”到“跑得快且好维护”

2025 年 1 月发布的 V1 是 vLLM 的一次核心架构重写，V0 已在 2026 年被完全弃用。V0 的问题是：早期为了快速覆盖模型和硬件，各功能独立演进，代码库越来越复杂，技术债累积，新能力的集成成本越来越高。

V1 保留了 V0 中稳定且经过验证的组件（模型实现、GPU 核函数、工具层），但重新架构了核心系统：调度器、KV 缓存管理器、worker、sampler 和 API server 被统一到一个更简洁、模块化、易于扩展的框架中。几个关键的设计变化值得注意：

• 统一调度器：用简单的字典 {request_id: num_tokens} 为每个请求动态分配固定 token 预算，不再在调度逻辑中区分 prompt 和 output token。这让 prefix caching、chunked prefill、speculative decoding 等能力可以“默认开启”，而不是各自作为补丁存在。

• 零配置理念：V1 的目标是让关键优化默认生效，而不是要求用户理解 140 多个配置参数才能跑出好性能。

• 异步调度与 Model Runner 改进：减少了 CPU 侧开销，使 GPU 尽可能不因调度逻辑而空转。

V1 在长上下文场景下性能提升尤为显著，这也符合它统一调度、减少 CPU 瓶颈的设计取向。

---

性能画像：数字背后的场景含义

vLLM 的性能优势不是一条均匀的曲线，而是随负载结构剧烈变化的。理解这一点，比记住某个基准数字更重要。

场景	关键数据	含义
Agentic 工作负载 + Mooncake 分布式 KV 池	吞吐 3.8×，P50 TTFT 降低 46×，端到端延迟降低 8.6×	Agent 多轮对话中，94.2% 的输入 token 是已见过的前缀；分布式缓存让这些前缀“跨实例免费”
DeepSeek-V4.1-Flash 规模化服务	单 GPU 954K tokens/s，P90 每用户 196 tokens/s；与 DeepSeek 自研引擎的 decode 吞吐差距在 6% 以内	vLLM 在顶级开源模型的生产级 serving 上已具备与专用引擎对等的能力
单卡并发优化（一个 flag）	RTX PRO 6000 Blackwell 上每 token 延迟 22ms → 13ms，同等延迟预算下并发翻倍	调度和内存参数调优仍有显著的“免费”空间
Agentic 真实基准（AgentX）	最高 130K total tokens/GPU-second；MiniMax M3 上交互性 376 tokens/s	Agent 负载的吞吐和交互性可以同时兼顾，前提是前缀缓存命中率高

这些数字的共同前提是高前缀复用。在传统聊天场景中，输入输出比通常在个位数到几十比一；而在 Agent 轨迹中，这个比例可以达到 131:1，94.2% 的前缀可以命中缓存。这意味着 vLLM 在 Agent 工作负载上的优势，很大程度上来自它把“缓存已见前缀”这件事做到了系统级——从单机的 block 级前缀缓存，到跨实例的分布式 KV 池（如 Mooncake），再到 P/D 分离架构，层层放大这一收益。

---

生态位：为什么是“默认选择”，而不是“最快选择”

2026 年的推理引擎格局已经比较清晰。vLLM 与 SGLang、TensorRT-LLM 的关系不是简单的“谁更快”，而是设计目标的分化。

vLLM 的核心竞争力是“广度 + 标准化” 。它是三者中硬件支持面最广的：NVIDIA、AMD、Intel GPU，以及 TPU、Gaudi、Ascend 等通过插件接入；量化格式覆盖 FP8、MXFP8/MXFP4、NVFP4、INT8、INT4、GPTQ/AWQ、GGUF 等。同时，它是最早把 OpenAI 兼容端点作为一等公民的引擎之一，这让客户端代码在切换引擎时几乎不需要改动。vLLM 已加入 PyTorch Foundation，与 PyTorch、DeepSpeed、Ray 并列，这进一步巩固了它作为“推理层基础设施”的生态位。

SGLang 的差异化优势在 Agentic 和结构化负载。它的 RadixAttention 在复杂多调用、思维树等场景下的前缀缓存命中率更高，P/D 分离和 HiCache 也针对大规模服务拓扑做了更深的设计。TensorRT-LLM 则在 NVIDIA 平台上追求极致吞吐，官方定位是在 H100 上比 vLLM 快 30%—60%，但它绑定 NVIDIA，且编译和调优的工程成本更高。

一句话概括选型逻辑：需要广泛硬件兼容、快速接入和跨模型迭代，选 vLLM；Agentic 前缀复用密集、需要更复杂服务拓扑，考虑 SGLang；锁定 NVIDIA 且愿意为最后一段吞吐付出工程代价，上 TensorRT-LLM。

---

部署现实：vLLM 不是“启动就完事”

vLLM 的性能上限很高，但它的参数空间和运维复杂度也同样可观。一个常被低估的事实是：V1 的目标之一是“零配置”，但生产环境中的关键决策仍然需要显式做对。

显存预算是第一道门槛。 vLLM 启动时会进行 profiling，决定 KV 缓存块的数量；--gpu-memory-utilization 控制模型权重和 KV 缓存之外留给运行时开销的余量，设得过高会导致 OOM，设得过低则浪费并发空间。--max-model-len 直接决定单条序列的 KV 预算，在长上下文场景中它与并发数之间存在明确的 trade-off。

调度参数影响延迟分布。 --max-num-seqs 和 --max-num-batched-tokens 共同决定批处理的上限；chunked prefill 在 V1 中默认开启，但它与 TTFT 和 TPOT 的关系需要通过压测来校准，而不是靠默认值“猜”。前缀缓存的收益高度依赖命中率：在 Agent 场景中它是倍增器，在短对话场景中收益有限，甚至可能因为哈希和索引开销带来轻微负效果。

分布式场景的复杂度陡增。 Tensor parallel 决定权重如何拆卡，Pipeline parallel 影响流水线气泡；P/D 分离架构可以针对 prefill 和 decode 的不同资源特征做独立扩缩容，但引入了 KV 传输的开销和调度复杂性。vLLM 提供了 vllm-playground 这类 GUI 工具来降低首次上手的门槛，但生产级的调优仍然依赖对 workload 特征的持续观测。

---

视角的浓缩表述

vLLM 的核心贡献是用 PagedAttention 把 KV 缓存从“连续预分配”改成“分页按需分配”，把显存碎片从 60%—80% 压到接近零；再用连续批处理在每次迭代粒度做调度，让完成请求立即释放资源、新请求即时插入，两者合起来把吞吐提升一个数量级以上。V1 重写了核心架构，统一调度、默认优化、降低 CPU 开销，长上下文场景收益明显。它在 Agentic 负载上的优势被分布式 KV 池（Mooncake）进一步放大，前缀命中率 94% 时 TTFT 可以降低 46 倍。生态位是“最广硬件支持 + OpenAI 兼容 + PyTorch Foundation 基础设施”，适合通用生产 serving；SGLang 在复杂前缀复用上更深，TensorRT-LLM 在纯 NVIDIA 上追求极致吞吐。代价是参数空间和运维复杂度不低，显存预算、调度参数、前缀命中率和分布式拓扑都需要按 workload 校准，不能“启动即最优”。