vLLM部署大模型踩坑实录：吞吐量从30到800的调优之路

三周前，我们的AI服务还在一台单卡4090上"苟延残喘"：8个并发就把机器打满，单用户等回复要十几秒，被业务同事吐槽"人工智障"。这三周我做了一件事——把推理服务从简单的Transformers脚本迁移到vLLM，并做了一轮深度调优，最终把吞吐量从约30 token/s 干到了800 token/s（8卡并行），延迟从十几秒压到2秒内。这篇把踩坑和调优过程完整写下来。

一、背景：为什么一开始那么慢

最初的架构很简单：Docker里跑Transformers的generate接口，单卡4090，模型是Qwen2.5-14B（4bit量化）。问题是：

1. 无批处理：每个请求独占显卡推理，并发一上来就排队；
2. 无优化：默认动态图执行，没有用CUDA Graph、没有page attention；
3. 单卡：14B模型在一张4090上，单请求生成也就30-40 token/s，8并发直接雪崩。

二、第一步：迁移到vLLM（提升5倍）

把Transformers换成vLLM，同样的单卡，效果立竿见影：

vllm serve ./qwen-14b-awq \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.92 \
  --port 8000

vLLM的PagedAttention（按页管理KV Cache，消除显存碎片）和Continuous Batching（动态把多个请求拼进一个batch）两个机制，让单卡4090的并发吞吐直接翻了5倍，从30 token/s 提到约150 token/s。这是投入产出比最高的一步——换框架，零代码改动。

三、第二步：多卡并行（吞吐再翻5倍）

单卡再优化也有限，我们把服务扩到8卡（2台4卡服务器），用vLLM的张量并行（TP）：

vllm serve ./qwen-14b-awq \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.92 \
  --port 8000

注意是每台机器4卡张量并行，两台机器分别起服务，前面挂负载均衡，而不是跨机器的张量并行——跨机TP的网络开销会吃掉收益，这是第一个大坑。

8卡之后，实测并发吞吐达到约800 token/s，单请求延迟稳定在2秒以内，总算能满足业务了。

四、第三步：细粒度调优（锦上添花）

多卡之后还有几个可以榨的油水：

1. 开启CUDA Graph

在vLLM参数里加--enforce-eager的反面——默认开CUDA Graph捕获，减少kernel启动开销。单请求延迟能再降10-15%。

2. 用AWQ/GPTQ量化替代GGUF

同样是4bit，AWQ量化的吞吐和显存效率比GGUF高一个档次（GGUF主要在llama.cpp系生态里更有优势）。迁移后同样卡数吞吐又涨了一截。

3. 调整max-model-len

业务里大部分请求上下文在2K以内，我把max-model-len从8192降到4096，显存占用下降，能塞进更大的batch，吞吐再涨约10%。注意：改这个要评估好业务最长上下文，别为了性能砍掉长文档场景。

4. 用LMCache/prefix caching（进阶）

相同前缀的请求（比如同样的系统提示词）可以复用KV Cache，实测相同系统提示词的场景下吞吐提升15-20%。vLLM的--enable-prefix-caching直接开启。

五、监控：调优没有监控就是盲人摸象

这轮调优能顺利推进，离不开监控。我配了：

• Prometheus + vLLM内置metrics：采集GPU利用率、吞吐量、队列长度、P99延迟；
• Grafana看板：压测时实时看每个指标的变化；
• wrk/locust压测：每个优化项前后各跑一轮，用数据说话，不靠感觉。

调优决策全部基于监控数据：比如看到"GPU利用率只有60%"，说明batch没打满，就调大max-num-seqs（batch上限）；看到"队列堆积"，说明并发超过能力，就加机器而不是硬调参数。

六、最终效果汇总

七、踩坑清单（重点收藏）

1. 跨机张量并行是大坑：网络延迟会吃掉并行收益，多机用"每机TP+前端LB"方案；
2. CUDA版本必须匹配：vLLM对CUDA版本敏感，装错版本启动就报错，建议用官方提供的Docker镜像；
3. 显存分配别拉满：gpu-memory-utilization设0.92留一点余量给CUDA context，拉满1.0容易OOM；
4. 量化格式要匹配推理框架：AWQ给vLLM用、GGUF给llama.cpp用，别混；
5. 压测要贴近真实负载：用真实的请求长度分布压测，纯短文本压测会高估性能。

八、总结

这次调优给我最大的启发是：大模型推理性能是个系统工程，框架选型（vLLM vs Transformers）是第一杠杆，并行规模是第二杠杆，量化、缓存、参数是第三杠杆。每一步都有数据支撑，每一步都踩了真实存在的坑。如果你的AI服务也面临"慢、并发低"的问题，建议按这个顺序排查：先换框架，再上并行，最后微调参数——大概率能让你省下几个通宵。