vLLM：把开源模型变成高吞吐 API

把开源大模型变成能扛并发的线上 API，同样的卡服务更多请求。

本地跑模型和线上服务模型是两件不同的事。Ollama、Jan 解决「能跑起来」，vLLM 解决「扛得住」——当 7B 到 70B 的模型要对外提供接口、同时面对几十上百个请求时，显存怎么分、请求怎么排、吞吐怎么提，是另一套工程。vLLM 起源于伯克利 Sky Computing 实验室，核心是 2023 年那篇 PagedAttention 论文，目前由两千多名贡献者维护，是自建推理服务绕不开的一层。

PagedAttention：像操作系统管内存一样管 KV Cache

传统推理把每个请求的 KV Cache 预分配成一块连续显存，长度按最大上下文算，结果大量空间闲置。PagedAttention 借鉴虚拟内存分页：把 KV Cache 切成固定大小的块，按需分配、用页表映射。效果是显存浪费大幅下降，同样一张卡能同时装下更多序列。这是吞吐提升的根本原因，也是它比其他推理框架更容易跑满显存的地方。

连续批处理与前缀缓存，降低平均延迟

请求不是一个批次一起进、一起出，而是到了就插进当前批次，这叫 continuous batching。配合分块预填（chunked prefill），长提示词不会卡住整个批次。再叠上前缀缓存：多个请求共享同一段系统提示词时，那段 KV 直接复用，不重复计算。对话类应用里系统提示词往往很长，这一条对首字延迟的改善很直接。

一行命令起一个 OpenAI 兼容服务

装完之后 vllm serve <模型名> 就能拉起服务，默认提供 OpenAI 兼容接口，已有的 SDK、客户端、业务代码把 base URL 改过来即可，业务逻辑不用改。除此之外还支持 Anthropic Messages API 与 gRPC 接口。对已经在用 OpenAI 格式的团队，迁移成本基本就是改一个地址。

生产需要的零件基本齐了

张量并行、流水线并行、数据并行、专家并行、上下文并行都有，大模型可以拆到多卡多机；同一实例可以挂多个 LoRA 适配器，按请求动态切换，一套部署服务多个垂直场景；量化支持 FP8、INT8、INT4、GPTQ、AWQ、GGUF 等；结构化输出用 xgrammar 或 guidance 约束成 JSON；指标可以对接 Prometheus。这些不是插件，而是主仓里的能力。

使用上手：五步跑通

1. 准备环境。主要是 Linux，装好与 CUDA 版本匹配的 PyTorch。
2. 安装。uv pip install vllm，随后建议跑一次 vllm download-kernels 预拉内核，能明显缩短服务启动时间。
3. 启服务。vllm serve <你的模型>，首次会自动从 Hugging Face 拉权重；显存不够时加量化参数或降 --max-model-len。
4. 验证接口。用 OpenAI SDK 把 base URL 指向本地端口，发一条 chat 请求，能返回即可。
5. 压测再上线。用真实长度的输入跑并发，看吞吐与首字延迟；需要多卡时再加张量并行参数，不要一次开满所有特性。

优点与不足

优点：吞吐与显存利用率是它的立身之本，同硬件下能服务的请求数明显高于朴素实现；模型覆盖面广，官方称支持 200 多个 Hugging Face 架构，含多模态与嵌入模型；API 兼容性好，迁移几乎零成本；Apache-2.0，商用无障碍；硬件后端不只 NVIDIA，AMD、Intel、TPU、昇腾等都有路径。

不足：它面向服务器级 GPU，没有图形界面，个人电脑上聊天不是它的主场；安装对 CUDA 与 PyTorch 版本匹配敏感，环境不对会直接报错；版本迭代快，0.x 系列每隔几周一个新版，升级前要看 Release Notes；部分高级特性（如某些量化格式、分离式部署）配置复杂，需要读文档而不是照搬示例。

适合谁

• 自建模型 API 的后端工程师：要把开源模型包成对外服务，这层绕不开。
• 做批量推理的数据团队：离线跑大量生成任务，吞吐直接决定成本。
• 企业私有化部署：数据不能出内网，又需要跟 OpenAI 接口对齐。

下载与访问

• 官网：https://vllm.ai
• 文档：https://docs.vllm.ai
• GitHub：https://github.com/vllm-project/vllm

许可证与部署

本文属于「项目」分类的 AI 资源专栏，更多评测见分类页。