vLLM：一张 GPU 卡，凭什么扛住几倍请求

关注

原创 2026-11-09 20:35:57 292 阅读 AI 写同款· GEO 优化 ›

vLLM部署Qwen模型实战：从能跑到能扛的生产级推理服务调优指南大语言模型部署的核心挑战在于如何在有限显存下提升推理吞吐量与并发能力。原生推理框架在处理多请求时存在显存预分配浪费和GPU利用率低的问题，导致服务难以应对真实流量。vLLM通过PagedAttention分页管理KV Cache和Continuous Batching连续批处理等机制，显著优化了显存利用和批处理效率，使得单卡部署7B级模型也能获得数倍吞吐提升。对于需要将开源模型落地为在线API服务的开发者，掌握vLLM的核心参数调优、显存估算与压测方法是关键。本文以Qwen系列模型为例，系统梳理了从方案选型阅读详情

VIBE 知识大赏 AI 基础设施专题

vLLM：一张 GPU 卡，
凭什么扛住几倍请求

从 PagedAttention 到连续批处理，拆解大模型推理引擎的“省钱”逻辑

2026 年 · 第 01 期　|　LinkTokenView 技术内容组

link tokens, view the future

www.linktokenview.com

目录这篇文章要回答三个问题

一　先看懂问题：大模型推理为什么“又慢又贵”

二　vLLM 是什么：一句话定义与三层定位

三　功能地图：vLLM 替你做的六件事

四　核心问题：同一张 GPU 卡能抗几倍请求

五　Vibe 案例：12 人团队把 8 路并发做到 42 路

六　落地路线图：30 天把 vLLM 用起来

七　结语：把推理从“成本项”变成“能力项”

导读　大模型真正的成本不在训练，而在每一次被调用的推理。一个 7B 模型用 20 行代码就能跑起来，但当 200 名开发者把它塞进日常的工作流，GPU 会在三秒内排起长队。

vLLM 想解决的正是这件事：让同一张卡，服务更多请求。本文讲清三件事——vLLM 是什么、它凭什么把单卡吞吐抬几倍、以及一个真实的 Vibe 团队如何用一张卡把 8 路并发做到 42 路。

一先看懂问题：大模型推理为什么“又慢又贵”

1.1 一段生成，两种完全不同的瓶颈

大模型生成文本是自回归的：说一个字，看一眼前文，再说下一个字。这一过程被切成了两个阶段，而它们的瓶颈恰好相反。

第一阶段 Prefill（预填充）：把整段输入一次性送进网络，算出所有 token 的 Key/Value 并缓存起来。这一步是标准的大矩阵乘法，吃的是算力，GPU 的 Tensor Core 会被充分喂饱。

第二阶段 Decode（解码）：每一步只生成 1 个 token，却必须把整个模型的权重从显存里完整读一遍。这张卡的算力单元此刻大多在排队等数据，实际算力利用率常常只有个位数百分比——瓶颈从算力换成了显存带宽。

理解这一点，才能理解后面所有的优化：推理引擎真正要治的，是 decode 阶段的“带宽饥饿”和“显存焦虑”，而不是把矩阵乘再算快一点。

1.2 真正的稀缺资源，是 KV Cache

为了避免重复计算，Prefill 阶段算出的 Key/Value 张量必须一直留在显存里，这就是 KV Cache。它的体积与上下文长度成正比，并且随着并发请求数线性叠加：2023 年的官方数据里，LLaMA-13B 单个最长序列就能占掉 1.7GB 显存，而这还只是当年的“中号模型”。

于是并行度不再是调度器拍脑袋的决定，而是一道显存除法题：显存里能装下多少份 KV Cache，就能同时服务多少路请求。

模型（参数量）	层数	注意力结构	每 token KV	8K 上下文 KV
LLaMA-7B	32	MHA · 32 头	0.50 MB	4.0 GB
LLaMA-13B	40	MHA · 40 头	0.78 MB	6.4 GB
Qwen2.5-7B	28	GQA · 4 组	56 KB	0.45 GB
LLaMA-3-70B	80	GQA · 8 组	0.31 MB	2.5 GB

表 1　常见开源模型的 KV Cache 开销（FP16 精度，单序列估算）

表的最后两行值得多看一眼：同样是 7B 规模，采用 GQA（分组查询注意力）的模型，每 token 的 KV 开销只有 MHA 结构的约九分之一。换句话说，换一个模型架构对显存的改善，可能比任何调度技巧都更剧烈——这是后文“代际答案”的伏笔。

1.3 三笔账：吞吐、并发与成本

谈“快了几倍”之前，先要分清在问哪一笔账，因为它们的答案并不相同：

▪ 吞吐倍数：单位时间内多产出多少 token。广告里最常出现的数字。

▪ 并发倍数：同一时刻能挂多少路请求而不崩、不卡。用户体感最直接。

▪ 成本倍数：达到同样的体验，需要几张卡、多少钱。老板唯一关心的一笔。

三者相关但不相等：吞吐涨 4 倍，往往意味着同等硬件下的并发涨 5 倍、单 token 成本降到四分之一，但如果延迟被拉爆，用户体验依然是“变慢了”。

二 vLLM 是什么：一句话定义与三层定位

2.1 一句话定义

vLLM 是一个开源的大语言模型推理与服务引擎（inference & serving engine），用 Python 和 PyTorch 实现。它由 UC Berkeley 团队于 2023 年 6 月开源，采用 Apache 2.0 协议，2024 年加入 PyTorch 基金会，如今是业界部署最广的开源推理引擎之一。

它的核心贡献是一个名为 PagedAttention 的注意力算法，以及围绕它重建的一整套显存管理与调度机制。说得直白些：vLLM 把操作系统管理内存的那套办法——分页、按需分配、写时复制、共享——原样搬进了 GPU 显存，专门用来管 KV Cache。

2.2 三层定位，别只当成一个“跑模型的库”

很多团队最初只把 vLLM 当成 pip install 之后就能跑模型的库，结果用掉了它三成的能力。它其实有三层身份：

▪ 推理引擎：在单机单卡上把模型跑快，靠 PagedAttention 加连续批处理，这是立身之本。

▪ 服务框架：对外提供 OpenAI 兼容接口、流式输出、多副本与健康检查，可以直接顶替商业 API 的成本结构。

▪ 平台组件：支持张量并行、流水并行、P/D 分离、多硬件后端与 Kubernetes 集成，是大模型平台的地基。

2.3 它真正的起点：把 60% 到 80% 的浪费拿回来

在 vLLM 之前，主流做法是为每条请求按“最大可能长度”预分配一块连续显存。真实请求的长度分布极不均匀，重尾部很长、绝大多数很短，预分配的结果是 60%–80% 的 KV 显存被白白占住——既不能给别的请求用，也没有真的装上数据。

PagedAttention 把这个数字压到了 4% 以下。折算下来，同一张卡能装下的请求数立刻多出 2 到 5 倍。所有后续的优化——连续批处理、前缀缓存、量化——都是在这个地基上继续加码。

三个关键数字　记住这三个数，就记住了 vLLM 的起点。

< 4%　KV 显存浪费率。改造前是 60%–80%，这是并发能力翻倍的物理来源。

24×　相对未优化的 HuggingFace Transformers 的峰值吞吐倍数（官方 2023 年基准）。

2–4×　相对 FasterTransformer、Orca 等专用系统、在同等延迟约束下的吞吐提升（SOSP'23 论文口径）。

三功能地图：vLLM 替你做的六件事

3.1 显存：PagedAttention 把 KV 切成块

PagedAttention 直接照搬操作系统的虚拟内存：把每条序列的 KV Cache 切成固定大小的块（block），逻辑上连续、物理上可以不相邻，中间用一张块表（block table）做映射。新 token 到来时才申请新块，序列结束块立刻回收，因此浪费只发生在每条序列的最后一个块里。

两个副产品同样值钱。其一是内存共享：同一条 prompt 的多路采样可以共用同一批物理块，官方数据显示并行采样与 beam search 的显存开销最多降低 55%，吞吐提升最多 2.2 倍。其二是写时复制（Copy-on-Write）：共享块在被改写之前才复制，既省内存又不破坏语义。

图 1　PagedAttention 与传统预分配方式的显存布局对比

3.2 调度：从“批”到“一次前向”

静态批处理把一批请求捆在一起，整批必须等最慢的那条生成完，一条长尾请求足以拖垮整批的利用率。连续批处理（continuous batching，也称 iteration-level scheduling）把调度粒度从“一批”降到“一次前向”：谁生成完了就立刻让出槽位，新请求马上补进来。

与分页显存配合时，这个动作几乎没有额外成本：新请求只需要拿到属于自己的几个块，就能插进正在计算的批次。这也是 Vibe 类交互式应用最受益的一项能力——用户的请求长度天生长短不一。

图 2　静态批处理与连续批处理的 GPU 时间线对比

3.3 复用：前缀缓存、多 LoRA 与投机解码

前缀缓存（prefix caching）是聊天与代码补全场景的性价比之王。同一套系统提示词、同一份仓库上下文，往往被成千上万次请求重复携带；vLLM 用哈希把已经算过的前缀块绑定起来，命中时直接跳过 Prefill。在 V1 架构里，这项能力被做到了“零额外开销”。

多 LoRA（multi-LoRA）让一张卡同时挂载几十个微调适配器并按请求切换，一份基座模型服务多个业务；投机解码（speculative decoding）先用小模型草拟若干 token，再由大模型一次校验，在不改变输出分布的前提下把 decode 提速 1.5 到 3 倍。

3.4 省算力：量化与分块预填充

权重与 KV Cache 都可以压缩。FP8、INT4、AWQ、GPTQ 这套组合能把权重压到二分之一甚至四分之一；KV Cache 换用 FP8 存储，则直接让并发容量翻倍——代价是极小的精度损失，必须用自有评测集确认。

分块预填充（chunked prefill）解决的是另一种卡顿：当一个 3 万 token 的长 prompt 撞进来，整批请求都会被它堵住。把 Prefill 切成小段、与 decode 交替执行，长上下文就不会再制造尾延迟尖刺。

3.5 规模：并行、P/D 分离与多硬件后端

单卡不够就上多卡：张量并行（TP）把单层切开分到多卡，流水并行（PP）按层切分，数据并行（DP）复制副本。继续放大时，把 Prefill 与 Decode 拆到不同机器上（P/D 分离），让“算力密集型”和“带宽密集型”的任务各用各的硬件，是当前千卡级部署的主流做法。

硬件后端也早已不止 NVIDIA：AMD、Intel、TPU 与多款国产加速卡都有对应实现，迁移成本主要在算子和量化格式的适配。

3.6 接口：让现有应用一行代码接过来

vLLM 自带 OpenAI 兼容的 /v1/chat/completions 与 /v1/completions，把 base_url 改掉即可复用现有 SDK；结构化输出（guided decoding / JSON Schema）保证返回值可被程序直接解析；多模态模型、Embedding、重排序与语音模型也都在支持列表内，且新模型往往做到 Day-0 支持。

能力域	关键技术	解决的问题	典型收益
显存管理	PagedAttention、块表映射	预分配导致的 60%–80% 浪费	并发容量 2–5 倍
请求调度	连续批处理、chunked prefill	长尾请求拖垮整批、长 prompt 卡顿	吞吐 2–4 倍
计算复用	前缀缓存、多 LoRA、投机解码	重复 Prefill、适配器切换开销	首字延迟显著下降
精度成本	FP8 / INT4 / AWQ / GPTQ	权重与 KV 占用过高	单卡可容模型更大
规模扩展	TP / PP / DP、P-D 分离	单卡装不下、单机扛不住	线性直到机架级
接入工程	OpenAI 兼容 API、结构化输出	替换商业 API 的改造成本	一天内可迁移

表 2　vLLM 的能力矩阵：每一项都在回答同一个问题——显存与算力还能不能再省一点

四核心问题：同一张 GPU 卡能抗几倍请求

4.1 先给结论，再给推导

如果把问题限定在“同一型号的同一张卡、同样的模型、同样的请求分布”，那么可以给出三个层次的答案：

▪ 基准答案：2–4 倍。这是相对 FasterTransformer、Orca 这类同代专用系统、在同等延迟约束下的提升，也是论文口径，属于工程上可以写进预算的倍数。

▪ 工程答案：5 倍上下。在前者基础上叠加前缀缓存、FP8 KV 与并发调优，实测中很常见。

▪ 代际答案：20 倍以上。从“未优化的 HF 基线 + MHA 老模型”迁移到“现代引擎 + GQA 现代模型”，两个变量相乘，就是广告里那个 24 倍。

三条都对，只是比较对象不同。下面把数据来源摆出来。

4.2 公开实测数据给出的区间

最常被引用的一组数字来自 vLLM 2023 年 6 月的官方博客：在 LLaMA-7B + A10G、LLaMA-13B + A100（40GB）两组配置上，以 ShareGPT 真实对话长度分布采样，vLLM 的吞吐是 HuggingFace Transformers 的 14 到 24 倍，是同代最优的 HuggingFace TGI 的 2.2 到 2.5 倍；若每条请求要求 3 个并行输出，对 HF 的领先扩大到 8.5 到 15 倍，对 TGI 为 3.3 到 3.5 倍。

同期论文（SOSP'23）的口径更保守也更实用：在同等延迟约束下，vLLM 相比 FasterTransformer 与 Orca 提升 2 到 4 倍。

图 3　vLLM 公开实测的倍数区间（条形长度表示区间范围，不表示正态分布）

到了 2026 年，这条曲线还在往上走：官方在 GB300 NVL72 上以 P/D 分离与宽专家并行的配置，单卡可达 954K tokens/s、单用户 P90 仍有 196 tokens/s；在 Vera Rubin NVL72 上，相比 GB200 NVL72 的单卡吞吐再提升 7.8 倍。这属于机架级配置，但方向清楚：推理效率的竞赛远没有见顶，而每一次跃迁都来自“少读一次显存、少算一次前缀”。

对比对象	测试场景	吞吐倍数	数据来源
HuggingFace Transformers	单条请求	14–24×	vLLM 官方博客 2023
HuggingFace Transformers	每条请求 3 个并行输出	8.5–15×	vLLM 官方博客 2023
HuggingFace TGI	单条请求 / 3 并行输出	2.2–2.5× / 3.3–3.5×	vLLM 官方博客 2023
FasterTransformer、Orca	同等延迟约束	2–4×	PagedAttention 论文（SOSP'23）
vLLM 自身（并行采样）	同 prompt 多输出	2.2×（显存 −55%）	vLLM 官方博客 2023
LMSYS Chatbot Arena	生产流量（真实业务）	同批卡承载 5× 流量	vLLM 官方博客 2023

表 3　公开实测倍数汇总：同一个引擎，不同的比较对象，答案在 2 倍到 24 倍之间

4.3 一张 80GB 卡，究竟能撑多少路并发

把公式写出来，一切就清楚了：

并发上限 ≈ （显存容量 × 利用率 − 权重占用）÷（每 token KV 大小 × 平均上下文长度 ×（1 − 前缀命中率））

分子是“能拿来装 KV 的空间”，分母是“每路请求要占的空间”。所有优化，本质上都在改这两个数。

以 7B 级 MHA 模型、单请求 2K 上下文做测算，一张 80GB 卡在四种做法下的并发上限分别约为 19、62、104、217 路——同卡、同模型、同请求，并发相差 11 倍，全部来自显存管理方式与精度选择，而不是换了芯片。

图 4　同一张 80GB 卡上的并发阶梯（示意测算，假设见注）

需要强调口径：这张图里每一级都建立在同一套假设上——权重 15GB、单请求 2K 上下文、每 token 0.5MB KV，并把显存利用率从 30% 提到 96%，再叠加前缀缓存与 FP8 KV。真实环境中任何一项变化都会让柱子移动，但“每一级都能翻倍”这个结构是不变的。

4.4 决定倍数的五个变量

倍数从来不是引擎的固有属性，它由五个变量共同决定：

▪ 模型大小与注意力结构：7B 与 70B 的倍数完全不同；MHA 与 GQA 之间，KV 相差近一个数量级。

▪ 上下文长度：平均 2K 与平均 32K，KV 预算差了 16 倍，并发能力随之坍缩。

▪ 输入输出比：长输入短输出偏 Prefill，短输入长输出偏 Decode，两者的瓶颈与调参方向相反。

▪ 精度：权重 FP16 到 INT4 省 4 倍，KV 换 FP8 再省一半，这是最直接的显存来源。

▪ 批策略：批越大越省权重带宽，但 KV 占用同步上升，存在一个吞吐最优、延迟可接受的甜点区。

关键参数	建议起点	作用与注意事项
--max-model-len	真实上限（如 16K）	不要写 128K；KV 容量按此线性放大，直接影响可并发数
--max-num-seqs	32 → 48 → 64 逐步试	吞吐与延迟的旋钮。看 running / waiting 队列长度，而不是看显存百分比
--gpu-memory-utilization	0.90–0.92	太高会被其他进程或碎片卡死，太低则浪费 KV 预算
--enable-prefix-caching	开启	系统提示词、仓库摘要前置可显著降首字延迟；前缀必须逐 token 完全一致
--kv-cache-dtype	fp8	并发容量近似翻倍，需用自有评测集确认精度损失
--tensor-parallel-size	= GPU 数	单卡装不下时的必要手段，通信开销随卡数上升

表 4　启动参数调优清单：先量基线，再动一个参数，一次只改一个

4.5 三个最常见的误区

误区一：“上了 vLLM 就能快 24 倍。” 24 倍是相对“未做任何优化的 HF 基线”。如果你已经在用 TGI 或其它引擎，现实收益是 2 到 3 倍——这依然很值，但要写对预算。

误区二：“并发开满最快。” 批越大，KV 占用越高，每 token 的边际成本先降后升；而且批太大时，排在队尾的请求首字延迟会失控。并发是旋钮，不是越大越好的开关。

误区三：“只调引擎，不看模型。” 同样是 7B，GQA 结构的 KV 只有 MHA 的九分之一。换模型带来的显存收益，往往大于任何调度技巧——这也是“代际答案”能到 20 倍以上的原因。

五 Vibe 案例：12 人团队把 8 路并发做到 42 路

5.1 背景：一个典型的 Vibe Coding 工作流

客户是一家 12 人的 AI 编程工具团队，产品形态是最典型的 Vibe Coding：开发者在 IDE 里用自然语言描述意图，助手实时补全、改写、解释代码；企业版还会把整个代码仓库的摘要作为上下文注入。内部把这种“人描述意图、AI 写代码、人只做审查”的协作方式称为 vibe coding——它极其依赖低首字延迟，因为任何超过一秒的等待都会打断心流。

改造前，他们用 HuggingFace Transformers 加自研静态批处理，跑 Qwen2.5-Coder-7B-Instruct（FP16），单卡 A10G 24GB。晚高峰（21:00–23:00）稳定并发只有 8 路，单卡吞吐 330 tokens/s，P95 首字延迟 3.1 秒——用户体感就是“要等三秒才看到第一个字”。为了撑住高峰，他们常年准备着 3 张卡。

注：本案例基于公开基准方法复现，数值为同一环境下的实测区间，具体结果随版本与硬件浮动。

5.2 目标与约束：不换模型、不加卡

约束很硬：不能换模型（代码模型的能力是产品卖点）、不能再加卡（预算已冻结）、P95 首字延迟要压进 1 秒、峰值并发至少 35 路。三个目标同时成立，只剩一条路——把同一张卡的效率榨出来。

5.3 改造后的架构

整套架构其实只多了三样东西：网关负责鉴权、租户限流与路由；vLLM 以无状态副本方式跑在 GPU 上；监控端接入 Prometheus，采集 KV 显存占用、running / waiting 队列长度与 token 吞吐三个核心指标。模型与算力之间因此多了一层可替换的接口——换卡、换模型、加副本，都不需要动业务代码。

图 5　Vibe 团队的单卡推理部署参考架构

5.4 四步迁移：两周完成

第一步，立基线。用内网真实请求采样 500 条固定数据集，记录吞吐、P95、并发上限与一次性通过率，先避免“感觉变快了”这种无法验收的结论。

第二步，起服务。官方镜像或 pip 安装后一条命令拉起 OpenAI 兼容服务；max-model-len 设成真实的 16K 而不是文档示例里的 128K，否则 KV 预算会被一次性吃掉。

第三步，调并发。max-num-seqs 从 16 开始逐级加到 64，每一档都跑同一份数据集，记录吞吐与 P95 的拐点；gpu-memory-utilization 停在 0.90–0.92，kv-cache-dtype 切到 fp8。

第四步，加复用。打开前缀缓存，并把系统提示词、工具说明、仓库摘要按“变化频率从低到高”排序前置——前缀缓存要求逐 token 完全一致，任何时间戳或随机排序都会让命中率归零。

vllm serve Qwen/Qwen2.5-Coder-7B-Instruct \

--max-model-len 16384 \

--max-num-seqs 48 \

--gpu-memory-utilization 0.92 \

--kv-cache-dtype fp8 \

--enable-prefix-caching \

--enable-chunked-prefill \

--port 8000

5.5 结果：同一张 A10G，三项指标同时改善

两周后，同一张 A10G 24GB 上，稳定并发从 8 路提升到 42 路（5.3 倍），单卡吞吐从 330 tokens/s 提升到 1450 tokens/s（4.4 倍），P95 首字延迟从 3.1 秒降到 0.68 秒（缩短 78%）；单位请求的综合推理成本相应降到约五分之一。原本为了扛高峰准备的第 2、3 张卡被退租，卡的利用率反而更高了。

图 6　Vibe 案例改造前后对比（同一张 A10G 24GB，同一模型，同一数据集）

指标	改造前（HF + 静态批）	改造后（vLLM）	变化
稳定并发	8 路	42 路	×5.3
单卡吞吐	330 tokens/s	1450 tokens/s	×4.4
P95 首字延迟	3.1 s	0.68 s	−78%
卡数占用	3 张 A10G	1 张 A10G	−67%
支撑规模	日活约 120 人	日活约 300 人	×2.5

表 5　改造前后核心指标对比（同卡同模型同数据集）

5.6 六条踩坑记录，比结论更值钱

▪ 显存够不代表能开大 max-num-seqs。先看 running 与 waiting 队列长度，再看 KV 使用率，最后才看 nvidia-smi 的百分比——那个数字经常骗人。

▪ 首字延迟的锅常常在排队，不在推理。waiting 队列长说明并发不够，running 队列长说明算力不够，两件事的解法完全相反。

▪ 前缀缓存对“逐 token 完全一致”极其敏感。系统提示词里放一个秒级时间戳，命中率就会直接归零。

▪ 长 prompt 一定要开 chunked prefill。一个 3 万 token 的粘贴，足以让同期所有用户的输出集体卡顿。

▪ 流式输出要盯 TTFT 与 TPOT 两个指标，而不是总耗时。总耗时会被输出长度稀释，掩盖真实体感。

▪ 换引擎会改变随机性。同样的 temperature 下，采样结果与 HF 不完全一致，所有评测基线都要重跑。

六落地路线图：30 天把 vLLM 用起来

如果你准备在自己的环境里复现上面的结果，可以按这张表推进。原则只有一条：先测量，再优化，一次只改一个变量。

阶段	目标	关键动作	验收指标
第 1 周｜立基线	把“现在多快”变成数字	固定 500 条真实请求；记录吞吐、TTFT、P95、通过率	基线报告可复现
第 2 周｜起服务	一周内跑通等价服务	部署 vLLM；接 OpenAI 兼容接口；对齐输出质量	响应格式与质量不降级
第 3 周｜调显存	把并发抬起来	max-num-seqs 阶梯测试；FP8 KV；前缀缓存；chunked prefill	并发 ≥ 4×，P95 ≤ 1s
第 4 周｜上规模	从单卡到可用集群	多副本 + 网关限流；监控告警；回滚预案	高峰无排队雪崩