vLLM 与 PagedAttention：把 GPU 显存当操作系统内存管

服务化痛点：显存被 KV Cache 浪费掉了

两个名词先解释：**KV Cache（键值缓存）**是自回归生成时为每个请求保存的注意力中间结果，有了它，每生成一个 token 就不用重算整段历史；吞吐是单位时间能处理完的请求数，是推理服务最重要的指标之一。

痛点出在传统方案的显存分配方式：按「最大序列长度」给每个请求预留一整块连续显存。请求实际只生成了 200 个 token，却提前占着按几千 token 预留的空间；剩下的零碎空隙装不下新请求，只能空着。量级上，这类预留式分配的真实利用率往往只有两三成——大头显存「占了没用」，同卡能并发的请求数上不去，吞吐自然卡死。最朴素的应对是换更大的卡，但显存翻倍、价格不止翻倍；先把手头显存的浪费挤出来，才是性价比最高的第一步。

PagedAttention：向操作系统借思路

vLLM（源自 UC Berkeley 的开源推理引擎）的解法叫 PagedAttention，核心思想一句话：把操作系统的虚拟内存分页搬到 GPU 显存管理上。

• 把 KV Cache 切成固定大小的块（block），物理块在显存里不要求连续
• 每个请求维护一张块表（block table），把逻辑序列的位置映射到一个个物理块
• 按需分配：生成进行到哪一步，才占用哪一块，不再按最大长度预留
• 共享与写时复制：多个请求共享同一段前缀（比如同一个 system prompt）时，直接指向同一批物理块；谁要改写，谁再复制一份——即写时复制（Copy-on-Write）

展开这个类比：操作系统把进程的虚拟地址空间切成固定大小的页，用页表把虚拟页映射到零散的物理页帧，程序只管用连续的虚拟地址，不关心数据物理上躺在哪。PagedAttention 里，模型「看到」的仍是一条连续的逻辑序列，背后的物理块却零散分布——连续性由块表在访问时翻译出来。

这与操作系统当年用分页消灭内存外部碎片是同一个思路：把「连续预留」改成「离散按需」，显存利用率从两三成拉到接近满载。

收益与连续批处理

收益定性地说：浪费掉的头寸被挤出来，同一张卡能同时容纳的请求数显著增加，吞吐量级上升。具体数字因模型、序列长度分布与负载而异，官方与社区的公开对比普遍显示数倍量级的提升——请以自己负载的实测为准。

第二个关键机制是连续批处理（continuous batching）。传统静态批处理攒一批请求、等最长的那个跑完才能进下一批，短请求被长请求拖死——实现简单，代价是队头阻塞。连续批处理把调度粒度从「批」细化到「步」：每步迭代后动态调度，有请求完成立刻腾位置，新请求随到随进队。它与 PagedAttention 配合——正因为 KV Cache 可以离散分配，请求进出批才不需要重新规划显存。

快速上手

上手需要一张 NVIDIA 显卡与足量显存：7B 级模型用 16GB 级显存的单卡（消费卡或云上按量租用）即可起步（估算量级）。安装与服务启动：

pip install vllm
vllm serve Qwen/Qwen2.5-7B-Instruct \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.9

服务起在 8000 端口，接口与 OpenAI 兼容：

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen2.5-7B-Instruct",
    "messages": [
      { "role": "user", "content": "用一句话解释什么是 KV Cache" }
    ]
  }'

代码里已经在用 openai SDK 的话，把 base_url 指向本地服务，几乎零改动就能迁移。

常用参数

• --max-model-len：单个请求的最大上下文长度。设得越大，单请求峰值占显存越多，能并发的请求就越少；按业务真实需要的长度设，不要默认拉满
• --gpu-memory-utilization：允许 vLLM 占用的显存比例（模型权重加 KV Cache 池），默认 0.9；与训练等其他任务同卡共存时要调低
• 量化加载：通过 --quantization 指定量化方案加载权重，用一点精度换显存，让单卡装下更大的模型，属进阶玩法，一句带过

边界

个人电脑上本地玩小模型，Ollama 这类方案更省心（参见本站《Ollama 实战指南》）。vLLM 的主场是高并发服务化：追求吞吐、延迟与显存利用率、把一张卡榨干的场景。它不是聊天产品，而是给服务端用的引擎——当你的 AI 应用需要同时伺候成百上千个请求时，就该它出场了。选型时可以先问三个问题：并发量有多大、单请求上下文多长、预算是一张卡还是一排卡——答案落在「并发高、上下文长、卡要省」这一侧，vLLM 就是正确答案。

小结

• 预留式显存分配是并发吞吐的瓶颈：按最大长度预留，利用率常常只有两三成
• PagedAttention 借鉴操作系统分页：KV Cache 切块、块表映射、按需分配、写时复制，把浪费挤出来
• 连续批处理让请求随到随进队，调度粒度从批细化到步
• 上手成本低：pip 装完一条命令起 OpenAI 兼容服务；--max-model-len 与 --gpu-memory-utilization 是最该先调对的两个参数