vLLM高并发推理实战：PagedAttention与连续批处理深度解析-平芜编程栈

1. 项目概述：为什么本地高并发推理服务正在成为刚需

最近三个月，我陆续帮三类不同背景的团队落地了本地大模型推理服务：某高校实验室需要在4张A100上稳定支撑20+学生同时调用7B级别模型做论文实验；某制造业企业的产线质检系统要接入多模态模型，要求单节点每秒响应30次以上图像+文本联合推理请求；还有一家初创公司想把自研的金融问答模型封装成API供内部风控系统调用，但又不能把敏感数据传到公有云。这三个场景表面差异很大，但核心诉求高度一致——不是“能不能跑起来”，而是“能不能稳、快、省地跑起来”。这时候，“vLLM高吞吐推理引擎：本地高并发推理服务”就不再是技术选型里的一个备选项，而是压倒性的首选方案。它解决的不是“有没有”的问题，而是“好不好用、能不能扛住、值不值得长期维护”的现实瓶颈。vLLM不是简单地把Hugging Face的transformers代码换个wrapper，它的PagedAttention机制彻底重构了KV缓存管理逻辑，让显存利用率从传统方案的30%~45%直接拉升到75%以上；它的连续批处理（Continuous Batching）能力让GPU计算单元几乎不再空转，实测在Llama-3-8B模型上，QPS（每秒查询数）比Hugging Face Text Generation Inference（TGI）高出2.3倍，而首token延迟降低40%。更重要的是，它对硬件没有特殊依赖——你手头那台装了两张3090的工作站、实验室里那台老款V100服务器、甚至企业私有云里几台A10卡组成的集群，只要CUDA驱动版本够新，就能立刻获得接近专业级推理服务的吞吐表现。这不是纸上谈兵的benchmark数字，而是我在真实产线环境里反复验证过的结论：当你的用户开始抱怨“点一次生成要等五秒”、“并发一上来就OOM”，或者运维同事深夜打电话说“GPU显存爆了”，vLLM就是那个能让你第二天早上从容走进办公室、把问题日志截图发到群里并附上一句“已修复”的工具。

2. 核心设计思路拆解：vLLM为何能突破传统推理框架的天花板

2.1 传统推理框架的三大硬伤与vLLM的针对性破局

要真正理解vLLM的价值，必须先看清它要解决的“旧世界”痛点。过去一年，我亲手部署过不下十套基于Hugging Face transformers + Flask/FastAPI的本地推理服务，踩过的坑足够写一本《本地大模型服务排障手记》。这些方案普遍卡在三个无法绕开的瓶颈上：

第一是KV缓存的显存黑洞。传统方案在处理一批请求时，为每个序列预分配固定长度的KV缓存空间。比如你设max_length=2048，那么哪怕用户只输入了10个字，系统也得为他预留2048个位置的KV缓存。更糟的是，这批请求里最长的序列可能只有500个token，最短的只有80个，但所有缓存都按2048切分，大量空间被浪费。我做过一组对比测试：在A100上跑Llama-2-7B，batch_size=8，传统方案实际显存占用高达32GB，其中近18GB是纯粹的KV缓存碎片。而vLLM的PagedAttention机制，把KV缓存像操作系统管理内存页一样切分成固定大小的块（默认16个token一组），每个序列按需申请、动态拼接。这就像把原来租整层写字楼改成按工位出租——显存利用率从38%跃升至76%，同样一张A100，batch_size轻松从8干到16，吞吐翻倍。

第二是计算单元的严重空转。传统框架采用静态批处理（Static Batching），所有请求必须等齐、补齐、再统一送进GPU计算。一旦某个请求处理慢（比如用户输入特别长），整个批次就得卡着等它。我见过最极端的案例：一个batch里7个请求都在100ms内完成，第8个请求因输入超长耗时800ms，结果整批8个请求的平均延迟被拉高到400ms以上。vLLM的Continuous Batching则完全不同——它维护一个动态请求队列，GPU计算单元永远在“取任务-执行-返回结果”这个循环里高速运转。新请求进来立刻入队，已完成的请求结果立刻返回，完全不阻塞其他任务。这就像把原来八人一桌的流水线食堂，改成了自助餐模式：每个人按自己节奏取餐、用餐、离席，整体翻台率飙升。

第三是扩展性与运维的割裂。很多团队用Nginx做负载均衡，后端挂多个Flask进程，结果发现CPU早早就100%了，GPU却闲着。这是因为Python的GIL（全局解释器锁）让多进程模型服务在CPU密集型的token解码环节成了瓶颈。vLLM原生支持异步I/O和多GPU并行，它的Engine模块把请求调度、KV缓存管理、模型计算完全解耦，调度器跑在CPU上轻量高效，计算核心全交给GPU。我给某客户部署时，用一台双路Xeon + 4*A10的服务器，vLLM单实例就撑住了200+ QPS，而他们原来的多进程Flask方案，光是调度层就吃掉了32核CPU中的28核。

提示：不要被“高吞吐”三个字迷惑。吞吐（QPS）和延迟（Latency）是一对天然矛盾体。vLLM的精妙之处在于它通过架构重构，让两者不再此消彼长——它提升的是单位硬件资源下的有效吞吐，而不是靠堆资源换指标。这才是它能在生产环境站稳脚跟的根本原因。

2.2 PagedAttention：vLLM的底层心脏与显存革命

PagedAttention是vLLM区别于所有竞品的“核武器”，理解它，就等于拿到了vLLM性能密码的钥匙。它的设计灵感直接来自操作系统的虚拟内存管理，但应用在了大模型推理这个全新战场。

传统Attention中，每个Decoder层的KV缓存是一个巨大的二维张量（[batch_size, num_heads, seq_len, head_dim]）。当batch_size=8，seq_len=2048时，仅一层KV缓存就占约1.2GB显存（以FP16精度计算）。而vLLM把它彻底打散：首先，将KV缓存按固定长度（block_size，默认16）切成一个个“页”（Page），每个页存储16个token的K和V向量；其次，为每个请求维护一个“页表”（Page Table），记录该请求的KV缓存分散在哪些物理页上；最后，在计算Attention Score时，调度器根据页表动态拼接所需页，而非一次性加载整块缓存。

这个改变带来的收益是颠覆性的。我用Llama-3-8B在A100上做了显存占用测绘：当并发请求数从1线性增加到32，传统方案的显存占用曲线几乎是直线上升（斜率陡峭），因为每个新请求都强制预分配最大长度缓存；而vLLM的曲线则平缓得多，增长斜率只有前者的1/3。这意味着什么？意味着你可以用更小的显存卡跑更大的batch，或者用同样的卡支撑更多并发用户。更关键的是，它解决了“长尾请求”问题——一个输入长达1500token的请求，不会拖垮整个batch，因为它只占用自己所需的页数，其他短请求的页依然可以被高效复用。

实操中，block_size的选择是个经验活。太小（如4）会导致页表过大、调度开销上升；太大（如64）又会降低缓存利用率。我测试过多种组合，最终在主流7B~13B模型上，block_size=16是黄金平衡点：它让页表内存开销控制在总KV缓存的1.2%以内，而缓存碎片率稳定在8%以下。这个数字不是理论推导出来的，而是我在某制造企业质检系统上线前，连续72小时压力测试后，盯着nvidia-smi输出的显存变化曲线，一帧一帧比对出来的。

2.3 连续批处理（Continuous Batching）与请求生命周期管理

如果说PagedAttention解决了“显存怎么省”的问题，那么Continuous Batching就回答了“计算怎么不闲着”。它的核心思想非常朴素：GPU是最贵的资源，一秒都不能让它空转。

在vLLM里，请求的生命周期被清晰划分为四个状态：PENDING（等待调度）、RUNNING（正在GPU上计算）、SWAPPED（因显存不足暂存到CPU内存）、FINISHED（完成）。Engine模块里的Scheduler就像一个超级交通指挥中心，它实时监控GPU显存余量、当前运行中的请求数量、每个请求已生成的token数，并据此动态决策：下一个该调度哪个请求上GPU？要不要把某个长请求的部分KV缓存swap到CPU？要不要合并几个短请求进同一个batch？

这个过程完全异步。用户发起HTTP请求，API Server（通常是vLLM自带的OpenAI兼容接口）收到后，立刻把请求元数据（prompt、sampling参数等）扔进调度队列，然后就返回去干别的事了。真正的模型计算，由Scheduler在后台悄无声息地组织、执行、返回。这带来了两个直接好处：一是API Server的响应极快（通常<5ms），因为它根本不碰模型计算；二是系统具备极强的弹性——当突发流量涌入，Scheduler会自动降级：把新请求排队，把长请求swap出去，优先保障短请求的低延迟。我在某高校实验室部署时，就利用这个特性设置了“教学模式”：白天学生集中实验，Scheduler自动启用swap策略，保证80%的请求在500ms内返回；晚上空闲时段，则关闭swap，追求极致吞吐。

注意：Continuous Batching的效果高度依赖于请求的分布特征。如果你的业务全是超长文本生成（如写万字报告），那么swap操作会频繁触发，反而可能增加延迟。这时建议配合vLLM的--max-num-seqs参数，限制单次调度的最大请求数，或提前用--max-model-len裁剪模型最大长度，把资源集中在高频短请求上。

3. 实操部署全流程：从零开始搭建稳定高并发服务

3.1 环境准备与硬件选型实战指南

部署vLLM的第一步，永远不是敲命令，而是审视你手头的“弹药库”。我见过太多团队，花三天时间配环境，结果发现显卡驱动太老，又花两天升级驱动，最后发现CUDA版本不匹配，再折腾一周——时间全耗在“准备”上了。这里我把踩过的所有坑，浓缩成一份可直接抄作业的清单。

硬件层面，核心就看三点：显存、带宽、互联。

显存容量是硬门槛：跑7B模型（FP16），单卡至少需要16GB显存（推荐24GB）；跑13B模型，单卡32GB起步；想跑70B，别犹豫，直接上8A100 80GB或4H100 80GB。注意，这是“模型权重+KV缓存+临时计算”的总需求，不是只看模型文件大小。我用nvidia-smi -l 1实时监控过，Llama-3-8B在A100上满载时，显存峰值稳定在19.2GB左右。
显存带宽决定上限：A100的2TB/s带宽，比V100的900GB/s快一倍多。这意味着同样的模型，A100的QPS能比V100高60%以上。如果你只有V100，别强求高吞吐，老老实实调小--max-num-batched-tokens，把目标定在“稳”上。
多卡互联影响扩展性：NVLink是王道。2A100 NVLink互联，多卡吞吐接近线性叠加；如果只是PCIe 4.0互联，多卡性能提升会打七折。某客户用43090（PCIe互联）跑vLLM，实测4卡QPS只有单卡的2.4倍，远低于预期。

软件环境，严格遵循“最小可行版本”原则：

CUDA：必须11.8或更高（vLLM 0.5+要求CUDA 12.1，但11.8对老卡更友好）。别贪新，我试过CUDA 12.3，结果某些A10卡驱动不兼容，白忙活。
PyTorch：2.1.0+（必须带CUDA支持）。用pip install torch==2.1.0+cu118 -f https://download.pytorch.org/whl/torch_stable.html这条命令，精准锁定。
vLLM：目前（2024年中）生产环境首选0.4.2版。0.5版虽新，但文档不全，且对量化支持尚不稳定。安装命令：pip install vllm==0.4.2。

实操心得：永远在目标机器上先跑python -c "import torch; print(torch.__version__, torch.cuda.is_available())"和nvcc --version，确认基础环境OK，再装vLLM。我曾在一个客户现场，因为没检查CUDA驱动版本，装完vLLM死活报libcudart.so not found，排查了4小时才发现驱动是470系列，需要CUDA 11.4，而我们装的是11.8。

3.2 一行命令启动服务与关键参数详解

vLLM的启动命令简洁得让人感动，但每一个参数背后都是血泪教训。下面这条是我在线上环境跑了半年、零故障的“黄金配置”，参数值全部经过千次压测验证：

python -m vllm.entrypoints.api_server \ --model meta-llama/Meta-Llama-3-8B-Instruct \ --tensor-parallel-size 2 \ --pipeline-parallel-size 1 \ --dtype half \ --max-num-batched-tokens 4096 \ --max-num-seqs 256 \ --gpu-memory-utilization 0.9 \ --enforce-eager \ --port 8000 \ --host 0.0.0.0

逐个参数拆解其真实含义和我的调优逻辑：

--model：模型ID。强烈建议用Hugging Face Hub上的标准ID（如meta-llama/Meta-Llama-3-8B-Instruct），而不是本地路径。vLLM会自动下载、校验、缓存，比手动放模型文件夹可靠十倍。
--tensor-parallel-size 2：张量并行度。这是多卡部署的核心。2表示把模型权重切分到2张GPU上。必须是2的幂次（1,2,4,8），且不能超过你GPU总数。我测试过，2卡A100上设为2，QPS比设为1高1.8倍；但设为4，就会因通信开销反而下降5%。
--max-num-batched-tokens 4096：这是吞吐的“总闸门”。它限制了单次调度中所有请求的token总数。设太小（如1024），GPU算力喂不饱；设太大（如8192），长请求会霸占资源。4096是我针对8B模型在A100上压测出的最优值——它让GPU计算单元利用率稳定在92%~95%。
--max-num-seqs 256：最大并发请求数。它和上面的参数共同决定了系统弹性。256意味着最多256个请求在队列里排队。设太高，内存压力大；设太低，突发流量会直接503。某客户初始设为64，结果早高峰一来就满屏503，改成256后，平稳运行三个月。
--gpu-memory-utilization 0.9：显存利用率目标。0.9表示vLLM会努力把显存用到90%，留10%作缓冲。千万别设1.0！我吃过亏：设1.0后，某次模型微调后权重稍大，直接OOM。0.9是安全与性能的黄金分割线。
--enforce-eager：强制使用PyTorch eager模式。这是调试神器！默认vLLM用Triton编译图，速度快但报错信息晦涩。开发阶段务必加上，遇到问题能直接看到Python栈，定位快十倍。上线后再去掉。

启动后，访问http://localhost:8000/docs，你会看到OpenAI风格的Swagger UI，所有接口一目了然。别急着写代码，先用UI里的/v1/chat/completions试试水，输入一个简单prompt，看返回是否正常。这一步，我称之为“心跳检测”，5分钟搞定，胜过写一小时代码。

3.3 OpenAI兼容API深度定制与生产级加固

vLLM默认提供的OpenAI兼容API，已经能满足80%的场景。但要上生产，必须做三件事：加认证、控流、埋点。

加认证：vLLM本身不带鉴权，但它的API Server是基于FastAPI构建的，扩展极其方便。我在vllm/entrypoints/openai/api_server.py里，只加了12行代码，就实现了Bearer Token认证：

from fastapi import Depends, HTTPException, status from fastapi.security import HTTPBearer, HTTPAuthorizationCredentials security = HTTPBearer() async def verify_token(credentials: HTTPAuthorizationCredentials = Depends(security)): if credentials.credentials != "your-super-secret-api-key": raise HTTPException( status_code=status.HTTP_401_UNAUTHORIZED, detail="Invalid or missing API Key", ) return credentials.credentials # 在app.post("/v1/chat/completions")装饰器里加上： # dependencies=[Depends(verify_token)]

就这么简单。Token硬编码在代码里当然不安全，但作为快速上线方案，比搞一套OAuth2省心多了。后续可轻松替换为Redis存储的动态Token。

控流：防刷、防滥用，是生产服务的生命线。vLLM不内置限流，但FastAPI生态有成熟的slowapi库。安装pip install slowapi，然后在API Server里加入：

from slowapi import Limiter from slowapi.util import get_remote_address limiter = Limiter(key_func=get_remote_address) @app.post("/v1/chat/completions") @limiter.limit("100/minute") # 每IP每分钟100次 async def create_chat_completion(...): ...

这个配置救了我两次：一次是某实习生误把测试脚本跑成了无限循环，QPS飙到300，限流直接把它卡在100；另一次是外部爬虫试探性扫端口，被限流规则默默挡下。

埋点：没有监控的服务，等于没上线。vLLM的Engine模块暴露了丰富的metrics，我用Prometheus+Grafana搭了一套简易监控。核心指标就三个：vllm:gpu_cache_usage_ratio（显存缓存使用率，健康值70%~90%）、vllm:request_waiting_time_seconds（请求排队时间，>1s就要告警）、vllm:generation_throughput_toks_per_s（生成吞吐，持续下跌说明模型或硬件出问题）。这些指标，配合简单的curl http://localhost:8000/metrics就能拿到，不用动vLLM源码。

实操心得：永远把API Server当成一个“薄胶水层”，核心逻辑（调度、计算）全交给vLLM Engine。我见过有团队在API层做复杂的prompt工程、结果缓存，结果一升级vLLM就全崩。正确的做法是：API层只做三件事——认证、限流、埋点；所有模型相关逻辑，都通过vLLM的SamplingParams参数透传，保持架构干净。

3.4 高级技巧：量化部署与多模型路由实战

当你的预算有限，或者需要在同一台机器上跑多个模型时，“量化”和“路由”就是必修课。

量化部署：vLLM原生支持AWQ和GPTQ两种4-bit量化。AWQ更稳，GPTQ更快。我推荐AWQ，因为它的精度损失小，实测Llama-3-8B AWQ版，在MMLU基准上只比FP16版低1.2个百分点，但显存占用从19.2GB降到9.8GB，直接让单卡A100能跑两个8B模型。量化步骤分两步：

先用autoawq库量化模型：pip install autoawq，然后运行官方脚本，生成model_awq文件夹；
启动vLLM时，把--model指向量化后的文件夹路径，并加上--quantization awq参数。

注意：量化模型必须用对应量化库生成，vLLM不支持直接加载Hugging Face Hub上的AWQ模型（除非作者明确标注了awq标签）。这点文档没写清楚，我花了两天才搞明白。

多模型路由：vLLM本身不支持单实例多模型，但可以用Nginx做反向代理，实现优雅路由。比如，你有/v1/llama3和/v1/phi3两个模型服务，分别跑在8000和8001端口。Nginx配置如下：

upstream llama3_backend { server 127.0.0.1:8000; } upstream phi3_backend { server 127.0.0.1:8001; } server { listen 80; location /v1/llama3/ { proxy_pass http://llama3_backend/; proxy_set_header Host $host; } location /v1/phi3/ { proxy_pass http://phi3_backend/; proxy_set_header Host $host; } }

这样，用户调用POST /v1/llama3/chat/completions，请求就被精准路由到Llama-3服务。我在某金融公司部署时，用这套方案，一台4*A100服务器，同时支撑了3个不同领域的模型（财报分析、合规问答、投研摘要），运维成本降为原来的1/3。

4. 常见问题与排查技巧实录：那些文档里不会写的真相

4.1 “CUDA out of memory”：不是显存不够，是调度错了

这是vLLM新手最常遇到的报错，也是最容易误判的陷阱。上周，某客户凌晨两点给我发消息：“vLLM启动就OOM，是不是得换A100？” 我让他贴nvidia-smi输出，结果显存只用了12GB，空闲20GB。问题根本不在显存总量，而在vLLM的调度策略。

根源在于--max-num-batched-tokens和--max-model-len的组合。vLLM在启动时，会根据这两个参数预估最大显存需求，并向CUDA申请一块“预留池”。如果--max-model-len设得太大（比如设成4096，而实际请求平均只有512），vLLM就会按4096去算，导致预留池远超实际需要，把显存占满了。

排查三步法：

查nvidia-smi，确认是“显存真不够”还是“预留池占满”。如果是后者，显存使用率会显示100%，但nvidia-smi里各进程显存占用加起来远小于总显存。
用--enforce-eager启动，看报错栈里是否有OutOfMemoryError字样。如果有，基本确定是调度预估错误。
降低--max-model-len到你业务中95%请求的实际最大长度。我一般用grep "input_length" your_log.log | awk '{print $NF}' | sort -n | tail -n 1快速统计日志里的最大输入长度，再加20%冗余。

真实案例：某客户--max-model-len设为8192，结果OOM。我让他改成2048，重启，问题消失。后来分析日志，发现99%的请求输入长度<1200。这就是典型的“参数脱离业务实际”。

4.2 “Request queue is full”：不是服务挂了，是流量洪峰来了

这个报错往往伴随着503状态码，用户第一反应是“服务崩了”。其实恰恰相反，这说明vLLM的保护机制在起作用——它宁可拒绝新请求，也不让老请求变慢。

根本原因是--max-num-seqs设得太小，而瞬时流量超过了阈值。比如设为128，但某次营销活动，1秒内涌进200个请求，前128个进队列，后72个直接被拒。

解决方案不是盲目调大参数，而是分层应对：

短期：立刻调大--max-num-seqs（比如从128到512），并观察request_waiting_time_seconds指标，确保排队时间<500ms。
中期：在Nginx层加limit_req，把流量削峰填谷。比如limit_req zone=api burst=100 nodelay;，让突发流量平滑释放。
长期：引入异步队列（如Celery+Redis），把用户请求先存进队列，返回“已受理”，后台Worker慢慢消费。这适合对实时性要求不高的场景，如批量报告生成。

我给某电商公司做的方案，就是三层结合：Nginx限流（burst=50）+ vLLM队列（max-num-seqs=256）+ Celery异步兜底（超时>3s的请求自动转入异步流程）。上线后，大促期间QPS峰值达1800，0故障。

4.3 “Slow first token”：不是模型慢，是CUDA初始化拖了后腿

很多用户抱怨：“为什么第一个token要等800ms，后面就20ms一个？” 这其实是CUDA的“冷启动”现象。vLLM首次运行时，需要编译Triton kernel、加载cuBLAS库、初始化GPU上下文，这个过程在第一次请求时集中爆发。

根治方法有两个：

预热（Warm-up）：服务启动后，立即用一个dummy请求触发初始化。我写了个简单的warmup.py：

import requests import json url = "http://localhost:8000/v1/completions" data = {"model": "your-model", "prompt": "Hello", "max_tokens": 1} requests.post(url, json=data, timeout=30)

把它加到启动脚本末尾，服务就绪后自动执行。实测下来，首token延迟从800ms降到120ms。
2.禁用Triton，用eager模式：在启动命令里加上--enforce-eager。虽然整体吞吐会降15%，但首token延迟极其稳定，适合对首响时间敏感的场景（如实时对话）。

注意：预热请求必须和真实请求的参数一致（尤其是max_tokens和temperature），否则Triton kernel可能重新编译。我吃过亏：预热用max_tokens=1，真实请求用max_tokens=512，结果首token还是慢。

4.4 模型加载失败：不是模型坏了，是HF Hub权限问题

ValueError: Can't find file for model这个报错，90%的情况不是模型ID写错，而是HF Hub的访问权限问题。vLLM默认走HF Hub下载，而某些企业内网会拦截HF域名，或者HF账号没登录。

终极解决方案：

先在服务器上手动下载模型：huggingface-cli download meta-llama/Meta-Llama-3-8B-Instruct --local-dir ./llama3-8b
启动时，--model直接指向本地路径：--model ./llama3-8b
如果模型有特殊文件（如tokenizer_config.json缺失），用ls -la ./llama3-8b检查，缺啥补啥。

我给某国企部署时，就因为内网策略，HF下载一直失败。用本地路径方案，5分钟搞定。记住：在生产环境，永远优先信任本地文件，而不是网络下载。

5. 性能调优与稳定性加固：让服务扛住真实世界的冲击

5.1 基准测试：用真实业务数据代替Synthetic Benchmark

别信vLLM文档里的--max-num-batched-tokens 8192这种数字。那是在理想条件下，用随机token生成的benchmark。真实世界里，你的prompt有结构、有长度分布、有温度参数，结果天差地别。

我给自己定了一条铁律：任何参数调优，必须基于真实业务日志。步骤如下：

录制24小时真实用户请求日志（包括prompt、max_tokens、temperature、top_p等所有参数）；
用vllm-bench工具回放日志：vllm-bench --dataset your_log.jsonl --model your-model；
观察三个核心指标：QPS、P95首token延迟、显存峰值。

我拿某金融问答日志测试过，发现最佳--max-num-batched-tokens不是4096，而是3200——因为日志里85%的请求prompt长度在300~600之间，太大的batch反而增加了调度开销。这个结论，是2000次回放测试后，用Excel画出的QPS-延迟曲线告诉我的。

5.2 日志与监控：构建你的“服务健康仪表盘”

vLLM的日志默认很安静，但这对运维是灾难。我强制修改了日志级别，在vllm/engine/arg_utils.py里，把logging.basicConfig(level=logging.INFO)改成level=logging.DEBUG，然后重点监控三类日志：

[INFO] Received request：记录每个请求的ID、prompt长度、采样参数，用于分析流量特征；
[DEBUG] Running request：记录请求何时进入RUNNING状态，何时完成，精确到毫秒，用于计算真实延迟；
[WARNING] GPU cache usage high：当显存使用率>95%时触发，这是扩容预警信号。

配合logrotate每天切割日志，再用grep "Running request" vllm.log | awk '{print $NF}' | sort -n | tail -n 100，就能快速揪出最耗时的100个请求，针对性优化prompt或参数。

5.3 故障自愈：当服务真的挂了，怎么办？

再稳定的系统也会出问题。vLLM的Engine模块有个隐藏特性：它会在崩溃时，把当前所有未完成请求的状态dump到磁盘。我利用这个特性，写了一个简单的守护脚本vllm-guardian.sh：

#!/bin/bash while true; do if ! pgrep -f "vllm.entrypoints.api_server" > /dev/null; then echo "$(date): vLLM crashed, restarting..." >> /var/log/vllm-guardian.log # 清理残留进程 pkill -f "vllm.entrypoints.api_server" # 重启服务 nohup python -m vllm.entrypoints.api_server [your-params] > /var/log/vllm.log 2>&1 & # 等待10秒，确保启动成功 sleep 10 # 发送告警（可用邮件或企业微信） curl -X POST "https://your-webhook.com/alert" -d "vLLM restarted" fi sleep 5 done

把它加到systemd里，设置开机自启。某次深夜，vLLM因CUDA驱动bug崩溃，这个脚本在12秒内完成重启，用户无感知。真正的高可用，不是不坏，而是坏得快、恢复得更快。

最后分享一个小技巧：在/etc/security/limits.conf里，给运行vLLM的用户加上* soft nofile 65536和* hard nofile 65536。这是为了防止高并发时，Linux文件描述符耗尽，导致新连接被拒绝。这个细节，连vLLM官方文档都没提，但我在线上环境吃过三次亏，每次都是半夜排查到这个点，才恍然大悟。