文档大纲

性能远超OLLaMA的开源推理引擎 vLLM

你有没有过这种时刻：想让 AI 帮店铺批量写详情页文案、给客服做 7×24 小时应答，却发现每调一次 API 都心疼账单；而自己租台服务器跑模型吧，显存一算就劝退。

这中间缺的不是模型，而是一层"把模型高效跑起来"的地基。今天 GitHub Trending 排到第二名的那个项目，就是这块地基里最结实的砖——它的仓库叫 vllm-project/vllm，开发语言主要是 Python，同时有 Rust 和 Cuda 参与。

读完这篇你能带走三件事：它到底解决了什么问题（你为什么可能需要它）、它和市面上其他方案比强在哪、以及如果你暂时没有 GPU，也能从它身上抄走哪些工程思路。

如果你只是想在笔记本上偶尔跑个 7B 模型聊天，那说实话，Ollama 这类工具对你更友好，别折腾。vLLM 是给"要把模型当成一条稳定服务线来经营"的人准备的。

一、它是什么：一个为生产环境而生的推理引擎

vLLM 全称来自它的自我描述："A high-throughput and memory-efficient inference and serving engine for LLMs"——一个高吞吐、显存高效的 LLM 推理与服务引擎。

它诞生于 2023 年 2 月，起源是 UC Berkeley 的 Sky Computing Lab，团队把那篇拿下 SOSP'23 的 PagedAttention 论文做成了工程实现。今天的它已经不只是"一种加速方案"，而是自建和自托管 OpenAI 兼容 API 服务的事实标准之一——你在很多公司的模型服务层背后，遇到的往往就是它。

1.1 它要解决的核心问题

大模型推理的真正瓶颈，往往不是算力，而是显存管理和调度效率。模型每生成一个新 token，都要重复读取此前所有 token 的 KV Cache（可以理解为模型的"工作记忆"）。如果这些记忆像一排参差不齐的文件夹，每次都要整块搬来搬去，浪费的空间和搬运的时间都很惊人。

vLLM 的解法来自它的核心论文：PagedAttention。它借鉴了操作系统虚拟内存的分页思想，把 KV Cache 切成固定大小的块来管理，从此不需要为可能到来的变长序列提前预留一整块连续显存，显存浪费大幅下降。

1.2 关键数据面板

指标数值
Stars94,961
Forks23,763
Open Issues2,686
Open PRs6,564
创建时间2023-02-09
最新版本v0.32.0（2026-10-18 发布）
发布节奏约两周一版
贡献者官方声明 2000+
许可证Apache-2.0（商业友好）
支持模型架构200+

几个值得注意的信号：它用的是 Apache-2.0，商用没有授权负担；而 6,564 个未合入的 PR 说明它极其活跃，也说明你在生产里锁版本是必要的。

官方地址是 https://vllm.ai ，文档在 docs.vllm.ai，核心论文是 arXiv:2309.06180（PagedAttention 原文）。

二、它凭什么能把显卡榨出更多性能

大模型推理的真正瓶颈，往往不是算力，而是显存管理和调度效率。想象一下：模型每吐一个字，都要重复把之前生成的几十上百个 token 的"记忆"（KV Cache）读一遍。如果这些记忆像一排参差不齐的文件夹，每次都要整块搬来搬去，浪费的空间和搬运的时间都很惊人。

vLLM 的解法，就是它论文里的核心贡献。

2.1 性能层：把"等待"挤出去

PagedAttention 是它的立身之本。它借鉴了操作系统虚拟内存的分页思想，把 KV Cache 切成固定大小的块来管理，从此不需要为可能到来的变长序列提前预留一整块连续显存，显存浪费大幅下降。简单说：以前是给每个客人留一间大房子，现在改成标准化的格子间。

Continuous Batching（连续批处理）让请求级的动态调度成为可能。有请求完成时，队列里的下一个立刻补位，GPU 不会因为等一批请求跑完而空转。

Chunked Prefill（分块预填充）把长 prompt 切成小块，让长文预处理和短问题解码混跑时互不阻塞——这对"一边处理几十页合同、一边给员工答疑"这类混合负载非常关键。

Prefix Caching（前缀缓存）则让多轮对话和共享系统提示词的场景大幅受益：反复出现的前缀不用重复计算。

此外还有 CUDA/HIP Graphs 消除 kernel 启动开销、torch.compile 自动生成和变换 kernel 等一整套组合拳。

2.2 量化：让模型瘦下来

量化可以粗略理解为"把模型精度调低一点，换显存和速度"。vLLM 支持的格式几乎覆盖了所有主流选项：FP8、MXFP8/MXFP4、NVFP4、INT8、INT4、GPTQ、AWQ、GGUF、compressed-tensors、ModelOpt、TorchAO，甚至包括 Blackwell 新硬件上的新格式。

2.3 推测解码与并行：不等算完才说话

推测解码用一个便宜的小模型先猜几个 token，再让大模型一次性验证，用"多猜几次少算几遍"的方式降低平均延迟。vLLM 并行支持 n-gram、suffix、EAGLE、DFlash 四种策略。

v1 引擎还引入了五种并行方式：Tensor、Pipeline、Data、Expert、Context；以及 Disaggregated prefill / decode / encode——把"读上下文"和"生成答案"拆到不同的硬件池上分别部署。这个设计在成本控制上很有想象空间：分析型负载放在便宜算力上，最终生成放在强算力上。

2.4 服务与生态

它对外提供的接口是 OpenAI 兼容 API Server（主力出口），同时还有 Anthropic Messages API 和 gRPC。你的客户端代码几乎不用改，只要换 base_url 就能切过来。

其他能力还包括：streaming 流式输出、结构化输出（xgrammar / guidance）、tool calling 与 reasoning parsers、多 LoRA 并行（dense 与 MoE 层都支持），以及流式的 Embedding / Rerank / Reward / Classification 模型服务。

2.5 硬件矩阵：这是本次最大的亮点

除了常见的 NVIDIA GPU，它还支持 AMD GPU、Intel GPU、x86/ARM/PowerPC CPU，外加 Google TPU、Intel Gaudi、IBM Spyre、华为昇腾、Rebellions NPU、Apple Silicon、MetaX GPU 等各类硬件插件。

这一点的现实意义：如果你在国产算力或 TPU 上做服务，不必被锁死在某一家生态里。仓库 topics 也明确挂着 amd、blackwell、cuda、tpu、gpt-oss、kimi、qwen3、deepseek-v3、moe 这些标签。

2.6 模型覆盖

  • Decoder-only：Llama / Qwen / Gemma
  • MoE：Mixtral / DeepSeek-V3 / Qwen-MoE / GPT-OSS
  • 混合注意力与 SSM：Mamba / Qwen3.5
  • 多模态：LLaVA / Qwen-VL / Pixtral
  • Embedding 与 Rerank：E5-Mistral / GTE / ColBERT
  • Reward 与分类：Qwen-Math

三、代码结构：值得偷看的几个目录

3.1 顶层目录

顶层是 vllm/（Python 主包）、rust/（Rust 前端，已经是独立的 Cargo 工程）、csrc/（CUDA/C++ 内核），以及 benchmarks、recipes、docs、docker、tools、tests 等。

3.2 Rust 前端：一个值得注意的趋势

它已经有一个独立的 rust/ 子工程（Cargo 工程 + protobuf 协议）。最近的提交里有多条明确标注 [Rust Frontend]，说明协议层正在被逐步从 Python 迁到 Rust。这是"编排层要表达力、热点路径要性能"的典型落地。

3.3 v1 引擎目录：野心都在这里

vllm/v1/ 目录最能体现它现在的野心：attention、core、engine、executor、fault_tolerance、hisparse（稀疏注意力）、kv_cache_interface / kv_cache_layout / kv_hints、kv_offload / simple_kv_offload、metrics、pool、sample、spec_decode、structured_output、watermarking、worker。

近期的提交几乎都落在这些新模块上，比如 Rust 前端追平 DeepSeek 等新模型的协议、修复启动路径上的 lazy-import 崩溃、给 BERT cross-encoder 补上 LoRA 支持。

顺带一提，它仓库里还有 .agents/ 和 .claude/ 目录——连 AI 协作开发配置都放进了主干，这本身也是一种信号。

四、五分钟跑起来

4.1 安装

# 推荐用 uv 安装
uv pip install vllm
vllm download-kernels        # 预编译 kernel，显著加速启动

# 源码构建（开发用）
uv pip install --editable .

启动一个 OpenAI 兼容服务：

4.2 启动服务

vllm serve <model-path-or-hf-id> \
  --host 0.0.0.0 --port 8000 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90

4.3 调用验证

然后你的客户端代码几乎不用改：

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"<model>","messages":[{"role":"user","content":"hi"}]}'

最后那行 vllm download-kernels 值得特别强调：跳过它，你可能会在第一次启动时等很久甚至失败。

五、和同类方案怎么选

5.1 对比总表

下表是它和当前主流方案的横向比较。

项目定位语言显存效率硬件广度生态成熟度适合场景
vLLM通用 LLM 推理服务引擎Python+Rust+Cuda★★★★★★★★★★★★★★★自建生产级推理后端
SGLang高性能 serving + 复杂结构化生成Python★★★★★★★★☆★★★☆RadixAttention / 结构化输出
TensorRT-LLMNVIDIA 官方极致优化C++/Python★★★★★★★☆★★★★纯 NVIDIA 集群榨性能
llama.cpp端侧 / CPU 轻量推理C++★★★★★★★★★★★★★★Mac / 边缘设备
Ollama极简本地模型管理Go★★★★★★★★★★★开发者本地试用
TGIHF 官方服务Python/Rust★★★★★★★★★HF 生态集成
LMDeployTurboMind 引擎Python/C++★★★★★★★★★★国产卡 + 量化

5.2 选型逻辑

一句话总结这张表：vLLM 不是"最快的那个"，而是"最快的那一批里，硬件覆盖最广、生态最完整、社区最大"的那个。

如果你是电商团队做批量文案生成这类高并发场景，选型逻辑很清晰：预算够就上 TensorRT-LLM 榨性能，卡不统一或想留退路就上 vLLM，本地试用就 Ollama。

六、值不值得现在就部署

6.1 暂不推荐部署的情形

坦白讲，如果你的设备是普通笔记本，那不部署。原因很实在：vLLM 需要 CUDA 或 ROCm 级别的独立显卡，模型权重要本地驻留（几十到几百 GB），成本和运维复杂度都不低。

6.2 应该立刻部署的三个信号

但有三个信号出现时，它应该立刻排到你的第一优先：

  • 持续的 API 调用成本开始让你肉疼
  • 你有稳定 24/7 的高频调用场景（比如自动化任务、全天候客服）
  • 你采购到了 24G 以上显存的显卡

6.3 收益与风险

收益也很直接：吞吐可以数倍于轻量本地工具，而且原生 OpenAI 兼容意味着你的客户端几乎零改造成本就能切换。

风险同样要记住：v0.x 阶段 API 变动频繁，v1 引擎正在快速演进，两个版本之间可能存在引擎级差异，升级务必锁版本 + 做回归验证。

七、不部署也能拿走的设计

这八个思路同样值得单独一说——即使你暂时不上 vLLM，它们也能直接迁移到你自己的 AI 工作台里。

7.1 上下文与技能加载：别把重复的东西反复重算

7.2 PagedAttention：上下文管理不要靠拷贝

有限上下文里该放什么，vLLM 的答案是"不要拷贝"——用分页加引用来复用。你的记忆检索工具同理：返回精确摘录而不是把全文重述一遍。

7.3 Prefix Caching：把固定前缀缓存起来

系统提示词、常用规范在每次调用中高度重复，完全可以被"缓存"而不是每轮重新解析。前缀哈希、引用计数、淘汰策略这个三段式可以直接抄。

7.4 分块与连续批处理：让长任务给短任务让路

长任务和短任务混合时，长任务应该被拆成可让出调度权的分片，让短任务插队，而不是傻等。

7.5 Prefill/Decode 分离：按环节分配算力

"检索与分析"重、"最终生成"轻，前者放到便宜算力上，后者放到强模型上。日常问答不必动用最贵的模型。

7.6 KV 卸载：冷热数据分层

把不常用的数据从显存卸载到内存或磁盘，这正是"热数据常驻、冷数据按需拉回"的工程范式。更妙的是它的 kv_hints：让上层显式声明"这段大概率要复用"。

7.7 输出约束做成独立可插拔模块

vLLM 把结构化输出约束和水印标记从主链路抽成独立可插拔模块，而不是散落成各处的 if 判断。你给不同平台（飞书、钉钉、公众号）写规则时，同一套思路适用。

7.8 热点路径换语言

它正把协议层往 Rust 迁，趋势很清楚：编排层用 Python 的表达力，热点路径用性能语言。你自己写的批量工具也一样。

7.9 长跑任务的容错三件套

长跑任务天生会崩，把它做成一等公民而不是补丁。真正稳的做法是三件套：可重入、幂等哨兵、半成品清理。

八、上手之后：继续挖的三个方向

8.1 值得动手试的三个实验

如果你决定真的部署，下面三个实验性价比最高：

  1. Prefix Caching 验证：给同一个模型连续发几轮相同 system prompt 的对话，对比开启前后首 token 延迟。
  2. 量化对比：同一个 7B 模型分别以 FP16、AWQ INT4 启动，测吞吐与显存占用。
  3. 并发压测：把并发从 1 提到 32，观察吞吐是否随连续批处理线性增长、延迟在哪个点开始抬头。

8.2 三个常见坑

  • 跳过 vllm download-kernels：首次启动可能等很久甚至直接失败。
  • 不锁版本：v0.x 的引擎级变动可能让两周前的启动参数失效，务必固定版本号。
  • --gpu-memory-utilization 设太满：容易在长上下文场景 OOM，0.90 是相对稳的起点。

九、写在最后

9.1 它为什么成了默认选项

vLLM 已经从一篇论文变成了一个基础设施级别的项目：9.5 万颗星、两万多个 fork、两周一个版本、200+ 种模型架构、七大硬件平台。它没有在"单项性能"上争第一，而是在"性能、硬件、生态"三者的平衡点上成了默认选项。

9.2 三个自检问题

如果你正在琢磨"要不要自建模型服务"，先问自己三个问题：调用量是否已经稳定到值得自建？硬件是否至少有一张 24G 显存的卡？团队是否有人能承担 v0.x 版本的升级维护？三个都是"是"，那就把 vllm-project/vllm 排进候选名单；有一个是"否"，继续用 API 或者 Ollama，把精力花在业务上。

技术选型的价值，一半在于它帮你跑得快，另一半在于你知道什么时候不该用它。

阅读量： 315

网站备案号：沪ICP备2025137870号