1. 为什么企业都在折腾私有化大模型部署这两年跟不少做基础架构的朋友聊天话题绕来绕去最后总会落到同一个点上模型能力已经摆在那了真正让人头疼的是怎么把它稳稳当当地塞进自己机房里还得让业务方用得舒服。公有云API调用确实省事但数据出域、调用成本、响应延迟这三座大山压下来稍微有点规模的业务都扛不住。特别是金融、医疗、制造业这几个圈子数据合规的红线碰都不能碰私有化部署几乎是唯一解。vLLM这个推理引擎就是在这个背景下火起来的。它最早是某高校实验室搞出来的开源项目核心卖点就一个把显存利用率拉满让同样的卡跑出几倍的吞吐。传统推理框架做KV Cache的时候要么预分配一大块显存浪费严重要么动态分配碎片化厉害vLLM用了个叫PagedAttention的机制把KV Cache切成固定大小的块来管理思路跟操作系统虚拟内存分页几乎一模一样。这个设计直接让显存浪费从60%以上降到4%以下吞吐量提升肉眼可见。这篇内容适合谁看如果你手里有几张A100或者H800正琢磨着怎么给公司内部搭一套能扛住并发的大模型服务那接下来的东西应该能帮你少走不少弯路。如果你只是想在单卡上跑个demo玩玩那vLLM也能用但很多调优参数你可能感受不深。我会从整体架构设计讲到具体参数怎么调再到踩过的坑怎么填尽量把每个决策背后的逻辑说清楚。2. 部署前的整体架构设计与选型考量2.1 推理引擎选型为什么是vLLM而不是其他市面上做LLM推理的方案不少TensorRT-LLM、TGI、DeepSpeed-Inference各有各的拥趸。我当初选型的时候把几个主流方案都跑了一遍最后落在vLLM上主要基于几个很实际的考量。TensorRT-LLM性能确实猛NVIDIA亲儿子算子融合做得极致但它的模型转换流程太折磨人了。每次换个模型版本都要重新走一遍编译流程调试信息也不够友好出了问题排查起来像在黑盒里摸象。TGI是HuggingFace家的生态整合好部署简单但它的调度策略相对保守高并发场景下吞吐量跟vLLM比有差距。DeepSpeed-Inference更适合研究场景生产环境的稳定性还需要更多验证。vLLM最大的优势在于它的PagedAttention和Continuous Batching这两个机制配合起来能把GPU利用率推到很高。Continuous Batching的意思是不等一个batch里所有请求都生成完才处理下一批而是哪个请求结束了就立刻把新请求塞进去GPU几乎不会空转。这个在真实业务场景里太重要了因为用户请求的长度参差不齐传统静态batching会有大量等待时间。注意vLLM对模型架构的支持有优先级Transformer类模型支持最好一些特殊架构比如Mamba的支持还在完善中。选型前先去官方文档确认你要部署的模型在不在支持列表里。2.2 硬件配置的取舍逻辑硬件这块没有标准答案但有几个关键参数决定了你的部署方案。首先是显存容量它直接决定了你能跑多大的模型。粗略估算的话FP16精度下模型权重占用的显存大约是参数量乘以2字节。比如一个70B的模型光权重就要140GB左右加上KV Cache和中间激活值至少需要2张80GB的卡才能跑起来。但实际部署中你会发现光看显存容量不够显存带宽往往才是瓶颈。A100的HBM2e带宽是2TB/sH800是3.35TB/s这个差距在长序列推理时体现得特别明显。我实测过一个13B模型在A100和H800上的表现短序列输入输出都在512 token以内差距不大但序列长度拉到4K以上H800的吞吐量能高出40%左右。卡间互联也值得说道。NVLink和PCIe的带宽差距是数量级的如果你打算做张量并行Tensor ParallelismNVLink几乎是必须的。PCIe环境下做TP通信开销会把并行带来的收益吃掉大半。所以如果预算允许尽量选同一台机器内NVLink互联的卡实在不行再考虑多机方案。配置项入门级生产级高性能级GPU型号RTX 4090 24GBA100 80GBH800 80GB卡间互联PCIeNVLinkNVLink适用模型规模7B-13B13B-70B70B-130B典型并发量5-1050-100200显存带宽1TB/s2TB/s3.35TB/s2.3 网络与存储的前置准备模型文件动辄几十上百GB从存储加载到显存的时间如果太长服务重启会变成一件很痛苦的事。我建议把模型文件放在本地NVMe SSD上读取速度能到3GB/s以上一个70B的模型加载时间可以控制在1分钟以内。如果放在网络存储上这个时间可能翻好几倍。网络方面如果做多机推理节点间至少需要25Gbps以上的带宽。100Gbps RoCEv2是更理想的选择但需要交换机支持PFC和ECN配置起来有一定门槛。单机多卡的话NVLink内部通信就够了网络压力不大。3. 核心细节解析与实操要点3.1 PagedAttention到底解决了什么问题要理解vLLM为什么快得先搞明白传统KV Cache管理的痛点。在标准Transformer推理中每个请求的KV Cache需要预先分配一块连续显存大小等于最大序列长度乘以层数乘以注意力头维度。问题是大部分请求的实际生成长度远小于最大长度预分配的空间就白白浪费了。更麻烦的是不同请求的KV Cache大小不一显存碎片化严重最后可能总显存够但找不到连续的大块空间。PagedAttention的思路是把KV Cache切成固定大小的block比如每个block存16个token的KV。每个请求维护一个block table记录它用了哪些block。这些block在物理显存上不需要连续逻辑上通过block table映射成连续的序列。这个设计跟操作系统用页表管理虚拟内存是一个道理。带来的好处很直接显存浪费从预分配模式下的60%-80%降到4%以下同样硬件能同时服务的请求数翻了好几倍。而且因为block是固定大小显存分配和回收都很快不会产生碎片。提示vLLM的block size可以通过--block-size参数调整默认是16。调大能减少block table的管理开销但内部碎片会增加调小则相反。大多数场景下默认值就够用除非你有特别的序列长度分布。3.2 张量并行的切分策略与通信开销当单卡显存装不下模型时张量并行TP是最常用的方案。它的做法是把每一层的权重矩阵按维度切分到多张卡上每张卡计算一部分然后通过All-Reduce通信把结果汇总。比如一个注意力层的QKV投影矩阵可以按列切分成N份每张卡负责一份。TP的通信开销跟切分数量成正比。2卡TP的通信量是单卡的1倍4卡就是3倍。所以TP不是越多越好一般建议控制在8卡以内。超过8卡通信开销的增长会超过计算收益整体吞吐反而下降。实际配置中--tensor-parallel-size这个参数要跟你的卡数匹配。比如4张A100可以设成4也可以设成2然后跑两个实例。哪种更好取决于你的请求模式如果请求的序列长度差异很大两个TP2的实例可能比一个TP4的实例吞吐更高因为调度粒度更细。# 4卡TP4的启动命令 python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --tensor-parallel-size 4 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --port 80003.3 量化方案的选择与精度权衡量化是降低显存占用的另一条路。vLLM支持AWQ、GPTQ、FP8等多种量化格式。AWQ和GPTQ是4bit量化能把显存占用降到FP16的1/4左右但精度损失因模型而异。FP8是8bit量化精度损失更小但需要H100/H800这种支持FP8的硬件。我实测过几个模型在AWQ 4bit下的表现大部分场景下跟FP16的差异肉眼很难分辨但在需要精确推理的任务上比如数学计算、代码生成4bit量化的错误率会明显上升。所以我的建议是对话类应用可以放心用4bit推理密集型任务还是老老实实上FP16或者FP8。量化方案显存节省精度损失硬件要求适用场景FP16基准无所有通用FP850%极小H100/H800推理密集AWQ 4bit75%中等所有对话GPTQ 4bit75%中等所有对话注意量化模型的加载需要对应的量化配置AWQ模型在加载时要指定--quantization awq否则会报错。另外不是所有模型都有现成的量化版本自己量化需要额外的校准数据集和计算资源。4. 实操过程与核心环节实现4.1 环境搭建与依赖安装环境这块我踩过最大的坑就是CUDA版本和PyTorch版本的匹配。vLLM对版本比较敏感官方推荐用CUDA 12.1以上配PyTorch 2.1以上。如果你用conda装建议直接创建一个干净的环境别在已有环境上折腾依赖冲突能让你怀疑人生。# 创建虚拟环境 conda create -n vllm python3.10 -y conda activate vllm # 安装vLLM会自动拉取匹配的PyTorch pip install vllm # 验证安装 python -c import vllm; print(vllm.__version__)如果网络环境受限可以用国内镜像源加速。但要注意有些镜像源同步不及时可能拉不到最新版本。我一般用清华源大部分时候没问题。pip install vllm -i https://pypi.tuna.tsinghua.edu.cn/simple安装完成后建议跑一个简单的推理测试确认环境没问题。用vLLM自带的示例脚本就行加载一个小模型比如Qwen-7B生成几句话看看输出是否正常。4.2 模型下载与格式转换模型下载是个体力活几十GB的文件从HuggingFace拉下来网络不稳的时候能下一整天。我一般用huggingface-cli配合--resume-download参数断了能续传。# 安装huggingface-cli pip install huggingface_hub # 下载模型支持断点续传 huggingface-cli download Qwen/Qwen-7B-Chat \ --local-dir /data/models/Qwen-7B-Chat \ --resume-download如果模型是safetensors格式vLLM可以直接加载不需要转换。但如果是PyTorch的bin格式建议转成safetensors加载速度更快安全性也更好。转换脚本HuggingFace提供了几行代码的事。from safetensors.torch import save_file import torch # 加载bin格式权重 state_dict torch.load(pytorch_model.bin, map_locationcpu) # 保存为safetensors save_file(state_dict, model.safetensors)提示下载大模型前先确认磁盘空间一个70B模型FP16格式大约140GB加上转换过程中的临时文件建议预留300GB以上空间。4.3 服务启动参数详解与调优启动vLLM服务时有几个参数直接决定了服务的性能和稳定性我逐个说一下我的理解。--gpu-memory-utilization控制vLLM能使用的显存比例默认0.9。这个值不能设太高因为CUDA本身和一些中间操作需要预留显存设成0.95以上容易OOM。但也不能太低否则KV Cache空间不够并发上不去。我一般设0.85到0.9之间根据实际显存大小微调。--max-model-len是模型支持的最大序列长度。这个值设得越大KV Cache占用的显存越多。如果你的业务场景输入输出都在2K token以内就没必要设成8K白白浪费显存。我一般会统计一下线上请求的序列长度分布取P99值再留一点余量。--max-num-seqs控制同时处理的最大请求数。这个值跟显存大小和序列长度有关。显存充足时可以设大一些比如256显存紧张时设小一些比如64。vLLM会根据实际显存动态调整但设一个上限能防止突发流量把显存打满。# 生产环境启动示例 python -m vllm.entrypoints.openai.api_server \ --model /data/models/Qwen-7B-Chat \ --tensor-parallel-size 2 \ --gpu-memory-utilization 0.88 \ --max-model-len 4096 \ --max-num-seqs 128 \ --served-model-name qwen-7b \ --port 8000 \ --host 0.0.0.0启动后可以用curl测试一下服务是否正常。curl http://localhost:8000/v1/completions \ -H Content-Type: application/json \ -d { model: qwen-7b, prompt: 你好请介绍一下你自己, max_tokens: 100, temperature: 0.7 }4.4 压力测试与性能基线建立服务跑起来只是第一步知道它能扛多少并发才是关键。我一般用locust或者wrk做压测但这两个工具对LLM场景的支持不够直观后来换成了vLLM自带的benchmark脚本。# 使用vLLM benchmark工具 python -m vllm.benchmarks.benchmark_serving \ --backend openai \ --base-url http://localhost:8000 \ --model qwen-7b \ --num-prompts 1000 \ --request-rate 10这个脚本会模拟不同请求速率下的表现输出吞吐量、延迟分布等关键指标。我一般会跑几轮从低速率开始逐步加压找到吞吐量开始下降的拐点那个点就是当前配置下的最优工作负载。压测时重点关注两个指标Time to First TokenTTFT和Time per Output TokenTPOT。TTFT反映的是用户等待第一个字出来的时间TPOT反映的是生成速度。对话场景下TTFT更重要因为用户对首字延迟很敏感批量生成场景下TPOT更关键因为它决定了整体完成时间。注意压测时不要用生产环境正在服务的实例压测流量会挤占正常请求的资源。最好单独起一个实例做压测或者选择业务低峰期进行。5. 常见问题与排查技巧实录5.1 显存溢出OOM的排查思路OOM是部署vLLM时最常见的问题没有之一。报错信息一般是CUDA out of memory但背后的原因可能有好几种。第一种是模型本身太大单卡装不下。这种情况看报错时显存缺口有多大如果只差几个GB可以尝试降低--gpu-memory-utilization或者启用量化。如果差得太多就得考虑TP或者换卡了。第二种是KV Cache空间不足。表现是服务能启动但并发一上来就OOM。这时候要检查--max-model-len和--max-num-seqs是不是设得太激进。我遇到过一个案例max-model-len设了32K但实际业务请求平均长度不到1K白白浪费了大量显存给KV Cache预留。改成4K后并发能力直接翻倍。第三种是显存碎片化。长时间运行后显存分配器可能产生碎片导致明明总显存够但分配失败。vLLM的PagedAttention本身就是为了解决碎片问题设计的但如果你的服务跑了很久没重启还是可能遇到。定期重启服务是个简单有效的办法。# 查看GPU显存使用情况 nvidia-smi # 更详细的显存分配信息 python -c import torch; print(torch.cuda.memory_summary())5.2 推理速度慢的优化方向推理速度慢可能出在多个环节需要逐层排查。先看是不是模型加载的问题。如果每次请求都重新加载模型那肯定慢。vLLM默认会把模型常驻显存不会重复加载。检查一下启动日志确认模型只加载了一次。再看是不是batching没生效。vLLM的Continuous Batching需要一定并发量才能体现优势如果请求是串行的每个请求单独处理那跟普通推理没区别。可以适当增加客户端并发数让vLLM有机会做batch。然后看是不是序列太长。长序列的注意力计算是O(n²)复杂度序列长度翻倍计算量翻四倍。如果业务允许尽量控制输入输出长度。实在需要长序列可以考虑用FlashAttention或者PagedAttention的优化版本。最后看是不是通信瓶颈。多卡TP场景下卡间通信如果走PCIe而不是NVLink通信开销会很大。用nvidia-smi topo -m可以查看卡间互联类型确认是不是NVLink。现象可能原因排查方法解决方向TTFT高请求排队看队列长度增加实例或降低并发TPOT高计算瓶颈看GPU利用率量化或换卡吞吐低batch小看batch size增加并发请求波动大显存碎片看显存分配重启服务5.3 服务稳定性保障经验生产环境的稳定性和实验室跑demo是两码事。我总结了几个保障稳定性的关键点。健康检查必须做。vLLM提供了/health接口Kubernetes的liveness probe可以配这个。但要注意模型加载期间服务是不可用的健康检查要设置足够的初始延迟否则容器会被反复重启。日志要收集全。vLLM的日志包括请求日志、错误日志、性能日志分开收集方便排查。我一般用ELK或者Loki做日志聚合出问题时能快速定位。监控要到位。除了常规的CPU、内存、GPU监控还要监控vLLM特有的指标比如运行中的请求数、等待队列长度、KV Cache使用率。这些指标能提前预警容量问题。提示vLLM暴露了Prometheus格式的metrics接口路径是/metrics。配一个Prometheus抓取任务再配几个告警规则能省很多半夜起来处理故障的麻烦。5.4 模型更新与版本管理业务迭代过程中模型更新是常态。怎么做到不中断服务地更新模型是个需要提前设计的问题。最简单的方案是蓝绿部署。起一个新版本的实例等它加载好模型、健康检查通过后把流量切过去然后下线旧实例。这个方案需要双倍资源但切换过程平滑回滚也快。资源紧张的话可以用滚动更新。逐个替换实例每次只更新一个更新完确认没问题再更新下一个。这个方案资源占用少但更新期间服务容量会下降需要评估业务能否接受。模型文件的管理建议用版本号区分别用latest这种模糊的标签。每次更新记录清楚模型版本、量化方式、启动参数出问题时能快速回滚到已知可用的版本。# 模型目录结构建议 /data/models/ ├── qwen-7b-chat/ │ ├── v1.0-fp16/ │ ├── v1.1-awq/ │ └── v1.2-fp8/ └── qwen-14b-chat/ ├── v1.0-fp16/ └── v1.1-awq/6. 一些掏心窝子的实操心得部署vLLM这件事说难不难说简单也不简单。框架本身已经把很多复杂的东西封装好了但生产环境的各种边界情况还是得自己趟。我最大的体会是别一上来就追求极致性能先把服务跑通、跑稳再逐步调优。很多性能问题不是调参能解决的而是架构设计阶段就埋下的。另外压测数据只能参考不能全信。实验室环境跟生产环境的请求模式差异很大线上真实的序列长度分布、并发模式、错误率都跟压测脚本模拟的不一样。我一般会在生产环境先小流量灰度观察真实表现后再逐步放量。最后说个容易被忽略的点文档。部署过程中遇到的每个问题、每个参数的调整理由、每次故障的处理过程都值得记录下来。过几个月再回头看这些记录能帮你省下大量重新摸索的时间。团队里其他人接手时也能快速上手。
