理解 vLLM PagedAttention把 KV Cache 从连续显存变成可分页的系统资源TL;DR场景在线 LLM 推理服务受 KV Cache 动态增长和碎片化限制无法高并发承载请求结论vLLM 用 PagedAttention 把 KV Cache 当作分页系统资源管理配合 continuous batching 把 LLM Serving 变成可调度的内存系统产出10 节系统化讲解原理 / 块化收益 / 与调度协同 / 共享 / 局限 / 选型 25 行版本矩阵 10 行错误速查卡版本矩阵功能 / 特性状态说明PagedAttention 论文SOSP 2023, arXiv 2309.06180✅ 已验证Kwon / Li / Zhuang / Sheng / Zheng / Yu / Gonzalez / Zhang / StoicaUC Berkeley Stanford UCSDSOSP 2023 最佳论文vLLM 0.10.x 持续更新 2025-09-05 Anatomy blog✅ 已验证GitHub 56.5k stars 领先其他开源推理引擎DeepSpeed ~40k / SGLang ~18kvLLM vs HF Transformers 14-24× 吞吐提升✅ 已验证PagedAttention 论文原始 benchmark 数据vLLM vs TGI 2.2-2.5× 吞吐提升✅ 已验证PagedAttention 论文原始 benchmark 数据Continuous batching PagedAttention 协同✅ 已验证vLLM 核心设计Orca iteration-level 调度继承Automatic prefix caching✅ 已验证vLLM 0.4 默认开启--no-enable-prefix-caching关闭Chunked prefill✅ 已验证vLLM 默认启用长 prompt 切片处理Speculative decoding✅ 已验证vLLM 支持 EAGLE / Medusa / n-gram draft modelGuided decodingFSM / xgrammar / outlines✅ 已验证vLLM 内置结构化输出约束Function callingauto/required/none✅ 已验证vLLM ≥ 0.8.3 起支持 named tool_choiceMulti-LoRA serving✅ 已验证vLLM 内置同 base 模型动态切换多 LoRATensor parallel / Pipeline parallel / Sequence parallel✅ 已验证1 GPU → 多机多 GPU支持万亿参数模型P/D disaggregationPrefill/Decode 分离✅ 已验证DistServe / Mooncake 风格vLLM 0.7 支持Multi-Step 调度vLLM 2024 引入✅ 已验证与 chunked prefill 协同降低 CPU overheadFlashAttention / FlashInfer attention kernel✅ 已验证vLLM 默认灵活切换 backend量化FP8 / INT4 / INT8 / AWQ / GPTQ✅ 已验证vLLM 支持多种权重 KV cache 量化多硬件支持NVIDIA / AMD / Intel / Gaudi / TPU / AWS Trainium✅ 已验证vLLM 0.6 全面扩展TensorRT-LLM v0.18.1 CVE-2025-23254⚠️ 注意0.18.2 pickle 反序列化漏洞 CVSS 8.8需升级SGLang v0.5.6 RadixAttention 基数树✅ 已验证LMSYS 出品DeepSeek 官方推荐推理引擎之一SGLang vs vLLM prefix 命中率 23% → 96%Qwen2-7B 多轮⚠️ 项目方测试SGLang 博客 第三方对比工作负载依赖明显TGI v1.0 HFOIL 1.0 license限制商业云托管✅ 已验证最后 Apache 2.0 版本是 0.9.4Ollama 个人 / 小并发本地推理✅ 已验证自动 API模型库丰富llama.cpp 极致轻量 CPU / 边缘推理✅ 已验证GGUF 量化纯 CPU 流畅vLLM v0.10.2 CVE-2025-62164embeddings RCE⚠️ 注意torch.load weights_only 边界检查CVSS 8.8连续批处理演进Static → Orca → vLLM → Chunked → Sarathi → P/D 分离 → SGLang 零开销✅ 已验证2024-2026 调度层持续演进vLLM 之所以成为 LLM Serving 里的标志性方案核心不在于它改变了模型结构也不在于它让每一次矩阵乘法突然变快而在于它抓住了在线推理里最关键、最容易被低估的资源KV Cache。PagedAttention 的思想很直接不要让每个请求的 KV Cache 占用一整段连续显存而是像操作系统管理虚拟内存一样把 KV Cache 拆成固定大小的 block再用映射表把逻辑 token 位置映射到物理 block。这个设计解决的是线上推理最现实的问题请求长度动态变化输出长度不可预测请求结束时间不一致显存容易碎片化并发数最终被 KV Cache 限制。理解 PagedAttention不只是理解 vLLM 的一个特性而是理解现代 LLM Serving 为什么越来越像一个小型操作系统。一、vLLM 要解决的不是“模型不会跑”在 vLLM 出现之前模型当然也能跑。Hugging Face Transformers 可以generateFasterTransformer 可以做高性能推理很多团队也能自己写一层服务把模型包装成 API。但“能跑”和“能高并发、低浪费、稳定地跑”不是一回事。在线 LLM Serving 的核心难点在于动态性请求随机到达prompt 长度不同输出长度不可预知请求可能中途取消KV Cache 会随生成过程不断增长多个采样分支可能共享一部分前缀长 prompt、短 prompt、短输出、长输出混在同一个服务里。如果只是低并发测试一切看起来都正常。模型可以加载接口可以返回GPU 也在工作。但一旦进入真实在线场景问题会集中暴露显存被 KV Cache 挤满请求开始排队batch size 上不去尾延迟变差短请求被长请求拖住。所以 vLLM 的切入点不是“模型推理这件事不会做”而是“高吞吐 LLM Serving 需要一个能管理动态资源的系统”。在这个系统里KV Cache 就像内存scheduler 像进程调度器block table 像页表请求像不断创建、运行、退出的进程。二、传统 KV Cache 管理为什么浪费假设每个请求都需要一段连续显存来存 KV Cache。系统通常会面对两种选择。第一种是提前预留最大可能长度。比如请求最大上下文是 2048 token系统就按 2048 token 预留 KV Cache。这很安全但非常浪费。用户可能只生成 50 个 token剩余空间却被提前占住。线上服务里大量请求不会真的用满最大长度提前预留就会让显存利用率很低。第二种是随着请求增长动态扩容。请求进入 prefill 后先占一段空间decode 每生成一些 token就继续扩容。听起来更省但实现复杂。因为 KV Cache 需要不断增长如果原位置后面没有连续空间就可能需要搬迁、重新分配或者失败。请求结束后也会留下碎片。A 请求释放了 300 token 空间B 请求释放了 2000 token 空间C 请求还在中间占用。显存总空闲看起来不少但连续可用区域不一定适合新请求。这就是内存碎片化。对 LLM Serving 来说碎片化不是一个“工程洁癖”问题而是会直接降低系统可承载的并发数。PagedAttention 要解决的就是这件事让 KV Cache 不再依赖连续显存。传统做法直接后果线上影响按最大长度预留大量空间从未使用并发数提前触顶连续显存扩容请求增长时容易搬迁或失败调度复杂、延迟不稳请求完成后释放连续段空闲空间被切碎总空闲不少但分配困难多分支复制 KV公共前缀重复占用beam / sampling 成本高三、PagedAttention 的基本思想PagedAttention 把每个请求的 KV Cache 切成固定大小的 block。逻辑上一个请求的 token 序列仍然是连续的物理上它的 KV block 可以分散在显存的不同位置。系统维护一张 block table。它记录某个请求的第几个逻辑 block对应显存中的哪个物理 block。这和操作系统虚拟内存很像。程序看到的是连续虚拟地址。操作系统底层用页表把虚拟地址映射到不连续的物理页。在 vLLM 中请求看到的是连续 token 序列。PagedAttention 底层把 KV Cache 映射到不连续的物理 block。这样一来请求不再需要连续显存。只要全局 block pool 里还有空闲 block请求就能继续分配。可以把它拆成三层层在操作系统里在 PagedAttention 里逻辑视图进程看到连续虚拟地址请求看到连续 token 序列映射结构页表block table物理存储不连续物理页不连续 KV block这不是一个表面类比。PagedAttention 的价值就在于把 KV Cache 从“连续大块显存分配问题”变成“固定粒度 block 管理问题”。粒度固定之后管理就简单了。申请时从全局 pool 拿 block生成更多 token 时继续追加 block结束时把 block 放回 pool共享前缀时让多个逻辑 block 指向同一个物理 block。四、block 化为什么能降低浪费假设 block size 是 16 token。一个请求需要 100 token 的 KV Cache它只需要 7 个 block。前 6 个 block 是满的最后一个 block 可能只用了一部分。这种浪费叫内部碎片。它仍然存在但浪费范围被限制在最后一个 block而不是整个最大预留空间。相比按最大长度预留block 化的浪费小得多。更重要的是block 化让请求的增长更自然。decode 阶段每生成一段 token就可以按需分配新的 block。请求结束后释放它占用的 block回到全局 pool后续请求可以立刻复用。这就是 PagedAttention 论文里强调的核心问题KV Cache 会动态增长和收缩如果管理低效就会因为碎片和重复复制浪费显存从而限制 batch size。PagedAttention 用分页式管理降低浪费让服务能容纳更多正在运行的请求。它不是把注意力复杂度从根本上消掉了。长上下文仍然昂贵decode 仍然要访问历史 KV。PagedAttention 的主要价值是让同样的显存可以承载更多有效上下文、更少碎片、更少重复复制。可以用一句话概括PagedAttention 不让 KV Cache 变小而是让 KV Cache 更像一种可调度、可复用、可回收的系统资源。这个变化非常关键。因为在线 Serving 里很多时候不是模型权重先把显存吃完而是动态增长的 KV Cache 限制了并发。五、PagedAttention 和 continuous batching 是一组能力PagedAttention 解决显存布局问题。Continuous batching 解决请求调度问题。两者经常一起被讨论因为它们在在线 LLM Serving 里互相需要。Continuous batching 让请求可以在 decode step 中动态加入和退出。已经完成的请求退出新请求补位GPU 上的 running batch 不再是一批固定生命周期的请求。这会显著提升 GPU 利用率也能避免短请求被长输出请求长期拖住。但调度越动态KV Cache 的申请和释放就越频繁。如果底层显存管理仍然依赖连续大块分配调度器越灵活碎片问题越明显。PagedAttention 让这种动态进出变得可控。请求完成后释放 block新请求可以复用这些 block。调度器不需要等一整批请求一起结束也不需要为每个请求提前保留巨大连续区域。所以 vLLM 的关键不是单独一个技术点而是一组协同scheduler 决定谁进入 running batchPagedAttention 管理 KV blockblock table 维护逻辑和物理映射free block pool 支撑快速分配和释放prefix caching / sharing 降低重复 KVpreemption 在资源紧张时为系统兜底。这也是为什么理解 vLLM 时不能只看“用了什么 attention kernel”。真正重要的是它把调度和内存管理做成了一套系统。六、PagedAttention 为什么适合共享 KV Cache分页式 KV Cache 还有一个重要好处共享更容易。多个请求如果共享相同前缀可以让它们的 block table 指向相同的物理 block。只有当后续 token 分叉时才分配新的 block。这类似 copy-on-write。例如用户要求生成多个候选答案。它们共享同一个 prompt 的 KV Cache然后在生成阶段走向不同分支。如果没有共享每个候选都要复制一份 prompt KV Cache。共享后公共前缀只存一次。这对 beam search、parallel sampling、多候选生成、多轮对话 prefix 复用都有价值。后来的 automatic prefix caching 也沿着这个方向继续发展如果一个新请求和历史请求有相同前缀就复用已经计算好的 KV block让新请求跳过共享部分的 prefill 计算。当然共享并不是免费的魔法。系统需要维护 block 引用关系、hash、生命周期、淘汰策略和一致性。prompt 结构越稳定命中越有价值prompt 完全随机时缓存命中率就会下降。但从系统设计角度看PagedAttention 给 KV Cache 共享提供了一个很自然的抽象逻辑上是不同请求物理上可以指向同一组 block。这就是为什么它像操作系统。操作系统的页表不仅解决连续地址问题也为共享内存、copy-on-write、进程隔离提供了基础抽象。PagedAttention 在 LLM Serving 里的角色也类似。七、PagedAttention 不是什么PagedAttention 很重要但它不是万能答案。第一它不是新的模型结构。它不改变 Transformer 权重也不改变模型能力。模型知道什么、推理能力如何、上下文窗口多大本质上还是由模型本身决定。第二它不是让 attention 复杂度从根本上消失。长上下文仍然昂贵。decode 阶段仍然需要访问历史 KV上下文越长读取压力越大。第三它不是所有 workload 都有巨大收益。如果请求很少、上下文很短、并发很低PagedAttention 带来的收益可能没有高并发场景明显。第四它不能替代良好的 scheduler。显存管理好不代表 TTFT 一定低。如果长 prefill 独占 GPU用户照样会等。如果 decode 请求过多TPOT 仍然可能变差。第五它不替代容量规划。你仍然要看 KV Cache 使用率、block pool、prefix cache hit rate、preemption、TTFT、TPOT、P95/P99 和上下文长度分布。所以更准确的说法是PagedAttention 把 KV Cache 管理这个关键资源问题解决得更优雅但完整的 Serving 仍然需要调度、缓存、切块 prefill、抢占、多 GPU 并行和监控体系一起工作。八、什么时候 vLLM 很适合vLLM 很适合以下场景。第一开放模型的在线推理服务比如 Qwen、Llama、DeepSeek、Mistral 等。第二并发请求较多需要提升吞吐、降低单位 token 成本并且希望在同样硬件上容纳更多 running sequence。第三输入输出长度变化明显传统静态 batch 或简单连续分配浪费较大。第四需要 OpenAI-compatible API方便替换云 API 或接入现有应用。第五需要流式输出、prefix caching、LoRA serving、多 GPU tensor parallel、量化、投机解码、chunked prefill 等能力。第六需要快速搭建工程化推理服务而不是从 CUDA kernel 开始自研。对于本地 Qwen、A6000、ASR/LLM/TTS 链路、机器人语音系统这类场景vLLM 是非常合理的默认选择。它能把 LLM 推理服务从“能跑”推进到“能承载并发”。但 vLLM 不是所有场景唯一答案。如果追求 NVIDIA GPU 上极致优化、强依赖 TensorRT engine、愿意接受更复杂构建流程TensorRT-LLM 值得评估。如果 workload 是复杂 Agent、多分支生成、结构化输出、共享 prefix 很多SGLang 也值得评估。如果在 Hugging Face 生态里需要成熟的生产接口、Prometheus、OpenTelemetry 和模型生态集成TGI 也可能更合适。如果只是个人本地使用、小模型、低并发Ollama 或 llama.cpp 可能更简单。九、自研时能从 PagedAttention 学到什么PagedAttention 的启发不只是“照抄一个 attention kernel”。如果自研 GPU Serving真正值得学的是三个原则。第一把动态请求资源变成固定粒度 block 管理。不要为每个请求预留大块连续资源。固定粒度不是为了形式漂亮而是为了分配、释放、复用、监控都可控。第二把逻辑序列和物理存储解耦。请求视角可以连续底层存储可以离散。这个抽象能让调度器和内存管理器分工更清楚。第三让调度器和内存管理器协同。Scheduler 决定谁运行KV Cache Manager 决定是否有资源运行。两者割裂就会出现 GPU 想跑但显存不够或者显存空着但调度低效的问题。这三个原则不只适用于 KV Cache也适用于音频流 buffer、工具调用上下文缓存、多模态 embedding 缓存、RAG 文档上下文和 Agent 中间状态管理。很多系统问题表面上是“算法慢”实际是“资源没有被当成一等对象管理”。十、核心结论PagedAttention 的价值是把 KV Cache 从“连续显存分配问题”变成“分页 block 管理问题”。它降低碎片减少浪费让更多请求能同时留在 GPU 上从而让 continuous batching 的效果更稳定。vLLM 的强大不是单点魔法而是围绕 LLM Serving 的真实瓶颈做了一套系统设计请求动态调度、KV Cache 分页管理、流式 decode、长 prompt 控制、prefix 复用和多 GPU 扩展。理解 PagedAttention就是理解现代 LLM Serving 为什么越来越像操作系统。当你开始把 KV Cache 看成需要分页、映射、共享、回收、监控和调度的资源时你才真正进入了 LLM Serving 的工程视角。参考资料vLLM Documentation, Paged Attention: https://docs.vllm.ai/en/latest/design/paged_attention/vLLM Blog, Easy, Fast, and Cheap LLM Serving with PagedAttention: https://vllm.ai/blog/2023-06-20-vllmPaper, Efficient Memory Management for Large Language Model Serving with PagedAttention: https://arxiv.org/abs/2309.06180vLLM Documentation, Automatic Prefix Caching: https://docs.vllm.ai/en/latest/features/automatic_prefix_caching/vLLM Blog, Inside vLLM: Anatomy of a High-Throughput LLM Inference System: https://vllm.ai/blog/2025-09-05-anatomy-of-vllmNVIDIA TensorRT-LLM Documentation: https://nvidia.github.io/TensorRT-LLM/Hugging Face Text Generation Inference: https://github.com/huggingface/text-generation-inferenceSGLang Documentation: https://docs.sglang.ai/错误速查卡症状根因定位修复OOM 在长 prompt 高并发下KV Cache 按 max-len 提前预留碎片化严重nvidia-smi看显存是否随请求结束清空升级 vLLM ≥ 0.6 启用--enable-chunked-prefill 调低max-model-len同一 system prompt 多请求吞吐不涨prefix KV 没共享每次重复 prefillPrometheus 看vllm:cache_hit_rate指标启用--enable-prefix-caching或迁移 SGLang RadixAttention长 prefill 请求阻塞 decodeTTFT 飙升prefill / decode 跑在同一 GPU 上调度没分开nsys profiling TTFT vs TPOT P99 对比启用chunked prefill高负载场景走 P/D disaggregationP99 延迟大幅抖动scheduler 与 KV Manager 割裂preemption 频繁监控preemption_count/used_blocks升 vLLM 0.7 启用 Multi-Step 调度扩显存或降并发vLLM 启动报 CVE-2025-62164embeddings RCE 风险torch ≥ 2.8.0 稀疏张量检查默认关闭torch.load(tensor, weights_onlyTrue)可绕过pip show vllm torch看 vllm ≥ 0.10.2 torch ≥ 2.8.0升级 vLLM 最新 patch 版本或临时回退 torch 2.8.0TensorRT-LLM Python executor RCEpickle 反序列化漏洞 CVE-2025-232540.18.2看 trtllm 版本 0.18.2 IPCZeroMqQueue升 TensorRT-LLM ≥ 0.18.2商业部署 TGI 收到 HF 法务函TGI v1.0 改 HFOIL 1.0 license限制未授权云托管看 TGI 版本 LICENSE退回 TGI 0.9.4最后 Apache 2.0或改用 vLLM / SGLang短请求被长请求拖住P99 高旧 static batching / 一次性 batch看 running batch 内最大请求长度升 vLLM 启用 continuous batching chunked prefill显存够但 batch size 上不去KV 碎片化严重free blocks 多但连续可用少监控free_blocks与最大连续块切到 vLLM PagedAttention 或 SGLang RadixAttentionOllama / llama.cpp 上生产后崩误把本地框架用到了高并发生产看 QPS / 并发 / GPU 利用率高并发场景换 vLLM / TensorRT-LLM / SGLang