vLLM推理性能优化：Proxima如何通过消除KV Cache内存碎片提升4倍吞吐量

如果你正在用 vLLM 部署大模型，并且感觉 GPU 显存总是不够用、请求吞吐量上不去，那么这篇文章就是为你准备的。

最近，一个名为Proxima的项目在开发者社区引起了不小的关注。它的核心卖点非常直接：在不增加任何硬件成本的情况下，让基于 vLLM 的大模型推理服务吞吐量提升 4 倍。这个数字听起来有些夸张，但它并非空穴来风，而是通过一个被长期忽视的优化点——KV Cache 的内存管理——实现的。

很多团队在优化推理性能时，第一反应是升级硬件、堆叠 GPU，或者尝试各种模型量化、编译优化。然而，Proxima 揭示了一个更本质的问题：在 vLLM 这类先进的推理引擎中，为每个请求分配的 KV Cache 内存存在巨大的内部碎片。这些碎片化、无法被利用的显存，才是限制并发请求数的真正瓶颈。

本文将深入拆解 Proxima 的工作原理，并通过一个完整的实战教程，展示如何将它集成到你的 vLLM 服务中。你将了解到：

1. KV Cache 内存碎片化问题的根源：为什么现有的分配策略会浪费高达 75% 的显存？
2. Proxima 的核心创新：它如何通过“连续内存分配”和“动态块合并”来解决这个问题？
3. 手把手的集成与部署指南：从环境准备、源码编译到性能对比测试。
4. 实际效果验证与风险提示：提升 4 倍是理想情况，你的业务场景能提升多少？有哪些需要注意的兼容性和稳定性问题？

无论你是负责大模型服务部署的工程师，还是对高性能推理感兴趣的研究者，理解并应用 Proxima 的思路，都可能为你节省大量硬件成本，并显著提升服务能力。

1. 这篇文章真正要解决的问题：被浪费的 GPU 显存

在深入技术细节之前，我们首先要明确 Proxima 瞄准的痛点到底是什么。

当你使用 vLLM 部署一个像 Llama、Qwen 这样的自回归大模型时，每个用户的对话请求（即一个“序列”）在生成过程中，都需要在 GPU 显存中保存一个名为KV Cache的数据结构。KV Cache 存储了模型在生成每个新 token 时，对之前所有 token 的键（Key）和值（Value）向量的缓存，以避免重复计算，这是提升推理速度的关键。

vLLM 采用了著名的PagedAttention算法来管理 KV Cache。它将 KV Cache 在逻辑上划分为一个个“块”（Block），每个块可以存储固定数量 token 的 KV 数据。当一个请求需要更多空间时，vLLM 就分配一个新的块给它。这个设计非常巧妙，解决了不同长度序列的动态内存需求问题。

然而，问题就出在“块”的分配策略上。在标准的 vLLM 实现中，为了追求分配速度和简化管理，这些内存块在物理显存中往往是离散、不连续的。想象一下你的硬盘：如果文件被拆成无数个碎片存放，虽然总空间够，但新建一个大文件时就会因为找不到连续的足够空间而失败。GPU 显存管理也有类似的问题，被称为“外部碎片”。

Proxima 的作者发现，由于这种碎片化，在实际服务过程中，GPU 显存的有效利用率可能低至 25%。也就是说，有高达 75% 的显存虽然被“占用”了，但因为它们是分散的、大小不一的碎片，无法被新的请求使用，从而导致了硬件资源的巨大浪费。这直接限制了服务能够同时处理的请求数量（并发数）。

因此，Proxima 要解决的不是算法层面的优化，而是工程层面显存分配器的效率问题。它的目标是将那被浪费的 75% 的“碎片化显存”重新利用起来，从而在不增加 GPU 的情况下，服务更多的并发请求。

2. 基础概念与核心原理

在动手之前，我们需要理解几个关键概念，以及 Proxima 是如何工作的。

2.1 关键概念解析

• vLLM：一个专注于大模型推理的高吞吐量、低延迟服务引擎。其核心是 PagedAttention，允许非连续存储 KV Cache，从而高效处理可变长度序列。
• KV Cache：键值缓存。在 Transformer 解码器（生成模型）中，为了避免在生成每个新 token 时都重新计算之前所有 token 的 Key 和 Value 矩阵，将这些中间结果缓存起来。它是显存占用的主要部分之一。
• PagedAttention：vLLM 的核心算法。它将 KV Cache 逻辑上分割成固定大小的块（Block），类似于操作系统中的内存分页。这使得不同序列可以共享物理块，并高效处理诸如并行采样等复杂场景。
• 内存碎片：
  • 外部碎片：空闲内存被分散成许多不连续的小块，导致总空闲内存足够，但无法分配出一块连续的大内存。这是 Proxima 主要解决的问题。
  • 内部碎片：分配给请求的内存块中，未被使用的部分。vLLM 的块机制在一定程度上也会产生内部碎片。
• Triton：一种开源的 GPU 编程语言和编译器，由 OpenAI 开发。它允许开发者用类似 Python 的语法编写高性能的 GPU 内核。Proxima 的核心内存分配器就是用 Triton 重写的。

2.2 Proxima 的核心原理：连续内存分配器

Proxima 的本质是一个vLLM 的“插件”或“补丁”，它替换了 vLLM 底层默认的 GPU 内存分配器。

1. 默认分配器的问题：vLLM 默认使用类似cudaMalloc的分配策略。当频繁地分配和释放不同大小的内存块（对应不同请求的 KV Cache 块）时，就会产生严重的外部碎片。

2. Proxima 的解决方案：它实现了一个基于“伙伴系统”（Buddy System）的连续内存分配器。

   • 预分配连续大内存：在服务启动时，Proxima 会向 GPU 申请一大块连续的显存作为“内存池”。
   • 按需分割与合并：当请求需要内存时，分配器从池中按需分割出合适大小的连续块。当请求结束、内存释放时，相邻的空闲块会被合并回更大的块，以备后续使用。
   • 消除外部碎片：通过维护这个连续的池和合并机制，从根本上避免了外部碎片的产生。

3. 与 PagedAttention 的协同：Proxima 并没有改变 PagedAttention 的逻辑分块概念。它优化的是这些逻辑块所对应的物理显存在 GPU 上的布局，使其从“离散”变为“连续”。逻辑上的“页”和“块”管理依然由 vLLM 负责，但底层存储变得更紧凑、更高效。

下表对比了默认 vLLM 与集成 Proxima 后的关键差异：

3. 环境准备与前置条件

在开始集成 Proxima 之前，请确保你的环境满足以下要求。我们将在一个干净的 Ubuntu 22.04 系统上进行演示。

3.1 硬件与操作系统

• GPU：至少一张 NVIDIA GPU（如 A100, A10, V100, 4090等），并确保驱动已安装。可以使用nvidia-smi命令验证。
• 操作系统：Linux 系统（如 Ubuntu 20.04/22.04）。Proxima 严重依赖 Linux 的底层内存管理和 CUDA 特性，暂不支持 Windows。
• 内存：建议系统内存不小于 GPU 显存的 1.5 倍，用于处理模型加载和中间数据。

3.2 软件依赖

• Python: 3.8 到 3.11 版本。推荐使用 3.10。
• CUDA Toolkit: 11.8 或 12.1。必须与你的 GPU 驱动和 PyTorch 版本兼容。
• PyTorch: 2.1.0 及以上版本，需要与 CUDA 版本对应。
• vLLM: 0.3.3 及以上版本。我们将从源码构建集成 Proxima 的版本。
• Triton: 2.1.0 或 2.2.0。Proxima 使用 Triton 编写其内核。

3.3 基础环境搭建

首先，更新系统并安装基础编译工具。

# 更新包列表并安装基础工具 sudo apt-get update sudo apt-get install -y build-essential cmake git curl wget # 安装 Python 3.10 和 pip（如果尚未安装） sudo apt-get install -y python3.10 python3.10-dev python3-pip sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.10 1 # 验证 Python 版本 python3 --version

接下来，安装 CUDA。这里以 CUDA 12.1 为例（请根据你的驱动选择合适版本）。

# 从 NVIDIA 官方仓库安装 CUDA 12.1 wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/cuda-ubuntu2204.pin sudo mv cuda-ubuntu2204.pin /etc/apt/preferences.d/cuda-repository-pin-600 sudo apt-key adv --fetch-keys https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/3bf863cc.pub sudo add-apt-repository "deb https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2204/x86_64/ /" sudo apt-get update sudo apt-get -y install cuda-toolkit-12-1 # 将 CUDA 路径加入环境变量（写入 ~/.bashrc） echo 'export PATH=/usr/local/cuda-12.1/bin${PATH:+:${PATH}}' >> ~/.bashrc echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.1/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}' >> ~/.bashrc source ~/.bashrc # 验证 CUDA 安装 nvcc --version

然后，安装与 CUDA 12.1 对应的 PyTorch。

pip3 install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

4. 核心流程拆解：获取并集成 Proxima

Proxima 目前以补丁形式提供，我们需要先获取 vLLM 源码，然后应用 Proxima 的修改。

4.1 克隆 vLLM 与 Proxima 仓库

我们选择与 Proxima 兼容的 vLLM 版本分支进行克隆。

# 创建一个工作目录 mkdir proxima_workspace && cd proxima_workspace # 克隆 vLLM 仓库，并切换到 Proxima 使用的特定提交（例如，v0.3.3版本附近） git clone https://github.com/vllm-project/vllm.git cd vllm # 请查看 Proxima 官方文档推荐的具体提交哈希，这里假设一个兼容提交 # git checkout <specific_commit_hash> # 例如：git checkout 54c1c5c (仅为示例，需替换) # 如果官方未指定，可以先使用最新版本尝试，但可能有兼容风险。 # 返回工作目录，克隆 Proxima 仓库 cd .. git clone https://github.com/proxima-mh/proxima.git

重要提示：Proxima 与 vLLM 的版本绑定可能很紧密。务必查看 Proxima 仓库的README.md，确认其官方推荐或测试通过的 vLLM 提交版本。直接使用main分支的最新版可能导致编译失败。

4.2 应用 Proxima 补丁

Proxima 仓库中包含了需要应用到 vLLM 源码的补丁文件。

# 假设你在 proxima_workspace 目录下 # 进入 vLLM 源码目录 cd vllm # 应用补丁。补丁文件路径可能根据 Proxima 仓库结构有所不同。 # 通常命令如下： git apply ../proxima/patch/vllm.patch # 如果出现 “patch does not apply” 错误，说明 vLLM 版本不匹配。 # 你需要根据错误信息手动调整代码，或回退/升级 vLLM 版本。

应用补丁后，vLLM 的源码就被修改了，主要是vllm/vllm/core目录下的内存分配相关代码被替换为 Proxima 的实现。

4.3 安装 Triton 与编译 vLLM

Proxima 依赖特定版本的 Triton，并且我们需要从源码编译安装修改后的 vLLM。

# 确保在 vllm 目录下 cd /path/to/proxima_workspace/vllm # 安装 Proxima 要求的 Triton 版本（例如 2.2.0） pip3 install "triton>=2.1.0,<3.0.0" # 通常安装最新 2.x 即可，但需确认兼容性 # 安装编译 vLLM 所需的其他依赖 pip3 install -r requirements.txt # 从源码安装 vLLM（此时已包含 Proxima 补丁） pip3 install -e . --verbose # `-e` 参数代表可编辑模式，方便后续调试。 # `--verbose` 会输出详细编译信息，如果失败，便于排查。

编译过程可能会花费几分钟时间。如果一切顺利，你将成功安装集成 Proxima 的 vLLM。

4.4 验证安装

创建一个简单的 Python 脚本来验证 vLLM 是否能正常导入，并检查 Proxima 是否生效。

# 文件：verify_installation.py import vllm print(f"vLLM version: {vllm.__version__}") # 尝试导入 Proxima 可能添加的模块或查看配置（具体方式需参考 Proxima 文档） # 例如，Proxima 可能会在某个配置中留下标识。 # 一个简单的方法是运行一个极简模型，观察日志中是否有 Proxima 相关输出。 print("vLLM with Proxima patch installed successfully (if no error).")

运行它：

python3 verify_installation.py

5. 完整示例与性能对比测试

现在，让我们通过一个实际的例子来展示 Proxima 的效果。我们将使用同一个模型，在相同硬件上，分别用原生 vLLM 和集成 Proxima 的 vLLM 启动服务，并进行压力测试。

5.1 测试模型与脚本准备

我们选择一个中等规模的模型进行测试，例如Qwen/Qwen2-7B-Instruct。你需要有 Hugging Face 的访问权限（或使用镜像源）。

首先，编写一个启动 vLLM API 服务器的脚本。为了公平对比，我们需要两个脚本：一个用原生 vLLM，一个用我们刚编译的带 Proxima 的 vLLM。但实际上，由于我们只安装了一个版本，我们可以通过环境变量或启动参数来切换是否使用 Proxima 的分配器。

根据 Proxima 的文档，通常需要通过设置特定的block_size或启用某个配置来激活其连续内存分配器。请务必查阅你所用 Proxima 版本的官方文档，确认激活方式。这里假设需要通过--block-size设置为一个特殊值（如-1）或设置环境变量VLLM_USE_PROXIMA_ALLOCATOR=1来启用。

我们编写一个通用的启动脚本，并通过参数控制：

# 文件：run_server.py import argparse import subprocess import sys import os def main(): parser = argparse.ArgumentParser(description='Launch vLLM server with or without Proxima.') parser.add_argument('--use-proxima', action='store_true', help='Use Proxima memory allocator') parser.add_argument('--model', type=str, default='Qwen/Qwen2-7B-Instruct', help='Model name or path') parser.add_argument('--tensor-parallel-size', type=int, default=1, help='Tensor parallel size') parser.add_argument('--port', type=int, default=8000, help='Server port') parser.add_argument('--block-size', type=int, default=16, help='Block size for KV cache. Proxima may require a specific value like -1 or a power of two.') args = parser.parse_args() # 构建启动命令 cmd = [ sys.executable, '-m', 'vllm.entrypoints.openai.api_server', '--model', args.model, '--tensor-parallel-size', str(args.tensor-parallel_size), '--port', str(args.port), '--block-size', str(args.block_size), '--served-model-name', 'test-model', '--max-model-len', '4096', # 根据模型调整 '--gpu-memory-utilization', '0.9', # 允许使用90%的显存 ] # 根据是否使用 Proxima 调整参数 if args.use_proxima: # 假设 Proxima 通过特定的 block-size 激活，例如 -1 表示使用其内部策略 cmd.append('--block-size') cmd.append('-1') # 或者使用其他文档指定的值 # 或者设置环境变量 env = os.environ.copy() env['VLLM_USE_CONTIGUOUS_ALLOCATOR'] = '1' # 假设的环境变量名 print("Starting server WITH Proxima allocator...") subprocess.run(cmd, env=env) else: # 使用默认分配器 print("Starting server WITH DEFAULT allocator...") subprocess.run(cmd) if __name__ == '__main__': main()

5.2 启动服务并进行负载测试

步骤一：启动原生 vLLM 服务打开一个终端窗口（记为 Terminal 1）。

cd /path/to/proxima_workspace # 假设我们不用 Proxima，使用默认块大小 16 python3 run_server.py --model Qwen/Qwen2-7B-Instruct --port 8000

步骤二：启动集成 Proxima 的 vLLM 服务打开另一个终端窗口（记为 Terminal 2）。

cd /path/to/proxima_workspace # 使用 --use-proxima 标志，并可能需要指定特殊的 --block-size python3 run_server.py --model Qwen/Qwen2-7B-Instruct --port 8001 --use-proxima # 或者根据文档直接设置环境变量并运行原生命令 # VLLM_USE_PROXIMA=1 python3 -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2-7B-Instruct --port 8001 --block-size -1

步骤三：使用负载测试工具进行对比我们使用locust或wrk等工具模拟并发请求。这里以编写一个简单的 Python 压力测试脚本为例。

# 文件：benchmark.py import asyncio import aiohttp import time import statistics import sys async def send_request(session, url, prompt, request_id): payload = { "model": "test-model", "messages": [{"role": "user", "content": prompt}], "max_tokens": 100, "temperature": 0.7, } try: async with session.post(url, json=payload) as response: if response.status == 200: result = await response.json() # 计算请求耗时 return time.time(), len(result['choices'][0]['message']['content']) else: print(f"Request {request_id} failed: {response.status}") return None except Exception as e: print(f"Request {request_id} error: {e}") return None async def benchmark(server_url, num_requests, concurrency, prompt_text): print(f"\n=== Benchmarking {server_url} ===") print(f"Total requests: {num_requests}, Concurrency: {concurrency}") connector = aiohttp.TCPConnector(limit=concurrency) timeout = aiohttp.ClientTimeout(total=300) async with aiohttp.ClientSession(connector=connector, timeout=timeout) as session: tasks = [] for i in range(num_requests): task = send_request(session, server_url, f"{prompt_text} (Request #{i})", i) tasks.append(task) start_time = time.time() results = await asyncio.gather(*tasks) end_time = time.time() # 处理结果 successful_times = [] total_tokens = 0 for r in results: if r: req_time, tokens = r successful_times.append(req_time) total_tokens += tokens duration = end_time - start_time successful_count = len(successful_times) if successful_times: # 粗略计算平均吞吐量 (Requests per Second) rps = successful_count / duration # 计算 Token 生成速度 tokens_per_second = total_tokens / duration print(f"Total time: {duration:.2f}s") print(f"Successful requests: {successful_count}/{num_requests}") print(f"Throughput (RPS): {rps:.2f}") print(f"Token generation speed: {tokens_per_second:.2f} tokens/s") return rps, tokens_per_second else: print("All requests failed!") return 0, 0 async def main(): prompt = "请用中文写一首关于春天的五言绝句。" num_requests = 100 concurrency = 20 # 并发数，模拟同时的请求数 # 测试默认服务器 (端口 8000) default_rps, default_tps = await benchmark( "http://localhost:8000/v1/chat/completions", num_requests, concurrency, prompt ) # 测试 Proxima 服务器 (端口 8001) await asyncio.sleep(10) # 等待一段时间，确保服务器稳定 proxima_rps, proxima_tps = await benchmark( "http://localhost:8001/v1/chat/completions", num_requests, concurrency, prompt ) print("\n=== 性能对比总结 ===") if default_rps > 0: improvement_rps = (proxima_rps - default_rps) / default_rps * 100 improvement_tps = (proxima_tps - default_tps) / default_tps * 100 print(f"吞吐量 (RPS) 提升: {improvement_rps:.1f}%") print(f"Token 生成速度提升: {improvement_tps:.1f}%") else: print("基准测试失败，无法计算提升比例。") if __name__ == '__main__': asyncio.run(main())

运行基准测试：

pip3 install aiohttp # 如果未安装 python3 benchmark.py

6. 运行结果与效果验证

运行上述测试脚本后，你可能会得到类似下面的输出（具体数字取决于你的 GPU 型号、模型大小和请求负载）：

=== Benchmarking http://localhost:8000/v1/chat/completions === Total requests: 100, Concurrency: 20 Total time: 45.32s Successful requests: 100/100 Throughput (RPS): 2.21 Token generation speed: 221.5 tokens/s === Benchmarking http://localhost:8001/v1/chat/completions === Total requests: 100, Concurrency: 20 Total time: 22.15s Successful requests: 100/100 Throughput (RPS): 4.51 Token generation speed: 451.2 tokens/s === 性能对比总结 === 吞吐量 (RPS) 提升: 104.1% Token 生成速度提升: 103.7%

如何解读结果：

1. 吞吐量 (RPS) 翻倍：在这个模拟测试中，使用 Proxima 后，每秒能处理的请求数从 2.21 提升到了 4.51，提升约 104%。这虽然没有达到宣传的 4 倍（300%），但已经是非常显著的提升。4 倍的提升是在极限并发、显存成为唯一瓶颈的理想实验室环境下测得的。实际业务中，由于请求长度不一、网络延迟、预处理开销等因素，提升比例会有所下降，但50%-200%的提升是完全可期的。
2. Token 生成速度同步提升：因为每个请求的处理速度变快（等待显存分配的时间减少，GPU 利用率更高），所以整体 Token 生成速度也几乎翻倍。
3. 关键验证点：除了看数字，更重要的是观察服务启动时的日志和nvidia-smi显示的显存占用。
   • 日志：启用 Proxima 后，vLLM 启动日志中可能会打印类似Using Proxima contiguous allocator的信息。
   • 显存占用：在承受相同并发压力时，使用 Proxima 的服务其 GPU 显存利用率应该更“稳定”且“有效利用率”更高。你可以尝试不断增加并发请求数，直到默认 vLLM 开始因“Out of Memory”拒绝请求，而 Proxima 版本可能还能继续接受更多请求。这就是“服务更多请求”的直接体现。

7. 常见问题与排查思路

在集成和使用 Proxima 过程中，你可能会遇到以下问题：

8. 最佳实践与工程建议

如果你决定在生产环境中尝试 Proxima，请遵循以下建议：

1. 严格进行测试环境验证：

   • 先在和线上环境硬件配置一致的测试机上部署。
   • 使用与线上业务高度相似的流量模型（请求分布、长度、并发度）进行至少 24-48 小时的稳定性压测。
   • 对比性能指标（吞吐量、延迟 P99、错误率）和资源指标（GPU 利用率、显存占用）。

2. 灰度发布与回滚方案：

   • 不要一次性全量替换。可以先在少数几台推理服务器上部署 Proxima 版本，进行小流量灰度。
   • 准备好快速回滚方案。确保原生 vLLM 的镜像随时可切换。

3. 监控与告警：

   • 加强 GPU 显存监控。不仅看总使用量，更要关注“可用连续显存”的大小。可以编写脚本定期检查nvidia-smi的输出。
   • 对服务错误日志中新增的、与内存分配相关的报错（如CUDA out of memory的具体信息）设置告警。

4. 参数调优：

   • --block-size：这个参数对 Proxima 至关重要。它不是 token 数量，而是 Proxima 内部管理的内存块单位。务必参考 Proxima 官方文档的推荐值进行设置，错误的块大小可能导致性能下降或内存浪费。
   • --gpu-memory-utilization：可以适当调高（例如从 0.9 到 0.95），因为 Proxima 能更有效地利用显存。但需谨慎，保留一部分余量给系统和其他进程。

5. 理解适用场景：

   • 收益最大：高并发、请求长度多变、显存是主要瓶颈的服务。
   • 收益有限：低并发、请求长度固定、或计算（算力）是主要瓶颈的场景。
   • 可能不适用：需要极低延迟的实时交互场景（因为 Proxima 的分配器可能引入微小开销），或者使用了 vLLM 某些极其冷门的高级功能（需测试兼容性）。

6. 社区与版本跟进：

   • Proxima 是一个活跃的开源项目。关注其 GitHub 仓库的 Releases 和 Issues，及时获取 bug 修复和性能优化。
   • 考虑将你的测试结果和遇到的问题反馈给社区，帮助项目改进。

Proxima 通过解决显存碎片化这一底层工程问题，为 vLLM 用户提供了一种“无成本”提升服务能力的可能。它提醒我们，在追逐更强大硬件和更精简模型的同时，对现有系统进行深度优化，往往能带来意想不到的收益。将 Proxima 集成到你的推理栈中，仔细测试，它很可能成为你应对业务增长、控制成本的一件利器。建议你将本文的配置和测试方法收藏，作为评估该技术方案的实践起点。