用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 看不出来差距，端到端服务会显现。
https://www.metk.cn/img/posts/vllm_qwen3_32b_deploy.jpg 楼主说的这个我也踩过，一开始图省事，结果后面返工的时间比省下的还多。 我之前也研究过这个方向，最后放弃了，主要是我这边数据量根本不够。 我关注的另一个点是稳定性，出问题的时候排查链路比传统方案长不少，得有心理准备。 成本这块还可以再拆细一点，隐性的人力投入其实占大头。 这个结论我保留意见，至少在我们行业不太成立，可能跟样本有关。 看完想补充一点：数据合规这块千万别忽略，我们就是因为这个卡了很久。 这篇看完最大的收获是那句"先算清楚自己的量"，很多人上来就冲设备，最后闲置。 这篇讲得比我之前看到的都实在，没那么多虚的，赞一个。 有个疑问，你说的这个方案在并发高的时候会不会有明显衰减？我这边测试过不太稳。