Qwen3.6-27B 可以说是最受全球本地部署爱好者追捧的大模型之一，之前也有过不少次介绍。

这次英伟达也亲自下场，放出了 nvidia/Qwen3.6-27B-NVFP4。

乍一看确实很香：官方 ModelOpt 量化，Apache 2.0 协议，vLLM 直接 serve，模型卡上写着磁盘和 GPU 显存需求大约降低 2.5x。

不过，翻完模型卡和社区讨论后，发现确实有必要详细拆解一下。

先说结论

• 显存收益是实打实的：官方把 transformer block 里的 linear operators 权重和激活量化到 NVFP4，参数位宽从 16 bit 降到 4 bit，磁盘和 GPU 显存需求大约降了 2.5x。
• 精度基本稳住了：官方评测里 NVFP4 和 FP8 很接近，MMLU Pro 甚至 86.3 vs 86.1，小赢 0.2。
• 性能表现有分歧：有测试显示 NVFP4 在 RTX PRO 6000 Blackwell 上 decode 可以跑到 200 t/s 左右，FP8 约 112 t/s；但也有更完整的对比测试里，FP8 在 decode-bound 场景反而快 8-12%。
• 坑也很具体：B200 / DGX Spark / RTX PRO 6000 Blackwell 上都有人遇到 Marlin 警告、modelopt_mixed 问题，以及重复 ! / d token 的问题。
• 生产建议很朴素：显存紧张、长上下文、想跑 27B 的同学可以试 NVFP4；追求稳定吞吐的同学，务必拿 FP8 在同一套 vLLM / FlashInfer / MTP 配置下做 A/B 测试。

这个模型到底是什么

Qwen3.6-27B 自身的亮点很明确，主打 Agentic Coding、仓库级推理、Thinking Preservation，以及更长的上下文。对本地部署玩家来说，最关键的其实就两个词：27B + 262K。27B 代表它还在个人工作站和单卡专业卡的想象范围里，262K 代表它适合 Agent、RAG、长文档、代码仓库这类吃上下文的任务。英伟达这次做 NVFP4，理论上的吸引力很直接：把 27B 再压一压，让它更容易塞进显存，同时尽量保住 Qwen3.6 的能力。

官方精度表：没明显变傻

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

一句话概括，精度层面基本可以放心，差值大多在 0.5 以内，考虑到 benchmark 本身的波动，这个结果相当漂亮。

社区的质量测试也支持这个判断。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、前缀缓存、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

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

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

先看 NVFP4：

再看 FP8：

把图里的关键数字整理出来：

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 出现三百多次 [AutoTuner]: Tuning fp8_gemm: 100%，nightly 升到 0.6.13 后 AutoTuner 异常缓解，但 CoT 中输出 !!! 的问题还在。

总结

这版 Qwen3.6-27B-NVFP4 总体评价是中性偏正面：值得测，别神化。

好处很明确：

• 官方 ModelOpt 量化，来源靠谱
• Apache 2.0，可商用
• 27B + 262K，本身就很适合 Agent 和长上下文
• 官方 benchmark 基本贴住 FP8
• 显存和体积下降大约 2.5x，工程价值很实在

风险也很明确：

• Blackwell 上仍可能看到 Marlin 警告
• modelopt_mixed 和 W4A16_NVFP4 意味着它未必吃满原生 FP4 compute 红利
• 社区实测性能分歧很大
• vLLM nightly、FlashInfer、CoT、MTP 组合下有重复 token 风险

建议很简单：显存优先，先试 NVFP4；吞吐优先，先拿 FP8 做基线；上线之前，固定 vLLM 版本并跑自己的 prompt 集测试一下。