为什么大模型推理都在用vLLM？聊聊 PagedAttention 如何降低推理成本

大模型推理中的显存浪费问题，被一种借鉴操作系统思路的技术有效缓解了。

在生成式AI领域，大语言模型的参数量和上下文长度持续增长。开发者将模型部署到生产环境时，常常遇到两个现实问题：推理成本高，以及显存溢出（OOM）。GPU 数量增加，吞吐量却未必成比例提升。

vLLM 是当前比较流行的大模型推理加速框架之一。很多开发者切换到vLLM后，发现系统吞吐量有明显提升。据官方基准测试，相比 HuggingFace Transformers，

vLLM的吞吐量最高可达24倍；相比 TGI(Text Generation Inference)，最高可达3.5倍。AWS、阿里云、字节跳动等云厂商也在生产系统中集成了vLLM。

那么vLLM是怎么做到的？主要归功于它管理显存的方式。

一、大模型推理的显存瓶颈

要理解 vLLM的设计，先看传统推理框架的问题。

大模型生成文本时，采用的是“自回归”方式：根据已生成的历史文本，逐词预测下一个词。为了避免重复计算历史，工业界普遍使用KV Cache技术-把已计算好的中间结果缓存在显存中。随着对话轮次增加或上下文变长，KV Cache的体积会迅速膨胀。

传统推理框架为了简化内存管理，会为每个请求分配一块连续且静态的显存空间，相当于提前按最大可能长度预留。这种做法带来三个典型问题：

1．过度预分配：按模型支持的最大长度预留，即使实际输入很短。

2．显存碎片化：预留了但未使用的空间无法被其他请求利用，浪费率可达60％以上。

3．并发受限：显存被预留占满后，新请求只能排队。

研究表明，传统框架下GPU显存的有效利用率往往不足40％。企业不得不购买更多GPU 来应对。

二、PagedAttention:vLLM 的核心设计

vLLM 由加州大学伯克利分校的 LMSYS 团队提出，核心创新是PagedAttention，其灵感来自操作系统的虚拟内存管理。

具体做法：

·非连续存储：KV Cache 被分割成固定大小的“键值块”KV Blocks，默认每块容纳512个token）。这些块在物理显存中不必连续存放，可以分散在空闲位置。

·虚拟页表映射：vLLM 维护一个“页表”，记录每个请求所使用的块ID序列。运行时，自定义CUDA 内核根据页表动态拼接这些分散的块，在逻辑上还原出完整的KV序列-这个过程对模型完全透明。

·按需分配，零拷贝扩容：新请求来了，只给它分配一个块；生成内容超出当前容量时，再申请一个新块追加到页表末尾，无需搬移已有数据。

·连续批处理：传统框架必须等 batch 填满才开始推理，而vLLM 允许随时插入新请求，只要GPU还在计算，就能持续接收新任务，使GPU 始终保持较高的利用率。

此外，vLLM 还支持前缀缓存（Prefix Caching)：如果多个请求共享相同的前缀（如系统提示词或对话历史），它们的KV Cache 可以复用，避免重复计算。这在多轮对话和少样本学习场景中能进一步降低延迟。

通过这种精细的显存管理，vLLM 大幅减少了显存碎片和浪费，提升了并发能力和吞吐量。这也是它能在实际生产中被广泛采用的核心原因。

三、三类算力服务商如何落地 vLLM？

开源框架提供了基础能力，但在实际生产环境中，还需要算力服务商根据自身基础设施做工程优化。不同背景的服务商，其技术路径和优化重点也有所不同。这里选择三类具有代表性的服务商：

·大型公有云厂商：以阿里云为代表，提供标准化、企业级的推理服务平台，重点在于与云原生生态的深度集成以及企业级功能扩展。

·互联网巨头旗下的云平台：以火山引擎为代表，侧重大规模集群下的通信优化

和自研引擎创新。

·专业算力基础设施服务商：以蓝耘科技为代表，通常拥有自有GPU集群，在引擎优化和弹性架构方面有自己的实践。

下面分别介绍这三类服务商的具体实践。

阿里云 PAI（公有云厂商代表）

阿里云人工智能平台PAI 深度集成了vLLM。在GPU实例上，PAI 提供完整的vLLM 容器镜像，帮助用户快速部署大模型推理服务。在企业级功能方面，PAI依托云原生生态，推出了PD分离部署（Prefill-Decode)，将预填充和解码阶段拆分到不同计算资源上，以优化延迟和吞吐。此外，支持DeepSeek-R1 等MoE 模型的 EP 专家并行部署，并提供与OpenAl API 兼容的接口，便于现有应用迁移。

火山引擎（互联网云平台代表）

火山引擎的机器学习平台veMLP 原生集成了vLLM，并进行了性能调优。火山引擎自研了PD分离＋EP并行的推理引擎，将预填充和解码阶段拆分到不同GPU节点，配合高性能 RoCE 网络，在长上下文场景下控制延迟。据公开信息，火山引擎接入vLLM后，平均吞吐量提升约8倍，部分场景接近10倍。

蓝耘元生代（专业算力基础设施服务商代表）

蓝耘元生代的推理服务基于自建GPU 集群。与依赖第三方租用算力的平台不同，自有集群可以避免资源超卖带来的性能波动，调度链路更短。在引擎层面，蓝耘基于vLLM 和 SGLang 进行自研优化，采用动态批处理和分页式KV Cache 管理。在部署模式上，提供了从共享API（按量付费、自动弹性）到专属资源池的平滑迁移路

径，企业可在业务增长后无缝切换，无需改造代码。

四、小结

大模型推理的优化，既依赖开源框架的创新（如vLLM的 PagedAttention、连续批处理、前缀缓存），也依赖算力服务商在工程层面的打磨。从上述三类服务商可以看出，不同背景的厂商各有侧重：公有云厂商强调整体平台能力和企业级功能，互联网云平台擅长大规模集群通信优化，而专业算力服务商则在自有集群基础上探索引擎优化与弹性架构。

对于企业用户而言，了解这些不同技术路径背后的逻辑，有助于结合自身业务场景（如规模、延迟敏感度、数据合规要求等）做出更合适的选择。

数据来源说明：

·本文引用的 vLLM 官方性能数据（相比 HuggingFace Transformers 吞吐量最高提升24倍，相比TGI最高提升3.5倍）来自 vLLM 官方 GitHub 仓库及 SOSP 2023 论文《Efficient Memory Management for Large Language Model Serving with PagedAttention》。

·火山引擎的吞吐量提升数据（平均约8倍，部分场景接近10倍）引自其公开技术大会分享及官方技术博客。

·阿里云 PAI的产品功能信息（vLLM 容器镜像、PD分离部署、EP 专家并行部署、一键部署 DeepSeek **模型等）来自阿里云官方帮助文档：**EAS Prefill-Decode 分离功能发布公告、EP专家并行部署功能说明、Model Gallery 推理加速匹配功能等。

·蓝耘科技的技术信息来自其公开的技术白皮书。

附录：vLLM 快速上手与常见问题

代码示例：使用vLLM 部署并调用一个开源模型

以下是一个最基础的 vLLM 服务启动和调用示例（以Llama 3.1 8B 为例）：

1．安装 vLLM

bash

pip install vllm

2．启动 OpenAl 兼容的 API 服务

bash

python -m vllm.entrypoints.openai.apiserver \

--model meta-llama/Meta-Llama-3.1-8B-Instruct\

--tensor-parallel-size 1\

--max-model-len 8192\

--port 8000

3．使用 curl 或 Python 调用

curl http://localhost:8000/v1/completions\

-H "Content-Type: application/json"\

-d'{

"model": "meta-llama/Meta-Llama-3.1-8B-Instruct",

＂prompt":＂大模型推理的显存优化方法有哪些？”，

$"max\_tokens":256$ ,

"temperature":0.7

}

Python 调用示例：

python

from openai import OpenAl

$$\text {client=OpenAl(}$$

$base\_url="http://localhost:8000/v1"$ ,

$$\text {api_{key}="EMPTY"}$$

)

$$response=client.completions.create($$

$model="meta-llama/Meta-Llama-3.1-8B-Instruct"$ ,

**prompt=＂大模型推理的显存优化方法有哪些？"，**

$$\text {max_{tokens}=256}$$

)

print(response.choices[0].text)

vLLM 默认使用 PagedAttention 进行 KV Cache 管理，上述命令即可享受到其带来的吞吐提升。

常见问题（FAQ）

Q1:vLLM 支持哪些主流模型？

vLLM 目前广泛支持 LLaMA、Mistral、Qwen、DeepSeek、Baichuan、ChatGLM 等主流开源模型架构。具体支持列表可在vLLM 官方文档的“Supported Models”页面查看。部分 MoE 模型（如 DeepSeek-V2、Mixtral）也提供实验性支持，可能需要调整并行参数。

Q2：如何在使用vLLM时处理超长上下文（如128K tokens)？

·适当增大–max-model-len参数，但需注意该值受限于单卡显存大小。若超出显存，可启用–enable-prefix-caching 复用公共前缀，或使用–tensor-parallel-size进行多卡张量并行。

·对于超过单卡容纳能力的上下文，可采用流水线并行（–pipeline-parallel-size）或将模型部署在多节点上。

·监控 GPU显存使用情况，避免因上下文过长导致OOM。vLLM的

PagedAttention 机制相比传统框架已经大幅降低了长上下文场景下的显存碎片，但仍需根据实际硬件调整批处理大小（–max-num-batched-tokens）。