NVIDIA 發布 Qwen3.6-35B-A3B-NVFP4:面向 vLLM 部署的 FP4 量化版本

整理 NVIDIA 在 Hugging Face 發布的 Qwen3.6-35B-A3B-NVFP4:模型來源、NVFP4 量化方式、vLLM 部署命令、硬體需求、評測結果和使用限制。

NVIDIA 在 Hugging Face 上發布了 nvidia/Qwen3.6-35B-A3B-NVFP4。這是基於阿里 Qwen3.6-35B-A3B 的量化版本,使用 NVIDIA Model Optimizer 處理,目標是讓開發者更方便地把模型部署到 vLLM、Agent、RAG、聊天機器人等推理場景中。

模型卡顯示,它採用 Apache-2.0 授權,可以用於商業和非商業場景。需要注意的是,NVIDIA 明確說明該模型並不是 NVIDIA 自研基礎模型,而是基於第三方模型 Qwen3.6-35B-A3B 的量化版本。

模型基本資訊

根據模型卡,Qwen3.6-35B-A3B-NVFP4 的關鍵參數如下:

  • 基礎模型:Qwen/Qwen3.6-35B-A3B
  • 發布方:NVIDIA
  • 量化工具:NVIDIA Model Optimizer
  • 授權:Apache-2.0
  • 架構:Transformer
  • 網路結構:MoE with Hybrid Attention
  • 參數規模:總參數 35B,啟用參數 3B
  • 輸入:文字、圖像、影片
  • 輸出:文字
  • 上下文長度:最高 262K
  • 推理引擎:vLLM
  • 建議硬體:NVIDIA Hopper、NVIDIA Blackwell
  • 建議系統:Linux

Hugging Face 頁面側邊欄同時顯示了模型檔案相關的體積與張量類型資訊。閱讀時不要把頁面側邊欄裡的檔案統計口徑,直接等同於基礎模型的架構參數。

NVFP4 量化做了什麼

這個版本的重點是 NVFP4 量化。模型卡描述中提到,NVIDIA 對 Qwen3.6-35B-A3B 的權重做了 NVFP4 量化,使其可以配合 vLLM 推理使用。

這次量化不是把所有內容都粗暴壓到 4-bit,而是針對 MoE Transformer block 中線性算子的權重和啟用值做處理。官方給出的結果是:每個參數的位寬從 16 bit 降到 4 bit,磁碟占用和 GPU 顯存需求約降低 3.06 倍。

對部署來說,這類預量化版本的意義很直接:不用自己重新跑量化流程,就可以直接拿來測試吞吐、顯存占用和長上下文推理表現。

vLLM 部署命令

模型卡給出的基礎啟動命令如下:

1
vllm serve nvidia/Qwen3.6-35B-A3B-NVFP4 --port 8000 --quantization modelopt --max-model-len 262144 --reasoning-parser qwen3

這條命令保留了 262K 上下文長度,適合先在高顯存環境中驗證模型能力。如果顯存緊張,可以先降低 --max-model-len,再逐步上調。

針對 NVIDIA DGX Spark,模型卡給了另一組環境變數和 vLLM 參數:

1
2
3
4
5
export VLLM_USE_FLASHINFER_MOE_FP4=0
export VLLM_FP8_MOE_BACKEND=flashinfer_cutlass
export FLASHINFER_DISABLE_VERSION_CHECK=1
export CUTE_DSL_ARCH=sm_121a
vllm serve nvidia/Qwen3.6-35B-A3B-NVFP4 --port 8000 --tensor-parallel-size 1 --trust-remote-code --dtype auto --quantization modelopt --kv-cache-dtype fp8 --attention-backend flashinfer --moe-backend marlin --gpu-memory-utilization 0.85 --max-model-len 65536 --max-num-seqs 4 --max-num-batched-tokens 8192 --enable-chunked-prefill --async-scheduling --enable-prefix-caching --speculative-config '{"method":"mtp","num_speculative_tokens":3,"moe_backend":"triton"}'

這組參數更偏向實際部署調優:降低上下文到 65536,啟用 FP8 KV cache、chunked prefill、prefix caching,並配置 speculative decoding。它不是所有機器都能直接複製使用,尤其是 CUTE_DSL_ARCH=sm_121a、FlashInfer、MoE backend 等參數,都和具體 GPU、驅動、CUDA、vLLM 版本有關。

評測結果怎麼看

模型卡對比了 BF16 基線和 NVFP4 量化版本的結果:

Precision MMLU Pro GPQA Diamond τ²-Bench Telecom SciCode AIME 2025 AA-LCR IFBench MMMU Pro
BF16 85.6 84.9 95.5 40.8 89.2 62.0 62.3 74.1
NVFP4 85.0 84.8 94.7 40.6 88.8 62.0 62.8 74.5

從表格看,NVFP4 相比 BF16 有小幅波動:部分指標略降,IFBench 和 MMMU Pro 反而略高。更穩妥的理解是:這個量化版本在這些公開評測上盡量接近 BF16,但部署前仍然需要用自己的業務資料測試。

尤其是 Agent、RAG、程式碼生成、長上下文檢索這類場景,公開 benchmark 只能給一個參考。真正上線前,還是要看:

  • 長上下文下是否穩定遵循指令;
  • RAG 場景中是否會忽略引用材料;
  • 工具呼叫是否容易產生錯誤參數;
  • 中文、英文和多模態輸入是否符合你的業務要求;
  • 低顯存配置下吞吐和延遲是否能接受。

適合哪些場景

這個模型更適合已經準備使用 NVIDIA GPU 和 vLLM 做推理服務的團隊。典型場景包括:

  • 本地或私有化聊天機器人;
  • RAG 知識庫問答;
  • Agent 系統中的規劃與工具呼叫;
  • 長文件閱讀與摘要;
  • 需要更低顯存占用的大模型推理測試;
  • 想比較 BF16 與 FP4 量化效果的部署團隊。

如果只是想在普通消費級顯示卡上隨便跑一跑,要先確認顯存、vLLM 版本和量化支援情況。預量化模型可以降低部署門檻,但不等於所有硬體都能無痛運行 262K 上下文。

使用限制

模型卡中也提醒了常見限制:基礎模型的訓練資料來自網際網路,可能包含有害內容和社會偏見,因此模型可能在某些提示下放大偏見、生成不準確內容、遺漏關鍵資訊,或者輸出不合適的文字。

如果用於生產環境,建議至少增加幾層保護:

  • 針對業務場景做安全評測;
  • 給 RAG 和工具呼叫增加結果校驗;
  • 對高風險輸出增加人工複核;
  • 記錄推理版本、量化配置和 vLLM 參數;
  • 對重要任務保留回滾到其他模型或 BF16 版本的方案。

小結

nvidia/Qwen3.6-35B-A3B-NVFP4 的價值在於:它把 Qwen3.6-35B-A3B 做成了一個可以直接面向 vLLM 部署的 NVIDIA 量化版本。NVFP4 降低了顯存和磁碟壓力,官方評測也顯示它在多項指標上接近 BF16。

但它仍然是一個需要工程驗證的推理模型。真正部署前,不要只看 benchmark 分數,更要結合自己的硬體、上下文長度、RAG 資料、Agent 工具鏈和安全要求做測試。

參考連結:

记录并分享
使用 Hugo 建立
主題 StackJimmy 設計