像管内存一样管显存:vLLM 用 PagedAttention 把推理吞吐翻了几倍

自建大模型服务这件事,卡住大多数团队的往往不是模型不够好,而是显存不够用:模型生成文本时必须在显存里为每个请求维护一份 KV Cache,传统引擎按请求的最大可能长度整块预分配,短请求用不完的部分只能白白空着,显存碎片还让并发量雪上加霜。2023 年从 UC Berkeley 走出来的开源项目 vLLM 换了一种思路——把操作系统管理内存的分页机制搬到显存上,这项名为 PagedAttention 的技术此后成了大模型推理服务领域被引用最多创新之一,项目本身也已聚集超过 91,000 颗 GitHub 星标,最新稳定版 v0.29.0 于 2026 年 9 月发布。

PagedAttention 的做法不难理解:KV Cache 不再按请求整块预留,而是切成固定大小的块,用一张块表记录每个请求的块分布在哪,用到多少分配多少。碎片因此几乎消失,官方数据显示显存利用率从传统方式的百分之三四十提升到九成以上——同样的 GPU,能同时服务的请求数量翻上两到四倍。在此之上叠加 Continuous Batching:请求不必凑批等齐,随时加入、算完立刻退出,长短请求混跑时吞吐量的差距进一步拉开。多项独立实测中,同一块 GPU 上 vLLM 的聚合吞吐量达到对照方案的两到五倍,原本需要几张卡才能扛住的并发,现在一张就能接住。

对工程团队来说,vLLM 的另一个关键决定是接口层面的"零迁移":它内置 OpenAI 兼容的 API 服务器,已有多款客户端和业务代码原本就在调 OpenAI 风格的接口,把请求地址改成本地服务就能切换到自托管模型,业务逻辑一行不动。生产所需的其他零件也大多开箱即用——张量并行与流水线并行可以把大模型拆到多张 GPU 上;同一个服务能同时挂载多个 LoRA 适配器,按请求动态切换,一套部署服务多个垂直场景;自动前缀缓存让共享同一段系统提示词的请求直接复用已算好的 KV 块,对话类应用的首字延迟明显下降;量化方面支持 AWQ、GPTQ、FP8,服务暴露 Prometheus 指标,方便接进现有的监控体系。

它的定位同样需要说清楚:vLLM 是面向服务器级 GPU 的推理服务框架,没有图形界面,核心场景是把 7B 到 70B 量级的开源模型变成扛得住并发的线上服务;个人电脑上的轻量本地对话并不是它的主场,那类需求前面介绍过的 Ollama、LM Studio 更合适。项目采用 Apache-2.0 许可证,商业使用与二次开发无障碍,头部 AI 基础设施公司普遍把它作为底层引擎。如果说 Ollama 们降低了"跑起来"的门槛,vLLM 解决的就是"扛得住"的问题——当自建模型服务从实验走向生产,这一层绕不开。

项目

说明

软件名称

vLLM(vllm-project,起源于 UC Berkeley)

最新版本

v0.29.0(2026-09-09 发布)

软件类型

开源高吞吐 LLM 推理与服务引擎(面向服务器 GPU,无 GUI)

开源许可

Apache-2.0

核心特性

PagedAttention 分页管理 KV Cache;Continuous Batching;OpenAI 兼容 API;张量/流水线并行;多 LoRA 动态切换;自动前缀缓存;AWQ/GPTQ/FP8 量化

适合人群

自建模型服务的后端与平台工程师、私有化部署团队

图片来源

GitHub 仓库 vllm-project/vllm(公开页面截图与仓库卡图)

vLLM下载地址
支持的操作系统: Linux Windows macOS