如果你正在用 vLLM 部署大模型并且感觉 GPU 显存总是不够用、请求吞吐量上不去那么这篇文章就是为你准备的。最近一个名为Proxima的项目在开发者社区引起了不小的关注。它的核心卖点非常直接在不增加任何硬件成本的情况下让基于 vLLM 的大模型推理服务吞吐量提升 4 倍。这个数字听起来有些夸张但它并非空穴来风而是通过一个被长期忽视的优化点——KV Cache 的内存管理——实现的。很多团队在优化推理性能时第一反应是升级硬件、堆叠 GPU或者尝试各种模型量化、编译优化。然而Proxima 揭示了一个更本质的问题在 vLLM 这类先进的推理引擎中为每个请求分配的 KV Cache 内存存在巨大的内部碎片。这些碎片化、无法被利用的显存才是限制并发请求数的真正瓶颈。本文将深入拆解 Proxima 的工作原理并通过一个完整的实战教程展示如何将它集成到你的 vLLM 服务中。你将了解到KV Cache 内存碎片化问题的根源为什么现有的分配策略会浪费高达 75% 的显存Proxima 的核心创新它如何通过“连续内存分配”和“动态块合并”来解决这个问题手把手的集成与部署指南从环境准备、源码编译到性能对比测试。实际效果验证与风险提示提升 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 矩阵将这些中间结果缓存起来。它是显存占用的主要部分之一。PagedAttentionvLLM 的核心算法。它将 KV Cache 逻辑上分割成固定大小的块Block类似于操作系统中的内存分页。这使得不同序列可以共享物理块并高效处理诸如并行采样等复杂场景。内存碎片外部碎片空闲内存被分散成许多不连续的小块导致总空闲内存足够但无法分配出一块连续的大内存。这是 Proxima 主要解决的问题。内部碎片分配给请求的内存块中未被使用的部分。vLLM 的块机制在一定程度上也会产生内部碎片。Triton一种开源的 GPU 编程语言和编译器由 OpenAI 开发。它允许开发者用类似 Python 的语法编写高性能的 GPU 内核。Proxima 的核心内存分配器就是用 Triton 重写的。2.2 Proxima 的核心原理连续内存分配器Proxima 的本质是一个vLLM 的“插件”或“补丁”它替换了 vLLM 底层默认的 GPU 内存分配器。默认分配器的问题vLLM 默认使用类似cudaMalloc的分配策略。当频繁地分配和释放不同大小的内存块对应不同请求的 KV Cache 块时就会产生严重的外部碎片。Proxima 的解决方案它实现了一个基于“伙伴系统”Buddy System的连续内存分配器。预分配连续大内存在服务启动时Proxima 会向 GPU 申请一大块连续的显存作为“内存池”。按需分割与合并当请求需要内存时分配器从池中按需分割出合适大小的连续块。当请求结束、内存释放时相邻的空闲块会被合并回更大的块以备后续使用。消除外部碎片通过维护这个连续的池和合并机制从根本上避免了外部碎片的产生。与 PagedAttention 的协同Proxima 并没有改变 PagedAttention 的逻辑分块概念。它优化的是这些逻辑块所对应的物理显存在 GPU 上的布局使其从“离散”变为“连续”。逻辑上的“页”和“块”管理依然由 vLLM 负责但底层存储变得更紧凑、更高效。下表对比了默认 vLLM 与集成 Proxima 后的关键差异特性默认 vLLMvLLM Proxima物理内存布局离散碎片化连续池化管理内存分配策略类似cudaMalloc按块分配基于伙伴系统的自定义分配器外部碎片严重可能浪费大部分显存基本消除内部碎片存在块内未用空间存在与块大小策略相关管理开销较低略有增加需维护池结构核心优势实现简单分配速度快显存利用率极高支持更高并发适用场景通用请求长度差异大高并发、追求极致吞吐量的生产服务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/cu1214. 核心流程拆解获取并集成 ProximaProxima 目前以补丁形式提供我们需要先获取 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 与编译 vLLMProxima 依赖特定版本的 Triton并且我们需要从源码编译安装修改后的 vLLM。# 确保在 vllm 目录下 cd /path/to/proxima_workspace/vllm # 安装 Proxima 要求的 Triton 版本例如 2.2.0 pip3 install triton2.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(fvLLM version: {vllm.__version__}) # 尝试导入 Proxima 可能添加的模块或查看配置具体方式需参考 Proxima 文档 # 例如Proxima 可能会在某个配置中留下标识。 # 一个简单的方法是运行一个极简模型观察日志中是否有 Proxima 相关输出。 print(vLLM with Proxima patch installed successfully (if no error).)运行它python3 verify_installation.py5. 完整示例与性能对比测试现在让我们通过一个实际的例子来展示 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_ALLOCATOR1来启用。我们编写一个通用的启动脚本并通过参数控制# 文件run_server.py import argparse import subprocess import sys import os def main(): parser argparse.ArgumentParser(descriptionLaunch vLLM server with or without Proxima.) parser.add_argument(--use-proxima, actionstore_true, helpUse Proxima memory allocator) parser.add_argument(--model, typestr, defaultQwen/Qwen2-7B-Instruct, helpModel name or path) parser.add_argument(--tensor-parallel-size, typeint, default1, helpTensor parallel size) parser.add_argument(--port, typeint, default8000, helpServer port) parser.add_argument(--block-size, typeint, default16, helpBlock 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, envenv) 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_PROXIMA1 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, jsonpayload) as response: if response.status 200: result await response.json() # 计算请求耗时 return time.time(), len(result[choices][0][message][content]) else: print(fRequest {request_id} failed: {response.status}) return None except Exception as e: print(fRequest {request_id} error: {e}) return None async def benchmark(server_url, num_requests, concurrency, prompt_text): print(f\n Benchmarking {server_url} ) print(fTotal requests: {num_requests}, Concurrency: {concurrency}) connector aiohttp.TCPConnector(limitconcurrency) timeout aiohttp.ClientTimeout(total300) async with aiohttp.ClientSession(connectorconnector, timeouttimeout) 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(fTotal time: {duration:.2f}s) print(fSuccessful requests: {successful_count}/{num_requests}) print(fThroughput (RPS): {rps:.2f}) print(fToken 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(fToken 生成速度提升: {improvement_tps:.1f}%) else: print(基准测试失败无法计算提升比例。) if __name__ __main__: asyncio.run(main())运行基准测试pip3 install aiohttp # 如果未安装 python3 benchmark.py6. 运行结果与效果验证运行上述测试脚本后你可能会得到类似下面的输出具体数字取决于你的 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%如何解读结果吞吐量 (RPS) 翻倍在这个模拟测试中使用 Proxima 后每秒能处理的请求数从 2.21 提升到了 4.51提升约 104%。这虽然没有达到宣传的 4 倍300%但已经是非常显著的提升。4 倍的提升是在极限并发、显存成为唯一瓶颈的理想实验室环境下测得的。实际业务中由于请求长度不一、网络延迟、预处理开销等因素提升比例会有所下降但50%-200%的提升是完全可期的。Token 生成速度同步提升因为每个请求的处理速度变快等待显存分配的时间减少GPU 利用率更高所以整体 Token 生成速度也几乎翻倍。关键验证点除了看数字更重要的是观察服务启动时的日志和nvidia-smi显示的显存占用。日志启用 Proxima 后vLLM 启动日志中可能会打印类似Using Proxima contiguous allocator的信息。显存占用在承受相同并发压力时使用 Proxima 的服务其 GPU 显存利用率应该更“稳定”且“有效利用率”更高。你可以尝试不断增加并发请求数直到默认 vLLM 开始因“Out of Memory”拒绝请求而 Proxima 版本可能还能继续接受更多请求。这就是“服务更多请求”的直接体现。7. 常见问题与排查思路在集成和使用 Proxima 过程中你可能会遇到以下问题问题现象可能原因排查方式解决方案应用补丁失败(git apply报错)vLLM 源码版本与 Proxima 补丁不兼容。查看补丁错误信息定位冲突的文件和代码行。1. 严格按照 Proxima 文档指定版本。2. 手动合并冲突仅建议高级用户。3. 联系 Proxima 社区寻求更新补丁。编译 vLLM 失败Triton 版本不匹配CUDA/PyTorch 版本冲突缺少系统依赖。查看pip install -e . --verbose的错误输出。1. 确认并安装指定版本的 Triton。2. 确保 CUDA、PyTorch、Python 版本兼容。3. 安装build-essential,cmake等编译工具。服务启动失败或崩溃Proxima 分配器初始化失败模型加载错误块大小参数设置不当。查看服务器启动日志的前几行错误信息。1. 检查--block-size参数是否按 Proxima 要求设置。2. 尝试不使用 Proxima 启动确认基础环境正常。3. 降低--gpu-memory-utilization参数值。启用 Proxima 后性能无变化甚至下降未成功激活 Proxima 分配器测试场景不是显存瓶颈请求负载太轻。1. 检查启动日志确认 Proxima 激活。2. 使用nvidia-smi观察显存碎片情况。3. 增加并发请求数和序列长度进行压力测试。1. 确认环境变量或启动参数正确。2. 设计更能暴露显存瓶颈的测试用例如超长上下文、高并发。3. 参考官方提供的基准测试脚本。长时间运行后出现内存错误Proxima 分配器可能存在内存泄漏或碎片合并 bug较新项目可能不稳定。监控服务进程的 GPU 显存占用是否随时间异常增长。1. 升级到 Proxima 的最新版本。2. 定期重启服务作为临时方案。3. 在测试环境充分验证稳定性后再上生产。不支持多 GPU (Tensor Parallel)Proxima 的早期版本可能对 TP 支持不完善。尝试使用--tensor-parallel-size2启动服务观察是否报错。1. 查阅 Proxima 的 Issue 列表看 TP 支持状态。2. 暂时在单 GPU 上使用或等待后续版本更新。8. 最佳实践与工程建议如果你决定在生产环境中尝试 Proxima请遵循以下建议严格进行测试环境验证先在和线上环境硬件配置一致的测试机上部署。使用与线上业务高度相似的流量模型请求分布、长度、并发度进行至少 24-48 小时的稳定性压测。对比性能指标吞吐量、延迟 P99、错误率和资源指标GPU 利用率、显存占用。灰度发布与回滚方案不要一次性全量替换。可以先在少数几台推理服务器上部署 Proxima 版本进行小流量灰度。准备好快速回滚方案。确保原生 vLLM 的镜像随时可切换。监控与告警加强 GPU 显存监控。不仅看总使用量更要关注“可用连续显存”的大小。可以编写脚本定期检查nvidia-smi的输出。对服务错误日志中新增的、与内存分配相关的报错如CUDA out of memory的具体信息设置告警。参数调优--block-size这个参数对 Proxima 至关重要。它不是 token 数量而是 Proxima 内部管理的内存块单位。务必参考 Proxima 官方文档的推荐值进行设置错误的块大小可能导致性能下降或内存浪费。--gpu-memory-utilization可以适当调高例如从 0.9 到 0.95因为 Proxima 能更有效地利用显存。但需谨慎保留一部分余量给系统和其他进程。理解适用场景收益最大高并发、请求长度多变、显存是主要瓶颈的服务。收益有限低并发、请求长度固定、或计算算力是主要瓶颈的场景。可能不适用需要极低延迟的实时交互场景因为 Proxima 的分配器可能引入微小开销或者使用了 vLLM 某些极其冷门的高级功能需测试兼容性。社区与版本跟进Proxima 是一个活跃的开源项目。关注其 GitHub 仓库的 Releases 和 Issues及时获取 bug 修复和性能优化。考虑将你的测试结果和遇到的问题反馈给社区帮助项目改进。Proxima 通过解决显存碎片化这一底层工程问题为 vLLM 用户提供了一种“无成本”提升服务能力的可能。它提醒我们在追逐更强大硬件和更精简模型的同时对现有系统进行深度优化往往能带来意想不到的收益。将 Proxima 集成到你的推理栈中仔细测试它很可能成为你应对业务增长、控制成本的一件利器。建议你将本文的配置和测试方法收藏作为评估该技术方案的实践起点。