[1] vLLM & Page Attention & Continuous Batching

姐姐你真好看.

101人浏览 · 2026-08-11 00:21:26

姐姐你真好看. · 2026-08-11 00:21:26 发布

视频：B站-怎么加快大模型推理？10分钟学懂VLLM内部原理，KV Cache，PageAttention
文档：vLLM官网文档

vLLM（virtual LLM）

伯克利 2023 开源的大模型推理 / 服务框架（SOSP 论文），用于把开源 LLM 部署成高性能 API 服务；核心创新 PagedAttention（分页注意力），解决 KV‑Cache 显存碎片，大幅提升 GPU 吞吐量、并发数。
定位：优先面向Decoder-Only模型生产级推理服务引擎，不是训练框架，只做推理 Serving。

背景痛点（传统 HuggingFace / TGI 旧方案）

Transformer 解码生成时，每一步都要保存KV‑Cache（每一层 Attention 的 K、V），占用绝大部分显存。

传统：每个请求分配一整块连续显存；请求长短不一、不断新建销毁 → 严重显存碎片，大量显存浪费（60‑80% 浪费），并发上不去，很容易 OOM（Out‑Of‑Memory）爆显存。
旧批处理：等整批全部请求完成，才接收新请求，GPU 经常空闲。

具体原因

在大模型推理时，按照可生成最长序列长度分配显存（VRAM）。
造成三种类型的浪费：

预分配，但不会用到
预分配，但尚未用到
显存之间的间隔碎片，不足以预分配给下一个文本生成
导致KV Cache预分配显存的利用率只有20%-40%。

vLLM解决方法

Page Attention 分页注意力
Sharing KV Cache
Continuous Batching 连续批处理

Page Attention 分页注意力(核心)

借鉴OS中的虚拟内存和页管理技术

把 GPU 显存切为很多固定大小物理 Block 块（一般每块存 16 个 token 的 KV）
逻辑上：每个对话序列 token 是连续；物理显存上，Block 可以分散、不连续
每个请求维护一张block_table页表：记录该请求的逻辑块，对应显存中哪一个物理块
按需分配：生成到哪个 token，才分配对应 Block；请求结束，Block 回收放回全局空闲池

类比：

传统：写文件必须分配一整块连续硬盘空间；

PagedAttention：硬盘分很多扇区，文件可以散落在不同扇区，靠文件分配表记录位置。

效果：KV‑Cache 显存浪费从 60‑80% 降到 4% 以内，同等 GPU 可承载并发大幅上涨。

KV Block

vLLM默认block_size=16，可以启动参数--block‑size修改。

对模型每一层，每个 Block 保存：block_size个 token，全部头的 K 向量 + 全部头的 V 向量。

举默认 16：

1 个物理 Block = 最多 16 个 token，每个 token 保存该层所有注意力头的 K、V。

❗不是 1 个 Block 只存 1 个头，是该层（Layers）全部头，16 份 token 的 K/V 全部塞在这个物理块。

KV Block

block_size 调参的权衡

block_size 调大（如 32）	block_size 调小（如 8）
每个 Block 装更多 token，块数量变少，块表变短，查表开销小	块数量变多，块表很长，间接寻址、调度开销上升，速度下降
内部碎片变多，很多 Block 用不满，显存浪费增加	碎片变少，显存利用率更高

虚拟内存

在逻辑KV Cache中，显存是连续的。

虚拟内存

vLLM框架会在后台维护一个逻辑KV Cache到实际物理显存KV Block的映射表

优点：

按需分配，不提前预分配
按Block分配，减少碎片大小
虚拟内存，方便实现调用

将KV Cache的利用率从20%-40%提升到96%

Sharing KV Cache

vLLM支持 KV Block 共享，分两大类场景，都建立在 PagedAttention 块 + 引用计数 ref‑count + 写时复制 COW (Copy On Write)之上。

Sharing KV Cache

Sharing KV Cache-COW

分两大类场景：

场景 1：同一个请求内部多分支（Beam Search / Parallel Sampling，默认就支持）

同一个 prompt，同时生成多条候选输出（beam 搜索、n>1 并行采样）。

例子：输入同一个 prompt，同时生成 2 条候选回答。

Prefill 阶段：prompt 部分的 KV Block，两份序列直接指向同一套物理 Block，只算一次 prefill，不复制多份 KV。ref_count 变成 2。
Decode 阶段，两条分支开始生成不一样的新词：

当某一个分支想要往 Block 追加新 token 的 KV 时，检测到ref_count>1（这块被别人共享）。

写时复制 Copy‑on‑Write：分配全新物理 Block，把旧块内容拷贝到新块，这个序列的块表切换指向新块；旧 Block 继续留给另一条分支共享使用。

只有发生分叉的那一刻才复制，前面共同上下文全程共享，节省大量显存。

场景 2：跨不同用户请求之间共享 —— Prefix Caching（APC-Automatic Prefix Caching 自动前缀缓存，需要手动开启）vLLM

启动参数：enable_prefix_caching=True

多个完全独立的用户请求，开头一大段 token 完全一模一样（例如企业服务，所有人共用一大段 system 系统提示词）。

例：

请求 A：【系统提示词】+用户A问题

请求 B：【系统提示词】+用户B问题

请求 A 先到达，prefill 算出系统提示词对应的 KV 物理 Block。
请求 B 过来，token 开头完全一样；vLLM 对每个 Block 做链式哈希，发现已经存在一模一样内容的物理 Block。
请求 B 的块表直接指向已经存在的物理 Block，不重复做 prefill 计算，不重复占用显存。ref_count +1。
到 token 分叉的位置，后面 Block 各自独立分配，不再共享。

还可以优化Beam search里的显存占用

Continuous Batching 连续批处理（动态批）

vLLM-Batch size

vLLM-Batch size
用更大的batch size来处理请求，从而提高吞吐量

普通静态 batch：必须等 batch 内全部请求生成结束，才能塞新请求，GPU 大量空转。

vLLM 连续批：

只要某个请求生成结束，立刻把新用户请求塞进 batch，不用等待整批完成。

结合 PagedAttention，不同长度、不同生成进度的请求混跑，GPU 尽量不空闲，最大化 token/s 吞吐量。

vLLM优缺点

vLLM 主要能力

原生 OpenAI 兼容 API 接口，可直接对接 LangChain、LangGraph、RAG 系统；支持流式输出vLLM
分布式推理：张量并行 TP、流水线并行 PP，支持 70B、405B 大模型多卡运行
丰富量化：AWQ、GPTQ、INT4/INT8、FP8；支持多 LoRA 同时加载服务
前缀缓存 Prefix‑Caching：多个请求共享相同 system prompt，KV 块复用，减少重复计算
支持推测解码、CUDA Graph 加速，对接 K8s、监控指标，适合线上生产部署vLLM

优点

高并发吞吐量极强：同等硬件对比原生 transformers，吞吐量提升数倍～二十多倍，线上 API 服务首选稀土掘金
长上下文友好：128K、256K 长对话 / RAG 场景，显存碎片被抑制，不容易 OOM
生态好：直接加载 HuggingFace 模型；支持 NVIDIA、AMD 显卡
工业界大量落地：企业私有部署、RAG 后端、Agent 服务普遍使用

缺点与局限

只做推理，不做训练（可以 LoRA 推理服务，不能做微调训练）
调试门槛比 TGI 高，部分小众模型需要适配
单机 CPU 上性能很差，主要面向 GPU；GGUF 支持属于实验特性，生产慎用
高并发下首 token 延迟 TTFT 会抬升，需要调优参数

vLLM vs TGI(HuggingFace) vs SGLang

框架	核心技术	优势	适合场景
vLLM	PagedAttention + 连续批	综合性能均衡，社区最火	通用大模型 API、RAG、Agent 线上服务
TGI	连续批，普通 KV 管理	HF 生态无缝、运维简单，开箱即用	小并发、快速原型，HF 重度用户
SGLang	RadixAttention（树状前缀缓存）	共享前缀复用更强，Agent/Few‑shot 场景更省显存	大量 system prompt、Few‑shot、Agent 集群

Ollama：侧重本地简单运行，没有 PagedAttention，不适合高并发线上服务，适合本地调试 Demo。

总结

vLLM 是伯克利开源的高性能 LLM 推理服务框架，核心是PagedAttention 分页注意力，借鉴操作系统虚拟内存管理 KV‑Cache，解决显存碎片化；搭配连续批处理 Continuous Batching，大幅提升 GPU 吞吐量与并发；主要用于线上 API、RAG、Agent 部署，不做模型训练。