1. vLLM 是什么

这是什么：vLLM = 把大模型塞进显卡、对外提供 HTTP 接口的高性能推理引擎。

为什么用：上一章的 大语言模型 LLM 让你认识了模型，可模型权重动辄几十上百 GB，真跑起来还会被显存和「一次只服务一个人」卡住。

如何用：本章先看懂它的两个核心本事，再把它和 Ollama 摆一起比，最后说清硬件门槛。

1.1 它站在推理链条的哪一环

一次对话要经过几段：你的问题进程序 → 文字切成 token → 模型在显卡上一步步算下一个 token → 结果变回文字发给你。

vLLM 干的是中间那两段：加载权重、调度请求、在显卡上跑模型。它不训练模型，也不做检索增强，是纯粹的「推理引擎」，所以能套在任何模型前面——Qwen、Llama、DeepSeek 都行。

1.2 第一个本事：PagedAttention（分页注意力）

模型跑起来要存一样东西：KV cache（键值缓存）——把算过的上下文留下来，避免重复计算。

老办法是给每个请求划一块连续显存。问题是长度不一：短问答浪费一整块，长文档又不够分，显存里全是碎片。

vLLM 把 KV cache 切成固定大小的页，像操作系统的虚拟内存一样按需分配：

# 传统做法：给每个请求预留一整块连续空间
reserved = {"req-1": 4096, "req-2": 4096}   # 实际只用了 300 和 500 个 token

# PagedAttention：切成固定大小的页，用多少占多少
PAGE_SIZE = 16
pages = {"req-1": 19, "req-2": 32}          # 19 页 + 32 页 = 816 个 token

你会看到（示意）：

传统方式预留: 8192 tokens，实际只用了 800，利用率 9.8%
分页方式预留: 816 tokens，实际用了 800，利用率 98.0%

同样的显存，能塞下的请求数翻了好几倍。

1.3 第二个本事：连续批处理（continuous batching）

静态批处理要等一整批人全问完才开下一批。vLLM 是流水作业：请求随时进来，生成完就让位给下一个，显卡一分钟也不空转。

1.4 最值钱的设计：OpenAI 兼容接口

vllm serve 一起来就是标准 OpenAI API。原来调 GPT 的代码，只改一行 base_url：

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy")

resp = client.chat.completions.create(
    model="Qwen/Qwen3-8B",
    messages=[{"role": "user", "content": "用一句话介绍你自己"}],
)
print(resp.choices[0].message.content)

你会看到（示意）：

我是由通义千问团队研发的语言模型 Qwen3-8B，可以帮你解答问题、撰写文案。

这就是 vLLM 最大的工程价值：接口标准化，换模型不用改业务代码。

1.5 vLLM 和 Ollama 怎么选

结论：本地体验选 Ollama；上生产、要并发、要接 OpenAI SDK，选 vLLM。

1.6 先把硬件门槛说清楚

vLLM 是给有 NVIDIA 显卡的机器准备的，没显卡装得上也跑不起来。本教程的分工是：

• 第 1、3 章是原理和接口，没显卡也完全读得懂；
• 第 2、4、5 章的命令需要真显卡才能跑；
• 第 6 章的客户端代码，没显卡时可以用云 API 顶替练习。

动手改

1. 把上面 PagedAttention 的例子改成 4 个请求，手算一下两种方式各浪费多少显存
2. 去 Hugging Face 看看 Qwen/Qwen3-8B 的模型卡，记下它的参数量和上下文长度
3. 用 Ollama 和 vLLM 的官网各自查一句定位，写下你所在场景会选哪个、为什么

小结

• vLLM 是纯推理引擎：加载权重、调度请求、跑模型，不训练也不做 RAG
• PagedAttention 把 KV cache 分页管理，显存利用率从百分之几十拉到接近满
• 连续批处理让显卡始终满载，排队体感平稳
• OpenAI 兼容接口是它最大的工程价值：业务代码只改 base_url
• 没 NVIDIA 显卡跑不起来，本教程的原理和接口部分照样能学

下一章：环境搭建 🐸