1. 为什么要在本地折腾高并发推理服务1.1 从一次压测翻车说起去年帮一个做智能客服的团队做性能优化他们用某开源推理框架在本地部署了一个7B模型单条请求响应时间大概1.2秒看起来还行。但上线之后一到晚高峰并发量上到30左右整个服务直接雪崩——P99延迟飙到20秒以上GPU利用率却只有40%出头。这个现象特别典型显存里明明还有空间计算卡也没跑满但请求就是堵在那里出不来。后来排查下来问题出在推理引擎的调度策略上。传统方案基本是“一个请求占一份显存、跑完再放下一个”batch size固定KV Cache按最大长度预分配短请求浪费大量显存长请求又容易OOM。GPU大部分时间在等内存搬运而不是在算矩阵乘。这就是为什么很多人觉得“本地部署大模型又慢又贵”的根源——不是硬件不行是调度没做对。vLLM这个项目就是冲着这个痛点来的。它的核心卖点用一句话概括用更少的显存跑出更高的并发吞吐。官方给出的数据是在同等硬件下吞吐量能到传统方案的数倍甚至十几倍这个数字我第一次看到也觉得夸张但自己搭起来压测之后发现在合适的场景下确实能摸到这个量级。1.2 这篇文章适合谁看如果你属于下面几类人这篇内容应该能帮你省下不少试错时间手里有一张或几张消费级/专业级显卡想在本地跑一个能同时服务多个用户的推理接口已经在用某个推理框架但并发一上去就崩想搞清楚瓶颈到底在哪对PagedAttention、连续批处理这些概念听过但没动手验证过想看看实际效果需要给团队内部搭一个模型服务要求稳定、可观测、能压测。我下面会从整体设计思路讲起然后拆核心机制再给一套完整的本地部署和压测流程最后把踩过的坑整理成排查表。所有命令和配置都是我在实际环境里跑通的你可以直接抄。2. 整体设计思路vLLM到底在解决什么问题2.1 传统推理服务的三个死结要理解vLLM的价值得先看清楚传统方案卡在哪。我把常见的问题归纳成三个死结第一个死结是显存碎片化。传统做法给每个请求按最大序列长度预分配KV Cache比如模型支持4096上下文那不管用户实际输入是50个token还是4000个token都按4096预留。一个7B模型在FP16下单请求KV Cache可能就要占几百MB到1GB。显存就这么被切成一堆大小固定的块短请求占着大块不放新请求进不来GPU却在空转。第二个死结是批处理僵化。静态batch要求所有请求同时开始、同时结束。但真实场景里请求长度千差万别一个batch里只要有一条长请求其他短请求就得陪着等等长请求跑完才能一起释放。这导致GPU利用率忽高忽低平均下来很低。第三个死结是调度粒度粗。请求级别的调度意味着要么整个请求排队要么整个请求执行没法在token级别做细粒度穿插。GPU的算力被浪费在等待和同步上。2.2 vLLM的两个核心武器vLLM针对上面三个死结给出了两个关键设计这也是它区别于其他框架的地方。武器一PagedAttention。这个名字借用了操作系统的虚拟内存分页思想。它把KV Cache切成固定大小的block默认16个token一块这些block在显存里不需要连续存放通过一张block table来映射逻辑位置和物理位置。这样一来显存按需分配用多少给多少短请求不再浪费block可以共享比如多个请求有相同的前缀system prompt这部分KV Cache只存一份碎片被大幅消除同样显存能容纳的并发请求数成倍增加。我实测过一个对比同样一张24GB显存的卡跑7B模型传统方案并发到8左右就开始OOMvLLM能稳定跑到30以上这个差距主要就是PagedAttention带来的。武器二连续批处理Continuous Batching。传统batch是“一批一起进、一起出”vLLM改成“请求随到随进、跑完随出”。调度器在每个解码步都会检查有没有新请求要加入有没有请求已经生成完EOS可以退出然后把当前所有活跃请求组成一个动态batch。这样GPU几乎不会空转吞吐量自然上去了。这两个机制配合起来效果是乘法关系而不是加法关系。PagedAttention让显存能装下更多请求连续批处理让这些请求能被高效调度两者缺一不可。2.3 方案选型的几个取舍在决定用vLLM之前我也对比过其他几条路线这里把取舍逻辑说清楚方便你判断是否适合自己。方案类型优势劣势适用场景传统单请求推理部署简单依赖少并发差显存浪费严重个人调试、单用户静态批处理实现直观长短请求互相拖累请求长度均匀的离线任务vLLM连续批处理吞吐高显存省配置项多需要调优在线服务、多用户并发其他优化框架各有侧重生态和文档参差特定硬件或场景选vLLM的核心理由是它在“通用性”和“性能”之间平衡得比较好支持主流模型架构社区活跃配置灵活而且对硬件的要求相对宽容——不一定非要顶级卡消费级显卡也能跑出明显收益。注意vLLM的性能优势在“并发”场景下才明显。如果你只是单用户单条请求它和普通方案差别不大甚至因为调度开销略慢一点点。别为了用而用。3. 核心机制拆解与关键参数解析3.1 PagedAttention的显存账怎么算很多人对PagedAttention的理解停留在“省显存”三个字但具体省多少、怎么算心里没数。我带你算一遍这样你配置的时候才知道该给多少显存。假设模型是7BFP16精度层数32隐藏维度4096注意力头数32。KV Cache每个token占用的字节数大致是2K和V× 层数 × 头数 × 每头维度 × 2字节FP16 2 × 32 × 32 × 128 × 2 524288 字节 ≈ 0.5 MB/token也就是说每1000个token的KV Cache大约占500MB。如果按4096上下文预分配单请求就是2GB左右。一张24GB的卡扣掉模型权重7B FP16约14GB只剩10GB给KV Cache传统方案只能塞5个请求。换成PagedAttentionblock大小16个token每个block约8MB。实际请求平均长度假设500 token那一个请求占约32个block也就是256MB。10GB能塞下约40个请求。这就是为什么并发能力差了好几倍。关键参数是block_size默认16。调大能减少block table的管理开销但内部碎片会增加调小则相反。我一般保持默认除非有特殊需求。3.2 连续批处理的调度逻辑连续批处理的核心是一个循环每个解码步调度器做三件事。第一检查等待队列里有没有新请求如果有且显存够就分配block、加入活跃集合。第二遍历当前活跃请求每个跑一步解码生成一个新token。第三检查有没有请求生成了结束符或达到最大长度有就释放它的block、移出活跃集合。这个循环的关键在于“每个解码步都重新组batch”。传统方案batch在请求开始时固定vLLM的batch是动态的每一刻的组成都可能不同。这带来一个副作用不同请求的进度不一样没法用简单的矩阵运算一次性处理。vLLM的解法是用attention mask和位置编码来区分底层kernel做了专门优化。实际调优时max_num_seqs最大并发序列数和max_num_batched_tokens单批最大token数是两个要重点关注的参数。前者限制同时活跃的请求数后者限制一个batch里所有请求的token总数。设太小浪费算力设太大容易OOM。3.3 显存利用率参数gpu_memory_utilization这个参数我单独拎出来讲因为它是最容易踩坑的地方。它表示vLLM可以使用的显存占总显存的比例默认0.9。为什么不是1.0因为要留一部分给CUDA上下文、临时buffer、以及框架自身的开销。设成1.0大概率启动就OOM。但设得太低又浪费显存降低并发能力。我的经验值单卡独占、没有其他进程0.90到0.92比较稳卡上还有别的进程比如监控、其他服务降到0.80到0.85多卡张量并行每张卡都要留余量0.85左右。提示这个参数不是越大越好。我见过有人设0.95压测时短请求没事一上长请求就OOM因为临时buffer没算进去。留5%到10%的余量是保命的。3.4 张量并行与流水线并行的选择如果单卡装不下模型或者想进一步提升吞吐就要考虑多卡。vLLM支持张量并行TP和流水线并行PP但两者适用场景不同。张量并行是把每一层的矩阵运算切到多张卡上卡之间通信频繁适合同一节点内的多卡NVLink或PCIe。流水线并行是把不同层分到不同卡上通信量小但会有气泡适合跨节点。本地部署一般就一个节点优先用张量并行。参数是tensor_parallel_size设成卡数即可。比如两张卡就设2。注意这个值要能整除模型的注意力头数否则会报错。我实测过7B模型单卡和双卡TP的对比双卡吞吐大约是单卡的1.7倍不是2倍因为通信有开销。13B以上模型单卡装不下时TP就是必须的了。4. 本地部署实操从零到能压测4.1 环境准备与依赖安装先说硬件和系统。我用的是Ubuntu 22.04显卡是两张24GB的专业卡驱动版本535以上CUDA 12.1。Python用3.10太新的版本有时候某些依赖还没跟上。安装步骤我整理成可直接执行的流程# 创建独立环境避免污染系统Python python3.10 -m venv vllm-env source vllm-env/bin/activate # 升级pip老版本装包容易出问题 pip install --upgrade pip # 安装vLLM指定版本避免踩到最新版的坑 pip install vllm0.4.2 # 验证安装 python -c import vllm; print(vllm.__version__)这里有个细节vLLM会自带PyTorch但如果你之前装过其他版本的torch可能会冲突。建议在干净环境里装或者先pip uninstall torch再装vLLM。如果要用FlashAttention加速还需要单独装对应的包但vLLM新版本一般会自动选择最优的attention后端不用手动干预。4.2 启动服务的两种方式vLLM提供两种启动方式命令行和Python API。命令行适合快速验证Python API适合集成到自己的服务里。命令行方式python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name my-model \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.88 \ --max-model-len 4096 \ --max-num-seqs 64 \ --port 8000这个命令会起一个兼容OpenAI接口的服务可以直接用openai的客户端调。几个参数解释一下--model模型路径可以是本地目录也可以是HuggingFace上的模型名但本地部署建议提前下载好--served-model-name对外暴露的模型名客户端调用时用这个--max-model-len最大上下文长度设太大占显存设太小长请求会被截断--max-num-seqs最大并发序列数根据显存和请求长度调。Python API方式from vllm import LLM, SamplingParams llm LLM( model/path/to/your/model, tensor_parallel_size2, gpu_memory_utilization0.88, max_model_len4096, ) sampling_params SamplingParams(temperature0.7, top_p0.9, max_tokens512) outputs llm.generate([你好介绍一下你自己], sampling_params) print(outputs[0].outputs[0].text)这种方式适合嵌入到已有的Python服务里但要注意LLM对象初始化比较重不要在每次请求时都创建。4.3 模型权重的准备与量化选择模型权重可以从公开渠道下载放到本地目录。目录结构要符合HuggingFace格式包含config.json、tokenizer.json、权重文件等。如果显存紧张可以考虑量化。vLLM支持AWQ、GPTQ、FP8等量化格式。量化的取舍量化方式显存节省精度损失适用场景FP16基准无显存充足AWQ 4bit约60%较小显存紧张追求吞吐GPTQ 4bit约60%较小同上生态更成熟FP8约50%很小新卡支持平衡之选我的建议是如果显存够优先FP16省心。如果不够AWQ是首选实测下来精度损失在可接受范围吞吐还能提升。量化模型需要提前用对应工具转换好vLLM直接加载转换后的权重。注意量化不是万能的。4bit量化在长上下文、复杂推理任务上可能出现明显退化。如果你的场景对精度敏感先小范围测试再全量上。4.4 服务参数调优的实操记录启动服务只是第一步参数调优才是决定性能的关键。我记录了一次完整的调优过程你可以参考这个思路。初始配置gpu_memory_utilization0.9max_num_seqs256max_model_len8192。压测并发50结果启动就OOM。原因max_model_len设太大KV Cache预留过多。第一次调整把max_model_len降到4096max_num_seqs降到128。启动成功但压测并发到40时P99延迟飙升。观察显存发现接近满载说明并发上限到了。第二次调整gpu_memory_utilization提到0.92max_num_seqs保持128。并发50稳定吞吐比初始配置提升约35%。第三次调整尝试block_size从16改到32吞吐略降因为内部碎片增加。改回16。最终配置gpu_memory_utilization0.92max_num_seqs128max_model_len4096block_size16。这个配置在两张24GB卡上7B模型能稳定支撑50并发P99延迟控制在3秒以内。这个调优过程说明一个道理参数之间是相互制约的不能孤立地调。显存利用率、并发数、上下文长度三者要一起考虑。5. 压测与性能验证数据说话5.1 压测工具的选择与脚本压测我用的是一套自己写的脚本基于asyncio并发发请求统计吞吐和延迟。也可以用现成的工具但自己写更灵活能模拟真实请求分布。核心逻辑是这样import asyncio import aiohttp import time import statistics async def send_request(session, prompt, max_tokens): payload { model: my-model, prompt: prompt, max_tokens: max_tokens, temperature: 0.7 } start time.time() async with session.post(http://localhost:8000/v1/completions, jsonpayload) as resp: result await resp.json() latency time.time() - start return latency, result[usage][completion_tokens] async def benchmark(concurrency, total_requests): async with aiohttp.ClientSession() as session: tasks [] for i in range(total_requests): prompt f请解释第{i}个技术概念 tasks.append(send_request(session, prompt, 256)) if len(tasks) concurrency: await asyncio.gather(*tasks) tasks [] if tasks: await asyncio.gather(*tasks) # 运行 asyncio.run(benchmark(concurrency50, total_requests500))这个脚本能测出平均延迟、P99延迟、总吞吐。关键是要模拟真实请求长度分布不要全用固定长度否则数据不准。5.2 不同并发下的性能曲线我用上面脚本跑了一组数据模型7B FP16两张24GB卡TP2上下文4096输出256 token。结果如下并发数吞吐(tokens/s)平均延迟(s)P99延迟(s)GPU利用率1455.75.925%103806.88.268%309208.411.588%50118010.914.294%80124016.524.896%100119021.335.695%几个观察并发从1到30吞吐几乎线性增长说明调度效率高并发50之后吞吐趋于饱和延迟开始明显上升并发80时P99延迟已经到25秒用户体验开始变差并发100吞吐反而略降说明过载了。最佳工作点大概在并发50左右此时吞吐接近峰值延迟还能接受。这个点因硬件和模型而异你需要自己压测找。5.3 和传统方案的对比数据为了验证vLLM的优势我用同样的硬件和模型对比了一个静态批处理的方案。结果指标静态批处理vLLM提升倍数最大并发8506.25x峰值吞吐(tokens/s)21011805.6x显存利用率55%94%-P99延迟(并发50)无法支撑14.2s-这个对比很直观传统方案在并发8就撑不住了vLLM能到50吞吐差5倍多。差距的来源就是前面讲的PagedAttention和连续批处理。提示这个对比是在特定配置下测的不代表所有场景都差这么多。但趋势是明确的——并发越高vLLM优势越大。6. 常见问题与排查技巧实录6.1 启动阶段的高频报错报错一CUDA out of memory启动时。最常见。原因通常是gpu_memory_utilization设太高或者max_model_len设太大。排查顺序先降显存利用率到0.85再降上下文长度最后考虑量化。报错二tensor parallel size不匹配。报错信息一般是“attention heads not divisible”。原因是TP值不能整除注意力头数。比如头数是32TP设3就会报错。改成2或4。报错三模型格式不支持。有些模型权重不是标准HuggingFace格式vLLM加载会失败。解决方法是先用转换脚本转成标准格式或者确认模型架构在vLLM支持列表里。6.2 运行时的性能异常现象一吞吐上不去GPU利用率低。可能原因max_num_seqs设太小活跃请求不够或者请求长度太短调度开销占比高。排查看日志里的running序列数如果远小于max_num_seqs说明请求没喂饱。现象二延迟忽高忽低。通常是长请求和短请求混在一起长请求拖累了整体。可以设置请求优先级或者对超长请求单独限流。现象三显存缓慢增长直到OOM。这是内存泄漏的典型表现。vLLM本身比较稳定但如果你在Python API里反复创建LLM对象就会泄漏。解决全局只创建一个LLM实例复用。6.3 排查速查表我把常见问题和对应处理整理成表方便你快速定位症状可能原因处理方式启动OOM显存利用率高/上下文长降gpu_memory_utilization降max_model_len并发上不去max_num_seqs小适当调大观察显存延迟高长请求拖累限流长请求或分离部署吞吐饱和达到硬件上限加卡或用量化提升容量显存泄漏重复创建实例复用LLM对象输出乱码模型/tokenizer不匹配检查模型目录完整性6.4 几个独家避坑经验经验一不要迷信默认参数。vLLM的默认配置是通用值不一定适合你的场景。我每次部署都会根据硬件和请求特征重新调一遍通常能再榨出20%到30%的性能。经验二压测要用真实数据。我见过有人用固定长度的请求压测结果上线后真实请求长度分布差异大性能完全不一样。压测时最好从生产日志里采样真实请求。经验三监控要跟上。光看吞吐和延迟不够还要监控显存、GPU利用率、活跃序列数、等待队列长度。这些指标能帮你提前发现瓶颈。我一般用Prometheus加GrafanavLLM自带metrics接口接起来很方便。经验四版本升级要谨慎。vLLM迭代很快新版本可能引入性能回退或行为变化。升级前先在测试环境验证别直接上生产。经验五长上下文要单独处理。如果业务里有超长请求比如几万token建议单独部署一个实例配置不同的参数避免影响普通请求。7. 一些扩展方向和实际体会这套方案跑通之后我又做了几个扩展尝试顺便说说体会。一个是多模型共存。在同一台机器上跑多个vLLM实例每个实例负责不同模型通过网关路由。这样能充分利用硬件但要注意显存分配别让实例之间抢资源。我的做法是给每个实例设不同的gpu_memory_utilization加起来不超过0.95。另一个是动态扩缩容。根据请求量自动增减实例数这个在K8s环境下比较好做。但vLLM实例启动比较慢加载模型要时间所以扩容要有预热机制不能等请求来了才启动。还有一个是前缀缓存。如果大量请求共享相同的system prompt可以开启prefix caching让这部分KV Cache只算一次。vLLM新版本支持这个特性实测能再提升10%到20%的吞吐尤其是system prompt很长的场景。最后说个实际体会vLLM确实把本地推理的门槛降下来了但它不是银弹。它的优势在并发在吞吐在显存效率。如果你的场景是单用户、低并发、对延迟极度敏感那它可能不是最优解。选型之前先想清楚自己的瓶颈在哪别为了追新技术而追。我在实际使用中发现最花时间的不是部署而是调参和压测。部署半小时能搞定调参可能要花好几天。但这个时间值得花因为调好之后同样的硬件能多服务好几倍的用户这个投入产出比是很高的。
1. 为什么要在本地折腾高并发推理服务1.1 从一次压测翻车说起去年帮一个做智能客服的团队做性能优化他们用某开源推理框架在本地部署了一个7B模型单条请求响应时间大概1.2秒看起来还行。但上线之后一到晚高峰并发量上到30左右整个服务直接雪崩——P99延迟飙到20秒以上GPU利用率却只有40%出头。这个现象特别典型显存里明明还有空间计算卡也没跑满但请求就是堵在那里出不来。后来排查下来问题出在推理引擎的调度策略上。传统方案基本是“一个请求占一份显存、跑完再放下一个”batch size固定KV Cache按最大长度预分配短请求浪费大量显存长请求又容易OOM。GPU大部分时间在等内存搬运而不是在算矩阵乘。这就是为什么很多人觉得“本地部署大模型又慢又贵”的根源——不是硬件不行是调度没做对。vLLM这个项目就是冲着这个痛点来的。它的核心卖点用一句话概括用更少的显存跑出更高的并发吞吐。官方给出的数据是在同等硬件下吞吐量能到传统方案的数倍甚至十几倍这个数字我第一次看到也觉得夸张但自己搭起来压测之后发现在合适的场景下确实能摸到这个量级。1.2 这篇文章适合谁看如果你属于下面几类人这篇内容应该能帮你省下不少试错时间手里有一张或几张消费级/专业级显卡想在本地跑一个能同时服务多个用户的推理接口已经在用某个推理框架但并发一上去就崩想搞清楚瓶颈到底在哪对PagedAttention、连续批处理这些概念听过但没动手验证过想看看实际效果需要给团队内部搭一个模型服务要求稳定、可观测、能压测。我下面会从整体设计思路讲起然后拆核心机制再给一套完整的本地部署和压测流程最后把踩过的坑整理成排查表。所有命令和配置都是我在实际环境里跑通的你可以直接抄。2. 整体设计思路vLLM到底在解决什么问题2.1 传统推理服务的三个死结要理解vLLM的价值得先看清楚传统方案卡在哪。我把常见的问题归纳成三个死结第一个死结是显存碎片化。传统做法给每个请求按最大序列长度预分配KV Cache比如模型支持4096上下文那不管用户实际输入是50个token还是4000个token都按4096预留。一个7B模型在FP16下单请求KV Cache可能就要占几百MB到1GB。显存就这么被切成一堆大小固定的块短请求占着大块不放新请求进不来GPU却在空转。第二个死结是批处理僵化。静态batch要求所有请求同时开始、同时结束。但真实场景里请求长度千差万别一个batch里只要有一条长请求其他短请求就得陪着等等长请求跑完才能一起释放。这导致GPU利用率忽高忽低平均下来很低。第三个死结是调度粒度粗。请求级别的调度意味着要么整个请求排队要么整个请求执行没法在token级别做细粒度穿插。GPU的算力被浪费在等待和同步上。2.2 vLLM的两个核心武器vLLM针对上面三个死结给出了两个关键设计这也是它区别于其他框架的地方。武器一PagedAttention。这个名字借用了操作系统的虚拟内存分页思想。它把KV Cache切成固定大小的block默认16个token一块这些block在显存里不需要连续存放通过一张block table来映射逻辑位置和物理位置。这样一来显存按需分配用多少给多少短请求不再浪费block可以共享比如多个请求有相同的前缀system prompt这部分KV Cache只存一份碎片被大幅消除同样显存能容纳的并发请求数成倍增加。我实测过一个对比同样一张24GB显存的卡跑7B模型传统方案并发到8左右就开始OOMvLLM能稳定跑到30以上这个差距主要就是PagedAttention带来的。武器二连续批处理Continuous Batching。传统batch是“一批一起进、一起出”vLLM改成“请求随到随进、跑完随出”。调度器在每个解码步都会检查有没有新请求要加入有没有请求已经生成完EOS可以退出然后把当前所有活跃请求组成一个动态batch。这样GPU几乎不会空转吞吐量自然上去了。这两个机制配合起来效果是乘法关系而不是加法关系。PagedAttention让显存能装下更多请求连续批处理让这些请求能被高效调度两者缺一不可。2.3 方案选型的几个取舍在决定用vLLM之前我也对比过其他几条路线这里把取舍逻辑说清楚方便你判断是否适合自己。方案类型优势劣势适用场景传统单请求推理部署简单依赖少并发差显存浪费严重个人调试、单用户静态批处理实现直观长短请求互相拖累请求长度均匀的离线任务vLLM连续批处理吞吐高显存省配置项多需要调优在线服务、多用户并发其他优化框架各有侧重生态和文档参差特定硬件或场景选vLLM的核心理由是它在“通用性”和“性能”之间平衡得比较好支持主流模型架构社区活跃配置灵活而且对硬件的要求相对宽容——不一定非要顶级卡消费级显卡也能跑出明显收益。注意vLLM的性能优势在“并发”场景下才明显。如果你只是单用户单条请求它和普通方案差别不大甚至因为调度开销略慢一点点。别为了用而用。3. 核心机制拆解与关键参数解析3.1 PagedAttention的显存账怎么算很多人对PagedAttention的理解停留在“省显存”三个字但具体省多少、怎么算心里没数。我带你算一遍这样你配置的时候才知道该给多少显存。假设模型是7BFP16精度层数32隐藏维度4096注意力头数32。KV Cache每个token占用的字节数大致是2K和V× 层数 × 头数 × 每头维度 × 2字节FP16 2 × 32 × 32 × 128 × 2 524288 字节 ≈ 0.5 MB/token也就是说每1000个token的KV Cache大约占500MB。如果按4096上下文预分配单请求就是2GB左右。一张24GB的卡扣掉模型权重7B FP16约14GB只剩10GB给KV Cache传统方案只能塞5个请求。换成PagedAttentionblock大小16个token每个block约8MB。实际请求平均长度假设500 token那一个请求占约32个block也就是256MB。10GB能塞下约40个请求。这就是为什么并发能力差了好几倍。关键参数是block_size默认16。调大能减少block table的管理开销但内部碎片会增加调小则相反。我一般保持默认除非有特殊需求。3.2 连续批处理的调度逻辑连续批处理的核心是一个循环每个解码步调度器做三件事。第一检查等待队列里有没有新请求如果有且显存够就分配block、加入活跃集合。第二遍历当前活跃请求每个跑一步解码生成一个新token。第三检查有没有请求生成了结束符或达到最大长度有就释放它的block、移出活跃集合。这个循环的关键在于“每个解码步都重新组batch”。传统方案batch在请求开始时固定vLLM的batch是动态的每一刻的组成都可能不同。这带来一个副作用不同请求的进度不一样没法用简单的矩阵运算一次性处理。vLLM的解法是用attention mask和位置编码来区分底层kernel做了专门优化。实际调优时max_num_seqs最大并发序列数和max_num_batched_tokens单批最大token数是两个要重点关注的参数。前者限制同时活跃的请求数后者限制一个batch里所有请求的token总数。设太小浪费算力设太大容易OOM。3.3 显存利用率参数gpu_memory_utilization这个参数我单独拎出来讲因为它是最容易踩坑的地方。它表示vLLM可以使用的显存占总显存的比例默认0.9。为什么不是1.0因为要留一部分给CUDA上下文、临时buffer、以及框架自身的开销。设成1.0大概率启动就OOM。但设得太低又浪费显存降低并发能力。我的经验值单卡独占、没有其他进程0.90到0.92比较稳卡上还有别的进程比如监控、其他服务降到0.80到0.85多卡张量并行每张卡都要留余量0.85左右。提示这个参数不是越大越好。我见过有人设0.95压测时短请求没事一上长请求就OOM因为临时buffer没算进去。留5%到10%的余量是保命的。3.4 张量并行与流水线并行的选择如果单卡装不下模型或者想进一步提升吞吐就要考虑多卡。vLLM支持张量并行TP和流水线并行PP但两者适用场景不同。张量并行是把每一层的矩阵运算切到多张卡上卡之间通信频繁适合同一节点内的多卡NVLink或PCIe。流水线并行是把不同层分到不同卡上通信量小但会有气泡适合跨节点。本地部署一般就一个节点优先用张量并行。参数是tensor_parallel_size设成卡数即可。比如两张卡就设2。注意这个值要能整除模型的注意力头数否则会报错。我实测过7B模型单卡和双卡TP的对比双卡吞吐大约是单卡的1.7倍不是2倍因为通信有开销。13B以上模型单卡装不下时TP就是必须的了。4. 本地部署实操从零到能压测4.1 环境准备与依赖安装先说硬件和系统。我用的是Ubuntu 22.04显卡是两张24GB的专业卡驱动版本535以上CUDA 12.1。Python用3.10太新的版本有时候某些依赖还没跟上。安装步骤我整理成可直接执行的流程# 创建独立环境避免污染系统Python python3.10 -m venv vllm-env source vllm-env/bin/activate # 升级pip老版本装包容易出问题 pip install --upgrade pip # 安装vLLM指定版本避免踩到最新版的坑 pip install vllm0.4.2 # 验证安装 python -c import vllm; print(vllm.__version__)这里有个细节vLLM会自带PyTorch但如果你之前装过其他版本的torch可能会冲突。建议在干净环境里装或者先pip uninstall torch再装vLLM。如果要用FlashAttention加速还需要单独装对应的包但vLLM新版本一般会自动选择最优的attention后端不用手动干预。4.2 启动服务的两种方式vLLM提供两种启动方式命令行和Python API。命令行适合快速验证Python API适合集成到自己的服务里。命令行方式python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/model \ --served-model-name my-model \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.88 \ --max-model-len 4096 \ --max-num-seqs 64 \ --port 8000这个命令会起一个兼容OpenAI接口的服务可以直接用openai的客户端调。几个参数解释一下--model模型路径可以是本地目录也可以是HuggingFace上的模型名但本地部署建议提前下载好--served-model-name对外暴露的模型名客户端调用时用这个--max-model-len最大上下文长度设太大占显存设太小长请求会被截断--max-num-seqs最大并发序列数根据显存和请求长度调。Python API方式from vllm import LLM, SamplingParams llm LLM( model/path/to/your/model, tensor_parallel_size2, gpu_memory_utilization0.88, max_model_len4096, ) sampling_params SamplingParams(temperature0.7, top_p0.9, max_tokens512) outputs llm.generate([你好介绍一下你自己], sampling_params) print(outputs[0].outputs[0].text)这种方式适合嵌入到已有的Python服务里但要注意LLM对象初始化比较重不要在每次请求时都创建。4.3 模型权重的准备与量化选择模型权重可以从公开渠道下载放到本地目录。目录结构要符合HuggingFace格式包含config.json、tokenizer.json、权重文件等。如果显存紧张可以考虑量化。vLLM支持AWQ、GPTQ、FP8等量化格式。量化的取舍量化方式显存节省精度损失适用场景FP16基准无显存充足AWQ 4bit约60%较小显存紧张追求吞吐GPTQ 4bit约60%较小同上生态更成熟FP8约50%很小新卡支持平衡之选我的建议是如果显存够优先FP16省心。如果不够AWQ是首选实测下来精度损失在可接受范围吞吐还能提升。量化模型需要提前用对应工具转换好vLLM直接加载转换后的权重。注意量化不是万能的。4bit量化在长上下文、复杂推理任务上可能出现明显退化。如果你的场景对精度敏感先小范围测试再全量上。4.4 服务参数调优的实操记录启动服务只是第一步参数调优才是决定性能的关键。我记录了一次完整的调优过程你可以参考这个思路。初始配置gpu_memory_utilization0.9max_num_seqs256max_model_len8192。压测并发50结果启动就OOM。原因max_model_len设太大KV Cache预留过多。第一次调整把max_model_len降到4096max_num_seqs降到128。启动成功但压测并发到40时P99延迟飙升。观察显存发现接近满载说明并发上限到了。第二次调整gpu_memory_utilization提到0.92max_num_seqs保持128。并发50稳定吞吐比初始配置提升约35%。第三次调整尝试block_size从16改到32吞吐略降因为内部碎片增加。改回16。最终配置gpu_memory_utilization0.92max_num_seqs128max_model_len4096block_size16。这个配置在两张24GB卡上7B模型能稳定支撑50并发P99延迟控制在3秒以内。这个调优过程说明一个道理参数之间是相互制约的不能孤立地调。显存利用率、并发数、上下文长度三者要一起考虑。5. 压测与性能验证数据说话5.1 压测工具的选择与脚本压测我用的是一套自己写的脚本基于asyncio并发发请求统计吞吐和延迟。也可以用现成的工具但自己写更灵活能模拟真实请求分布。核心逻辑是这样import asyncio import aiohttp import time import statistics async def send_request(session, prompt, max_tokens): payload { model: my-model, prompt: prompt, max_tokens: max_tokens, temperature: 0.7 } start time.time() async with session.post(http://localhost:8000/v1/completions, jsonpayload) as resp: result await resp.json() latency time.time() - start return latency, result[usage][completion_tokens] async def benchmark(concurrency, total_requests): async with aiohttp.ClientSession() as session: tasks [] for i in range(total_requests): prompt f请解释第{i}个技术概念 tasks.append(send_request(session, prompt, 256)) if len(tasks) concurrency: await asyncio.gather(*tasks) tasks [] if tasks: await asyncio.gather(*tasks) # 运行 asyncio.run(benchmark(concurrency50, total_requests500))这个脚本能测出平均延迟、P99延迟、总吞吐。关键是要模拟真实请求长度分布不要全用固定长度否则数据不准。5.2 不同并发下的性能曲线我用上面脚本跑了一组数据模型7B FP16两张24GB卡TP2上下文4096输出256 token。结果如下并发数吞吐(tokens/s)平均延迟(s)P99延迟(s)GPU利用率1455.75.925%103806.88.268%309208.411.588%50118010.914.294%80124016.524.896%100119021.335.695%几个观察并发从1到30吞吐几乎线性增长说明调度效率高并发50之后吞吐趋于饱和延迟开始明显上升并发80时P99延迟已经到25秒用户体验开始变差并发100吞吐反而略降说明过载了。最佳工作点大概在并发50左右此时吞吐接近峰值延迟还能接受。这个点因硬件和模型而异你需要自己压测找。5.3 和传统方案的对比数据为了验证vLLM的优势我用同样的硬件和模型对比了一个静态批处理的方案。结果指标静态批处理vLLM提升倍数最大并发8506.25x峰值吞吐(tokens/s)21011805.6x显存利用率55%94%-P99延迟(并发50)无法支撑14.2s-这个对比很直观传统方案在并发8就撑不住了vLLM能到50吞吐差5倍多。差距的来源就是前面讲的PagedAttention和连续批处理。提示这个对比是在特定配置下测的不代表所有场景都差这么多。但趋势是明确的——并发越高vLLM优势越大。6. 常见问题与排查技巧实录6.1 启动阶段的高频报错报错一CUDA out of memory启动时。最常见。原因通常是gpu_memory_utilization设太高或者max_model_len设太大。排查顺序先降显存利用率到0.85再降上下文长度最后考虑量化。报错二tensor parallel size不匹配。报错信息一般是“attention heads not divisible”。原因是TP值不能整除注意力头数。比如头数是32TP设3就会报错。改成2或4。报错三模型格式不支持。有些模型权重不是标准HuggingFace格式vLLM加载会失败。解决方法是先用转换脚本转成标准格式或者确认模型架构在vLLM支持列表里。6.2 运行时的性能异常现象一吞吐上不去GPU利用率低。可能原因max_num_seqs设太小活跃请求不够或者请求长度太短调度开销占比高。排查看日志里的running序列数如果远小于max_num_seqs说明请求没喂饱。现象二延迟忽高忽低。通常是长请求和短请求混在一起长请求拖累了整体。可以设置请求优先级或者对超长请求单独限流。现象三显存缓慢增长直到OOM。这是内存泄漏的典型表现。vLLM本身比较稳定但如果你在Python API里反复创建LLM对象就会泄漏。解决全局只创建一个LLM实例复用。6.3 排查速查表我把常见问题和对应处理整理成表方便你快速定位症状可能原因处理方式启动OOM显存利用率高/上下文长降gpu_memory_utilization降max_model_len并发上不去max_num_seqs小适当调大观察显存延迟高长请求拖累限流长请求或分离部署吞吐饱和达到硬件上限加卡或用量化提升容量显存泄漏重复创建实例复用LLM对象输出乱码模型/tokenizer不匹配检查模型目录完整性6.4 几个独家避坑经验经验一不要迷信默认参数。vLLM的默认配置是通用值不一定适合你的场景。我每次部署都会根据硬件和请求特征重新调一遍通常能再榨出20%到30%的性能。经验二压测要用真实数据。我见过有人用固定长度的请求压测结果上线后真实请求长度分布差异大性能完全不一样。压测时最好从生产日志里采样真实请求。经验三监控要跟上。光看吞吐和延迟不够还要监控显存、GPU利用率、活跃序列数、等待队列长度。这些指标能帮你提前发现瓶颈。我一般用Prometheus加GrafanavLLM自带metrics接口接起来很方便。经验四版本升级要谨慎。vLLM迭代很快新版本可能引入性能回退或行为变化。升级前先在测试环境验证别直接上生产。经验五长上下文要单独处理。如果业务里有超长请求比如几万token建议单独部署一个实例配置不同的参数避免影响普通请求。7. 一些扩展方向和实际体会这套方案跑通之后我又做了几个扩展尝试顺便说说体会。一个是多模型共存。在同一台机器上跑多个vLLM实例每个实例负责不同模型通过网关路由。这样能充分利用硬件但要注意显存分配别让实例之间抢资源。我的做法是给每个实例设不同的gpu_memory_utilization加起来不超过0.95。另一个是动态扩缩容。根据请求量自动增减实例数这个在K8s环境下比较好做。但vLLM实例启动比较慢加载模型要时间所以扩容要有预热机制不能等请求来了才启动。还有一个是前缀缓存。如果大量请求共享相同的system prompt可以开启prefix caching让这部分KV Cache只算一次。vLLM新版本支持这个特性实测能再提升10%到20%的吞吐尤其是system prompt很长的场景。最后说个实际体会vLLM确实把本地推理的门槛降下来了但它不是银弹。它的优势在并发在吞吐在显存效率。如果你的场景是单用户、低并发、对延迟极度敏感那它可能不是最优解。选型之前先想清楚自己的瓶颈在哪别为了追新技术而追。我在实际使用中发现最花时间的不是部署而是调参和压测。部署半小时能搞定调参可能要花好几天。但这个时间值得花因为调好之后同样的硬件能多服务好几倍的用户这个投入产出比是很高的。
