2026-05-09
llama.cpp 落地 Gemma 4 26B-A4B NVFP4（b9080）與 MiMo-V2.5 注意力核心（b9085）
llama.cpp b9080–b9085 加入原生 Gemma 4 26B-A4B NVFP4（Spark 上 52 tok/s、KV 可用 82 GB）與支援 d_kq=192/d_v=128 GQA 形狀的 MiMo-V2.5 flash-attention 核心。
在 2026 年 5 月 8–9 日的 48 小時內，llama.cpp 連續發布兩個與 DGX Spark 操作者高度相關的版本：Google Gemma 4 26B-A4B MoE 的原生 NVFP4 支援，以及 Xiaomi MiMo-V2.5（310B 稀疏 MoE）的 flash-attention 核心。
b9080 — Gemma 4 26B-A4B NVFP4 原生支援
PR #22804（5/8 18:42 UTC 合併，由 NVIDIA ynankani 簽署）加入 Gemma 4 26B-A4B NVFP4 的原生 GGUF 轉換。架構為 25.2B 總 / 3.8B 啟用每 token 的 MoE —— 在亞 A3B 等級的算力下達成前沿多模態能力（影像輸入、文字輸出）。在此 PR 之前，社群版 NVFP4 轉換需要手動修補 scale 張量，每次模型權重更新都會壞掉。
DGX Spark 社群實測（PR 討論串內）： 52 tok/s 單使用者、佔用 16.5 GB、KV 快取可用 82 GB。 那個「可用」的數字才是頭條。在 82 GB 可用記憶體下，Gemma 4 26B-A4B 在 NVFP4 下能撐起超過 100 萬 token 的上下文視窗 —— 在單張 Spark 上跑「整套程式庫」級別的 agent 已經是現實。
b9085 — MiMo-V2.5 注意力核心
PR #22812（5/9 03:28 UTC 合併）加入 d_kq=192 / d_v=128 的 flash-attention MMA 拼塊。這正是 Xiaomi MiMo-V2.5 使用的 head 維度（310B 稀疏 MoE，15B 啟用，1M 上下文，全模態）。MiMo-V2.5 本身過大無法放入單張 Spark —— 但這個注意力核心是獨立發布的，凡使用相同 head 形狀 GQA 的模型都可重用。
實際意涵：未來開放權重模型只要 GQA 設置相似、規模超過 100B，在 Blackwell 消費級硬體上都已有 CUDA 最佳化的快路徑，而不必等上游補丁。
同視窗中的相關改善
- b9075 — CUDA 蛇形啟動函式融合（減少 MoE router 的核心啟動次數）
- b9066 —
out_prod批次 cuBLAS GEMM（更快的訓練式外積，對 in-context fine-tuning 有用） - b9082 — L2_NORM Hexagon HTP 核心（若你把草稿模型 offload 到搭配 Spark 的 Qualcomm DSP，會用到）
節奏值得注意：NVIDIA 員工正在主動向 llama.cpp 主線貢獻，而不只是維護下游 fork。2026 年初要等好幾週才能浮上來的 NVFP4 修復，現在從提案到合併往往只要幾天。
行動項
# 在 b9080 或更新版本重建 llama.cpp
cd llama.cpp && git fetch && git checkout b9085
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=121 \
-DLLAMA_CURL=OFF -DGGML_NATIVE=ON
cmake --build build --config Release -j
# 從 NVIDIA 的 HF 組織拉取 Gemma 4 26B-A4B NVFP4
huggingface-cli download nvidia/Gemma-4-26B-A4B-NVFP4 \
--local-dir ~/models/gemma4-26b-a4b-nvfp4
# 基準測試
./build/bin/llama-bench -m ~/models/gemma4-26b-a4b-nvfp4/Gemma-4-26B-A4B-NVFP4.gguf \
--n-gpu-layers 99 --flash-attn -p 512,2048 -n 128對照你的數字與 52 tok/s 參考。若較低，檢查 --flash-attn 是否有效（log 中應有 FA: 1）以及版本是否為 b9080+ —— b9080 之前的版本走舊版 NVFP4 路徑，慢約 30–35%。