🥌vLLM 初体验

vLLM

1. 传统内存分配的痛点（为什么浪费严重）

• KV Cache 需要连续大块内存：自回归生成时，序列长度动态增长 → 必须提前预分配一大段连续显存。

• 两大碎片化问题：
• 内部碎片：预分配过多，实际用不完的部分空闲浪费。
• 外部碎片：请求结束释放后，显存出现很多小空洞 → 无法放入新的大请求，即使总空闲够。

• 结果：显存利用率常只有 20–40%，GPU 计算资源严重闲置 → 吞吐量（tokens/s）和并发能力很低。

2. vLLM 的两大革命性优化（直接解决以上两大痛点）

A. PagedAttention（分页注意力）—— 内存分配的“操作系统式革命”

• 借鉴 OS 虚拟内存 + 分页机制：
• 把整个 KV Cache 切成固定大小的 小块（block/page）（通常每块存 16–32 个 token 的 K 和 V）。
• 这些块 不需要连续，可以散落在 GPU 显存的任何地方。

• 核心数据结构：
• 每个请求维护一个 块表（block table）：逻辑序列号 → 物理块 ID 的映射表。
• 注意力计算时，通过块表间接访问（自定义 CUDA 内核支持），计算结果和传统连续方式完全等价。

• 带来的巨大收益：
• 近零浪费：内存利用率从 <40% 提升到 >90–95%（碎片几乎消除）。
• 支持 KV 缓存共享/复用（相同 prompt 前缀、prefix caching、多轮对话复用块）。
• 允许动态增长/释放块 → 完美支持变长序列和高并发。

B. Continuous Batching（连续批处理）—— 计算资源的“永不空闲”

• 传统静态批处理：凑够一批请求，一起跑完所有序列才结束 → 快完成的序列空闲 padding，GPU 浪费；必须等最慢的那个结束才能进新请求。

• vLLM 的连续批处理：
• 每生成一个 token（每一步迭代）都 动态调整 batch：
• 已完成的请求 → 立即移除，释放其 Paged KV 块。
• 新请求 → 立即加入当前 batch（如果有空位）。
• 不需要 padding，GPU 始终满载。

• 必须依赖 PagedAttention：只有非连续块 + 块表，才能零开销地移除中间序列、插入新序列。

• 收益：
• GPU 利用率接近 100%。
• 吞吐量提升 2–24×（视模型、硬件、负载）。
• 平均延迟更低（快请求不被慢请求拖累），p50/p90 显著改善。

3. vLLM 整体架构简图

• API Server（FastAPI + Uvicorn）：OpenAI 兼容接口，高并发异步处理。

• 高性能推理内核（PagedAttention）：分页 KV Cache → 近零浪费 + 共享复用。

• 推理调度器（Scheduler）：Continuous Batching + 抢占式调度 → GPU 永不空闲、动态进出请求。

总结

vLLM

You are viewing the latest developer preview docs. Click here to view docs for the latest stable release.

https://docs.vllm.ai/en/latest/

「略」autoDL租赁机器

环境准备

conda准备

安装vllm和hf tools

模型下载

模型部署