用vLLM部署Qwen3-32B：吞吐和首token延迟调优手记

咨询发布

硬件和起步

公司上周要上线一个 32B 的推理服务，预算只能批 4 张 H20。试了 TGI、SGLang、vLLM 三个推理框架，最后选 vLLM，吞吐最高，调优手记分享一下。模型用 Qwen3-32B-Instruct，AWQ 4bit 量化版，每张 H20 显存 96G，4 卡放得下。

• vLLM 0.6.5 + PyTorch 2.5 + CUDA 12.4
  
• 启动参数：--tensor-parallel-size 4 --gpu-memory-utilization 0.92 --max-model-len 8192
  
• 关键开关：--enable-prefix-caching --enable-chunked-prefill
  

调优过程

第一版跑下来 RPS 只有 18，首 token 延迟 1.4 秒，惨不忍睹。用 benchmark_throughput.py 测了一下，瓶颈在 KV cache，默认 0.9 利用率下预留给 activations 的空间不够，OOM 反复触发 prefix cache 失效。

把 gpu-memory-utilization 提到 0.92，max-model-len 从 32K 砍到 8192（业务确实用不到长上下文），KV cache 槽位数从 4100 涨到 14800，吞吐直接翻两倍。再开 --enable-chunked-prefill，长 prompt 切成 512 token 块预填，首 token 延迟从 1.4s 压到 280ms。

结果

最终 RPS 58，平均延迟 220ms，首 token 延迟 280ms，对比基线提升三倍多。监控推荐用 Prometheus + vLLM 自带的 /metrics 接口，关键看 vllm:num_requests_waiting 和 vllm:gpu_cache_usage_perc，前者超 0 就是有请求在排队，后者长期低于 0.6 说明 KV cache 配小了可以再开大。

踩过的坑

一是 prefix caching 对 system prompt 不变的场景收益巨大（我们的 system prompt 有 1.2K token，缓存命中后吞吐再涨 30%），但 prompt 动态变化时会反向劣化；二是 AWQ 量化版 vLLM 默认不支持 TP>1，要手动加 --quantization awq_marlin 走 Marlin kernel；三是 H20 的 HBM3e 带宽比 H100 低 15%，纯算子 benchmark 看不出来差距，端到端服务会显现。

过期奶北岛

楼主说的这个我也踩过，一开始图省事，结果后面返工的时间比省下的还多。

慢半拍拾光

我之前也研究过这个方向，最后放弃了，主要是我这边数据量根本不够。

浅夏小筑

我关注的另一个点是稳定性，出问题的时候排查链路比传统方案长不少，得有心理准备。

远山笔记

成本这块还可以再拆细一点，隐性的人力投入其实占大头。

言默说事

这个结论我保留意见，至少在我们行业不太成立，可能跟样本有关。

寻梅柚子

看完想补充一点：数据合规这块千万别忽略，我们就是因为这个卡了很久。

野渡48

这篇看完最大的收获是那句"先算清楚自己的量"，很多人上来就冲设备，最后闲置。

半盏

这篇讲得比我之前看到的都实在，没那么多虚的，赞一个。

秋刀小筑

有个疑问，你说的这个方案在并发高的时候会不会有明显衰减？我这边测试过不太稳。