# vLLM 推理原理（二）：请求怎么排队，KV Cache 怎么住进显存？

> **摘要：** 面对长短不一的生成请求，vLLM 如何兼顾并发、响应速度与有限显存？本文从连续批处理出发，用 token 预算和显存算例解释 Chunked Prefill、分页 KV、前缀缓存与抢占机制，展示调度器和缓存管理器如何协作，并厘清并发数、上下文长度、计算预算之间的关系，帮助读者理解常见配置的作用与代价。

![vLLM 推理原理（二）封面：请求调度与 KV Cache 显存管理]![cover-02.png](https://developer.qcloudimg.com/http-save/yehe-12628201/f41313c7784f68e628147b565d41f560.png)

一个用户输入十个字，另一个用户提交一份长文档；前者只想得到一句话，后者希望生成几千字。

如果把它们当成普通 HTTP 请求，逐个执行，GPU 很可能没有得到充分利用；如果一次收齐一大批再运行，短请求又可能被长请求拖住。与此同时，生成中的每条序列都在积累 KV Cache，随时可能把显存吃满。

vLLM 的调度与显存管理，需要一起回答两个问题：**本轮让哪些 token 进入计算，它们所需的历史状态放在哪里？**

> 本篇以 vLLM v0.32.0 的 V1 引擎为参照，采用常见的全注意力 / GQA 文本模型，不启用推测解码。示例中的块大小、预算和轮数只用于讲解机制。若不熟悉 prefill、decode 和 KV Cache，可以先读[第一篇](01-一次请求如何变成输出.md)。

## 1. 为什么一个固定 batch 不够用？

应用开发中很常见的批处理方式是：收集一组任务，一起运行，整批结束后再收下一批。

但生成请求的输出长度并不相同。假设 A 需要 2 轮 decode，B 需要 3 轮，C 需要 6 轮。如果整批成员固定，A 和 B 结束后，它们原先占用的位置可能要等到 C 结束，才能交给新请求。

![图 6：静态批次与连续批处理]![06-continuous-batching.png](https://developer.qcloudimg.com/http-save/yehe-12628201/cefe7eac2a9d20ee9e6da674bb6dfb6d.png)

*图 6：这里只比较批次成员如何变化。真实 GPU 上不存在必须与图中逐格对应的固定“请求槽位”，不同迭代的执行时间也可能不同。*

**Continuous Batching（连续批处理）** 的核心，是在迭代边界重新组织批次：结束的请求退出，新请求在资源允许时加入。

这不要求所有请求处于同一进度。一个请求可以正在处理提示词，另一个已经输出了很多 token；执行器根据每个请求的元数据，组织这一轮的实际计算。

vLLM 最初的 [PagedAttention 论文](https://arxiv.org/abs/2309.06180) 讨论了生成服务中动态增长的 KV 状态如何限制批处理。连续推进请求和按需管理缓存，正好需要相互配合：可同时容纳的有效工作越多，调度器才越有机会组织高效批次。

## 2. V1 调度器看的单位，是待计算的 token

先看 [v0.32.0 的 Scheduler.schedule()](https://github.com/vllm-project/vllm/blob/v0.32.0/vllm/v1/core/sched/scheduler.py#L591)。源码注释提供了一个重要视角：调度器不必把 prefill、decode 当成两个完全独立的阶段来实现，而可以统一追踪每个请求还有哪些 token 没有算完。

在不考虑推测 token、异步占位等细节时，可以用下面的差值理解：

```text
待计算 token 数 ≈ 已知的 prompt + output token 数 − 已计算 token 数
```

一个新请求可能有几千个 prompt tokens 尚未处理。一个普通 decode 请求则通常刚刚多出一个已采样、还没输入模型的 token，所以本轮需要再计算一个位置。

实际代码还会考虑推测解码、异步调度占位、长 prefill 阈值及其他约束，上式只是基本数据流，不是源码表达式的完整替代。

### 一轮调度至少受三类限制

| 限制 | 常见参数 / 资源 | 它限制什么 |
| --- | --- | --- |
| 本轮计算量 | `max_num_batched_tokens` | 这一轮能安排多少待计算 token |
| 同时参与的序列 | `max_num_seqs` | 调度时可并发推进的序列数量上限 |
| 历史状态容量 | 可用 KV blocks | 能否为这些序列提供所需缓存空间 |

另外还有单序列长度限制 `max_model_len` 等条件。这里的“本轮 token 数”并不等于所有活跃请求的完整上下文总长度：decode 本轮也许只输入一个 token，但它仍然可能读取几千个历史位置的 K、V。

因此，把 `max_num_batched_tokens` 调大，不等于凭空获得更多显存；把 `max_num_seqs` 调大，也不保证可以同时承载同样数量的超长上下文。

## 3. Chunked Prefill：长提示词不必一口气处理完

设本轮 token 预算是 8，有三条候选请求：

- A 正在 decode，需计算 1 个 token。
- B 正在 decode，需计算 1 个 token。
- C 刚进入 prefill，还有 20 个提示词 token 待处理。

可以先为 A、B 各安排一个位置，再用剩余 6 个预算处理 C 的一部分提示词。下一轮继续推进 C。

![图 7：按 token 预算组织混合批次]![07-token-budget.png](https://developer.qcloudimg.com/http-save/yehe-12628201/aa9ed529141adf0c9ca892c124444c2d.png)

*图 7：C 在本轮处理了 6 个已知输入位置，并不代表它生成了 6 个输出 token。*

这就是 **Chunked Prefill** 的基本作用：把长提示词切成可调度的小段，与 decode 工作交错执行，降低长 prefill 对持续输出的干扰。

V1 的常见配置会优先推进 decode，并用剩余预算容纳 prefill；不过，不能据此推导出所有模式下都有严格的实时优先级保证。正在运行的请求、等待队列、优先级策略和资源限制，都会参与实际决策。官方说明见 [Optimization and Tuning：Chunked Prefill](https://docs.vllm.ai/en/v0.32.0/configuration/optimization/#chunked-prefill)。

### 不同长度的序列，怎样一起送到 GPU？

执行器可以把本轮选出的 token 打包成扁平输入，同时携带边界、位置和缓存映射。例如：

```text
token 输入：[A_next, B_next, C1, C2, C3, C4, C5, C6]
请求边界： [0, 1, 2, 8]
另附：每个位置的 position、历史长度、KV 块表等
```

请求边界表达的是：第一个位置属于 A，第二个属于 B，其余六个属于 C。Attention 元数据保证它们读取各自适用的历史，而不是把拼在数组里的 token 当成同一段对话。

这类输入准备可以在 [GPU Model Runner](https://github.com/vllm-project/vllm/blob/v0.32.0/vllm/v1/worker/gpu_model_runner.py) 中继续追踪。底层的实际张量形状、padding 和图捕获策略，会随后端变化。

## 4. KV Cache 为什么能成为显存的大头？

先把显存账本拆开。

![图 8：显存组成与一个 KV 体积算例]![08-vram-budget.png](https://developer.qcloudimg.com/http-save/yehe-12628201/c83e33101d3e5ad3ecb1b3fe5b58763d.png)

*图 8：上方各部分宽度不代表实际占比。下方为假设模型的算术推导。*

除了模型权重，推理还需要 KV Cache、激活、算子工作区、通信缓冲、CUDA Graph 相关内存等资源。

例如一个假设的 70 亿参数模型，仅按每参数 2 字节估算，权重就约为 14 GB，也就是约 13 GiB；实际装载还要考虑额外数据与运行开销。权重装得下，不代表还能同时接住大量长请求。

对于常规全注意力 / GQA 模型，不考虑分片和分块浪费时，KV 的逻辑数据量可以近似写成：

```text
KV bytes ≈ 2 × L × T × Hkv × D × S
```

其中：

- `2` 表示 K 和 V 两份数据。
- `L` 为层数，`T` 为缓存的 token 数。
- `Hkv` 为 KV head 数，`D` 为每个 head 的维度。
- `S` 为每个缓存元素的字节数。

设 `L=32、Hkv=8、D=128、S=2`，每个 token 就需要：

```text
2 × 32 × 8 × 128 × 2 = 131072 bytes = 128 KiB

8192 tokens：8192 × 128 KiB = 1 GiB
32 条同长度、且不共享前缀的序列：约 32 GiB
```

这是全模型范围的逻辑体积，不是每张 GPU 的分配量。实际还会受 TP 的分片或复制规则、缓存数据类型、分块以及模型结构影响。MLA、滑动窗口注意力、混合架构的缓存布局，也不能直接套用这组假设。

这个算例说明：**请求的上下文长度与活跃数量，需要和模型大小一起参与容量规划。**

## 5. Paged KV：把连续序列映射到分散的物理块

如果为每条请求都预留最大输出长度对应的一整段缓存，会出现两个问题：

1. 请求最终没用完的部分被提前占住。
2. 多条长短不一的请求不断申请和释放，很难长期保持理想布局。

分页思路是：序列仍然有连续的逻辑位置，但其 K、V 可以存放在多个固定容量的物理块中。请求持有一张块表，记录逻辑块到物理块的映射。

![图 9：逻辑 KV 块与物理块池的映射] ![09-paged-kv.png](https://developer.qcloudimg.com/http-save/yehe-12628201/3e98b6a8ba9ee0eeadc86b00f5453935.png)

*图 9：图中每块能放 4 个 token 的 KV，便于手算；不是对真实部署块大小的推荐。*

在这个例子中，序列有 10 个 token：

```text
逻辑块 0：token 0..3 → 物理块 7
逻辑块 1：token 4..7 → 物理块 2
逻辑块 2：token 8..9 → 物理块 9

Block Table = [7, 2, 9]
```

要找第 5 号 token 的缓存位置，可以先算逻辑块号 `5 // 4 = 1`，再查块表得到物理块 2，块内偏移为 `5 % 4 = 1`。

这里的块描述的是缓存中若干 token 的 K、V，不是 CUDA 的 thread block。真实实现还需要处理层、head、数据类型、向量化访问等维度。[Paged Attention 设计说明](https://docs.vllm.ai/en/v0.32.0/design/paged_attention/) 可以帮助理解相应的设备侧访问方式，但其中展示的特定 kernel 不能代表当前所有 Attention 后端。

分页让请求按需获得块，不要求每条序列在物理内存中完全连续。不过，最后一块仍可能没装满，元数据和块表也有开销。

它同样不意味着每产生一个 token，就在 Python 中执行一次 GPU 内存分配。常见路径是在启动阶段准备 KV 内存池，运行中进行池内块的分配与映射管理。需要查找这些操作时，可以从 [KVCacheManager](https://github.com/vllm-project/vllm/blob/v0.32.0/vllm/v1/core/kv_cache_manager.py) 的 `get_computed_blocks()`、`allocate_slots()` 和 `free()` 入手。

### 与操作系统分页，像在哪里？

相似之处是逻辑地址与物理存储解耦，并以块为单位管理。

但这里通常由推理框架及 Attention 后端显式维护块表。不能仅凭“分页”两个字，就推断它默认拥有操作系统式的缺页异常，或者会透明地把活跃 KV 换入 CPU、磁盘。缓存卸载和跨实例传输属于另外的执行机制。

## 6. Prefix Caching：同一段开头，为什么可以只算一次？

设两个请求有完全相同的系统提示词和长文档，只是最后的问题不同。在模型及相关执行条件一致时，相同因果前缀的 KV 可以复用。

![图 10：两个请求共享相同前缀的缓存块] ![10-prefix-cache.png](https://developer.qcloudimg.com/http-save/yehe-12628201/b8e22bb822b0b344a13be312d2fcea59.png)

*图 10：共享的是已经计算好的 KV 块；不同问题的后缀和新答案仍需继续计算。*

vLLM V1 使用基于 hash 的识别方式：一个完整块的身份，包含当前块的 token、前序块的身份，以及需要纳入区分的额外信息。例如 LoRA、部分多模态信息或缓存隔离条件，都可能影响复用资格。V1 的这条前缀缓存路径主要复用完整块。[参考：Automatic Prefix Caching](https://docs.vllm.ai/en/v0.32.0/design/prefix_caching/)

为什么要把前面的内容也纳入身份？因为同样一句话出现在两个不同上下文后，其隐藏状态可能不同，只比较当前块的文字还不够。

应用侧也有一个直接启示：稳定且公共的内容适合放在前面，把变化内容放在后面。如果每次都在开头加入不同时间戳，即使后面有同一份长文档，也可能破坏可复用前缀。

这里有三个边界：

- 语义相似不等于 token 前缀相同。
- 前缀命中主要减少重复 prefill，不会自动生成新的答案，也不消除 decode 读取历史 KV 的成本。
- 命中多少个 KV token，不意味着一定能跳过等量的全部工作；例如仍可能需要为最后位置的 logits 做必要计算。

请求结束后，“释放”也可以只是减少其块引用。在没有活跃引用、但尚未被覆盖时，块内容仍可留在池中供后续命中；需要空间时再淘汰。因此，显存占用维持在较高水平，不足以单独证明发生内存泄漏。

## 7. 当块池不够用，系统怎么办？

调度器不能只看 token 预算，还要先确认本轮有地方保存新增 KV。

资源不足时，可能暂缓新请求，或者抢占正在运行的请求，之后重新推进。V1 常见的抢占恢复路径采用重计算，不能把历史资料中描述的 KV swap 当作当前所有配置的默认行为。[参考：Optimization and Tuning：Preemption](https://docs.vllm.ai/en/v0.32.0/configuration/optimization/#preemption)

抢占不代表用户的原始 token 序列消失了，但恢复已释放的中间状态需要额外工作。频繁抢占会让请求完成时间和尾延迟变得更难看。

调参时，应先判断是哪项资源不足：

| 现象或目标 | 优先检查 | 需要付出的代价 |
| --- | --- | --- |
| 活跃长序列放不下 | 上下文长度分布、并发数、KV 容量 | 降并发可能影响吞吐 |
| 权重占用过大 | 兼容量化方式、TP / PP | 量化有精度与后端要求；并行引入通信 |
| 首 token 等待过久 | 排队、prefill 预算、前缀命中 | 加大 prefill 工作可能影响 ITL |
| 持续输出被长输入拖慢 | chunked prefill 的混合工作量 | 小 chunk 也有调度与执行开销 |

`gpu_memory_utilization` 也要正确理解：它参与实例的设备内存预算与 KV 池容量计算，并不是“GPU 计算利用率”，更不是把全部显存按这个百分比直接交给 KV。权重与运行开销仍然需要占据预算。

至此，调度和缓存管理形成了闭环：调度器选择本轮推进的 token，缓存管理器提供对应的存储，执行结果再更新请求进度。下一步要看的是，这份计划怎样变成 GPU 上的高效算子，以及一份模型怎样由多张卡共同执行。

下一篇：[vLLM 推理原理（三）：GPU 怎样真正干活，多张卡又怎样协作？](https://cloud.tencent.com/developer/article/2767045)

## 参考资料与源码入口

1. [PagedAttention 论文](https://arxiv.org/abs/2309.06180)
2. [v0.32.0：Scheduler](https://github.com/vllm-project/vllm/blob/v0.32.0/vllm/v1/core/sched/scheduler.py)
3. [Optimization and Tuning](https://docs.vllm.ai/en/v0.32.0/configuration/optimization/)
4. [v0.32.0：GPU Model Runner](https://github.com/vllm-project/vllm/blob/v0.32.0/vllm/v1/worker/gpu_model_runner.py)
5. [Paged Attention 设计说明](https://docs.vllm.ai/en/v0.32.0/design/paged_attention/)
6. [v0.32.0：KV Cache Manager](https://github.com/vllm-project/vllm/blob/v0.32.0/vllm/v1/core/kv_cache_manager.py)
7. [Automatic Prefix Caching](https://docs.vllm.ai/en/v0.32.0/design/prefix_caching/)


摘要： 面对长短不一的生成请求，vLLM 如何兼顾并发、响应速度与有限显存？本文从连续批处理出发，用 token 预算和显存算例解释 Chunked Prefill、分页 KV、前缀缓存与抢占机制，展示调度器和缓存管理器如何协作，并厘清并发数、上下文长度、计算预算之间的关系，帮助读者理解常见配置的作用与代价。

vLLM 推理原理（二）：请求怎么排队，KV Cache 怎么住进显存？

云平台负责人

人工智能

后端

架构设计

vLLM通过连续批处理动态重组请求批次，以token预算调度prefill与decode混合执行。分页KV缓存实现物理块按需分配，解决长序列显存占用问题。前缀哈希缓存复用公共上下文，减少重复计算。当资源不足时触发抢占重算，平衡并发、响应速度与显存限制。

代码解释

数据流

Python

Kernel

LoRa

2026上云采购 | AI焕新·智启新局

tione

4核4G3M云服务器 新用户低至38元/年！

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

vLLM 推理原理（二）：请求怎么排队，KV Cache 怎么住进显存？-腾讯云开发者社区-腾讯云

vLLM 推理原理（二）：请求怎么排队，KV Cache 怎么住进显存？

vLLM 推理原理（二）：请求怎么排队，KV Cache 怎么住进显存？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐