vLLM本地高并发推理服务部署与调优实战

1. 从单次对话到并发洪流：本地推理服务的真实瓶颈在哪

很多人第一次在本地跑通一个大模型对话时，心情是激动的。输入一句话，等上几秒，屏幕上蹦出一段回答，感觉一切都很美好。可一旦把这个服务丢给三五个人同时用，或者写个脚本连续发几十个请求，画面立刻变了：显存爆了、请求排队排到天荒地老、GPU利用率却低得可怜。这不是模型不行，而是推理服务的调度方式出了问题。

我最初做本地推理服务时，用的是最朴素的方案：一个Python脚本加载模型，写个HTTP接口，来一个请求就调一次生成。单请求下延迟还能接受，但并发一上来，吞吐量几乎不增长，显存却成倍往上翻。后来才明白，问题出在KV Cache的管理方式和请求调度策略上。传统方案里，每个请求都要预分配一大块连续的显存来存放KV Cache，请求长度未知就只能按最大长度预留，浪费极其严重；而且请求之间无法共享计算，GPU大部分时间在等数据搬运，算力空转。

vLLM这个推理引擎之所以在圈子里被反复提起，核心就是它用了一套叫PagedAttention的注意力实现，把KV Cache切成固定大小的块来管理，像操作系统管理内存分页一样，按需分配、动态回收。这样一来，显存碎片大幅减少，同一张卡能同时容纳的请求数成倍增加。再加上连续批处理机制，新请求可以随时插入正在执行的批次，不用等当前批次全部结束，GPU的利用率被拉满。

这篇文章面向的是已经能在本地跑起模型、但被并发问题卡住的开发者。我会从原理讲到实操，把vLLM部署本地高并发推理服务的完整链路拆开，包括环境准备、参数调优、压测方法、常见报错排查，以及我在实际使用中踩过的那些坑。读完你应该能自己搭起一个稳定支撑几十路并发的本地推理服务，并且知道每个参数背后的取舍逻辑。

2. PagedAttention与连续批处理：vLLM吞吐量翻倍的底层逻辑

2.1 传统KV Cache为什么会把显存吃光

要理解vLLM的价值，得先看清楚传统方案浪费在哪。大模型生成每个token时，都需要用到之前所有token的Key和Value向量，这些向量缓存起来就是KV Cache。问题在于，生成之前你不知道这个请求最终会输出多长。保守做法是按模型最大上下文长度（比如4096或8192）预分配，可实际很多请求只输出一两百个token，剩下的显存全被占着不能用。

更麻烦的是显存碎片。假设一张卡剩10GB，来了三个请求分别需要3GB、4GB、5GB，理论上能放下，但因为预分配的块不连续，实际可能一个都塞不进去。这就是为什么很多本地服务明明显存看着还有余量，却频繁报OOM。

2.2 分页管理如何把碎片压到最低

vLLM的PagedAttention把KV Cache划分成固定大小的block，每个block存放固定数量token的KV向量。请求生成过程中，需要新block时再向显存池申请，用完的block立即归还。因为block大小固定，显存池里永远是规整的小块，碎片问题基本消失。

这个思路和操作系统的虚拟内存分页几乎一模一样。逻辑上每个请求看到的是连续的KV序列，物理上这些block可以散落在显存各处，通过一张block table做映射。带来的直接好处是：显存利用率能从传统方案的百分之二三十提升到百分之八九十，同一张卡能并发的请求数自然翻了好几倍。

还有一个容易被忽略的点：前缀共享。如果多个请求有相同的系统提示词或相同的开头，这些token的KV block可以被多个请求共享，只读不复制。在客服、问答这类系统提示词很长的场景里，这一项就能省下大量显存。

2.3 连续批处理让GPU不再空转

传统批处理是静态的：凑齐一批请求，一起跑，等这批全部生成完，再跑下一批。问题是每个请求输出长度不同，短请求早就结束了，GPU还得陪着长请求空跑，利用率直线下降。

连续批处理（也叫迭代级调度）改成了动态模式：每个生成步结束后，调度器检查有没有请求完成，完成的立刻释放资源，同时把排队中的新请求插进来。GPU每个step都在处理当前所有活跃请求，几乎没有空闲。实测下来，同样的硬件，连续批处理能把吞吐量再提升两到四倍。

这两套机制叠加，才是vLLM高吞吐的真正来源。理解了这个，后面调参时你才知道每个参数在动什么。

3. 本地部署vLLM的完整链路：从环境到第一个并发请求

3.1 硬件与驱动的前置检查

vLLM对硬件有明确要求，不是随便一张卡就能跑。核心门槛是显存容量和算力架构。以常见的7B模型FP16精度为例，权重本身约占14GB，加上KV Cache和中间激活，一张24GB显存的卡是比较稳妥的起点。如果是量化版本（如AWQ、GPTQ的4bit），7B模型权重能压到4GB左右，16GB显存的卡也能跑起来。

驱动层面，需要较新的CUDA版本，通常建议CUDA 11.8以上。装之前先用nvidia-smi确认驱动版本和CUDA版本，再对照vLLM官方文档的兼容矩阵。我见过不少人卡在这一步，驱动太老导致编译失败，折腾半天以为是代码问题。

提示：如果你的卡算力架构较老（比如某些早期计算卡），可能不被最新版vLLM支持，建议先查兼容列表再动手，避免白费功夫。

3.2 安装方式的选择与取舍

vLLM的安装有两条路：pip直接装预编译包，或者从源码编译。绝大多数情况用pip就够了：

pip install vllm

但要注意，pip装的版本绑定了特定的CUDA和PyTorch版本。如果你的环境里已经有其他框架依赖特定版本的PyTorch，可能会冲突。这时候建议用独立的虚拟环境，把vLLM的依赖隔离出来。

源码编译适合需要改源码、或者要用最新特性的人。编译过程比较吃时间和内存，而且对gcc版本、CUDA toolkit路径都有要求。我的建议是：除非有明确需求，否则优先pip，把精力留给后面的调优。

3.3 启动服务的关键参数逐个拆解

vLLM自带一个OpenAI兼容的API服务，启动命令大致长这样：

python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name my-model \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --gpu-memory-utilization 0.9 \ --max-model-len 4096 \ --max-num-seqs 64

这里面每个参数都值得说清楚：

• --tensor-parallel-size：张量并行度，单卡填1，多卡填卡数。多卡时模型权重会被切分到各卡，适合单卡放不下的大模型。
• --gpu-memory-utilization：允许vLLM使用的显存比例，默认0.9。这个值不是越高越好，留一点余量给CUDA上下文和临时激活，否则容易OOM。
• --max-model-len：最大上下文长度。这个值直接决定KV Cache的block池大小，设得越大，能并发的请求数越少。按实际业务需要设，别盲目拉满。
• --max-num-seqs：同时处理的最大请求数。这是控制并发的核心旋钮，设太小吞吐上不去，设太大显存扛不住。

启动后看到日志里打印出模型加载完成、API server listening，就说明服务起来了。第一次启动会花时间做模型加载和显存预分配，耐心等。

3.4 用curl和Python客户端验证并发

服务起来后，先用最简单的curl验证单请求：

curl http://localhost:8000/v1/completions \ -H "Content-Type: application/json" \ -d '{ "model": "my-model", "prompt": "介绍一下你自己", "max_tokens": 128 }'

单请求通了之后，用Python写个并发脚本压一压：

import concurrent.futures import requests def send_request(i): resp = requests.post( "http://localhost:8000/v1/completions", json={ "model": "my-model", "prompt": f"这是第{i}个请求，请简短回答。", "max_tokens": 64 } ) return resp.status_code with concurrent.futures.ThreadPoolExecutor(max_workers=32) as executor: results = list(executor.map(send_request, range(32))) print(results)

这个脚本一次性发32个并发请求，观察返回状态和耗时。如果全部200且总耗时远小于串行执行，说明连续批处理在起作用。如果出现超时或500，就要回头看显存和并发参数了。

4. 吞吐与延迟的平衡术：参数调优的实战经验

4.1 显存利用率不是越高越好

--gpu-memory-utilization设成0.95甚至0.98，看起来能把显存榨干，实际上很危险。vLLM在运行中除了KV Cache，还需要显存做中间激活、CUDA kernel的临时缓冲。这些开销随批次大小波动，如果预分配时把显存占满，运行时一波动就OOM。

我的经验值是0.85到0.9之间。留出的那部分显存，换来的是服务在高负载下的稳定性。曾经为了多塞几个请求把利用率调到0.95，结果压测到一半就崩，回退到0.88后连续跑几小时都没事。

4.2 max-num-seqs与max-model-len的联动

这两个参数是此消彼长的关系。KV Cache的总显存池是固定的，每个请求占用的block数取决于它的上下文长度。max-model-len设得越大，单个请求可能占用的block越多，能同时容纳的请求数就越少。

一个实用的估算方法：先算出KV Cache可用显存，除以单个block的字节数，得到总block数。再根据业务里请求的平均长度，估算每个请求平均占多少block，两者相除就是理论最大并发数。max-num-seqs设成这个值的七八成比较稳妥。

比如业务里请求平均长度512，max-model-len设4096，那单个请求最多占8个block（假设block存512token）。如果总block池有1000个，理论并发125，max-num-seqs设到96左右比较合适。

4.3 调度策略对延迟的影响

vLLM默认的调度是先到先服务，但可以通过参数调整优先级策略。对于延迟敏感的场景，比如在线对话，希望短请求尽快返回，可以适当限制单批次里的请求数，避免长请求把短请求拖住。对于吞吐优先的离线批处理，则可以把批次开大，让GPU吃满。

还有一个参数是--swap-space，当显存不够时，vLLM会把部分block换出到CPU内存。这个机制能防止OOM，但换入换出有开销，延迟会明显上升。如果业务对延迟敏感，建议把swap space设小甚至关掉，宁可拒绝请求也不要拖慢整体。

4.4 量化模型的取舍

显存紧张时，量化是绕不开的话题。AWQ和GPTQ是两种常见的4bit量化方案，能把7B模型压到4GB左右。代价是精度有轻微损失，在大多数对话和问答任务里几乎感知不到，但在需要精确计算或代码生成的场景，可能会出问题。

我的做法是：先用FP16跑通，记录吞吐和延迟基线；再换量化版本对比，看精度损失是否可接受。如果业务对精度要求高，宁可加卡也不要硬上量化。

5. 压测与监控：怎么知道服务到底能扛多少并发

5.1 压测工具的选择

压测本地推理服务，常用的有wrk、locust，或者自己写脚本。vLLM社区也有专门的benchmark脚本，能直接测吞吐和延迟。我一般用自己写的Python脚本，因为可以精确控制请求的prompt长度和输出长度，更贴近真实业务。

压测时要关注三个指标：吞吐量（每秒处理的token数或请求数）、首token延迟（TTFT，从发请求到收到第一个token的时间）、单请求总延迟。这三个指标往往互相矛盾，调优就是找平衡点。

5.2 逐步加压找到拐点

不要一上来就发几百并发，那样只会把服务打挂，看不出拐点在哪。正确做法是从低并发开始，逐步增加，观察指标变化：

从这张模拟表能看出，并发到64左右吞吐接近饱和，再往上加，吞吐几乎不涨，但延迟飙升。这个拐点就是服务的合理容量上限。实际业务里，把并发控制在拐点的七八成，留出突发余量。

5.3 监控显存和GPU利用率

压测时开着nvidia-smi -l 1或者用watch -n 1 nvidia-smi，实时看显存占用和GPU利用率。理想状态下，GPU利用率应该稳定在较高水平，显存占用平稳。如果显存持续上涨不回落，可能有请求没被正确释放，要查是不是有异常请求卡住了。

vLLM自身也会打印一些调度日志，包括当前活跃请求数、等待队列长度、KV Cache使用率。这些日志对定位瓶颈很有帮助。KV Cache使用率长期接近100%，说明显存是瓶颈；等待队列很长但KV Cache没满，说明调度或计算是瓶颈。

6. 那些让我熬夜的报错：常见问题排查实录

6.1 启动就OOM：显存预分配失败

最常见的报错是启动时提示显存不足。这时候先别急着降参数，按顺序排查：模型权重本身占多少显存，gpu-memory-utilization设了多少，max-model-len是不是设太大。有时候是模型加载时用了FP16但卡本身显存就不够，换量化版本或者换卡是唯一出路。

还有一种隐蔽情况：卡上残留了之前的进程占用显存。用nvidia-smi看有没有僵尸进程，有的话kill掉再启动。

6.2 运行中OOM：请求长度超出预期

服务跑着跑着突然OOM，多半是某个请求的上下文长度超出了max-model-len，或者并发数超过了显存能承受的上限。vLLM对超长请求的处理是截断或拒绝，但如果多个长请求同时进来，KV Cache瞬间被占满，就会触发OOM。

解决办法有两个：一是把max-model-len设得比业务实际需要略大，留缓冲；二是限制max-num-seqs，从源头控制并发。还可以开启swap space作为兜底，但如前所述，会影响延迟。

6.3 请求卡住不返回：调度死锁的排查

偶尔会遇到请求发出去后一直不返回，也不报错。这种情况先看服务日志，有没有调度相关的异常。常见原因是某个请求的生成陷入了异常循环，或者block分配出现了死锁。vLLM较新版本对这类问题做了不少修复，如果频繁遇到，建议升级版本。

另一个可能是客户端超时设置太短，请求其实还在处理，但客户端已经断开。服务端检测到连接断开后会释放资源，但如果释放逻辑有问题，资源就会泄漏。压测时用长超时，观察服务端日志确认请求是否真的完成。

6.4 多卡并行的通信开销

用--tensor-parallel-size开多卡时，卡间通信会成为瓶颈。如果卡之间不是高速互联（比如NVLink），通信开销可能吃掉并行带来的收益。实测中，两张卡通过PCIe互联跑张量并行，吞吐提升可能只有1.5倍而不是2倍。这种情况下，与其开张量并行，不如用数据并行——每张卡跑一个独立实例，前面挂个负载均衡。

7. 从能跑到好用：生产化的几个关键补丁

7.1 加一层请求队列和限流

vLLM本身有调度，但面对突发流量，最好在它前面加一层队列和限流。用Nginx或者自己写个中间件，控制进入vLLM的请求速率，避免瞬间打满。队列还能做优先级管理，把重要请求排在前面。

7.2 健康检查与自动重启

长时间运行的服务难免出问题，加个健康检查接口，定期探测/health，发现异常自动重启。重启脚本要处理好显存释放，确保旧进程完全退出再拉新进程，否则会因显存残留启动失败。

7.3 日志与指标采集

把vLLM的日志接到统一的日志系统，采集吞吐、延迟、显存、GPU利用率等指标，做成监控面板。这样出问题时能快速定位，也能根据历史数据做容量规划。我习惯把每次压测的结果存档，换模型或改参数后对比，判断优化是否有效。

7.4 模型热更新的取舍

业务需要换模型时，直接重启服务会中断所有请求。vLLM目前对热更新的支持有限，常见做法是起两个实例，用负载均衡切换流量，新实例加载好新模型后再切过去。这样虽然多占一份显存，但能做到零中断。

8. 我在实际使用中总结的几条经验

折腾vLLM这段时间，最大的体会是：高吞吐不是靠堆硬件堆出来的，而是靠对调度和显存的理解省出来的。同样一张卡，参数调得好和调得差，能扛的并发数可能差三倍。

第二条经验是先压测再上线。很多人本地跑通单请求就敢往生产丢，结果一上量就崩。压测不只是测极限，更是摸清服务的脾气——它在什么并发下延迟开始劣化，什么情况下会OOM，这些数据是容量规划的依据。

第三条是别迷信默认参数。vLLM的默认值是为通用场景设的，你的业务有你的特点。请求长度分布、延迟容忍度、精度要求，这些都会影响参数选择。花时间理解每个参数在动什么，比盲目抄配置有用得多。

最后分享一个小技巧：如果显存实在紧张，又不想上量化损失精度，可以试试把max-model-len设小，同时在应用层做上下文截断或摘要。很多业务其实用不到4096的上下文，把长对话压缩后再送进模型，既省显存又不影响效果。这个思路在客服和问答场景里特别管用，我靠它在一张卡上多塞了近一倍的并发。