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、以及重复!/dtoken 的问题生产建议很朴素：显存紧张、长上下文、想跑 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，也都没有 mutation59KB 文档转 JSON 两边都能产出 valid JSON，严重程度都判成 highHTML 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 上并行跑
配置大概是：
nvidia/Qwen3.6-27B-NVFP4 | Qwen/Qwen3.6-27B-FP8 | |
它的吞吐结论和 前面实测的截图相反：
这里我觉得最关键的是这句话：
FP8 在 decode-bound 场景里稳定快 8-12%，NVFP4 只在大 prompt 并发这种 prefill-bound 场景里小幅领先
再看 per-prompt latency，也挺扎心：
merge_intervals | ||
这组测试有点局限了：两边 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 集测试一下
