编辑过程已审核“结合LLM理解→作者撰文不介入AI→AI润色→修改”一、vLLM 的定位vLLM 不在模型结构内部而是包裹在模型外层的推理引擎。其介入位置如下外层vLLM 接收请求、调度 batch、驱动整个模型的前向计算包括 prefill 和 decode 两种模式。注意力层PagedAttention 管理 KV Cache这是 vLLM 直接介入模型内部的唯一位置。循环外Continuous Batching 和 Chunked Prefill 决定每轮迭代送入哪些 token属于调度层。简单说Transformer 定义怎么算vLLM 决定算什么、何时算、KV 存哪。二、官网 | 论文贡献点arxiv 2309.06180参考论文Efficient Memory Management for Large Language Model Serving with PagedAttention识别了 LLM 服务中内存分配的核心挑战并量化其对服务性能的影响。提出PagedAttention一种在非连续分页内存中存储 KV Cache 的注意力算法灵感来自操作系统中虚拟内存与分页的经典思想。设计并实现了vLLM一个基于 PagedAttention 构建的分布式 LLM 服务引擎。在多种场景下评估 vLLM证明其显著优于 FasterTransformer、Orca 等前沿方案。三、官方博客 | 核心秘诀PagedAttention在自回归解码过程中所有输入 token 都会产生 Attention 的 Key 和 Value 张量并保存在 GPU 显存中以生成后续 token这些缓存的张量称为KV Cache。KV Cache 的两个关键特性体积大单条序列在 LLaMA-13B 上最多占用 1.7 GB。动态性强其大小取决于序列长度而序列长度高度可变且难以预测。研究发现现有系统因碎片化和过度预留浪费了60%80%的显存。为解决这一问题vLLM 引入了PagedAttention——受操作系统虚拟内存与分页思想启发的注意力算法。与传统注意力算法不同PagedAttention 允许将连续的 Key 和 Value 存储在非连续的内存空间中将每条序列的 KV Cache 划分为固定大小的 Block每个 Block 包含固定数量 token 的 K/V 张量在注意力计算时PagedAttention kernel 高效定位并读取这些 Block。四、vLLM 的两大核心方向调度优化和缓存优化vLLM 可以理解为大模型的高效服务员调度系统模型是厨师负责计算并生成回答GPU 是厨房提供实际计算资源vLLM 是餐厅的运营系统负责管理请求、组织计算以及管理显存中的 KV Cache。整体上vLLM 分为调度优化和KV Cache 缓存优化两大方向参考第三部分图机制类别作用PagedAttention缓存优化将 KV Cache 划分为固定大小的 Block按需分配并支持非连续存储提高显存利用率Continuous Batching调度优化允许已完成的请求退出并让新请求进入后续推理批次减少 GPU 空闲Prefix Caching缓存优化当不同请求具有相同且可命中的前缀时复用对应的 KV Cache减少重复的 Prefill 计算Chunked Prefill调度优化将长 Prefill 切分为多个小块与 Decode 请求混合调度降低首 token 延迟抖动Scheduler调度优化根据请求状态、计算预算和缓存资源决定每轮执行哪些推理任务KV Cache Manager缓存优化跟踪 KV Cache Block 的使用状态在需要时分配、释放或回收资源五、各机制重要性与适用场景重要性机制解决的问题有效场景★★★★★PagedAttentionKV Cache 显存浪费几乎所有场景尤其并发高、输出长度不可预知的在线服务★★★★Continuous BatchingGPU 利用率低短请求被长请求拖累多用户同时请求、请求长度差异大的生产服务★★★Chunked Prefill长 prompt 阻塞 decode造成卡顿混合长短请求对首 token 延迟和流式输出体验敏感的场景★★★Prefix Caching相同前缀重复计算共享 system prompt、RAG 固定文档、多轮对话、few-shot 示例★★PD 分离实验性Prefill 与 Decode 资源需求互相干扰大规模集群两阶段负载差异明显且有充足多卡资源单机或小规模不适用六、各机制详细拆解1. PagedAttention解决 KV Cache 显存浪费问题背景以 A100 80G 显存为例Qwen-32B 按 BF16 约占 64G剩余约16G留给 KV Cache。在没有 vLLM 的情况下系统会按请求预估的最大长度预先整块保留显存。假设某次请求实际只用了 16% 的预留空间却已占用了 38% 的显存配额造成 22% 的显存浪费而使用 vLLM 的 PagedAttention则在实际需要时动态分配 Block按需扩展、无需预留显存利用率大幅提升。机制原理PagedAttention 将每条序列的 KV Cache 划分为若干固定大小的Block默认约 16 token 一块。Block 按需申请无需连续排列类似操作系统的分页内存管理。当序列生成结束时对应 Block 立即释放可供其他请求复用。效果显著降低内存碎片提升高并发下的显存利用率支持更大的 batch size。2. Continuous Batching解决 GPU 利用率低位置说明Continuous Batching 位于调度层在每个 token 迭代开始前执行不在 Transformer 内部。它对应 vLLM 推理引擎中请求队列之后、模型前向之前的调度环节。问题背景传统静态批处理Static Batching中一个 batch 必须等待所有请求都生成完毕才能释放——哪怕其中某个请求已经提前结束它的位置也会空置到整批完成造成 GPU 资源浪费。机制原理每轮 token 生成迭代中调度器决定本轮 batch 包含哪些请求完成的踢出新请求补入。PagedAttention为这些请求分配 KV Block。模型做一次前向采样一个 token。未结束的请求回到调度器进入下一轮结束的请求立即释放 Block空出的位置由新请求填入。它的作用是**“每轮动态决定谁上桌”**而不是改变模型怎么算。效果短请求完成后立即释放资源新请求即刻补入GPU 始终保持高利用率吞吐量显著提升。3. Prefix Caching解决相同前缀重复计算适用场景在以下场景中不同请求往往共享相同的前缀 token导致 KV Cache 存在大量重复计算共享 system prompt如每次对话都带相同的角色设定固定的 RAG 文档检索到的上下文完全相同few-shot 示例固定的 prompt 模板多轮对话历史消息作为前缀被反复复用复用条件满足以下全部条件方可命中缓存模型权重相同且精度、量化方式、LoRA 适配器相同从第一个 token 开始token 序列完全相同逐字节一致包括空格和换行位置相同前缀都从位置 0 开始自然满足以完整 Block 为单位vLLM 默认约 16 token 一块不足一块的尾部不会复用机制原理vLLM 为每个 KV Cache Block 计算哈希值。当新请求的前缀 Block 哈希命中已有缓存时直接复用对应 Block跳过对应 token 的 Prefill 计算节省算力与显存。效果在相同前缀场景下Prefill 耗时大幅降低首 token 延迟TTFT显著改善同时减少 KV Cache 的重复占用。4. Chunked Prefill解决长 Prompt 阻塞 Decode问题背景Prefill读取输入和 Decode逐 token 生成是两种性质截然不同的工作Prefill需要一次性处理大量 token算力密集。Decode每次只生成一个 token但对延迟极其敏感。当一个长 Prefill 请求独占整个 batch 时正在进行 Decode 的请求必须等待造成明显的卡顿首 token 延迟抖动。机制原理Chunked Prefill 把 Prefill 改成了分块Chunked方式每轮只处理部分 Prefill token将剩余的计算槽位让给 Decode 请求。以一个具体例子说明假设每轮 GPU 最多处理 6 个 token轮次不切块切块每次读 4 个第 1 轮读完 12 个 token聊天的人被迫停住读 4 个聊天的人各说 1 个字第 2 轮聊天的人各说 1 个字读 4 个聊天的人各说 1 个字第 3 轮聊天的人各说 1 个字读完最后 4 个聊天的人各说 1 个字类比食堂大锅一次只能装 6 份菜。一位客人点了 12 份的大菜。不切块整锅先给他做完排队的人全等着。切块每锅先给排队的人留空间剩下的空间分批做大菜分 3 锅做完。大菜稍慢一点但排队的人不用等。权衡与弊端切块会让这 12 个 token 的长请求本身变慢TTFT首 token 延迟和总耗时都会拉长。收益是其他正在生成的请求不被卡住整体的流畅度TPOT / ITL 稳定性更好。适用原则对整体吞吐和流式体验有要求时开启对单个长请求速度有极致要求时需权衡。5. PD 分离实验性解决 Prefill 与 Decode 资源争抢问题背景以前一台机器一个 GPU 实例既负责 Prefill又负责 DecodePrefill像读长文章要一次读很多字特别吃算力Compute-bound。Decode像一个字一个字地写回答每次只写一个字但要反复翻看前面所有内容特别吃显存带宽Memory-bound。两件事混在同一台机器上会互相抢资源有人在读长文章时正在写回答的人就得停下来等而写回答的人太多又会挤占读文章的空间。机制原理Prefill-Decode 分离Prefill 实例专门负责读取输入读完后把记忆KV Cache打包传给下一台机器。Decode 实例专门负责接过记忆一个 token 一个 token 地往外写。两端可以各自独立配置读文章的机器配算力强的卡适合 Compute-bound写回答的机器配显存大、带宽高的卡适合 Memory-bound互不干扰。代价与限制KV Cache 需要在两台机器之间通过网络传输网络带宽不足时反而会拖慢整体速度。因此目前仍是实验性功能主要用于大规模集群中两阶段负载差异明显的场景单机或小规模部署不适用。七、小结vLLM 通过在模型外层构建完整的调度与缓存管理体系将 GPU 资源的利用率推向极致。其核心思路可以归纳为两点用PagedAttention用“虚拟内存”的思维 解决存在哪的问题 Continuous Batching / Chunked Prefill 解决轮到谁的问题。两者协同使得 vLLM 在高并发、长上下文、多样化请求的生产场景中相比传统服务框架实现吞吐提升。 
长河君 · 2026/10/18 8:45:47 · 阅读 1.2k 10 | vLLM 定位与核心机制详解
编辑过程已审核“结合LLM理解→作者撰文不介入AI→AI润色→修改”一、vLLM 的定位vLLM 不在模型结构内部而是包裹在模型外层的推理引擎。其介入位置如下外层vLLM 接收请求、调度 batch、驱动整个模型的前向计算包括 prefill 和 decode 两种模式。注意力层PagedAttention 管理 KV Cache这是 vLLM 直接介入模型内部的唯一位置。循环外Continuous Batching 和 Chunked Prefill 决定每轮迭代送入哪些 token属于调度层。简单说Transformer 定义怎么算vLLM 决定算什么、何时算、KV 存哪。二、官网 | 论文贡献点arxiv 2309.06180参考论文Efficient Memory Management for Large Language Model Serving with PagedAttention识别了 LLM 服务中内存分配的核心挑战并量化其对服务性能的影响。提出PagedAttention一种在非连续分页内存中存储 KV Cache 的注意力算法灵感来自操作系统中虚拟内存与分页的经典思想。设计并实现了vLLM一个基于 PagedAttention 构建的分布式 LLM 服务引擎。在多种场景下评估 vLLM证明其显著优于 FasterTransformer、Orca 等前沿方案。三、官方博客 | 核心秘诀PagedAttention在自回归解码过程中所有输入 token 都会产生 Attention 的 Key 和 Value 张量并保存在 GPU 显存中以生成后续 token这些缓存的张量称为KV Cache。KV Cache 的两个关键特性体积大单条序列在 LLaMA-13B 上最多占用 1.7 GB。动态性强其大小取决于序列长度而序列长度高度可变且难以预测。研究发现现有系统因碎片化和过度预留浪费了60%80%的显存。为解决这一问题vLLM 引入了PagedAttention——受操作系统虚拟内存与分页思想启发的注意力算法。与传统注意力算法不同PagedAttention 允许将连续的 Key 和 Value 存储在非连续的内存空间中将每条序列的 KV Cache 划分为固定大小的 Block每个 Block 包含固定数量 token 的 K/V 张量在注意力计算时PagedAttention kernel 高效定位并读取这些 Block。四、vLLM 的两大核心方向调度优化和缓存优化vLLM 可以理解为大模型的高效服务员调度系统模型是厨师负责计算并生成回答GPU 是厨房提供实际计算资源vLLM 是餐厅的运营系统负责管理请求、组织计算以及管理显存中的 KV Cache。整体上vLLM 分为调度优化和KV Cache 缓存优化两大方向参考第三部分图机制类别作用PagedAttention缓存优化将 KV Cache 划分为固定大小的 Block按需分配并支持非连续存储提高显存利用率Continuous Batching调度优化允许已完成的请求退出并让新请求进入后续推理批次减少 GPU 空闲Prefix Caching缓存优化当不同请求具有相同且可命中的前缀时复用对应的 KV Cache减少重复的 Prefill 计算Chunked Prefill调度优化将长 Prefill 切分为多个小块与 Decode 请求混合调度降低首 token 延迟抖动Scheduler调度优化根据请求状态、计算预算和缓存资源决定每轮执行哪些推理任务KV Cache Manager缓存优化跟踪 KV Cache Block 的使用状态在需要时分配、释放或回收资源五、各机制重要性与适用场景重要性机制解决的问题有效场景★★★★★PagedAttentionKV Cache 显存浪费几乎所有场景尤其并发高、输出长度不可预知的在线服务★★★★Continuous BatchingGPU 利用率低短请求被长请求拖累多用户同时请求、请求长度差异大的生产服务★★★Chunked Prefill长 prompt 阻塞 decode造成卡顿混合长短请求对首 token 延迟和流式输出体验敏感的场景★★★Prefix Caching相同前缀重复计算共享 system prompt、RAG 固定文档、多轮对话、few-shot 示例★★PD 分离实验性Prefill 与 Decode 资源需求互相干扰大规模集群两阶段负载差异明显且有充足多卡资源单机或小规模不适用六、各机制详细拆解1. PagedAttention解决 KV Cache 显存浪费问题背景以 A100 80G 显存为例Qwen-32B 按 BF16 约占 64G剩余约16G留给 KV Cache。在没有 vLLM 的情况下系统会按请求预估的最大长度预先整块保留显存。假设某次请求实际只用了 16% 的预留空间却已占用了 38% 的显存配额造成 22% 的显存浪费而使用 vLLM 的 PagedAttention则在实际需要时动态分配 Block按需扩展、无需预留显存利用率大幅提升。机制原理PagedAttention 将每条序列的 KV Cache 划分为若干固定大小的Block默认约 16 token 一块。Block 按需申请无需连续排列类似操作系统的分页内存管理。当序列生成结束时对应 Block 立即释放可供其他请求复用。效果显著降低内存碎片提升高并发下的显存利用率支持更大的 batch size。2. Continuous Batching解决 GPU 利用率低位置说明Continuous Batching 位于调度层在每个 token 迭代开始前执行不在 Transformer 内部。它对应 vLLM 推理引擎中请求队列之后、模型前向之前的调度环节。问题背景传统静态批处理Static Batching中一个 batch 必须等待所有请求都生成完毕才能释放——哪怕其中某个请求已经提前结束它的位置也会空置到整批完成造成 GPU 资源浪费。机制原理每轮 token 生成迭代中调度器决定本轮 batch 包含哪些请求完成的踢出新请求补入。PagedAttention为这些请求分配 KV Block。模型做一次前向采样一个 token。未结束的请求回到调度器进入下一轮结束的请求立即释放 Block空出的位置由新请求填入。它的作用是**“每轮动态决定谁上桌”**而不是改变模型怎么算。效果短请求完成后立即释放资源新请求即刻补入GPU 始终保持高利用率吞吐量显著提升。3. Prefix Caching解决相同前缀重复计算适用场景在以下场景中不同请求往往共享相同的前缀 token导致 KV Cache 存在大量重复计算共享 system prompt如每次对话都带相同的角色设定固定的 RAG 文档检索到的上下文完全相同few-shot 示例固定的 prompt 模板多轮对话历史消息作为前缀被反复复用复用条件满足以下全部条件方可命中缓存模型权重相同且精度、量化方式、LoRA 适配器相同从第一个 token 开始token 序列完全相同逐字节一致包括空格和换行位置相同前缀都从位置 0 开始自然满足以完整 Block 为单位vLLM 默认约 16 token 一块不足一块的尾部不会复用机制原理vLLM 为每个 KV Cache Block 计算哈希值。当新请求的前缀 Block 哈希命中已有缓存时直接复用对应 Block跳过对应 token 的 Prefill 计算节省算力与显存。效果在相同前缀场景下Prefill 耗时大幅降低首 token 延迟TTFT显著改善同时减少 KV Cache 的重复占用。4. Chunked Prefill解决长 Prompt 阻塞 Decode问题背景Prefill读取输入和 Decode逐 token 生成是两种性质截然不同的工作Prefill需要一次性处理大量 token算力密集。Decode每次只生成一个 token但对延迟极其敏感。当一个长 Prefill 请求独占整个 batch 时正在进行 Decode 的请求必须等待造成明显的卡顿首 token 延迟抖动。机制原理Chunked Prefill 把 Prefill 改成了分块Chunked方式每轮只处理部分 Prefill token将剩余的计算槽位让给 Decode 请求。以一个具体例子说明假设每轮 GPU 最多处理 6 个 token轮次不切块切块每次读 4 个第 1 轮读完 12 个 token聊天的人被迫停住读 4 个聊天的人各说 1 个字第 2 轮聊天的人各说 1 个字读 4 个聊天的人各说 1 个字第 3 轮聊天的人各说 1 个字读完最后 4 个聊天的人各说 1 个字类比食堂大锅一次只能装 6 份菜。一位客人点了 12 份的大菜。不切块整锅先给他做完排队的人全等着。切块每锅先给排队的人留空间剩下的空间分批做大菜分 3 锅做完。大菜稍慢一点但排队的人不用等。权衡与弊端切块会让这 12 个 token 的长请求本身变慢TTFT首 token 延迟和总耗时都会拉长。收益是其他正在生成的请求不被卡住整体的流畅度TPOT / ITL 稳定性更好。适用原则对整体吞吐和流式体验有要求时开启对单个长请求速度有极致要求时需权衡。5. PD 分离实验性解决 Prefill 与 Decode 资源争抢问题背景以前一台机器一个 GPU 实例既负责 Prefill又负责 DecodePrefill像读长文章要一次读很多字特别吃算力Compute-bound。Decode像一个字一个字地写回答每次只写一个字但要反复翻看前面所有内容特别吃显存带宽Memory-bound。两件事混在同一台机器上会互相抢资源有人在读长文章时正在写回答的人就得停下来等而写回答的人太多又会挤占读文章的空间。机制原理Prefill-Decode 分离Prefill 实例专门负责读取输入读完后把记忆KV Cache打包传给下一台机器。Decode 实例专门负责接过记忆一个 token 一个 token 地往外写。两端可以各自独立配置读文章的机器配算力强的卡适合 Compute-bound写回答的机器配显存大、带宽高的卡适合 Memory-bound互不干扰。代价与限制KV Cache 需要在两台机器之间通过网络传输网络带宽不足时反而会拖慢整体速度。因此目前仍是实验性功能主要用于大规模集群中两阶段负载差异明显的场景单机或小规模部署不适用。七、小结vLLM 通过在模型外层构建完整的调度与缓存管理体系将 GPU 资源的利用率推向极致。其核心思路可以归纳为两点用PagedAttention用“虚拟内存”的思维 解决存在哪的问题 Continuous Batching / Chunked Prefill 解决轮到谁的问题。两者协同使得 vLLM 在高并发、长上下文、多样化请求的生产场景中相比传统服务框架实现吞吐提升。