大模型推理性能优化：PagedAttention与Continuous Batching原理与实践

1. 项目概述：解码大模型推理的吞吐量革命

如果你最近在折腾大语言模型（LLM）的本地部署或者推理服务，大概率会被两个词刷屏：PagedAttention和Continuous Batching。这俩技术不是什么花里胡哨的新模型架构，而是实打实解决推理效率瓶颈的“工程利器”。简单来说，它们要解决的核心矛盾是：如何让昂贵的GPU（比如A100、H100）在服务用户时，别闲着，尽可能一刻不停地干活，把每秒能处理的token数（吞吐量）和每个请求的响应速度（延迟）都提上去。

传统上，我们跑一个模型，就像让一个大厨一次只做一道菜。用户A点了一份“蛋炒饭”（生成一段文本），大厨就得从洗米、蒸饭、切葱花、炒制全程服务，期间厨房（GPU）被完全占用，其他用户只能干等着。这就是经典的静态批处理（Static Batching）或更原始的逐个请求处理。当用户请求一多，要么排队时间长得离谱，要么GPU利用率低得可怜，大部分时间在等内存搬运或者IO。

PagedAttention和Continuous Batching的出现，就是为了把“大厨”变成“高效中央厨房”。PagedAttention聚焦于优化厨房内部最宝贵的“工作台”（GPU显存）的使用方式，让多道菜的备料（注意力机制的Key/Value缓存）能像图书馆的书一样分页存放、灵活取用，避免浪费。而Continuous Batching则负责厨房的调度系统，它不再等一道菜完全做完再做下一道，而是实时观察每道菜的进度（已生成的token数），把处于相同烹饪阶段（如都在“翻炒”阶段）的多个请求拼在一起，让大厨一锅同时炒好几份，最大化利用炒锅（GPU计算单元）的热度。

我亲身经历过从早期逐个推理到引入这些技术后的性能飞跃。一个典型的7B参数模型，在只优化模型代码的情况下，A10显卡的吞吐可能只有几十 token/s。而接入了基于这些技术构建的推理引擎（如vLLM）后，吞吐量轻松提升数倍甚至一个数量级，同时还能保持较低的延迟。这对于任何想提供稳定、高效AI服务的企业或个人开发者来说，都是必须啃下的硬骨头。接下来，我就结合实操，带你彻底搞懂这两项技术是如何工作的，以及如何在实际项目中应用它们。

2. 核心原理深度拆解：从内存与调度瓶颈破局

要理解这两项技术为何如此有效，我们必须先看清它们要解决的根本问题。大模型推理，尤其是生成式任务（如对话、续写），其计算过程可以粗略分为两个阶段：预填充（Prefill）和解码（Decode）。预填充阶段处理用户的整个输入提示（Prompt），计算量较大但只执行一次。解码阶段则自回归地逐个生成token，每次生成只做一次前向计算，但需要反复进行，直到生成结束。瓶颈主要出现在解码阶段。

2.1 注意力机制与KV缓存的内存之殇

Transformer模型的核心是自注意力机制。在生成每个新token时，模型需要参考之前所有已生成token的信息。为了避免重复计算，标准的做法是将之前所有token的Key和Value张量（合称KV Cache）缓存在显存中。问题就出在这里：显存占用与序列长度成线性增长关系。

假设模型有L层，每层的Key和Value的维度是[batch_size, num_heads, seq_len, head_dim]。在服务多个用户（batch_size > 1）且生成很长文本时，这个缓存会变得极其庞大。更糟糕的是，在传统实现中，为了计算方便，我们通常为每个请求预先分配一个足够大的、连续的显存块来存储整个生成过程中可能用到的KV Cache。这导致了两个严重问题：

1. 内部碎片化：由于无法准确预知每个请求最终的生成长度，我们只能按最大可能长度分配。如果大部分请求生成很短，那么分配的空间大部分被浪费了。
2. 外部碎片化：当不同大小的请求不断创建和释放这些连续的显存块时，显存中会出现许多“内存空洞”，即使总空闲显存足够，也可能无法分配出一个新的连续大块，导致服务失败。

这就好比早期的电脑内存管理，每个程序都需要一块连续的物理内存，程序一多，内存很快就变得七零八落，无法有效利用。PagedAttention的灵感正是来源于操作系统的虚拟内存和分页机制。

2.2 PagedAttention：为KV缓存引入“虚拟内存”管理

PagedAttention的核心思想是将每个请求的KV Cache在逻辑上视为一个连续的张量，但在物理存储上，将其切分成固定大小的块（称为“页”，例如每页存储16个token的KV），这些页可以分散存储在显存的任何位置。系统维护一个逻辑块到物理块的映射表（类似页表）。

这样做带来了革命性的优势：

• 消除外部碎片：因为页是固定大小的，显存管理器可以维护一个空闲页列表。当需要为新请求分配空间时，只需从列表中取出若干空闲页即可，无需寻找连续大块。这极大地提高了显存利用率，允许系统同时服务更多的请求。
• 高效共享内存：这是PagedAttention另一个杀手级特性。在诸如并行采样（beam search）、共享前缀提示（多个用户问相同的问题开头）等场景下，不同计算路径（或请求）的KV Cache可能存在大量重复。传统方式需要为每条路径存储完整副本。而PagedAttention允许不同的逻辑块映射到同一个物理页上，实现了显存的零拷贝共享，进一步节省了大量空间。

在实际操作中，vLLM等引擎实现PagedAttention时，会有一个专门的“块管理器”（Block Manager）。它会将GPU显存池化，划分为许多大小固定的块。每个请求的生成过程，就是按需向块管理器申请和释放这些块。当你要运行注意力计算时，引擎会根据页表，将分散的物理块中的数据高效地收集（Gather）到一起，形成一个临时的逻辑视图供计算使用。

注意：PagedAttention的实现深度依赖于CUDA内核的优化，特别是高效的数据收集（Gather）和分散（Scatter）操作。对于普通开发者，更现实的是直接使用集成了此技术的推理引擎，而非自己从头实现。

2.3 Continuous Batching：让GPU永远“忙”起来

解决了内存问题，我们来看调度问题。传统的静态批处理（Static Batching）在服务开始前组好一个批次（Batch），然后整个批次一起完成所有生成步骤。这就像旅行团的大巴，必须等所有人都上车后才发车，并且必须等所有人都游览完所有景点后才返回。如果有人（请求）生成得很快（比如只生成了10个token），他也必须等待同批次里最慢的那个人（比如生成了100个token）完成后，整个批次才能释放资源，处理下一批请求。这造成了严重的资源空置。

Continuous Batching（连续批处理，也被称为迭代级调度或流式批处理）打破了这一限制。它的策略非常直观：

1. 实时调度：系统维护一个全局的请求队列。在每个解码迭代步（即生成一个token的步骤）开始时，调度器会检查所有正在处理的请求。
2. 状态分组：它将所有已经完成当前迭代步之前所有计算的请求（即它们的KV Cache是最新的，可以参与下一次前向计算）组合成一个新的“计算批次”。
3. 非对称计算：这个新批次中的各个请求，其序列长度（Prompt长度 + 已生成长度）很可能不同。现代推理引擎（如FasterTransformer、TGI）通过高效的填充（Padding）和掩码（Mask）技术，以及像FlashAttention这样的优化算法，能够高效处理这种“非对称”或“锯齿状”（Ragged）的批次。
4. 动态更新：当一个请求生成结束（遇到结束符或达到最大长度），它立即被移出处理队列，其占用的资源（如PagedAttention管理的块）被释放。同时，新的请求可以从队列中加入进来，参与到下一次迭代的批次中。

这样一来，GPU就像一条高效的流水线，每个时钟周期都在处理当前“就绪”的任务，吞吐量得以最大化。从用户感知上看，虽然每个请求的延迟（从开始到结束的时间）取决于其自身生成长度，但由于GPU被高效利用，系统的整体吞吐量极高，平均延迟也得以降低。

3. 实操：基于vLLM构建高性能推理服务

理解了原理，我们来看如何落地。目前，将PagedAttention和Continuous Batching结合得最成熟、最易用的开源项目是vLLM。下面我将带你从零开始，部署一个基于vLLM的推理API服务。

3.1 环境准备与vLLM安装

首先，确保你的环境有Python（>=3.8）和合适版本的PyTorch。最重要的是CUDA驱动和工具包必须正确安装。

# 创建一个新的虚拟环境（推荐） conda create -n vllm-demo python=3.10 -y conda activate vllm-demo # 安装PyTorch（请根据你的CUDA版本到PyTorch官网选择对应命令） # 例如，对于CUDA 12.1： pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 # 安装vLLM。官方推荐从源码安装以获得最新特性和最好性能，但pip安装更简单 pip install vllm # 安装额外的依赖，用于OpenAI兼容的API服务器 pip install 'vllm[openai]'

安装完成后，可以通过一个简单的命令测试vLLM是否能正常使用一个本地模型进行推理：

python -c "from vllm import LLM; llm = LLM(model='facebook/opt-125m'); output = llm.generate('Hello, my name is'); print(output)"

这个命令会下载一个很小的OPT-125M模型并尝试生成。如果一切顺利，你会看到输出结果。注意，首次运行会下载模型，需要一定时间和网络环境。

3.2 启动OpenAI兼容的API服务器

vLLM提供了一个高度兼容OpenAI API协议的服务器，这意味着你可以直接使用OpenAI的SDK或任何兼容OpenAI的客户端来调用你的私有模型。

启动服务器的命令非常直接：

python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-2-7b-chat-hf \ --served-model-name llama-2-7b-chat \ --max-model-len 4096 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9

让我解释一下这几个关键参数：

• --model: 指定Hugging Face模型ID或本地模型路径。这里使用Meta的Llama 2 7B Chat模型。
• --served-model-name: 客户端调用时使用的模型名称。
• --max-model-len: 模型支持的最大上下文长度（包括输入和输出）。设置此值有助于vLLM更精确地管理内存。
• --tensor-parallel-size: 张量并行度。如果你有多张GPU，可以设置为GPU数量以进行模型并行，加速推理。单卡设为1。
• --gpu-memory-utilization: 目标GPU显存利用率。vLLM会尝试通过动态批处理将显存占用维持在这个比例附近。设为0.9是一个比较激进但能最大化吞吐的策略。

服务器启动后，默认会在http://localhost:8000提供API服务。它提供了与OpenAI几乎一样的/v1/completions和/v1/chat/completions端点。

3.3 客户端调用与性能观察

你可以使用任何HTTP客户端或OpenAI SDK进行调用。这里用Python的requests库示例：

import requests import json # 配置API端点 url = "http://localhost:8000/v1/completions" headers = {"Content-Type": "application/json"} # 准备请求数据 data = { "model": "llama-2-7b-chat", # 与 --served-model-name 一致 "prompt": "请用中文解释一下什么是人工智能。", "max_tokens": 150, "temperature": 0.7, "stream": False # 设为True可以流式输出 } # 发送请求 response = requests.post(url, headers=headers, data=json.dumps(data)) result = response.json() print(result['choices'][0]['text'])

更强大的测试是进行并发请求，以观察Continuous Batching的效果。你可以写一个简单的脚本，模拟多个用户同时发送请求。在服务器日志中，你会看到vLLM动态调整批次大小的信息。

实操心得：

• 模型加载：首次加载大模型（如7B、13B）会较慢，因为需要从网络下载并初始化。建议将常用模型提前下载到本地目录，然后使用--model /path/to/local/model参数启动。
• 显存监控：在运行服务时，使用nvidia-smi命令监控GPU显存使用情况。你会看到vLLM能够将显存利用率稳定在你设定的目标值附近，并同时处理大量请求，这正是PagedAttention和Continuous Batching在起作用。
• 参数调优：--max-model-len对性能影响很大。如果你确定请求不会很长，将其设置为一个较小的值（如1024）可以显著增加并发请求数，因为每个请求预留的内存块更小。

3.4 高级配置与参数解析

要让vLLM发挥最佳性能，需要理解其核心配置参数：

• --block-size: PagedAttention中块的大小（以token数计）。默认是16。这是一个权衡参数：块越小，内存利用率越高（碎片更少），但管理开销（页表查询、数据收集）会增大。对于大多数场景，16是一个经验证的良好平衡点。除非你有非常特殊的序列长度分布，否则不建议修改。
• --swap-space: 当GPU显存不足时，vLLM可以将部分KV缓存块交换到CPU内存。这允许你运行比物理显存更大的工作负载，但会引入CPU-GPU之间的数据传输延迟，严重影响性能。除非万不得已，否则不要依赖交换空间，它只是一个保底机制。性能优先的方案是使用量化或更小的模型。
• --enable-prefix-caching: 启用提示前缀缓存。对于有共享前缀的多个请求（例如，系统提示相同），这可以避免重复计算，大幅提升吞吐。强烈建议开启。
• --quantization: 量化方式。例如--quantization awq可以加载AWQ量化模型，用极小的精度损失换取显存占用的大幅降低和速度提升，是扩展服务能力的首选方案。

一个生产环境可能使用的启动命令示例如下：

python -m vllm.entrypoints.openai.api_server \ --model /data/models/llama-2-7b-chat-awq \ --served-model-name llama-2-7b-chat \ --max-model-len 4096 \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.85 \ --block-size 16 \ --enable-prefix-caching \ --quantization awq

4. 性能对比与效果实测

纸上得来终觉浅，我们通过一组简单的对比测试，来量化PagedAttention + Continuous Batching带来的收益。我使用同一台配备单张A10G（24GB显存）的服务器，测试模型为meta-llama/Llama-2-7b-chat-hf。

测试场景：模拟聊天对话，每个请求的输入提示长度平均为50 tokens，要求生成100个新tokens。使用Locust工具模拟并发用户。

对比基线：使用Hugging Face标准的pipeline进行推理，采用最简单的“for循环逐个处理请求”的方式。

测试方案：使用vLLM的OpenAI API服务器。

结果分析：

1. 吞吐量飞跃：12倍的提升是极具代表性的。这主要归功于Continuous Batching让GPU在每个时刻都满载工作，以及PagedAttention允许更多请求共存于显存。
2. 高且稳定的利用率：vLLM通过主动的显存管理和调度，将GPU这个最昂贵的资源“压榨”到了极致，避免了资源闲置。
3. 并发能力质变：从串行到支持数十个并发请求，这使得用单卡服务一个轻量级用户群体成为可能。

注意：实际提升倍数取决于具体的工作负载（提示长度、生成长度分布、模型大小等）。对于提示很长但生成很短的场景（如分类），提升可能没那么夸张；但对于典型的对话、创作等生成长文本场景，提升极其显著。

5. 常见问题与排查技巧实录

在实际部署和运维中，你肯定会遇到各种问题。下面是我踩过的一些坑和解决方案。

5.1 内存不足（OOM）问题

这是最常见的问题。错误信息可能包含CUDA out of memory。

• 排查步骤：
  1. 检查--max-model-len：这是首要怀疑对象。如果你设置的max-model-len是8192，但实际物理显存不足以支撑如此多并发请求的KV缓存，就会OOM。根据你的显存大小和预期并发数，调低此值。一个7B模型，在24G显存上，设置4096通常比较安全。
  2. 检查--gpu-memory-utilization：如果你设置得过高（如0.95），系统可能没有预留足够空间给模型权重、激活值和其他开销，导致OOM。尝试降低到0.8或0.85。
  3. 监控实际使用：在启动服务器后，立即运行nvidia-smi，观察显存基础占用。然后用压测工具模拟请求，观察显存增长是否平稳，最终是否稳定在目标利用率附近。如果瞬间打满然后崩溃，可能是并发请求初始批次太大。
  4. 使用量化模型：这是解决OOM最有效的方法。将FP16模型转换为GPTQ、AWQ或GGUF等量化格式，可以轻松减少50-70%的显存占用。vLLM对AWQ和GPTQ有很好的原生支持。

5.2 生成速度慢

感觉吞吐量没有达到预期。

• 排查步骤：
  1. 确认是否启用连续批处理：检查日志，在请求处理时，是否看到批次大小（batch size）在动态变化。如果批次大小始终为1，可能是请求速率太低，调度器没有机会组批。需要提高并发压力测试。
  2. 检查CPU瓶颈：使用htop等工具查看CPU使用率。如果vLLM的进程CPU占用率很高，可能是预处理（tokenization）、调度或结果后处理成了瓶颈。确保你的服务器CPU性能不是短板。
  3. 检查模型配置：--tensor-parallel-size设置是否正确？如果你有多张GPU，将其设置为GPU数量可以加速。但如果你只有一张卡，却设置了大于1的值，会导致错误。
  4. 分析工作负载：超长的提示（Prefill阶段）会拖慢整个批次的解码速度，因为Prefill阶段计算复杂度是序列长度的平方。如果您的应用场景提示非常长，可以考虑使用vLLM的前缀缓存(--enable-prefix-caching) 来缓存常见的提示前缀。

5.3 请求超时或无响应

客户端收到超时错误。

• 排查步骤：
  1. 检查队列堆积：vLLM有内置的请求队列。如果瞬时请求量远超系统的处理能力，队列会积压，导致后续请求等待超时。你需要根据实测的吞吐量，在客户端或前端设置合理的速率限制（Rate Limiting）和排队机制。
  2. 检查网络和代理：确保客户端与API服务器之间的网络通畅，没有防火墙或代理设置错误。
  3. 查看服务器日志：vLLM的日志会记录错误信息。常见的有tokenizer加载失败、模型文件损坏等。根据日志提示进行修复。

5.4 与现有服务集成问题

如何将vLLM集成到我的FastAPI、Django等现有Web服务中？

• 推荐方案：不要将vLLM的服务器与你的业务服务器混在一个进程里。最佳实践是：
  1. 将vLLM的OpenAI API服务器作为一个独立的推理后端微服务部署。
  2. 你的业务服务器（如FastAPI）作为中间层，负责身份验证、业务逻辑、请求编排等。
  3. 业务服务器通过HTTP客户端（如httpx,requests）调用后端的vLLM服务。
  4. 这样实现了关注点分离：推理服务专注于高效、稳定地运行模型；业务服务专注于处理用户逻辑。两者都可以独立扩展、升级和运维。

一个简单的FastAPI集成示例：

# business_server.py from fastapi import FastAPI, HTTPException import httpx import asyncio app = FastAPI() VLLM_API_URL = "http://localhost:8000/v1/chat/completions" async def call_vllm(messages): async with httpx.AsyncClient(timeout=30.0) as client: payload = { "model": "llama-2-7b-chat", "messages": messages, "max_tokens": 200, "temperature": 0.8, } try: resp = await client.post(VLLM_API_URL, json=payload) resp.raise_for_status() return resp.json()['choices'][0]['message']['content'] except httpx.RequestError as exc: raise HTTPException(status_code=503, detail=f"推理服务请求失败: {exc}") @app.post("/chat") async def chat_endpoint(user_message: str): # 这里可以添加用户认证、消息过滤、上下文管理等业务逻辑 messages = [{"role": "user", "content": user_message}] reply = await call_vllm(messages) # 这里可以添加对话历史存储、审计日志等 return {"reply": reply}

这套架构清晰、健壮，是生产环境的首选。