Qwen3.6-27B-NVFP4 深度评测：英伟达官方量化，27B 长上下文本地部署新选择

作为本地部署爱好者，Qwen3.6-27B 系列一直是我的"本命模型"。这次英伟达亲自下场，releasing nvidia/Qwen3.6-27B-NVFP4，官方 ModelOpt 量化 + Apache 2.0 商用许可 + vLLM 原生支持，模型卡宣称显存和磁盘需求降低约 2.5 倍。

乍一看很香，但翻完模型卡和社区实测后，我发现有必要写一篇"避坑 + 实测"指南。先说结论：

• 显存收益真实：27B 从 55.6GB（BF16）压到约 20-22GB，适合单卡专业卡/工作站跑 262K 长上下文

• 精度基本稳住：官方 benchmark 显示 NVFP4 与 FP8 差距在±0.5 以内，MMLU Pro 甚至 86.3 vs 86.1 小赢

• 性能有分歧：RTX PRO 6000 Blackwell 上 decode 有测到 200 t/s vs FP8 112 t/s，但也有对测显示 FP8 在 decode-bound 场景快 8-12%

• 坑很具体：B200/DGX Spark/RTX PRO 6000 上有人遇到 Marlin 警告、modelopt_mixed、以及重复 !/d token 的 bug

这个模型到底是什么

Qwen3.6-27B 自身的亮点很明确：主打 Agentic Coding、仓库级推理、Thinking Preservation，以及 262K 超长上下文。对本地部署玩家来说，最关键就两个词：27B + 262K——27B 还在个人工作站/单卡专业卡的想象范围，262K 适合 Agent、RAG、长文档、代码仓库这类吃上下文的任务。

英伟达这次做 NVFP4，理论吸引力很直接：把 27B 再压一压，更容易塞进显存，同时尽量保住 Qwen3.6 的能力。

官方精度表：没明显变傻

模型卡给了 NVFP4 和 FP8 的 accuracy benchmark，关键数字如下：

精度层面基本可以放心：差值大多在 0.5 以内，考虑到 benchmark 本身的波动，这个结果挺漂亮。NVFP4 在 9 个基准中 4 个领先、1 个持平、其余差距小于统计噪声。

社区质量测试也支持这个判断：7 个 prompt 的质量检查（诗歌、投诉邮件、HTML todo、HTML Snake、逻辑题转 JSON、merge_intervals、59KB 文档转 JSON）结果显示两边非常接近：

• 逻辑题：两边都是 5/5 correct

• merge_intervals：两边都过 6/6 edge cases，都能处理 ValueError，也没有 mutation

• 59KB 文档转 JSON：两边都能产出 valid JSON，严重程度都判成 high

• HTML todo 和 Snake：都是 valid single-file，关键 API 存在

唯一需要注意的是 Thinking mode：有测试显示 NVFP4 在一个 trivial Python 任务里 16K token budget 都没把函数收完，FP8 能正确完成。所以我的判断是：正常非思考模式下，NVFP4 没有明显质量塌陷；但做确定性代码任务时，Thinking mode 要谨慎。

官方部署方式

NVIDIA 模型卡给的 vLLM 命令很简短：

vllm serve nvidia/Qwen3.6-27B-NVFP4 \ --port 8000 \ --quantization modelopt \ --max-model-len 262144 \ --reasoning-parser qwen3

如果要上工具调用、MTP（Multi-Token Prediction）、前缀缓存、chunked prefill，有 DGX Spark 用户贴过一组更详细的命令：

vllm serve ~/models/hf/Qwen3.6-27B-NVFP4 \ --trust-remote-code \ --served-model-name qwen36-27b \ --gpu-memory-utilization 0.45 \ --dtype bfloat16 \ --max-num-seqs 4 \ --max-model-len 131072 \ --reasoning-parser qwen3 \ --enable-auto-tool-choice \ --tool-call-parser qwen3_coder \ --speculative-config '{"method":"mtp","num_speculative_tokens":3}' \ --max-num-batched-tokens 16384 \ --enable-chunked-prefill \ --async-scheduling \ --enable-prefix-caching \ --quantization modelopt

关键点：

• --quantization modelopt：必须加，否则 vLLM 不会按 NVFP4 路径走

• --reasoning-parser qwen3：Qwen3.6 的 thinking mode 解析器

• MTP 配置：--speculative-config '{"method":"mtp","num_speculative_tokens":3}' 可以显著提升吞吐

• prefix caching：对 Agent 循环、RAG 重复 query 场景很有用

社区实测一：NVFP4 看起来真能打

测试条件：RTX PRO 6000 Blackwell 96GB，开启 MTP speculative decoding。

NVFP4 vs FP8 decode 吞吐对比

NVFP4 decode 都在 200 t/s 左右，FP8 大多在 111-119 t/s 区间。

但别只看 decode：

• prefill 上 FP8 反而更强：比如 pp4096 / tg32 / d0，FP8 是 9,785 t/s，NVFP4 是 6,782 t/s

• TTFT 也有类似现象：pp16384 / tg32 / d0，FP8 是 1,605 ms，NVFP4 是 2,595 ms

结论：某些 decode 场景里，NVFP4 的确能跑出很漂亮的数字；但长 prompt 和 prefill 场景下，FP8 依然有反杀空间。

社区实测二：另一组完整对测里，FP8 反而更快

有网友把 NVFP4 和 FP8 放到两张 RTX PRO 6000 Blackwell 96GB 上并行跑，配置如下：

吞吐结论和前面实测的截图相反：

这里最关键的是：FP8 在 decode-bound 场景里稳定快 8-12%，NVFP4 只在大 prompt 并发这种 prefill-bound 场景里小幅领先。

再看 per-prompt latency（部分典型任务）：

这组测试有局限（两边 vLLM build 不同，attention / MoE backend 也有差异），但它给了一个很重要的提醒：NVFP4 的速度优势没有形成统一规律，尤其别把显存下降自动等价成吞吐上涨。

重复 token：这坑有点吓人

这个 bug 典型现象是：模型能正常加载，但极简 prompt 也会输出一串 d d d d d 或者满屏 !。

社区反馈：

• 有用户说 vLLM release 0.24.0 正常，nightly 有问题

• 从 vllm/vllm-openai:nightly 换到 vllm/vllm-openai:v0.24.0-cu129-ubuntu2404 后缓解

• 但也有人说 vLLM==0.24.0 和 nightly 都遇到过

更细的反馈：

• 0.24.0 里 flashinfer 0.6.12 会让 AutoTuner 出现 300+ 次 [AutoTuner]: Tuning fp8_gemm: 100%

• nightly 升到 0.6.13 后 AutoTuner 异常缓解，但 CoT 中输出 !!! 的问题还在

建议：生产环境先固定 vLLM 版本（推荐 0.24.0 stable），用你的真实 prompt 集跑一轮回归测试，确认没有重复 token 再上线。

总结

这版 Qwen3.6-27B-NVFP4 我会给一个中性偏正面的评价：值得测，别神化。

好处很明确

• 官方 ModelOpt 量化，来源靠谱

• Apache 2.0，可商用

• 27B + 262K，本身就很适合 Agent 和长上下文

• 官方 benchmark 基本贴住 FP8

• 显存和体积下降约 2.5x，工程价值很实在

风险也很明确

• Blackwell 上仍可能看到 Marlin 警告

• modelopt_mixed 和 W4A16_NVFP4 意味着它未必吃满原生 FP4 compute 红利

• 社区实测性能分歧很大（有的场景 NVFP4 快，有的 FP8 快）

• vLLM nightly、FlashInfer、CoT、MTP 组合下有重复 token 风险

我的建议很简单

• 显存优先：先试 NVFP4，看能不能在你的卡上跑 262K 长上下文

• 吞吐优先：先拿 FP8 做基线，再 A/B 测试 NVFP4

• 上线之前：固定 vLLM 版本并跑自己的 prompt 集测试一下，确认没有重复 token / 质量塌陷