vLLM 推理底层结构深解：PagedAttention、Token流式与并发调度解析

个人简介

作者简介：全栈研发，具备端到端系统落地能力，专注大模型的压缩部署、多模态理解与 Agent 架构设计。 热爱“结构”与“秩序”，相信复杂系统背后总有简洁可控的可能。
我叫观熵。不是在控熵，就是在观测熵的流动
个人主页：观熵
个人邮箱：privatexxxx@163.com
座右铭：愿科技之光，不止照亮智能，也照亮人心！

专栏导航

观熵系列专栏导航：
AI前沿探索：从大模型进化、多模态交互、AIGC内容生成，到AI在行业中的落地应用，我们将深入剖析最前沿的AI技术，分享实用的开发经验，并探讨AI未来的发展趋势
AI开源框架实战：面向 AI 工程师的大模型框架实战指南，覆盖训练、推理、部署与评估的全链路最佳实践
计算机视觉：聚焦计算机视觉前沿技术，涵盖图像识别、目标检测、自动驾驶、医疗影像等领域的最新进展和应用案例
国产大模型部署实战：持续更新的国产开源大模型部署实战教程，覆盖从 模型选型 → 环境配置 → 本地推理 → API封装 → 高性能部署 → 多模型管理 的完整全流程
TensorFlow 全栈实战：从建模到部署：覆盖模型构建、训练优化、跨平台部署与工程交付，帮助开发者掌握从原型到上线的完整 AI 开发流程
PyTorch 全栈实战专栏： PyTorch 框架的全栈实战应用，涵盖从模型训练、优化、部署到维护的完整流程
深入理解 TensorRT：深入解析 TensorRT 的核心机制与部署实践，助力构建高性能 AI 推理系统
Megatron-LM 实战笔记：聚焦于 Megatron-LM 框架的实战应用，涵盖从预训练、微调到部署的全流程
AI Agent：系统学习并亲手构建一个完整的 AI Agent 系统，从基础理论、算法实战、框架应用，到私有部署、多端集成
DeepSeek 实战与解析：聚焦 DeepSeek 系列模型原理解析与实战应用，涵盖部署、推理、微调与多场景集成，助你高效上手国产大模型
端侧大模型：聚焦大模型在移动设备上的部署与优化，探索端侧智能的实现路径
行业大模型 · 数据全流程指南：大模型预训练数据的设计、采集、清洗与合规治理，聚焦行业场景，从需求定义到数据闭环，帮助您构建专属的智能数据基座
机器人研发全栈进阶指南：从ROS到AI智能控制：机器人系统架构、感知建图、路径规划、控制系统、AI智能决策、系统集成等核心能力模块
人工智能下的网络安全：通过实战案例和系统化方法，帮助开发者和安全工程师识别风险、构建防御机制，确保 AI 系统的稳定与安全
智能 DevOps 工厂：AI 驱动的持续交付实践：构建以 AI 为核心的智能 DevOps 平台，涵盖从 CI/CD 流水线、AIOps、MLOps 到 DevSecOps 的全流程实践。
C++学习笔记？：聚焦于现代 C++ 编程的核心概念与实践，涵盖 STL 源码剖析、内存管理、模板元编程等关键技术
AI × Quant 系统化落地实战：从数据、策略到实盘，打造全栈智能量化交易系统

---

vLLM 推理底层结构深解：PagedAttention、Token流式与并发调度解析

---

✨ 摘要：

vLLM 是当前大模型推理部署领域最受欢迎的框架之一，
它在不改变模型结构的前提下，显著提升了推理吞吐与并发能力，
支持token 流式输出（Streaming）、长上下文支持、OpenAI API 接口无缝适配等一系列强特性。
本篇将以系统级视角，深入解析 vLLM 的关键优化模块——PagedAttention 的设计原理、KV 缓存机制、Token Scheduling 算法与高并发调度策略，
并结合实际部署经验，告诉你：

“为什么 vLLM 能让同样的模型推理 TPS 翻倍？”
本文适合希望将 Huggingface 权重部署为生产级服务、追求低延迟与高吞吐的开发者与系统工程师。

---

🧭 目录：

1. 为什么传统推理框架在多轮对话中效率低下？
2. vLLM 的核心架构介绍：模块拆解与执行流程
3. 深度拆解 PagedAttention：内存分页、KV 缓存映射与懒回收机制
4. Token 输出为啥快？Streaming Decode 的 token-level 优化逻辑
5. 并发调度器如何提升吞吐？Token Round-Robin 与 batching 机制分析
6. vLLM 在生产部署中的最佳实践（模型加载、worker 启动、接口路由）
7. 本篇总结：vLLM 的优势、限制与应用推荐路径

---

1. 为什么传统推理框架在多轮对话中效率低下？

你可能已经部署过大模型，发现一个现象：

单轮问答 TPS 勉强过得去，到了多轮对话就「断崖式下滑」，响应延迟暴涨，显存突然飙高。

这是传统推理引擎的一个普遍痛点，尤其是在 Chat 类应用中 ——
token 流式响应、KV 缓存管理、上下文复用等细节处理不到位，
会让你训得再好的模型，跑起来依然像「拖着沙包」。

---

🎯 原因一：KV 缓存重复计算

以 Huggingface Transformers 为例，它的推理行为是这样的：

用户输入：Hello → 模型输出第一 token → 缓存 KV → 输入新 token → 全部重复计算

每轮都要重新走一遍长上下文计算 → 浪费极大。

---

🎯 原因二：Multi-turn Chat = 长上下文爆炸

轮数	累计上下文长度
单轮	256 tokens
4 轮	1200+ tokens
8 轮	2000+ tokens

→ 若未做 KV 管理优化，显存 / 延迟会呈指数增长。

---

🎯 原因三：缺乏批处理并发调度

传统推理：一个请求 → 一个模型 → 一次前向
→ 无法拼 batch，token-level granularity 太粗
→ GPU 资源利用率非常低（只有一个 token 正在跑）

---

✅ vLLM 设计目标总结：

vLLM 的全部核心优化围绕这三点：

问题	vLLM 解决方式
重复计算 → 慢	✅ KV Cache 分页 + PagedAttention
上下文拉长 → 显存爆	✅ 动态分配 + 映射 + 延迟回收
并发低 → TPS 低	✅ Token Scheduling + 请求合并调度

---

2. vLLM 的核心架构介绍：模块拆解与执行流程

vLLM = Visionary Language Model Server（开玩笑 😄）
vLLM 实际是 Huggingface 模型 + 高性能 KV 管理 + Streaming Scheduler 的融合体。

---

🧱 核心架构图概览：

┌────────────────────────────┐
│         Web API 接口层     │ ← OpenAI 风格 API（兼容）
├─────────────┬──────────────┤
│ Token Scheduler │ Request Router │ ← 动态合并 & token-level 执行
├─────────────┴──────────────┤
│       PagedAttention Engine        │ ← 核心：KV 分页映射 & 懒惰清理
├────────────────────────────┤
│    Huggingface Transformer        │ ← 支持所有 HF 权重 + LoRA
└────────────────────────────┘

---

🔍 模块解析：

✅ 1. Web API 接口层

• 完全兼容 OpenAI API 格式
• 支持流式输出（stream=True）
• 支持异步请求并发（asyncio + fastapi）

✅ 2. Token Scheduler

• 以 token 为最小调度单元（而非 batch）
• 动态收集多个用户请求 → 拼接 → 一起执行 → 再分发返回结果
• 支持：
  • Round-Robin Scheduling（默认）
  • FIFO / Priority Scheduling（可定制）

✅ 3. PagedAttention Engine

• 真正的性能黑科技（我们下节详细讲）
• 将传统 KV Cache 改为 内存分页映射结构，允许：
  • 单轮多 token 精准查找
  • KV 缓存动态分配 / 回收
  • 极大降低上下文冗余

✅ 4. Huggingface Model Core

• 无需修改模型结构
• 支持原生 Transformers 权重 + peft LoRA 插件
• 可自动切换至 fp16/bf16 运行模式

---

3. 深度拆解 PagedAttention：内存分页、KV 缓存映射与懒回收机制

✳️ 背景回顾：传统 KV Cache 如何拖垮推理效率？

在标准 Huggingface 推理中，Transformer 的注意力机制会为每个输入保存：

• K（Key）向量缓存
• V（Value）向量缓存

默认做法是：

KV Cache = List[BatchSize][SeqLen][Head][Dim]

每当你追加新的 token，模型就会重新构建完整 attention mask、重新加载全量 KV。
长上下文、多个请求一起跑，就会导致：

• ❌ 显存激增
• ❌ KV 内存碎片严重
• ❌ token 推理串行化，吞吐急剧下降

---

✅ vLLM 的创新点：引入分页式注意力机制（PagedAttention）

你可以类比操作系统的内存管理方式：

不再把 KV Cache 视为连续长数组，而是划分为「内存页」（pages），并通过页表进行管理和映射。

---

🔍 架构核心：KV Cache × Paged Memory × Page Table

✅ KV 被切分成“页”：

KV_Pool = List[Pages]  # 每页大小固定，如 512 tokens

✅ 每个请求维护自己的「虚拟页表」：

Request KV Map = {
  request_1: [page_2, page_5, page_8],
  request_2: [page_3, page_7]
}

不同请求共享物理页，但拥有独立逻辑地址映射。

---

🧠 优势 1：动态分配 + 精准复用

• 每次生成新 token，只需要增量追加当前 token 的 KV → O(1) 写入
• 多轮历史 KV 只需保留引用 → O(1) 复用
• 无需拷贝整个上下文 → 显存显著下降

---

🧠 优势 2：懒回收 + 压缩机制

• 如果请求中止、KV 超过最大页数 → 仅回收未活跃页
• 冷热页判定机制 + 精细回收算法，可实现「边跑边释放」

---

🧠 优势 3：长上下文性能稳定

以 LLaMA2-7B 为例：

上下文长度	Huggingface TPS	vLLM TPS（PagedAttention）	提升比
512 tokens	500 tok/s	510 tok/s	≈ 1.0×
2048 tokens	180 tok/s	500 tok/s	≈ 2.8×
4096 tokens	❌ OOM	480 tok/s	✅ 可用！

---

📦 内部执行流程图（简化）：

请求 A：
"Hi, how are you?" → 分页 → page_1, page_2

请求 B：
"Tell me a joke..." → 分页 → page_3, page_4

新 token 到来：
→ 仅追加新页（page_5）  
→ 原上下文只查页表，无需重构整个 KV

生成时：
→ 每个 token 从对应 page 中 fetch KV → 注意力计算 → 输出

---

✅ 为什么这就是 vLLM TPS 起飞的秘密？

PagedAttention 让大模型推理从原本的：

一次请求 = 整个上下文重新算一遍

变成了：

一次请求 = 仅处理新增 token + 已缓存页重用

这就是**“Token 级增量推理”**，
这也是为什么你把同一个模型扔进 vLLM，TPS 立刻翻倍，长上下文还能不卡。

---

4. Token 输出为啥快？Streaming Decode 的 token-level 优化逻辑

---

🧩 背景问题：为什么很多框架支持 stream=True，但响应还是慢？

这是很多人搞混的一个点：

“stream=True ≠ 每个 token 都能即时返回。”

在 Huggingface Transformers 默认行为下：

• token 是 batch 级别执行的
• 等待整个 forward pass 后，才能开始发送 response
• 在高并发场景中，你仍然会等整批 token 全部生成

结果就是：响应延迟并未真正下降，用户仍需等待首个 token 被 return。

---

✅ vLLM 的 Streaming 设计思路：Token-first，异步调度

vLLM 的关键优化逻辑是：

把每个 token 的生成、缓存、发送 变成三条独立可并发的流水线

---

🎯 执行流程解析：

1. 用户请求发起（stream=True）

2. Token Scheduler 收到请求 → 拆成 token 级别执行任务

3. 第一个 token 被计算出来后（比如 "Hello"）→ 立即推入输出队列

4. 后续 token 一边计算、一边通过 Streaming Server 持续送出

最终形成：

[Request Queue] → [Token Decode Engine] → [Output Stream Dispatcher]

---

🧠 核心机制解析

✅ 1. Token-Level Granularity Decode

vLLM 使用 token 作为最小调度单位，而不是句子 / batch，带来两个结果：

• 多用户可同时调度单 token 请求（共享 GPU 计算资源）
• 前一个 token decode 完，不等后面的，一起送出

✅ 2. Async Token Dispatch（异步输出推流器）

vLLM 的 Streaming Server 构建在 FastAPI + asyncio + SSE（Server-Sent Events） 之上，支持：

• 每个用户请求维护独立的输出 buffer
• 计算线程将 token 推入 → 输出线程监听并异步 send
• 实现类似 ChatGPT 风格的“字一个个滚出来”的体验

✅ 3. 动态抢占调度（Token Round-Robin）

多个用户的 decode 请求，按 token 跨轮分配：

用户A: T1 → T2 → T3
用户B: T1 → T2 → T3
调度：A.T1 → B.T1 → A.T2 → B.T2 → ...

这样可以确保：

• 所有请求都“活跃”起来，而非一个跑完再换另一个
• 在 token 数不一致的情况下，公平且 GPU 利用率高

---

📊 实测效果对比（LLaMA2-7B，stream=true）：

框架	首 token 响应时间（ms）	总 latency（10 tokens）	notes
HF Transformers	2200 ms	2600 ms	首 token 等待 full batch
vLLM	320 ms	820 ms	每个 token 都立即 decode + send

---

✅ 可视化概念图：

[用户请求] → Token1 → 即时发出
             Token2 → ↓
                     → Token3 → ↓
                              → ...
   （而不是等所有 Token 都出来才发）

---

✅ 特别适配场景：

场景	原因
多轮对话	每轮只等首 token，响应体验大幅提升
智能客服 / 助手	快速返回首字，模拟人类“思考中”
前端流式 UI	支持 OpenAI 风格 SSE / Websocket 无缝对接

---

⚠️ 注意事项：

• 若模型本身不支持动态 shape（如 GPTQ 格式），stream 也会受限
• 推荐结合 PagedAttention + Streaming Decode 才能发挥最大价值
• 请求非常多时建议限制 max_tokens + 设定 stream timeout，防止阻塞

---

5. 并发调度器如何提升吞吐？Token Round-Robin 与 Batching 机制分析

---

🎯 背景问题：为什么你的模型吞吐起不来？

在传统推理架构中，即使你是多用户请求，最终表现也往往是「串行处理」：

• 请求 A 完整生成 → 再处理请求 B
• 或者 batch 拼不上，每轮只跑一个用户
• GPU 时间利用率极低，大部分资源在等待和复制数据

---

✅ vLLM 的目标：让多个请求在“token级”打通协同执行管线

不是一个 request 一次 forward，而是多个 request 的多个 token 拼成一次 forward！

这就引出 vLLM 的核心调度策略：

---

🧠 核心机制一：Token-level Round-Robin Scheduling

传统：BatchSize 个请求，依次执行 N 个 token
vLLM：轮流在每个 request 之间调度下一个 token

示例：

请求 A：token1, token2, token3  
请求 B：token1, token2  
请求 C：token1, token2, token3, token4

vLLM 调度顺序：
A.token1 → B.token1 → C.token1 → A.token2 → B.token2 → C.token2 → ...

---

✅ 优点：

优势	说明
🚀 提高吞吐	每轮调用都是 batch，避免 token 分散执行
⚖️ 保证公平	所有用户轮流拿 token，响应时间不会差距太大
⏱ 降低延迟	首 token 不必等完其他请求，快速送出
💡 提高显存复用率	KV Cache 页共享，PagedAttention 组合生效

---

🧠 核心机制二：动态 Batch Grouping + 静态编译融合

vLLM 的调度器在每轮 Forward 前：

1. 收集所有可调度的 token（多用户）
2. 按 token shape 分组（batch-size, seq-len）
3. 生成 Batch Group → 提交到 GPU 一次 forward

👉 这就变成了“异构 batch 静态融合执行”，对 GPU kernel 非常友好。

---

📊 实测吞吐效果（LLaMA2-7B, batch size = 32, 1024 ctx）：

框架	tok/s（总吞吐）	平均响应延迟（ms）
Huggingface Transformers	~500 tok/s	~2200 ms
vLLM（RoundRobin）	~2800 tok/s	~520 ms

🚀 吞吐提升接近 5 倍，响应缩短接近 4 倍！

---

✅ vLLM 调度器还支持什么？

能力	说明
OpenAI 风格最大 token 控制	max_tokens per request 精准调度
Stream / 非 stream 请求混合	同时管理两个流派的输出模式
Prompt Cache 机制	多轮共享 KV page，避免重复 decode history
Token Dropping	对异常长请求可触发 truncate 或提前终止

---

⚠️ 使用建议与限制：

项目	建议
若想最大化吞吐	设置合理 --max-num-seqs（如 128）保证并发拼 batch 数量
若请求差异大	开启 --disable-log-stats 避免调度日志阻塞
若接企业服务	将调度器挂入 FastAPI / Uvicorn，实现外层负载均衡

---

6. vLLM 在生产部署中的最佳实践（模型加载、Worker 启动、接口集成）

你已经明白 vLLM 为什么快了，那怎么把它跑在线上环境中？

---

✅ 一句话概括部署思路：

用最少改动把 Huggingface 模型部署为类 OpenAI 接口的高并发推理服务。

---

🛠️ Step-by-step 快速部署指南

Step 1：准备模型

# 建议使用已合并 LoRA 的 Huggingface 格式权重
# 支持 .bin / .safetensors

Step 2：启动 vLLM OpenAI 接口服务

python -m vllm.entrypoints.openai.api_server \
  --model /path/to/merged_model \
  --tokenizer /path/to/tokenizer \
  --tensor-parallel-size 1 \
  --max-model-len 4096 \
  --dtype float16

💡 启动后默认绑定 8000 端口，可用 curl / Postman / 前端 SDK 直接调用

---

✅ 接口兼容性说明：

功能	是否支持	说明
/v1/chat/completions	✅	完全兼容 OpenAI Chat API
stream=true	✅	支持 SSE 流式输出
stop/temperature/max_tokens	✅	全部支持
多轮对话	✅	用 history 填入 prompt，即可上下文推理

---

✅ 部署调优参数建议：

参数	建议值	说明
--max-num-seqs	128	支持并发请求上限
--max-model-len	4096 / 8192	支持长文本上下文
--disable-log-stats	✅	减少日志阻塞，适合线上
--trust-remote-code	✅	若使用自定义模型结构如 Qwen、Baichuan

---

✅ 多机部署推荐：

• 每台机器单独运行一个 vLLM 实例，监听不同端口
• 使用 Nginx / Traefik 做负载均衡 + HTTPS 接入
• 建议搭配 token 缓存策略 + 多模型副本 + streaming proxy

---

📘 本篇总结：vLLM 的性能秘诀与工程路线

模块	关键优化点
PagedAttention	内存分页式 KV Cache，极致上下文管理
Streaming Token Decode	token 级异步输出，首字响应低延迟
Token Scheduler	并发 token 调度，批处理融合提升吞吐
OpenAI 接口层	即插即用 REST 服务，对接无痛
LoRA 兼容性	支持轻量微调后的模型部署，不影响结构

---

🧠 vLLM 推荐使用路径（工程落地视角）

场景	建议配置
API 服务部署	vLLM + Huggingface 模型 + OpenAI 接口
多轮对话 / 长文本摘要	开启 --max-model-len=8192，配 PromptCache
快速原型测试	合并 LoRA 后直接启动 vLLM 服务
对吞吐要求极高场景	搭配 Tensor Parallel × 多实例 Nginx 负载均衡

---

🌟 如果本文对你有帮助，欢迎三连支持！

👍 点个赞，给我一些反馈动力
⭐ 收藏起来，方便之后复习查阅
🔔 关注我，后续还有更多实战内容持续更新

---

写系统，也写秩序；写代码，也写世界。
观熵出品，皆为实战沉淀。