双卡 4090 部署 Qwen3.8-27B调优踩坑实录：从55tokens/s到“速度直接腰斩“，再到68~85tokens/s

目录开局我以为的最优配置第一坑改 FLASH_ATTN想恢复 FULL CUDA Graph第二坑BF16 KV速度直接腰斩第三坑GDN Decode Kernel 回退第四坑长 Prompt Prefill 导致服务器重启尝试 1nvidia-smi 功率墙-pl 150 / -pl 200尝试 2限制核心频率最终方案最终踩坑链条复盘三套配置的实测数据对比最终稳定配置vLLM nightly 0.26.1vLLM 0.27.2 升级展望待0.27.2发布后更新0.27 可能改变的变量经验总结硬件2× RTX 4090 24G (PCIe无 NVLink)模型Qwen3.8-27B INT4 (AWQ)vLLMdocker 环境0.20.2和0.26.1 (nightly cu129)测试负载实际工作对话和Agent数据分析工作核心矛盾消费级 GPU 上看着舒服的配置往往比warning 满天飞的配置慢一倍效果从最开始MTP的55tokens/s详见上一篇开启MTP的文章提升到平均68tokens/s峰值85tokens/s开局我以为的最优配置vllm serve /models \ --tensor-parallel-size 2 \ --kv-cache-dtype fp8 \ --speculative-config {method:mtp,num_speculative_tokens:2} \ --enable-prefix-caching \ --max_num_seqs 16 \ --gpu-memory-utilization 0.93 \ --max-model-len 262144预期MTP 加速 FP8 省显存 FlashInfer 最快 backend单流破百 tok/s。实际能跑但日志里飘出 7 个 warning。WARNING ... CUDAGraphMode.FULL_AND_PIECEWISE is not supported with spec-decode for attention backend FlashInferBackend ... setting cudagraph_modePIECEWISE INFO ... Falling back to the Triton GDN decode path: torch.ops._C.fused_gdn_decode_post_conv_mtp is not built WARNING ... Triton kernel JIT compilation during inference: precopy_mamba_align_fused_kernel WARNING ... Triton kernel JIT compilation during inference: _causal_conv1d_fwd_kernel ... WARNING ... Enabling num_speculative_tokens 1 will run multiple times... WARNING ... Add 3 padding layers, may waste at most 6.25% KV cache memory速度单流峰值 decode~80 tok/sprefill 峰值5016 tok/sMTP 平均接受长度2.7整体接受率84.9%。心理活动能跑但看着难受。PIECEWISE 是什么GDN 回退又是什么不行我得把这些 warning 清掉。这个心理活动是后面所有踩坑的开始。第一坑改 FLASH_ATTN想恢复 FULL CUDA Graph看到第一条 warning —— FlashInfer spec decode 不支持 FULL_AND_PIECEWISE问了KIMI换 backend换成FLASH_ATTN就可以走起vllm serve /models \ --tensor-parallel-size 2 \ --attention-backend FLASH_ATTN \ --kv-cache-dtype fp8 \ --speculative-config {method:mtp,num_speculative_tokens:2} \ ...结果直接报错启动失败。ValueError: Selected backend AttentionBackendEnum.FLASH_ATTN is not valid for this configuration. Reason: [fp8 KV cache requires FA3 on SM90 or FA4 on SM100]分析FLASH_ATTN (FA2/FA3) 在 Ampere (SM89即 4090) 上不支持 FP8 KV Cache。只有 Hopper (SM90) 或 Blackwell (SM100) 才有 FP8 KV 的 FA 路径。此时面临选择回退 FlashInfer接受 PIECEWISE 和那 7 个 warning保留 FLASH_ATTN但把 FP8 KV 换成 BF16我选了后者——试试行不行再说。第二坑BF16 KV速度直接腰斩vllm serve /models \ --tensor-parallel-size 2 \ --attention-backend FLASH_ATTN \ --speculative-config {method:mtp,num_speculative_tokens:2} \ ... # kv-cache-dtype 默认 auto BF16结果能跑CUDA Graph 确实恢复为FULL_AND_PIECEWISE日志里看到Capturing CUDA graphs (decode, FULL)warning 少了。速度单流 decode~31.7 tok/sprefill 峰值4230 tok/s。对比初始配置慢了将近一半。从日志看更明显FLASH_ATTN BF16decode 稳定在29–39 tok/sFlashInfer FP8decode 稳定在58–86 tok/s根因分析RTX 4090 上的 FP8 KV Cache 是storage-only——计算时仍会反量化为 BF16但读取数据量确实是 BF16 的一半。在 decode 这种 memory-bound 场景下这直接省了一半显存带宽。项目FP8 KVBF16 KVKV Cache 读取量1×2×4090 显存带宽~1008 GB/s~1008 GB/s实际占用带宽比例瓶颈但可接受直接打满成为绝对瓶颈INT4 权重已经把 weights 带宽压到极低此时 KV Cache 读取成为 decode 的绝对大头。BF16 KV 让这部分带宽直接翻倍而FULL_AND_PIECEWISE省下的 kernel launch 时间完全无法弥补这个差距。关键认知纠正在 4090 上FP8 KV 的价值不是Tensor Core 加速而是显存带宽节省 50%。这个节省比 FULL_AND_PIECEWISE 的图优化更有价值。第三坑GDN Decode Kernel 回退回到 FlashInfer 配置还有一条看着难受的 logFalling back to the Triton GDN decode path: torch.ops._C.fused_gdn_decode_post_conv_mtp is not builtfused_gdn_decode_post_conv_mtp是 vLLM 在 PR #51674约 2026-08-14中才引入的融合 CUDA kernel专门加速 GDN MTP 的 decode 阶段。nightly 0.26 尚未包含该 kernel因此回退到 Triton 链式调用。影响功能正确但 decode 延迟比融合 kernel 高1.2–2.2×。这也是 0.26 下 MTP 收益被部分抵消的原因之一。第四坑长 Prompt Prefill 导致服务器重启解决了 decode 速度问题后上线实测遇到更隐蔽的坑现象用户输入长 prompt4K tokens时prefill 阶段显卡功率瞬间飙高服务器直接重启。根因RTX 4090 标称 TDP 450W但 prefill 阶段 compute-bound电源虽然是1600W但是响应速度跟不上瞬时功率可能突破电源/主板供电极限尤其是双卡同时满载时。尝试 1nvidia-smi 功率墙-pl 150 / -pl 200nvidia-smi -pl 150 # 双卡各限 150W结果确实不重启了但 prefill 速度下降非常严重。而且发现功率墙只能50W 为步长设置设 200W 仍然会重启——说明功率墙有采样周期峰值功耗在采样间隔内已经冲高导致重启。尝试 2限制核心频率最终方案# 限制 GPU 核心频率上限为 2100 MHz nvidia-smi -lgc 0,2100验证过程2400 MHz长 prefill 仍会重启 ❌2100 MHz连续压测稳定不重启 ✅为什么比功率墙更好方案对 Prefill对 Decode速度影响功率墙 150W强制降频功率平滑频繁撞墙抖动大-50%频率锁 2100MHz频率封顶功率自然受限稳定跑在 2100无抖动-10~15%实测功率锁定 2100MHz 后双卡功率稳定在 180W 左右满载时稳定 180Wprefill时瞬间可达250W既避免了 450W 峰值冲击又比 150W 功率墙保留了更多性能。原理decode 阶段本来就是 memory-boundGPU 核心频率通常跑不满。把上限锁在 2100 MHz对 decode 影响很小而 prefill 阶段 compute-bound原本能飙到 2500 MHz现在被硬封顶瞬时功率被直接管住。最终踩坑链条复盘7 个 warning 看着难受 ↓ 改 FLASH_ATTN 恢复 FULL ↓ FP8 KV 报错被迫换 BF16 ↓ 速度直接腰斩31 tok/s ↓ 回到 FlashInfer接受 warning ↓ 上线实测长 prefill 功率过高服务器重启 ↓ 功率墙 150Wprefill速度暴跌 ↓ 改频率锁 2100MHzprefill 稳定功率 180W ↓ 最终配置FlashInfer FP8 MTP 频率锁 2100MHz三套配置的实测数据对比配置BackendKV CacheCUDA GraphMTP单流 DecodePrefill 峰值接受率结果初始FlashInferFP8PIECEWISE✅ MTP2~67.6 tok/s5016 tok/s84.9%⚠️ 7 warning第一坑FLASH_ATTNFP8—✅ MTP2 启动失败——❌ 不支持第二坑FLASH_ATTNBF16FULL✅ MTP2~31.7 tok/s4230 tok/s76.3%✅ 能跑但极慢当前最优FlashInferFP8PIECEWISE✅ MTP2~67.6 tok/s5016 tok/s84.9%✅ 局部最优图1 关键指标对比图2 吞吐量对比图3 MTP投机解码指标对比最终稳定配置vLLM nightly 0.26.1# 1. 硬件层面限制核心频率开机执行写入 rc.local nvidia-smi -lgc 0,2100 # 2. 启动 vLLM vllm serve /models \ --tensor-parallel-size 2 \ --kv-cache-dtype fp8 \ --speculative-config {method:mtp,num_speculative_tokens:2} \ --enable-prefix-caching \ --max_num_seqs 16 \ --max-num-batched-tokens 4096 \ --gpu-memory-utilization 0.93 \ --max-model-len 262144 \ --reasoning-parser qwen3 \ --enable-auto-tool-choice \ --tool-call-parser qwen3_xml # 不指定 attention-backend让 vLLM 自动选 FlashInfer预期表现单流 decode~60–85 tok/s频率锁损失约 10%长 prefill8K稳定不重启TTFT 约 1–2s显存占用每卡约 22 GiBweights 10.5G KV 9.3G graph 0.5G activation 2GMTP 平均接受长度2.7整体接受率~85%vLLM 0.28 升级展望待0.28版本的docker镜像发布后更新经查询资料fused_gdn_decode_post_conv_mtp这个特性是2026.8.14合并入主线的但是0.27.1是2026.8.11发布的今天2026.8.26vLLM发布了0.28静待0.28的docker镜像发布。0.27 可能改变的变量特性来源对当前场景的预期影响fused_gdn_decode_post_conv_mtpPR #51674GDN MTP 有望从 Triton 恢复到 CUDA 融合路径decode 预计提速 1.2–2.2×FlashInfer 0.6.140.27 依赖spec decode 下 CUDA Graph 支持可能从UNIFORM_SINGLE_TOKEN_DECODE改善PyTorch 2.13.00.27 升级需验证与当前 INT4/Marlin 量化路径的兼容性经验总结4090 的 FP8 是 bandwidth saver不是 compute accelerator。BF16 KV 会让 decode 直接慢 40–50%。不要为了清 warning牺牲 FP8。GDN 模型对 PIECEWISE 敏感但不如对 BF16 KV 敏感。同样的降级BF16 的损失远大于 PIECEWISE。消费级 GPU 的功率管理频率锁比功率墙更优雅。-lgc 0,2100比-pl 150对性能影响小得多且能有效管住 prefill 峰值。Warning 不一定需要修。能跑 67 tok/s 带 warning比 31 tok/s 干净日志有用得多。nightly 0.26 缺 GDN 融合 kernel。fused_gdn_decode_post_conv_mtp在 0.27 才合并0.26 的 MTP decode 走 Triton path 是已知限制。一句话总结在 RTX 4090 上不要为了清 warning 而牺牲 FP8 KV也不要为了防重启牺牲 decode 速度。频率锁 2100MHz 比功率墙更优雅等 0.27 的 GDN 融合 kernel 来了再试能不能突破 80 tok/s。本文基于 vLLM nightly 0.26.1 实测0.27.2 部分待vllm发布升级后补充。如有错误欢迎指正。