摘要：大模型推理的瓶颈不是算力，是 KV Cache 显存。vLLM 用操作系统虚拟内存分页思想解决它：PagedAttention 分块管理 KV（近零浪费 + 块级共享），连续批处理让请求动态进出，吞吐较 FasterTransformer/Orca 提升 2-4×。本文精讲机制、串联 DeepSeek/GLM/K2 开源生态，附 FP8 部署实战与代码级精讲。
关键词：vLLM、PagedAttention、KV Cache、连续批处理、推理引擎、DeepSeek、GLM、FP8
引子：大模型推理的瓶颈，不是算力，是"内存"
你可能以为让大模型跑得更快，拼的是 GPU 算力。但真实部署中，最先卡死你的往往是显存——更准确地说，是KV Cache：每个请求在生成时都要缓存历史的 Key/Value，这个缓存巨大且动态增长，管理不好，一张 80GB 的 H100 也装不下几个并发请求[1]。
vLLM 用一篇 SOSP'23 论文级别的思想解决了这个问题：把操作系统的虚拟内存分页搬进 GPU[1]。如今，DeepSeek、GLM、K2 Horizon 这些开源模型的部署文档里，vLLM 是同一张面孔——它是开源模型生态的"水电煤"。
这篇从 KV Cache 的痛点讲起，拆解 PagedAttention 与连续批处理，最后给你一套可直接上手的 DeepSeek/GLM 部署实战。
一、先搞清楚：推理的瓶颈为什么是"内存"？
1.1 KV Cache 是什么、多大
大模型生成时，每个 token 都要"回看"之前的所有 token。为了不重复计算，系统把历史的Key 和 Value 缓存下来——这就是 KV Cache。它的规模有多夸张？
KV Cache ≈ 2 × 层数 × 头数 × 头维度 × 序列长度 × 字节数 例：70B 模型、128K 上下文、单请求 ≈ 数十 GB → 显存里最贵的"住户"，而且逐 token 增长1.2 传统系统的三大浪费
论文指出现有系统的三个痛点[1]：
痛点 | 表现 |
|---|---|
预分配 | 提前按"最大可能长度"分配整段内存，实际用不满 → 内部碎片 |
外部碎片 | 各请求长度不一，内存块零散，无法组合利用 |
不共享 | parallel sampling / beam search 的多条序列重复存同一份前缀 KV |
结果：显存浪费严重，批大小被内存卡死——再强的 GPU 也算不动[1]。
二、PagedAttention：把操作系统搬进 GPU
2.1 分页思想的三连
PagedAttention 的灵感来自操作系统的虚拟内存分页：逻辑上连续，物理上可以零散。KV Cache 不再为每个请求预留整段连续内存，而是切成固定大小的块（block），按需分配[1]。
三个关键设计[1][2]：
分块：KV Cache 切成固定大小的页（如每页 16 个 token 的 K/V）
按需：生成到哪，页分配到哪——用多少、占多少
共享：块粒度共享——同一请求的 parallel sampling 序列、beam search 分支、甚至跨请求的公共前缀，都能复用同一批块
2.2 块级共享如何支撑复杂解码
传统系统无法在序列间共享 KV，导致 beam search 的每个分支都要完整复制前缀缓存。PagedAttention 的块级共享让分支只"引用"共享块，新增分支的显存成本趋近于零——这是它对比 FasterTransformer/Orca 的吞吐优势的重要来源[1]。
2.3 论文数据
在 PagedAttention 之上构建的 vLLM 实现了KV Cache 内存近零浪费，吞吐量相比当时最先进的 FasterTransformer、Orca 提升2-4×——且序列越长、模型越大、解码越复杂（beam search 等），优势越明显[1]。
三、连续批处理：请求动态进出
3.1 传统批处理 vs 连续批处理
传统批处理"整批同进同出"：先到的请求要等后到的，最慢的拖累整批。连续批处理让请求到达即入批、完成即出批，GPU 流水线上始终有活干[1][2]。
3.2 与分页内存如何协同
分页内存解决"装得下"：显存利用率高，能容纳更多并发序列
连续批处理解决"跑得满"：调度粒度细，GPU 时刻满载
两个机制缺一不可：内存装得下更多请求，调度才能让它们动态流转——这是 vLLM 高吞吐的两个引擎。
四、vLLM 全景：不止 PagedAttention
生产级推理引擎需要更多拼图[2][3]：
能力 | 说明 |
|---|---|
量化 | AWQ / GPTQ / FP8 / INT8，低精度换吞吐 |
张量并行（TP） | 单模型切到多卡 |
流水线并行（PP） | 按层切分，跨节点 |
prefix caching | 公共前缀（system prompt）缓存复用 |
OpenAI 兼容 API |
|
vLLM 支持几乎所有主流开源架构——Llama、Qwen、DeepSeek、GLM-4（THUDM/glm-4-9b-chat-hf）都在列表里[2]。
五、热点串联：开源模型生态的"共同底座"
最近几个开源大事件，部署层都是同一张面孔：
DeepSeek V4 权重开源（8 月）：社区部署指南的默认引擎是 vLLM[5]
GLM 5.2：官方 recipe 直接给出 vLLM 的 FP8 部署命令[4]
K2 Horizon（9 月）：开源模型推理同样落在 vLLM 生态
推理引擎是开源模型的"水电煤"——模型是内容，vLLM 是管道。模型再多，没有高效的管道，都到不了用户手里。这也是本期选它做深度剖析的原因：看懂 vLLM，就看懂了大模型落地的"最后一公里"。
六、实战：vLLM 部署 DeepSeek/GLM + 调用 + 观测
环境：NVIDIA GPU（推荐 A100/H100 或 4090 级别）+ CUDA。以下命令基于官方文档与生产实践[2][4][5]。
6.1 部署命令
# 安装 pip install vllm # 部署 GLM-5.2（FP8 量化 + 张量并行 + 前缀缓存）——生产配置参考[4] vllm serve "zai-org/GLM-5.2-FP8" \ --tensor-parallel-size 8 \ --max-model-len 262144 \ --kv-cache-dtype fp8 \ --enable-prefix-caching \ --port 8000 # 部署 DeepSeek 系（控制并发序列数）[5] vllm serve "deepseek-ai/DeepSeek-V4" \ --max-num-seqs 32 \ --gpu-memory-utilization 0.9 \ --port 8001参数解读：
--tensor-parallel-size 8：模型切到 8 卡并行--max-model-len 262144：256K 上下文（GLM 5.2 长上下文配置）--kv-cache-dtype fp8：KV 缓存也用 FP8，显存减半--enable-prefix-caching：系统提示词等公共前缀复用--max-num-seqs 32：并发序列上限（越大吞吐越高、显存线性增加）
6.2 OpenAI 兼容调用
from openai import OpenAI client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY") resp = client.chat.completions.create( model="zai-org/GLM-5.2-FP8", messages=[{"role": "user", "content": "用一句话解释 PagedAttention"}], max_tokens=128, ) print(resp.choices[0].message.content)应用零改造——只要把base_url指到 vLLM，任何 OpenAI SDK 应用都能切换到底层开源模型[2]。
6.3 吞吐观测与调优
# vLLM 启动日志会输出吞吐指标： # Avg prompt throughput / Avg generation throughput # 用 vllm-bench 压测不同并发下的吞吐-延迟曲线 python -m vllm.bench.benchmark_throughput \ --model zai-org/GLM-5.2-FP8 \ --max-num-seqs 32 --num-prompts 1000调优三板斧：先看 KV cache 利用率（--gpu-memory-utilization往上顶）、再调--max-num-seqs（并发与显存权衡）、最后开--enable-prefix-caching（有公共前缀时收益明显）[5]。
七、代码级精讲 + 我的观点
7.1 BlockManager 与 Scheduler：两个心脏
vLLM 的核心代码里，有两个模块撑起整个系统[2][3]：
BlockManager：管理物理块分配——维护 free block 列表、引用计数（块级共享的实现处）、页表映射（逻辑页 → 物理块）
Scheduler：连续批处理调度——决定哪些序列占用 GPU、哪些抢占（preempt，把不活跃序列的块换出）
理解它们的关键：把 KV 当"虚拟内存"管——BlockManager 是"内存管理单元"，Scheduler 是"进程调度器"。OS 教科书上的概念，在 GPU 显存里原样重演[1][2]。
7.2 三个判断
判断一：分页思想是 LLM 服务工程的分水岭。PagedAttention 之前，KV 管理是"粗放预分配"；之后是"精细分页"。这个思想已被 vAttention 等后续工作延续、挑战、演进[1]。
判断二：推理引擎是开源模型生态的隐形冠军。模型参数、框架、Agent 项目刷屏，但真正决定"模型能不能用起来"的是 vLLM 这类基础设施——生态的话语权正在向推理层转移。
判断三：量化 + 分页 + 调度是未来三年的主战场。FP8 已经进 KV Cache；下一步是稀疏化、推测解码与更智能的调度——每省一分显存，就多一分并发。
7.3 两个风险
工程复杂度：分页、抢占、多卡并行的边界情况极多，自建推理栈需要极强的系统能力——生产环境优先用成熟发行版
生态锁定：vLLM 的调度与内存模型深度绑定，迁移到其他引擎有成本——评估时考虑可替代性[3]
从"装不下"到"装得下、跑得满"，vLLM 用一次 OS 思想的移植，把大模型推理从作坊带进了工厂。而这一切都是开源的——这就是开源 AI 基础设施最性感的模样。
参考资料
信源编号对应
02-情报.md信源清单。
[1] arXiv:2309.06180：Efficient Memory Management for Large Language Model Serving with PagedAttention（SOSP'23）（一级）
[2] vLLM 官方文档（docs.vllm.ai）（一级）
[3] GitHub vllm-project/vllm（一级）
[4] 阿里云开发者社区：GLM 5.2 自托管部署实战（2026-06-17）（二级）
[5] 腾讯云开发者社区：DeepSeek 大模型本地部署与调用全指南（2026-08-15）（二级）
[6] 稀土掘金：vLLM 生产环境部署踩坑实录（2026-08-11）（三级）
