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)。