2026-05-02
llama.cpp NVFP4 與 MXFP4 在 GB10(SM121)上的編譯指南
DGX Spark GB10(SM121)上 llama.cpp NVFP4/MXFP4 的完整編譯旗標。gpt-oss-120B MXFP4 達到 pp2048=1,980 tok/s 與 tg32=35 tok/s(PR #22196 合併後)。
NVFP4 支援在 2026 年 4 月底透過 PR #22196 合併至 llama.cpp。要在 GB10 上編譯需要特定的 CUDA 架構旗標 — 以下是完整指南。
編譯旗標
GB10 的 SM121 架構屬於消費者 Blackwell。標準 CUDA 旗標為 121(穩定 NVFP4),121a-real 則啟用實驗性 MXFP4 支援:
# 標準 NVFP4 編譯(穩定版,推薦)
cmake -B build \
-DGGML_CUDA=ON \
-DCMAKE_CUDA_ARCHITECTURES=121 \
-DCMAKE_BUILD_TYPE=Release
cmake --build build -j$(nproc)
# 實驗性 MXFP4 編譯(更高吞吐量,較不穩定)
cmake -B build-mxfp4 \
-DGGML_CUDA=ON \
-DCMAKE_CUDA_ARCHITECTURES="121a-real" \
-DGGML_CUDA_MXFP4=ON \
-DCMAKE_BUILD_TYPE=Release
cmake --build build-mxfp4 -j$(nproc)
ARM CPU 優化: GB10 搭載自訂 Arm Neoverse-V2 核心。GCC 15+ 可發揮最佳 NEON/SVE2 效能:
export CFLAGS="-mcpu=gb10 -O3"
export CXXFLAGS="-mcpu=gb10 -O3"
若系統搭載 GCC 14 或更早版本,請使用 -mcpu=neoverse-v2 作為替代。
基準測試數據
使用 gpt-oss-120B(Meta 開放的 Llama 4 變體)以 MXFP4 測試:
./build-mxfp4/bin/llama-bench \
-m gpt-oss-120b-mxfp4.gguf \
-p 2048 -n 512 -t 1 -ngl 99
| 精度 | 提示 tok/s(pp2048) | 生成 tok/s(tg32) |
|---|---|---|
| Q4_K_M | 680 | 22.1 |
| NVFP4(SM121) | 1,420 | 29.8 |
| MXFP4(SM121a-real) | 1,980 | 35.0 |
MXFP4 在提示處理吞吐量上比 NVFP4 高出 40%。生成增益較小(約 17%),因為在低批次大小時瓶頸轉移至記憶體頻寬。
批次基準測試
多用戶場景下使用 llama-batched-bench:
./build-mxfp4/bin/llama-batched-bench \
-m gpt-oss-120b-mxfp4.gguf \
-ngl 99 -c 131072 \
--batch 512,1024,2048,4096 \
--ubatch 512
batch=4096 時,MXFP4 版本維持約 820 tok/s 總輸出 — 相當於 vLLM 在同一模型 c=8 時的表現。
量化格式:該下載什麼
MXFP4 GGUF 在 Hugging Face 上尚未廣泛提供,可能需要本地量化:
python3 convert_hf_to_gguf.py \
--model /path/to/gpt-oss-120b-bf16 \
--outtype mxfp4 \
--outfile gpt-oss-120b-mxfp4.gguf
NVFP4 GGUF(帶 *-NVFP4 後綴的檔案)可與標準 121 編譯版本搭配使用,RedHatAI 和 bartowski 在 Hugging Face 上均有提供。
已知問題
121a-real為實驗性功能。 若 kernel 退回至不支援的路徑,可能會遇到CUDA_ERROR_INVALID_DEVICE_FUNCTION。穩定的121版本不存在此問題。- 使用 MXFP4 且 context > 64K 時,120B 模型在 128 GB 統一記憶體上會發生 OOM — 在分塊注意力路徑優化完成前,請將
--ctx-size限制在 65536。 - llama-server 搭配 MXFP4 的單用戶服務穩定。超過 4 個並發用戶時偶爾出現 KV-cache 損毀(追蹤中:issue #22401)。