1. 从单次对话到并发洪流本地推理服务的真实瓶颈在哪里很多人第一次在本地跑起大模型推理时体验路径几乎一模一样装好环境加载权重敲一句提示词看着终端里一个字一个字往外蹦心里挺美。可一旦把这个服务挂到内网让三五个人同时用或者接一个稍微有点流量的前端页面情况立刻急转直下——显存爆了、请求排队排到天荒地老、GPU利用率却低得可怜。这个落差就是“能跑”和“能扛”之间的鸿沟。我最初做本地推理服务时也踩过这个坑。当时用的是一个很朴素的方案一个Python进程加载模型外面套一层HTTP接口来一个请求就调一次生成。单请求测试时延迟大概两三秒看着还行。结果同事三个人同时点第四个请求直接超时日志里全是显存分配失败的报错。问题不在于模型本身而在于整个服务架构根本没有为并发做任何设计。vLLM这个推理引擎解决的正是这个层面的问题。它的核心定位不是“让模型跑起来”而是“让模型在高并发下跑得又快又稳”。关键词里的“高吞吐”和“高并发”是两个不同的维度吞吐量衡量的是单位时间内整个系统能处理多少token并发数衡量的是同时能服务多少个活跃请求。很多方案能提高其中一个但会牺牲另一个而vLLM的设计目标是在两者之间找到一个工程上可用的平衡点。这篇文章适合三类人看。第一类是在本地或内网部署过大模型、但被并发问题折磨过的开发者第二类是想了解推理引擎底层调度逻辑、不满足于只会调API的技术爱好者第三类是需要给团队搭建一个可共享的推理服务、但预算有限只能用现有显卡的工程人员。我会从并发瓶颈的本质讲起把vLLM的几个关键机制拆开揉碎然后给出一套可以直接复现的本地部署方案最后分享一些我在实际调参和排错中攒下来的经验。需要提前说明的是下面涉及的所有配置和参数都是基于常见实践给出的参考值具体到你的硬件和模型需要根据实测结果做调整。我不会给一套“万能配置”因为那东西不存在。2. 并发上不去到底是卡在计算还是卡在显存2.1 传统推理的串行困境一个请求占满一张卡要理解vLLM为什么快得先看清楚传统推理慢在哪。最朴素的推理方式是这样的一个请求进来把输入token喂给模型模型逐层计算生成第一个token然后把这个token拼回输入再算下一个直到遇到结束符。整个过程是严格串行的而且有一个致命特点——显存占用是“全量”的。具体来说模型权重占一部分显存这部分是固定的。但除此之外每个请求还需要一块额外的显存来存放KV Cache也就是注意力机制里Key和Value的缓存。传统方案里这块KV Cache是按“最大可能长度”预分配的。比如你设置最大生成长度是2048那不管这个请求实际只生成50个token就结束了系统都会先给它留出2048长度的缓存空间。这就导致一个尴尬的局面显存明明还有富余但因为都被“预留”出去了新请求进不来。我做过一个粗略的测算。假设模型权重占10GB显存一张卡有24GB剩下14GB可用。如果每个请求预分配2GB的KV Cache那理论上最多同时服务7个请求。但实际上这7个请求里可能只有一两个在真正生成其他都在排队等待或者已经生成完了但缓存还没释放。GPU的计算单元大部分时间在空转利用率可能只有20%到30%。这就是典型的“显存瓶颈伪装成计算瓶颈”。2.2 PagedAttention把KV Cache切成块来管vLLM最核心的一个机制叫PagedAttention。这个名字里的“Paged”借用了操作系统内存分页的概念。操作系统管理物理内存时不会给一个进程分配一整块连续的大内存而是切成固定大小的页用页表来映射虚拟地址和物理地址。这样做的好处是内存利用率高不会因为找不到连续空间而浪费。PagedAttention做的事情类似。它把每个请求的KV Cache切成固定大小的块比如每块存16个token的Key和Value。这些块在物理显存里不需要连续存放可以散落在各处用一个块表来记录逻辑顺序和物理位置的对应关系。这样一来显存分配就从“按最大长度预留”变成了“按实际需要动态分配”。这个改变带来的效果是立竿见影的。还是上面那个例子14GB可用显存现在不需要给每个请求预留2GB了而是生成一个token就分配一个块块用完了再分配新的。实际测试中同样一张24GB的卡用PagedAttention之后并发服务请求数能从个位数提升到几十个。更关键的是显存浪费大幅减少因为不同请求的KV Cache块可以交错存放碎片化的空间也能被利用起来。注意PagedAttention的块大小是一个可调参数。块太小块表本身占用的显存和计算开销会上升块太大内部碎片又会变多。常见的选择是16或32具体要看模型隐藏层维度和序列长度分布。2.3 连续批处理让GPU不再等单个请求光有显存管理还不够。传统推理还有一个问题GPU的计算是批量的但请求是逐个到达的。如果来一个请求就算一次GPU的并行能力完全没发挥出来。如果等一批请求凑齐再算那先到的请求就要干等延迟飙升。vLLM用的是连续批处理Continuous Batching有时候也叫迭代级调度。它的思路是不按“请求”来组织批次而是按“迭代步”来组织。每一步生成一个token系统会检查当前有哪些请求还在活跃状态把它们动态组成一个批次送进GPU计算。新来的请求可以在任意一步插入已经生成完的请求可以在任意一步退出。这个机制听起来简单但实现起来很复杂因为它要求显存管理必须支持动态增删。PagedAttention正好提供了这个能力。两者配合起来GPU的利用率能从原来的20%到30%提升到70%以上。我实测过一个场景8个并发请求传统方案下GPU利用率在35%左右波动换成vLLM之后稳定在75%到80%吞吐量翻了将近三倍。2.4 吞吐与延迟的取舍不是越快越好这里要泼一盆冷水。vLLM的高吞吐是建立在“批处理”基础上的而批处理天然会带来延迟的增加。因为一个请求可能要等同一批次里其他请求的计算完成才能拿到自己的结果。如果你只服务一个用户追求极致的单次响应速度vLLM未必是最优解甚至可能比一些针对单请求优化的方案还慢一点。所以选型之前要想清楚你的场景是“很多人偶尔用一下”还是“少数人高频使用”还是“机器自动调用、对延迟不敏感但对总量敏感”。vLLM最适合的是第二和第三种场景。第一种场景下如果并发数长期低于4用vLLM的收益可能不明显反而增加了部署复杂度。3. 本地部署vLLM从裸机到可用服务的完整路径3.1 环境准备中最容易翻车的三个地方部署vLLM的第一步不是装包而是确认硬件和驱动环境。我见过太多人卡在环境问题上折腾一整天连模型都加载不进去。下面这三个点每一个我都亲自踩过。第一个是CUDA版本和PyTorch版本的匹配。vLLM对这两者的版本要求比较严格不是随便装个最新版就能跑。比如某个版本的vLLM可能要求PyTorch 2.1以上、CUDA 11.8或12.1。如果你系统里已经装了其他版本的CUDA或者用conda装了一个和系统驱动不匹配的PyTorch大概率会在加载模型时报一堆看不懂的符号错误。我的建议是先用nvidia-smi看清楚驱动支持的CUDA最高版本然后去vLLM的官方文档查对应版本的安装命令不要自己猜。第二个是显存容量的“名义值”和“可用值”差距。一张标称24GB的卡实际可用显存可能只有22GB出头因为驱动和系统会占用一部分。如果你按24GB去规划模型加载和KV Cache最后一定会OOM。更稳妥的做法是留出至少1.5GB到2GB的余量。比如24GB的卡按22GB来规划。第三个是Python环境隔离。vLLM依赖的包比较多而且版本敏感。如果你在一个已经装了很多其他AI框架的环境里直接pip install很容易出现依赖冲突。我习惯用conda新建一个干净的环境Python版本选3.10或3.11这两个版本兼容性最好。# 创建独立环境 conda create -n vllm_env python3.10 -y conda activate vllm_env # 安装vLLM具体版本根据你的CUDA版本选择 pip install vllm # 验证安装 python -c import vllm; print(vllm.__version__)如果这一步报错大概率是CUDA版本不匹配。可以去vLLM的发布页面找对应CUDA版本的预编译包或者从源码编译。源码编译比较耗时但兼容性最好。3.2 模型加载权重格式和量化选择vLLM支持多种模型格式最常见的是Hugging Face的safetensors格式。加载方式有两种一种是从本地路径加载一种是从模型仓库在线拉取。本地部署建议提前把权重下载好避免运行时网络波动导致加载失败。# 启动一个基础的OpenAI兼容服务 python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name my-model \ --host 0.0.0.0 \ --port 8000 \ --dtype auto \ --max-model-len 4096这里有几个参数需要解释。--dtype auto会让vLLM自动选择合适的数据精度通常是float16或bfloat16。如果你的显卡支持bfloat16优先用bfloat16数值稳定性更好。--max-model-len是模型支持的最大序列长度这个值直接影响KV Cache的显存占用。设得太大浪费显存设得太小长文本请求会报错。一般设成模型训练时的最大长度或者根据你的实际业务需求来定。如果显存不够可以考虑量化。vLLM支持AWQ和GPTQ两种主流量化格式。量化后的模型权重占用显存更少但推理质量会有轻微下降。我的经验是7B级别的模型用4bit量化后显存占用能从14GB左右降到5GB到6GB质量下降在大多数对话场景下几乎感知不到。但如果是代码生成或数学推理这类对精度敏感的任务量化带来的影响就比较明显了。3.3 关键参数调优显存利用率和并发数的平衡服务跑起来之后真正决定性能的是几个核心参数的配置。下面这张表是我在实际调优中总结的参考值针对的是单卡24GB、7B模型、4bit量化的场景。参数作用推荐值调整方向gpu-memory-utilization控制vLLM预分配的显存比例0.85到0.90调高增加并发但可能OOMmax-num-seqs单批次最大请求数16到32调高提升吞吐但增加延迟max-model-len最大序列长度2048到4096按业务需求设不要盲目调大block-sizePagedAttention块大小16一般不需要改swap-spaceCPU交换空间大小4到8GB显存不足时的缓冲gpu-memory-utilization这个参数特别值得说。它控制的是vLLM在启动时预分配的显存比例。比如设成0.9就是让vLLM占用90%的可用显存。这个值设得太低KV Cache空间不够并发上不去设得太高系统其他进程可能没显存可用导致服务崩溃。我一般从0.85开始试观察服务稳定运行时的显存占用再逐步往上调。max-num-seqs是另一个关键参数。它限制的是单个批次里最多有多少个请求。设得太小GPU并行度不够吞吐上不去设得太大每个请求分到的计算资源变少单请求延迟增加。对于7B模型我通常设在16到24之间。如果是更大的模型比如13B或70B这个值要相应调小。3.4 服务验证用并发压测看真实表现服务启动之后不要只看单次请求能不能通一定要做并发压测。我见过太多服务单请求正常、一并发就崩的情况。压测工具可以用简单的Python脚本也可以用现成的压测框架。import concurrent.futures import requests import time def send_request(prompt): url http://localhost:8000/v1/completions payload { model: my-model, prompt: prompt, max_tokens: 128, temperature: 0.7 } start time.time() resp requests.post(url, jsonpayload) elapsed time.time() - start return elapsed, resp.status_code prompts [请解释什么是机器学习] * 20 with concurrent.futures.ThreadPoolExecutor(max_workers20) as executor: results list(executor.map(send_request, prompts)) for i, (elapsed, status) in enumerate(results): print(f请求{i}: 耗时{elapsed:.2f}秒, 状态码{status})这个脚本会同时发20个请求观察每个请求的耗时和返回状态。如果出现大量超时或500错误说明并发配置有问题。正常情况下20个并发请求的总耗时应该远小于串行执行的时间而且没有请求失败。压测的时候要盯着nvidia-smi看显存和GPU利用率的变化。如果显存接近打满但GPU利用率很低说明瓶颈在显存管理如果GPU利用率很高但吞吐上不去说明瓶颈在计算本身可能需要换更小的模型或者做量化。4. 那些文档里不会写的坑我在调优中攒下的经验4.1 长文本请求的“隐形杀手”KV Cache碎片PagedAttention虽然解决了大部分显存碎片问题但在长文本场景下还是会有一些边角情况。比如一个请求生成了3000个token占用了大量KV Cache块然后突然结束这些块被释放回池子。如果下一个请求需要的是连续的大块空间而池子里都是零散的小块就可能出现“明明总显存够用但就是分配不出来”的情况。我的应对办法是控制max-model-len不要设得过大。如果业务上大部分请求的长度在1000以内就没必要把最大长度设成8192。设小一点每个请求占用的块数少碎片问题就轻很多。另外swap-space参数可以给一点CPU内存作为缓冲当显存块分配不出来时把一些不活跃的块换到CPU内存里腾出空间给新请求。这个机制会带来一些延迟但总比直接报错强。4.2 模型加载慢权重格式和磁盘IO的影响第一次加载模型时如果发现速度特别慢通常不是vLLM的问题而是磁盘IO或者权重格式的问题。safetensors格式的加载速度比传统的bin格式快不少因为它是内存映射的不需要一次性把整个文件读进内存。如果你的模型还是bin格式建议转成safetensors。另外如果模型放在网络存储上加载速度会受网络带宽限制。我试过从网络挂载的盘加载一个13B模型花了将近十分钟换成本地SSD之后缩短到一分半。如果服务需要频繁重启这个时间成本很可观。4.3 并发数上不去先查这几个地方有时候配置都按推荐值设了但并发数就是上不去。我总结了一个排查顺序按这个顺序查基本能定位到问题。第一步看显存是不是真的够。用nvidia-smi看服务运行时的显存占用。如果已经接近100%那并发上不去是正常的需要降低gpu-memory-utilization或者换更小的模型。第二步看max-num-seqs是不是设得太小。这个参数默认值可能比较保守如果你的显存有富余可以适当调大。但要注意调大之后单请求延迟会增加需要权衡。第三步看请求的实际长度。如果每个请求都生成了接近max-model-len的token数那KV Cache占用会很大并发数自然上不去。这种情况下可以考虑限制max_tokens参数或者用流式输出让用户更早看到结果。第四步看CPU和内存。vLLM的调度逻辑跑在CPU上如果CPU核心数太少或者主频太低调度本身会成为瓶颈。这种情况在老旧服务器上比较常见。4.4 流式输出的正确打开方式vLLM支持流式输出也就是生成一个token就返回一个而不是等全部生成完再返回。这个功能对用户体验影响很大但配置上有个细节容易忽略流式输出需要客户端也支持SSEServer-Sent Events协议。如果你用普通的HTTP客户端去调流式接口可能会一直卡住或者收到不完整的数据。import requests import json url http://localhost:8000/v1/completions payload { model: my-model, prompt: 写一段关于春天的描述, max_tokens: 256, stream: True } with requests.post(url, jsonpayload, streamTrue) as resp: for line in resp.iter_lines(): if line: line line.decode(utf-8) if line.startswith(data: ): data line[6:] if data ! [DONE]: chunk json.loads(data) text chunk[choices][0][text] print(text, end, flushTrue)流式输出除了提升用户体验还有一个隐性好处它让请求的“活跃时间”变短了。因为用户看到第一个token之后心理上就觉得请求已经响应了即使后面还在继续生成。这在并发场景下能减少用户主动取消请求的概率间接提升了系统吞吐。5. 从能用 to 好用生产环境还需要补哪些课5.1 健康检查和优雅重启本地测试时服务崩了重启就行但如果这个服务是给团队用的就需要考虑健康检查和优雅重启。vLLM自带一个/health接口可以返回服务状态。但光有这个还不够因为服务可能处于“能响应健康检查但实际已经无法处理请求”的状态比如显存碎片化严重导致新请求分配不到块。我的做法是在健康检查里加一个轻量级的推理测试比如发一个很短的请求看能不能在合理时间内返回。如果连续几次失败就触发重启。重启的时候要注意不能直接kill进程因为可能有正在处理的请求。vLLM支持通过信号触发优雅关闭等待当前批次处理完再退出。5.2 多模型共存显存怎么分一个常见的需求是同时服务多个模型比如一个通用对话模型加一个代码生成模型。如果两张卡分别部署那最简单。但如果只有一张卡就要考虑显存怎么分。vLLM本身不支持在同一个实例里加载多个模型但可以起多个实例每个实例用不同的端口通过gpu-memory-utilization来分配显存。比如一张24GB的卡一个实例占0.45另一个占0.45留0.1给系统。但这样做有个问题两个实例的显存是静态划分的不能动态借用。如果某个模型请求量突然增大它的显存不够用而另一个模型的显存却在闲置。更灵活的方案是用一个路由层根据请求内容转发到不同的后端实例。路由层可以监控各实例的负载动态调整转发比例。但这套方案复杂度高不少适合请求量比较大、模型差异明显的场景。如果只是偶尔用一下第二个模型静态划分就够了。5.3 日志和监控出了问题怎么查vLLM的日志默认输出到标准输出包含请求处理时间、批次大小、显存使用等信息。这些日志在排查问题时很有用但默认的日志级别可能不够详细。可以通过环境变量调整日志级别。export VLLM_LOGGING_LEVELDEBUGDEBUG级别会输出每个批次的详细调度信息包括哪些请求被加入批次、哪些被移除、KV Cache块的分配和释放情况。这些信息在排查性能问题时非常关键但日志量很大生产环境不建议长期开着。监控方面除了常规的CPU、内存、GPU利用率还要关注几个vLLM特有的指标运行中的请求数、等待中的请求数、KV Cache使用率。这些指标能直接反映系统的健康状态。如果等待中的请求数持续增长说明并发能力不足如果KV Cache使用率长期接近100%说明显存是瓶颈。5.4 安全边界本地服务也不能裸奔虽然是本地或内网服务但基本的安全措施还是要做。vLLM的OpenAI兼容接口默认没有认证任何能访问到端口的人都可以调用。如果内网环境不完全可信建议加一层简单的API Key认证或者用反向代理做访问控制。另外输入长度要有限制。虽然max-model-len限制了模型处理的最大长度但如果客户端发来一个超长输入vLLM可能会在预处理阶段就消耗大量资源。可以在反向代理层加一个请求体大小限制把明显异常的请求挡在外面。6. 一些关于选型和扩展的个人看法vLLM不是唯一的选择也不是所有场景下的最优解。如果你的并发需求长期在个位数用更轻量的方案可能更省心。如果你的场景对首token延迟极其敏感可能需要考虑其他针对单请求优化的推理框架。但如果你需要一个能扛住几十路并发、显存利用率高、部署相对简单的本地推理服务vLLM目前是工程上比较成熟的选择。我在实际使用中最大的体会是参数调优没有终点只有平衡。每次调整gpu-memory-utilization或max-num-seqs都是在吞吐、延迟、稳定性之间做取舍。最好的办法是先用一套保守配置把服务跑起来然后根据实际监控数据逐步调整每次只改一个参数观察效果。不要一次性改一堆参数那样出了问题根本不知道是哪个引起的。还有一个容易被忽略的点是模型本身的选择。7B模型和13B模型在同样的硬件上并发能力可能差一倍以上。如果业务场景对模型能力的要求不是特别高选一个更小的模型配合vLLM的调度优化整体体验可能比用大模型但并发上不去要好得多。这个取舍需要根据具体业务来判断没有标准答案。最后分享一个小技巧如果你的服务需要频繁重启比如开发调试阶段可以把模型权重放在内存盘上加载速度会快很多。但内存盘会占用系统内存要确保总内存够用。这个技巧在SSD速度不够快或者模型特别大的时候比较有用。