上线9个月新增4万星：vLLM 如何从学术论文变成生产级推理引擎

上线 9 个月新增 4 万星：vLLM 是如何从学术论文变成生产级 LLM 推理引擎的

2023 年 6 月 UC Berkeley 的一篇论文提出了一个看似简单的问题：LLM 推理时 GPU 显存碎片化严重，能不能像操作系统管理内存那样管理 KV Cache？答案是 PagedAttention，这篇论文成了 vLLM 的起点。三年过去，vLLM 已经成为大模型推理引擎领域最活跃的开源项目之一，GitHub 星标数突破 92,000，最近一次提交就在昨天——这个项目显然没有停在”论文实现”阶段。

一个数字说清楚 vLLM 在解决什么问题

Ollama 单用户场景下首 token 延迟约 150ms，vLLM 约 180ms——差别不大。但如果把用户数从 1 增加到 50，vLLM 的吞吐量开始以 10-50 倍的优势甩开 Ollama。这不是 vLLM 更快，而是它解决了一个 Ollama 架构上没打算解决的问题：高并发场景下的 GPU 利用率。

核心机制有两个。

连续批处理（Continuous Batching）：传统批处理要等当前批次所有请求完成才能处理下一批，有新请求进来也得排队等。vLLM 的做法是动态地往正在跑的批次里塞新请求、移出已完成的请求，GPU 始终保持饱和状态，吞吐量的提升来自这里。

PagedAttention：借鉴操作系统虚拟内存分页思路来管理 KV Cache，把显存切成分页块，减少碎片。实测同样一张 24GB 显存的 GPU，Ollama 显存利用率约 20-30%，vLLM 可以做到 85-92%。

这意味着什么？用同样的 GPU，vLLM 能同时服务更多并发用户，或者用更少的 GPU 服务同样数量的用户。对于 API 服务来说，这是直接的成本差异。

适合谁，不适合谁

适合用 vLLM 的场景：

• 构建生产级 LLM API，对外提供 /v1/chat/completions 接口
• 多用户并发场景（10+ 并发请求是基准线）
• 需要多卡张量并行（70B 以上模型单卡放不下）
• 多租户 SaaS 平台，需要同时服务多个 LoRA 适配器
• 对接 Kubernetes 做弹性扩缩容
• 企业私有化部署，有 GPU 集群

不适合用 vLLM 的场景：

• 个人开发者笔记本上跑模型做实验（Ollama 两分钟搞定，vLLM 要配 CUDA 环境）
• CPU-only 环境（vLLM 为 GPU 优化设计，CPU 推理不是它的主战场）
• 单用户、低并发、延迟不敏感的场景（Ollama 够用，上 vLLM 是杀鸡用牛刀）
• 实时交互延迟要求极高的场景（vLLM 的连续批处理会带来少量额外延迟）

最新版本状态

v0.29.0 于 2026 年 9 月 9 日发布，距离前一个版本 v0.28.0（8 月 26 日）不到两周——迭代节奏非常快。v0.29.0 包含了对 DeepSeek 新硬件的优化支持和若干 bug 修复。

vLLM 社区非常活跃：GitHub 有超过 8,000 个 open issues，但更值得注意的是平均每天有数十个 commit，21,000+ commits 分布在 200+ contributors 中，背后有来自 Amazon、LinkedIn、Google、Meta 和 NVIDIA 的实际贡献者。Hugging Face 官方也推荐在生产环境使用 vLLM。

量化对比：vLLM vs Ollama vs TGI

数据来源： Ginger Labs 2026 年 6 月对比测试（https://www.gingerlabs.ai/blog/vllm-vs-ollama-vs-tgi）

一行代码验证是否该迁移

如果你已经在用 Ollama，有一个判断标准：同时有多少用户在跑推理？

• 1-5 人偶尔用：Ollama 够用，先别动
• 5-10 人中等并发：开始感受到排队，考虑 vLLM
• 10 人以上稳定并发：vLLM 不是可选项，是必选项

迁移成本比想象低。由于两者都提供 OpenAI 兼容 API，应用层改 base URL 即可——主要工作量在基础设施层（GPU 节点、Kubernetes 配置）。

生产环境快速上手

# 方式一：pip 安装（推荐 Python 项目集成）
uv pip install vllm

# 方式二：Docker 快速起服
docker run --gpus all 
  -v ~/.cache/huggingface:/root/.cache/huggingface 
  -p 8000:8000 
  vllm/vllm-openai:latest 
  --model Qwen/Qwen3-8B 
  --gpu-memory-utilization 0.85

# 验证服务可用
curl http://localhost:8000/v1/chat/completions 
  -H "Content-Type: application/json" 
  -d '{"model":"Qwen3-8B","messages":[{"role":"user","content":"Hello"}]}'

生产级 Kubernetes 部署建议配合 KEDA 根据队列深度做弹性扩缩容，vLLM 官方提供 Prometheus + OpenTelemetry 监控指标，开箱即用。

项目边界说明

vLLM 是一个推理和服务引擎，不是一个模型。它依赖外部模型文件（HuggingFace 格式），需要自己准备 GPU 基础设施，不提供模型训练能力。

支持的模型架构超过 200 种，包括 Llama、Qwen、DeepSeek-V3/MoE、Mistral、Gemma 以及多模态模型 LLaVA、Qwen-VL 等。支持的硬件涵盖 NVIDIA GPU（主力）、AMD ROCm、Intel Gaudi、TPU，以及 Google、苹果 M 系列芯片等。

下一步建议

1. 评估阶段：如果当前用 Ollama，先用 docker run vllm/vllm-openai:latest --model <your-model> 跑一个最小实例，测一下你的真实并发场景下延迟和吞吐量变化
2. 迁移阶段：准备 GPU 节点，参考 vLLM 官方文档 的 Kubernetes 部署指南，配置 Prometheus 监控
3. 多租户场景：vLLM 的 Multi-LoRA 支持是亮点，多个垂直领域适配器共用一个 base 模型可以显著降低显存成本
4. 关注新方向：vLLM 正在推进 Rust 前端集成和 disaggregated prefill/decode（解耦预填充与解码），有兴趣可以看他们的 vLLM Blog

链接汇总：

• GitHub：https://github.com/vllm-project/vllm
• 官网：https://vllm.ai
• 文档：https://docs.vllm.ai
• 博客：https://vllm-project.github.io/
• 论文（PagedAttention）：https://arxiv.org/abs/2309.06180
• Red Hat 开发者对比指南：https://developers.redhat.com/articles/2025/07/08/ollama-or-vllm-how-choose-right-llm-serving-tool-your-use-case
• Ginger Labs 框架对比：https://www.gingerlabs.ai/blog/vllm-vs-ollama-vs-tgi
• 企业级部署实战（CSDN）：https://blog.csdn.net/weixin_28729331/article/details/164383571