英偉達出手，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

τ2-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

Qwen3.6-27B-NVFP4 在 RTX PRO 6000 Blackwell 上的社區實測

再看 FP8

Qwen3.6-27B-FP8 在 RTX PRO 6000 Blackwell 上的社區實測

把圖里的關鍵數字拎出來：

場景

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或者滿屏!

Qwen3.6-27B-NVFP4 社區反饋的重復感嘆號問題

有用戶反饋 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 集測試一下