英伟达出手，Qwen3.6-27B 量化版来了，褒贬不一

Qwen3.6-27B 是最受全球本地部署爱好者追捧的大模型，当然也是我的最爱，之前介绍过多次了

Qwen3.6-27B 量化版本推荐，本地部署
Qwen3.6-27B 开源了，27B 小身板干翻 397B 巨无霸
Claude Opus蒸馏Qwen3.6-27B，GGUF来了，消费级显卡轻松本地部署！
Claude Opus 蒸馏 Qwen3.6-27B，v2 来了

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

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

但我翻完模型卡和社区 discussion 后，感觉有必要详细介绍一下

先说结论

• 显存收益是真实的：官方说把 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 release0.24.0 正常，nightly 有问题

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

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

更细的反馈是：0.24.0 里 flashinfer0.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 集测试一下