vLLM部署LLama2-7B实战：PagedAttention与连续批处理高并发调优

1. 为什么选vLLM跑LLama2-7B而不是继续用HuggingFace原生推理如果你之前用transformers库直接加载过LLama2-7B做推理大概率经历过这样的场景单条请求响应还算能忍一旦并发上来显存直接爆掉或者吞吐量低到让人怀疑人生。我最早在一台单卡A100 40G上跑原生推理batch size开到8就开始OOMQPS连2都上不去。后来换成vLLM同样的硬件并发32的情况下吞吐量翻了将近15倍显存占用反而更稳定。这个差距不是调参能弥补的是底层架构决定的。1.1 原生推理的瓶颈到底卡在哪里HuggingFace的generate()方法在推理时KV Cache键值缓存是随着序列长度动态增长的连续显存块。每来一个新请求如果序列长度不同就需要重新分配显存。更致命的是原生实现里KV Cache的显存利用率极低——预分配的显存块可能只用了30%到40%剩下的全浪费了。当并发请求数增加时显存碎片化严重最终导致OOM。另一个问题是批处理策略。原生推理通常采用静态批处理也就是说一个batch里的所有请求必须等最长的那个序列生成完毕才能一起返回。短请求被长请求拖死GPU利用率在大部分时间里处于饥饿状态。我实测过一个场景10条请求里有一条要生成2000个token其余9条只需要50个token静态批处理下GPU有超过70%的时间在等那一条长序列。1.2 PagedAttention机制的核心逻辑vLLM的核心创新是PagedAttention灵感来自操作系统的虚拟内存分页管理。它把KV Cache切分成固定大小的块block每个块默认存16个token的KV数据。不同序列的块可以非连续地存储在显存中通过一个块表block table来映射逻辑位置和物理位置。这个设计带来两个直接好处。第一显存浪费被压到极低。块按需分配序列生成完就释放碎片率从原生实现的60%以上降到不足5%。第二内存共享成为可能。多个请求如果共享相同的prompt前缀比如few-shot场景下的系统提示词这些前缀对应的KV块只需要存一份通过引用计数管理。我在一个客服问答场景里测试过系统提示词占了800个token50个并发请求共享前缀显存节省了将近40%。1.3 连续批处理如何把GPU喂饱vLLM采用连续批处理Continuous Batching也叫迭代级调度。它的逻辑是每生成一个token就重新评估一次batch组成。新来的请求可以立刻插入到当前batch中已完成的序列立刻退出不用等整个batch结束。GPU的利用率从静态批处理下的30%到50%拉到了80%以上。用个生活化的类比静态批处理像一辆公交车必须等所有乘客到齐才发车到站后所有人一起下。连续批处理像地铁随时有人上车有人下车车厢始终保持在接近满载的状态。这个调度策略的代价是调度器复杂度上升但在vLLM里已经被封装好了你不需要手动管理。注意连续批处理对延迟敏感型任务不一定友好。如果你的场景要求单条请求的P99延迟极低可能需要限制最大并发数或者考虑用TensorRT-LLM做进一步优化。vLLM的默认调度偏向吞吐量优先。2. 部署前的环境准备与版本选型避坑环境准备这一步看起来简单实际上是我踩坑最多的地方。CUDA版本、PyTorch版本、vLLM版本三者之间的兼容性矩阵非常敏感错一个版本就可能编译失败或者运行时报奇怪的CUDA错误。2.1 硬件与驱动的前置检查LLama2-7B的FP16权重约13GB推理时KV Cache加上激活值单卡至少需要24GB显存才能比较舒服地跑起来。我用的是A100 40G但也在RTX 4090 24G上验证过batch size控制在16以内没问题。如果你只有16G显存可以考虑量化版本AWQ或GPTQ但量化会带来一定的精度损失需要根据业务场景权衡。驱动方面NVIDIA驱动版本建议在525以上CUDA Toolkit用11.8或12.1。这两个版本vLLM官方支持得最好。我试过CUDA 12.4编译时flash-attn会报错降回12.1就正常了。# 检查驱动和CUDA版本 nvidia-smi nvcc --version # 确认GPU显存和计算能力 python -c import torch; print(torch.cuda.get_device_properties(0))2.2 Python环境隔离与依赖安装强烈建议用conda建一个独立环境不要跟其他项目的依赖混在一起。vLLM对torch版本有硬性要求跟其他框架冲突的概率很高。conda create -n vllm_env python3.10 -y conda activate vllm_env # 安装PyTorch以CUDA 12.1为例 pip install torch2.1.2 torchvision0.16.2 torchaudio2.1.2 --index-url https://download.pytorch.org/whl/cu121 # 安装vLLM pip install vllm0.4.2版本选择上vLLM 0.4.x系列是我目前最推荐的稳定版本。0.5.x引入了一些新特性但API有变动0.3.x则缺少一些性能优化。0.4.2在LLama2-7B上的实测吞吐量比0.3.7高了约20%而且对transformers的版本要求更宽松。2.3 模型权重的获取与格式转换LLama2-7B的原始权重是Meta发布的HuggingFace格式可以直接用。但如果你手头是GGUF格式或者需要做量化就需要额外转换。我一般直接从HuggingFace Hub拉取# 方式一用huggingface-cli下载 huggingface-cli download meta-llama/Llama-2-7b-hf --local-dir ./llama2-7b --local-dir-use-symlinks False # 方式二用modelscope国内网络更友好 pip install modelscope python -c from modelscope import snapshot_download; snapshot_download(modelscope/Llama-2-7b-chat-ms, cache_dir./llama2-7b)下载完成后检查目录结构确保包含config.json、tokenizer.model、pytorch_model.bin或分片的safetensors文件。如果缺少tokenizer.modelvLLM启动时会报tokenizer加载失败。提示LLama2的tokenizer有个坑tokenizer.model和tokenizer.json可能只存在一个。vLLM优先读tokenizer.model如果没有会尝试从tokenizer.json转换。建议两个文件都保留。3. vLLM服务启动参数详解与调优启动vLLM服务看起来就是一行命令的事但参数配置直接决定了吞吐量、延迟和显存占用。我见过太多人用默认参数跑然后抱怨性能不如预期。3.1 核心启动参数逐个拆解python -m vllm.entrypoints.openai.api_server \ --model ./llama2-7b \ --served-model-name llama2-7b \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --max-model-len 4096 \ --gpu-memory-utilization 0.90 \ --max-num-seqs 64 \ --max-num-batched-tokens 8192 \ --dtype float16 \ --swap-space 8 \ --disable-log-requests--gpu-memory-utilization是最关键的参数之一。它控制vLLM预分配多少比例的显存给KV Cache。默认0.9意味着留10%给模型权重和激活值。如果你发现启动时报OOM先降到0.85试试。反过来如果显存有富余可以提到0.95KV Cache空间更大能支持的并发数更多。--max-num-seqs限制同时处理的最大序列数。设太大KV Cache不够会触发抢占preemption反而降低吞吐。设太小GPU利用率上不去。我的经验值是40G显存跑7B模型设64比较合适24G显存设32。--max-num-batched-tokens控制一个batch里最多处理多少个token。这个值跟max-model-len配合使用。如果设成8192意味着一个batch里所有序列的token总数不超过8192。设太小会导致大序列被拆分设太大则显存压力大。--swap-space是CPU内存交换空间单位GB。当KV Cache不够时vLLM会把部分块换出到CPU内存。这个机制能防止OOM但换入换出有延迟。我一般设8到16GB作为安全缓冲。3.2 张量并行与单机多卡配置如果你有多张卡--tensor-parallel-size可以开启张量并行。比如两张A100 40G设成2模型权重和KV Cache会平均分配到两张卡上。注意张量并行要求卡间通信带宽足够NVLink最好PCIe 4.0 x16也能用但效率会打折扣。# 双卡张量并行 python -m vllm.entrypoints.openai.api_server \ --model ./llama2-7b \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.85 \ --max-num-seqs 128实测下来双卡张量并行的吞吐量大约是单卡的1.7倍不是线性的2倍因为卡间通信有开销。如果你的场景对延迟不敏感、追求极致吞吐可以考虑用流水线并行--pipeline-parallel-size但vLLM对流水线并行的支持不如张量并行成熟。3.3 量化部署的取舍如果显存不够量化是绕不开的选项。vLLM支持AWQ和GPTQ两种量化格式。AWQ的精度损失更小推荐优先考虑。# AWQ量化模型启动 python -m vllm.entrypoints.openai.api_server \ --model ./llama2-7b-awq \ --quantization awq \ --dtype float16 \ --gpu-memory-utilization 0.90AWQ 4bit量化后7B模型的显存占用从13GB降到约4GB24G卡上可以轻松跑batch size 64。但精度方面我在一个文本分类任务上对比过AWQ量化的准确率比FP16低了约1.5个百分点。如果你的任务对精度要求极高建议还是用FP16。注意量化模型和原始模型的tokenizer必须一致。我遇到过有人用LLama2的tokenizer配LLama2-chat的量化权重结果生成的文本乱码。确认config.json里的vocab_size和tokenizer匹配。4. 高并发压测与性能调优实战服务跑起来只是第一步真正的高并发场景下能不能扛住需要压测来验证。我用locust和wrk都做过压测各有优劣。4.1 压测工具选型与脚本编写wrk适合做HTTP层的纯吞吐压测但构造JSON请求体不太方便。locust用Python写脚本灵活度高能模拟真实的请求分布。我一般用locust做功能验证用wrk做极限吞吐测试。# locustfile.py from locust import HttpUser, task, between import json class VLLMUser(HttpUser): wait_time between(0.1, 0.5) task def chat_completion(self): payload { model: llama2-7b, messages: [ {role: user, content: 请用一句话解释什么是机器学习} ], max_tokens: 128, temperature: 0.7 } headers {Content-Type: application/json} self.client.post(/v1/chat/completions, datajson.dumps(payload), headersheaders)启动压测locust -f locustfile.py --hosthttp://localhost:8000 --users100 --spawn-rate104.2 关键性能指标的解读压测时重点看三个指标TTFTTime To First Token、TPOTTime Per Output Token和吞吐量tokens/s。TTFT反映的是首token延迟主要受prompt长度和调度排队影响。在并发100的情况下如果TTFT超过2秒说明调度队列积压严重需要调大max-num-seqs或者加卡。TPOT反映的是生成速度7B模型在A100上FP16推理TPOT通常在20到40毫秒之间。如果TPOT突然飙升大概率是触发了抢占KV Cache不够用了。吞吐量是整体指标我实测的数据单卡A100 40GLLama2-7BFP16并发64输入128 token、输出128 token吞吐量约2800 tokens/s。换成AWQ量化后吞吐量能到4500 tokens/s左右。配置并发数TTFT (ms)TPOT (ms)吞吐量 (tokens/s)FP16 单卡32180281600FP16 单卡64420352800AWQ 单卡64150184500FP16 双卡TP1283803248004.3 抢占与OOM的排查链路压测时最常见的两个问题是抢占和OOM。抢占的日志特征是出现PreemptionMode.RECOMPUTE或PreemptionMode.SWAP。RECOMPUTE是把被抢占序列的KV Cache丢掉等重新调度时再算一遍SWAP是换到CPU内存。前者浪费算力后者浪费带宽。排查步骤先看gpu-memory-utilization是不是设太高了降到0.85试试检查max-num-seqs是否超过了KV Cache的实际承载能力看max-model-len是不是设得过大4096对于大多数场景够用了设成8192会吃掉大量KV Cache空间如果以上都调了还有抢占考虑加卡或者上量化OOM的排查更直接看报错信息里是哪一步分配的显存不够。如果是模型加载阶段OOM说明gpu-memory-utilization设太高模型权重都放不下。如果是推理阶段OOM说明KV Cache预分配不够需要降低max-num-seqs或max-model-len。提示vLLM启动时会打印KV Cache的块数量和可支持的并发token数。这个信息在日志里搜GPU KV cache size就能找到。根据这个数字反推合理的max-num-seqs比盲目试参数高效得多。5. 生产环境部署的工程化考量把vLLM跑通和把它用好是两回事。生产环境要考虑服务发现、负载均衡、监控告警、模型热更新等一系列问题。5.1 用Docker封装推理服务直接裸跑Python进程在生产环境不够稳健。用Docker封装配合--restartalways能保证进程挂了自动拉起。FROM nvidia/cuda:12.1.0-runtime-ubuntu22.04 RUN apt-get update apt-get install -y python3.10 python3-pip RUN pip install vllm0.4.2 COPY ./llama2-7b /models/llama2-7b EXPOSE 8000 CMD [python, -m, vllm.entrypoints.openai.api_server, \ --model, /models/llama2-7b, \ --host, 0.0.0.0, \ --port, 8000, \ --gpu-memory-utilization, 0.90, \ --max-num-seqs, 64]启动容器时记得加--gpus all和--shm-size。shm-size默认是64MBvLLM的多进程通信需要更大的共享内存设成8GB比较稳妥。docker run -d --gpus all --shm-size8g \ -p 8000:8000 \ --restartalways \ --name vllm-llama2 \ vllm-llama2:latest5.2 多实例负载均衡与健康检查单实例扛不住的时候起多个vLLM实例前面挂一个Nginx做负载均衡。注意vLLM的OpenAI兼容接口是无状态的可以直接轮询。upstream vllm_backend { server 127.0.0.1:8000; server 127.0.0.1:8001; server 127.0.0.1:8002; } server { listen 80; location /v1/ { proxy_pass http://vllm_backend; proxy_read_timeout 300s; proxy_send_timeout 300s; } }健康检查用/health端点vLLM自带。Nginx配置里加proxy_next_upstream error timeout某个实例挂了自动切到下一个。5.3 监控指标与告警阈值vLLM暴露了Prometheus格式的指标在/metrics端点。重点监控这几个vllm:num_requests_running当前正在处理的请求数持续接近max-num-seqs说明需要扩容vllm:gpu_cache_usage_percKV Cache使用率超过90%会触发抢占vllm:time_to_first_token_secondsTTFT的直方图P99超过2秒要告警vllm:time_per_output_token_secondsTPOT的直方图P99超过100毫秒要排查# prometheus告警规则示例 groups: - name: vllm_alerts rules: - alert: HighKVCacheUsage expr: vllm:gpu_cache_usage_perc 0.9 for: 5m labels: severity: warning annotations: summary: KV Cache使用率过高可能触发抢占5.4 模型热更新的平滑方案生产环境不可能每次换模型都停服务。我的做法是新模型起一个新实例端口不同等健康检查通过后把Nginx的upstream指向新实例然后优雅关闭旧实例。# 1. 启动新实例 docker run -d --gpus all --shm-size8g -p 8001:8000 --name vllm-new vllm-llama2-new:latest # 2. 等待健康检查通过 until curl -s http://localhost:8001/health; do sleep 5; done # 3. 更新Nginx配置reload nginx -s reload # 4. 优雅关闭旧实例 docker stop vllm-old这个方案的关键是Nginx的proxy_next_upstream和健康检查要配好否则切换瞬间会有请求失败。注意vLLM实例启动时需要加载模型权重7B模型大概需要30到60秒。如果你的服务SLA要求零中断建议保持至少两个实例在线滚动更新。6. 实际业务场景中的参数微调经验不同业务场景对推理服务的需求差异很大。我做过对话机器人、文档摘要、代码生成三类场景参数配置策略完全不同。6.1 对话场景的低延迟优先策略对话场景对TTFT极其敏感用户发完消息后超过1秒没响应就会觉得卡。这时候max-num-seqs不能设太大否则排队严重。我一般设16到24牺牲吞吐保延迟。max-model-len设2048就够了对话历史很少超过这个长度。另外对话场景适合开启--enable-prefix-caching。多轮对话中系统提示词和历史对话是共享前缀prefix caching能大幅减少重复计算。实测TTFT能降低30%左右。python -m vllm.entrypoints.openai.api_server \ --model ./llama2-7b \ --max-num-seqs 24 \ --max-model-len 2048 \ --enable-prefix-caching \ --gpu-memory-utilization 0.856.2 批量摘要场景的吞吐优先策略文档摘要场景通常是离线批处理对延迟不敏感追求单位时间处理尽可能多的文档。这时候max-num-seqs可以拉到128甚至256max-model-len设4096以支持长文档。gpu-memory-utilization提到0.95把显存榨干。批量场景还有一个技巧把多个短文档拼成一个长prompt一次推理生成多个摘要。这样能减少请求数提高GPU利用率。但要注意prompt拼接的边界避免文档之间互相干扰。6.3 代码生成场景的精度与速度平衡代码生成对精度要求高量化模型容易生成语法错误。我建议用FP16不要用AWQ。temperature设0.2到0.4比对话场景低保证生成的代码确定性更强。max-model-len设8192因为代码文件通常较长。代码生成场景的TPOT比对话场景高因为代码token的生成难度更大。如果TPOT超过80毫秒用户体验会明显下降。这时候可以考虑用投机采样speculative decodingvLLM 0.4.x已经支持但需要额外的小模型做draft。# 投机采样配置需要draft模型 python -m vllm.entrypoints.openai.api_server \ --model ./llama2-7b \ --speculative-model ./llama2-1.1b \ --num-speculative-tokens 5 \ --max-model-len 8192投机采样能让TPOT降低20%到40%代价是显存占用增加要加载draft模型。如果你的显存有富余值得一试。6.4 常见报错与快速修复对照表报错信息根因修复方案CUDA out of memory显存不足降低gpu-memory-utilization或max-num-seqsPreemptionMode.RECOMPUTE频繁出现KV Cache不足降低max-model-len或加卡tokenizer.model not foundtokenizer文件缺失补全tokenizer.model或tokenizer.jsonflash-attn编译失败CUDA版本不匹配降级到CUDA 11.8或12.1ValueError: Model class not found模型架构不支持检查vLLM版本是否支持该模型请求超时调度队列积压增加实例数或调大max-num-seqs这些报错我基本都踩过一遍最坑的是flash-attn编译失败当时折腾了一整天才定位到是CUDA 12.4的问题。后来养成习惯部署前先查vLLM官方文档的兼容性矩阵能省很多时间。7. 从单机到多机的扩展思路单机多卡跑通之后如果业务量继续增长就需要考虑多机部署。vLLM本身支持分布式推理但配置复杂度比单机高不少。7.1 Ray集群的搭建与vLLM集成vLLM用Ray做分布式调度。多机部署需要先起一个Ray集群然后vLLM通过--tensor-parallel-size和--pipeline-parallel-size跨节点分配模型。# 在head节点启动Ray ray start --head --port6379 # 在worker节点加入集群 ray start --addresshead-node-ip:6379 # 启动vLLM跨2个节点每个节点4张卡 python -m vllm.entrypoints.openai.api_server \ --model ./llama2-7b \ --tensor-parallel-size 4 \ --pipeline-parallel-size 2 \ --distributed-executor-backend ray多机部署的网络带宽是瓶颈。张量并行要求节点间通信延迟极低最好用InfiniBand或者100Gbps以上的以太网。普通千兆网跑张量并行性能会惨不忍睹。7.2 什么场景适合多机什么场景适合多实例这里有个决策逻辑如果你的模型单卡放不下比如70B模型必须用张量并行跨多卡多机。如果模型单卡能放下比如7B但并发量很大多实例加负载均衡比多机张量并行更划算。原因很简单多机张量并行的通信开销大扩展效率不是线性的。4张卡张量并行的吞吐量可能只有单卡的2.5倍而4个单卡实例加负载均衡吞吐量接近4倍。所以7B模型的高并发场景我强烈建议多实例方案。7.3 成本与性能的平衡点最后算一笔账。假设你的业务需要5000 tokens/s的吞吐量。方案A单卡A100 40GAWQ量化吞吐量4500 tokens/s差一点达标需要加一张卡做双实例。方案B双卡A100 80GFP16张量并行吞吐量约4800 tokens/s。方案A的硬件成本是2张40G卡方案B是2张80G卡。方案A成本更低但量化有精度损失。方案B精度高但成本高。如果业务对精度不敏感方案A更划算。如果精度是硬指标方案B是唯一选择。我的经验是先上AWQ量化跑起来用监控数据说话。如果精度达标就继续用如果不达标再考虑升级硬件。不要一上来就堆顶配浪费预算。提示vLLM的版本迭代很快新版本经常带来性能提升。建议每隔一个季度评估一次升级但不要盲目追新。升级前在测试环境跑一遍压测确认吞吐量和精度没有回退再上生产。