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

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

这次英伟达也下场了，放出了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

项目

信息

基座

Alibaba Qwen3.6-27B

参数量

27B

架构

Hybrid Attention，Gated DeltaNet + Gated Attention

上下文

262K，Qwen 原版还写了可扩展到 1,010,000 tokens

量化工具

nvidia-modelopt v0.45.0

量化目标

transformer blocks 内 linear operators 的权重与激活

推理引擎

vLLM

官方测试硬件

NVIDIA GB300

硬件兼容

Hopper / Blackwell

License

Apache 2.0

Qwen3.6-27B 自身的亮点也很明确，主打 Agentic Coding、仓库级推理、Thinking Preservation，以及更长的上下文

对本地部署玩家来说，最关键的其实就两个词：27B + 262K

27B 代表它还在个人工作站和单卡专业卡的想象范围里，262K 代表它适合 Agent、RAG、长文档、代码仓库这类吃上下文的任务

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

官方精度表：没明显变傻

官方模型卡给了 NVFP4 和 FP8 的 accuracy benchmark，我把关键数字搬出来

Benchmark

FP8

NVFP4

差值

MMLU Pro

86.1

86.3

GPQA Diamond

86.0

85.5

-0.5

HLE

21.7

21.8

τ²-Bench Telecom

95.2

95.4

MMMU Pro

74.6

74.3

SciCode

44.8

44.5

AIME 2025

93.1

92.7

-0.4

AA-LCR

68.8

68.3

-0.5

IFBench

65.1

65.5

+0.4

一句话，精度层面基本可以放心，差值大多在 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

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

先看 NVFP4

打开网易新闻 查看精彩图片

再看 FP8

打开网易新闻 查看精彩图片

把图里的关键数字拎出来：

场景

NVFP4 decode t/s

FP8 decode t/s

观察

pp256 / tg32 / d0

204

112

NVFP4 明显高

pp256 / tg256 / d0

201

111

NVFP4 明显高

pp4096 / tg32 / d0

117

112

接近

pp4096 / tg256 / d0

159

112

NVFP4 高

pp16384 / tg32 / d0

205

119

NVFP4 高

pp16384 / tg256 / d0

200

111

NVFP4 高

pp256 / tg32 / d4k

161

113

NVFP4 高

pp4096 / tg32 / d4k

203

117

NVFP4 高

pp16384 / tg32 / d4k

204

112

NVFP4 高

pp256 / tg32 / d8k

205

113

NVFP4 高

pp4096 / tg32 / d8k

204

117

NVFP4 高

pp16384 / tg32 / d8k

204

113

NVFP4 高

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 上并行跑

配置大概是：

项目

NVFP4

FP8

模型

nvidia/Qwen3.6-27B-NVFP4Qwen/Qwen3.6-27B-FP8

GPU

1× RTX PRO 6000 Blackwell 96GB

1× RTX PRO 6000 Blackwell 96GB

vLLM

0.24.0

0.23.1rc1.dev

Spec decoding

MTP, 3 tokens

MTP, 3 tokens

KV cache

fp8_e4m3

fp8_e4m3

max len

262K

262K

gpu util

0.92

0.92

max seqs

128

128

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

场景

NVFP4

FP8

结论

single small decode

77.1 tok/s

84.7 tok/s

FP8 +10%

warm TTFT

0.09 s

0.09 s

持平

big prompt decode

98.7 tok/s

111.0 tok/s

FP8 +12%

big prompt prefill

~5,700 tok/s / 3.9 s

~7,000 tok/s / 3.2 s

FP8 更强

16 并发 aggregate

891.7 tok/s

963.3 tok/s

FP8 +8%

16 并发 per-request

67.4 tok/s

68.5 tok/s

接近

4 并发 big aggregate

358.9 tok/s

342.5 tok/s

NVFP4 +5%

4 并发 big per-request

100.4 tok/s

103.7 tok/s

接近

这里我觉得最关键的是这句话：

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

再看 per-prompt latency，也挺扎心：

Prompt

NVFP4

FP8

捷克语 2000 词故事

49.3 s / 74.4 tok/s

36.8 s / 87.3 tok/s

HTML todo

16.3 s / 104 tok/s

15.9 s / 116 tok/s

HTML Snake

17.6 s / 124 tok/s

15.8 s / 141 tok/s

逻辑题转 JSON

2.75 s / 104 tok/s

2.6 s / 129 tok/s

Pythonmerge_intervals

1.78 s / 122 tok/s

1.87 s / 129 tok/s

捷克语投诉邮件

11.0 s / 60.5 tok/s

6.0 s / 110 tok/s

59KB 转 JSON

20.0 s / 103 tok/s

25.2 s / 103 tok/s

这组测试有点局限了：两边 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 集测试一下