前一篇 CyberQ 介紹了 Meta 開源的 Muse-Glimmer-30B，文末提到「有機會在本地跑跑看，驗證官方宣稱的數字」，本篇是驗證的記錄與教學。CyberQ 測試將 BF16 原精度的模型跑在自己的 DGX Spark 上，用官方公布的取樣參數跑完 AIME 2026 全部 30 題，看看能不能重現官方宣稱的 94.7%。
實測未發現與官方宣稱有系統性落差，但是呢，我們後面會說明為什麼不能寫成成功重現 94.7的成績，這牽涉到一個常被忽略的方法論問題。
過程中也發現，GB10 這台機器跑 BF16 的單序列速度只有 4.5 tokens/s，而這不是設定沒調好，是記憶體頻寬的物理上限。同一台機器改成批次一起跑後，總吞吐衝到 111 tokens/s，相差 24.7 倍。這個對比決定了 GB10 這類機器適合做什麼、不適合做什麼，後面會告訴大家囉。
一、硬體與方案選擇
CyberQ 的測試機是 NVIDIA GB10（Blackwell, aarch64），也就是 DGX Spark，具備128 GB 統一記憶體。本輪 Meta 的開放模型權重放在 NAS 上，透過 10 GbE 掛載 QNAP NAS 上的 NFS4（實測讀 462 MB/s、寫 420 MB/s），這台機種是 TS-855x。
一開始評估了二條路：
1. Ollama 這台跑不了
Ollama 對 Muse-Glimmer 目前僅透過 MLX engine 支援 Apple Silicon，NVIDIA 支援尚未正式提供。而且走的是 GGUF 量化版，並不適合拿來對照官方的原精度數字。
但之後就可以跑量化版了，也會比較快。
2. NAS 上的 Open WebUI 是前端
QNAP NAS 上跑著 Open WebUI ，扮演的角色是接上 GB10 的 OpenAI 相容端點當 UI。
最後 CyberQ 採用官方 vLLM 容器 vllm/vllm-openai:muse-glimmer，已確認有 arm64 manifest，映像內自帶 transformers 5.14.1 與 torch 2.13.0+cu130，正好補上本機缺的兩塊，同時繞開版本地獄。
關於精度的選擇，當時我們測試時參考 vLLM recipe 提到 NVFP4 變體（25.42 GB）在 Blackwell 上更省，但 HuggingFace 的 meta-models 底下目前只有 BF16、GGUF、assistant-3B 與 ExecuTorch 四個 repo，還沒有官方 NVFP4 釋出，目前也會有了。既然目的是對照官方數字，BF16 原精度才是正確基準，代價就是後面會看到的速度會比較慢，實務上要跑快一點就是拿 NVFP4 模型會比較實用喔。
二、部署設定
實測可用的 compose.yaml 範例重點如下，要使用時請自行修改對應的設定：
services:
muse-glimmer:
image: vllm/vllm-openai:muse-glimmer
network_mode: host
ipc: host
shm_size: "8gb"
gpus: all
volumes:
- ${GLIMMER_MODEL_DIR}:/model:ro
- ${HF_CACHE_DIR}:/root/.cache/huggingface
command:
- /model
- --served-model-name=muse-glimmer
- --tensor-parallel-size=1
- --gpu-memory-utilization=0.80
- --max-model-len=32768
- --enable-auto-tool-choice
- --tool-call-parser=muse_glimmer
- --reasoning-parser=muse_glimmer
- --generation-config=auto
- '--override-generation-config={"temperature":1.0,"top_p":0.95,"top_k":64}'YAML 當中幾個參數稍微說明一下，--gpu-memory-utilization=0.80 是因為 recipe 對多卡 GB300 建議 0.92，但 GB10 的統一記憶體是 CPU/GPU 共用，桌面工作階段也要吃。0.80 的 128 GiB 扣掉 55.49 GiB 權重後仍留 40.89 GiB 給 KV cache，實測綽綽有餘。
--max-model-len=32768這部分是模型宣告 131072，但 52 層的全長 KV cache 塞不下 BF16 權重旁邊。實際配到 2,108,998 tokens 的 KV cache，等同 64 條 32K 滿長度並行序列，後來證明用量從沒超過 4%，也被證明 32768 是錯的，可以用更大的宣告。
muse_glimmer 的 tool-call 與 reasoning parser 只存在於這個官方映像裡，換別的映像就沒有結構化的推理輸出了，可能因為模型剛出，其他版本還沒有。
坑一：官方的 `generation_config.json` 預設是 greedy
模型附的 generation_config.json 裡是：
“do_sample”: false
也就是 greedy decoding。但 vLLM recipe 明文警告這是推理模型，不可用 greedy 跑。兩份官方檔案自己打架。
用 --generation-config=auto 讓服務端沿用 Meta 的預設，剛好就踩進去了，但 Open WebUI 不帶取樣參數，會直接落入 greedy，推理品質失真而且完全沒有錯誤訊息。
解法是加上 --override-generation-config。要注意它與 --generation-config auto 是合併而非取代的關係，所以只會蓋掉取樣參數，Meta 其餘的預設（eos_token_id 等）都保留。
坑二：Open WebUI 的預設 HTTP 逾時太短
Open WebUI 的 AIOHTTP_CLIENT_TIMEOUT 預設多半是 300 秒。在 4.5 tokens/s 之下，一段 2000 token 的推理就要 445 秒，會在模型還在想的時候被前端切斷，畫面上看起來像模型壞了，其實只是逾時。建議把它調到 3600。在頻寬受限的機器上跑推理模型，長等待是常態而非異常。
冷啟動資料這邊也提供參考，Meta 該模型權重載入 7 分 43 秒（55.49 GiB from NFS），加上 CUDA graph 捕捉（PIECEWISE 51 + FULL 35），到 /v1/models 可回應總共約 640 秒。改設定要重啟一次就是 10 分鐘，如果放本地端 SSD 會載得更快。
三、4.5 tokens/s 不是調校問題，是物理天花板限制
服務起來後的第一個測試，單序列生成速度是 4.5 tokens/s。這個數字低到讓人想去翻設定，但算一下就會發現無從最佳化，因為GB10 統一記憶體頻寬約 273 GB/s，BF16 權重 55.49 GiB，
每產生一個 token 都必須把全部權重讀過一遍，所以理論上限 273 ÷ 55.49 ≈ 4.9 tokens/s，所以實測 4.5，是理論值的 92%。這就是天花板，不是設定沒調好。
這也正好解釋了 recipe 為什麼在 GB10 上偏好 NVFP4（25.42 GB），頻寬需求少一半以上，速度可翻倍，就會更順利且能善用了，同時也說明 Meta 宣稱的「24GB VRAM 可跑」指的是量化版而非 BF16。
但批次是另一回事
CyberQ 測試一次權重讀取可以服務整批序列，同樣的權重讀進來，是餵給 1 條序列還是 30 條，頻寬成本一樣，這個模型適合 AI 代理人使用。
實測 30 條並行時：
| 情境 | 吞吐 |
|---|---|
| 單序列 | 4.5 tok/s |
| 30 條並行 | 111 tok/s（24.7 倍） |
| 尾端剩 4 條 | 16.8 tok/s（≈ 4 × 4.2） |
| 剩 2 條 | 8.6 tok/s（≈ 2 × 4.3） |
這邊可以注意最後兩列，每條序列的速度始終是那個由頻寬決定的常數，總吞吐純粹取決於有幾條在跑。這是頻寬受限（memory-bound）而非算力受限（compute-bound）的典型指紋。
實務上，CyberQ 建議，這台機器跑 BF16 的 Muse-Glimmer，單人互動式對話會很慢，但批次與 agentic 工作負載相當有效率，所以當然如 Meta 官方所言是適合給 AI 代理人用的模型，拿來給龍蝦、Hermers Agents 串接都是適合的。如果你的用途是一個人坐在聊天視窗前等回覆，4.5 tok/s 大概會讓你失去耐性，如果是排隊處理一批任務，它的性價比完全不同。實務上，跑量化版是更快的，也有人也用 NVFP4 來提高速度。
四、AIME 2026 的測試方法
資料集
用的是 math-ai/aime26，30 題（AIME I + II），含標準答案，也是官方 benchmark 常引用的來源。
取樣參數
照官方 recipe：
SAMPLING = {“temperature”: 1.0, “top_p”: 0.95, “top_k”: 64} MAX_TOKENS = 30000
PYTHON
明確傳送而不依賴服務端預設，這樣光看紀錄就能重現，也避開了前面那個 greedy 陷阱。
為什麼 30 題必須平行送
如果一題一題跑，以 4.5 tok/s 計算大約要 15 小時。全部平行送出後實際跑完只花 2 小時。這不是取巧，批次不會改變模型的輸出品質，只是把頻寬成本攤提掉。
評分邏輯上的一個堅持
答案擷取取最後一個 \boxed{}（要能處理 \boxed{m+n=277} 這類變體），這點很重要，也把「答錯」與「截斷／錯誤」分開計：
# A truncated completion is a resource failure, not a wrong answer; # scoring it as incorrect would understate the model.
如果把資源性失敗混進答錯，得到的分數會系統性低估模型。
五、實測結果
第一輪 30 題一起跑，總共跑了 2 小時：
| 指標 | 數值 |
|---|---|
| 正確 | 27 / 30 = 90.0% |
| 真正答錯 | 2 題（#15、#30） |
| 客戶端逾時 | 1 題（#29） |
| 截斷（觸及 max_tokens） | 0 |
| 總生成 token | 265,231 |
| 整體吞吐 | 30.3 tok/s |
零截斷這點值得強調：30,000 的 max_tokens 上限沒有限制到任何一題，所以沒有任何一題是想到一半被切斷而失分的。
推理長度的分佈
| 題號 | tokens | |
|---|---|---|
| 未收斂 | #29 | 30,000（觸頂截斷） |
| 最長 | #10 | 24,693 |
| #15 | 24,237 | |
| #28 | 19,083 | |
| #30 | 16,862 | |
| 中位數 | 約 6,000 | |
| 最短 | #5 | 1,547 |
| #1 | 1,074 |
最長與最短差了 23 倍。這解釋了跑批次時前面掉得快、尾巴拖很長的現象，簡單題幾分鐘就結束，硬題會獨自佔著 GPU 再跑一小時，而此時批次已經縮小，每條序列又回到 4.x tok/s 的頻寬極限。
兩題真正答錯
#15：模型花了 24,237 tokens 深度推理，把問題歸約成「不交叉框分割數 = 卡塔蘭數 $C_5 = 42$」，但正解是 83。
#30：花了 16,862 tokens，用字元和（character sum）的論證推導出 $N = 3^7/(3 \cdot 3) = 3^5$，答 243，正解是 393。
兩題的共通點值得注意：推理鏈完整、格式正確、finish_reason 都是 stop，沒有任何技術面的異常。純粹是把問題歸約成了一個結構相近但不等價的計數問題，然後自信地把那個問題解對了。這是推理模型典型的失敗樣態，錯不在算術，在建模，也是為什麼看分數之外還要看推理過程。
六、對照官方的 94.7%
| 情境 | 得分 |
|---|---|
| 保守下界（未收斂的 #29 算答錯） | 27/30 = 90.0% |
| 排除未收斂題（只看正常結束的 29 題） | 27/29 = 93.1% |
| 樂觀上界（#29 放開上下文後答對） | 28/30 = 93.3% |
| 官方宣稱 | 94.7% |
官方的 94.7% 換算成題數是 28.41 題，而我們的最好情況是 28 題。也就是說，官方比我們高出 0.41 題。
在 30 題的資料集上，這個差距是無法分辨的，沒有任何測試能區分「28.41 題」和「28 題」，因為題數是整數，最小刻度就是 1 題 = 3.33 個百分點。我們的結果比官方低，但低的幅度小於這個測試方法的解析度。
為什麼不能說成功重現 94.7 呢 ?
官方那類分數的慣例是多次取樣取平均（avg@k，常見 k=32）。而這次是 single-run。在 temperature 1.0 的取樣設定下，同一題重跑兩次的答案不一定相同，單次結果本來就會有隨機波動。
更關鍵的是粒度問題，30 題的資料集，一題就是 3.33 個百分點。可能的分數只有 90.0%、93.3%、96.7% 這些離散值，中間沒有任何刻度。而官方的 94.7% 根本不落在這個格子上，它必然來自多次取樣的平均，單次跑 30 題永遠不可能得出這個數字。光是運氣造成正負一兩題的差距，就足以讓單次分數跳過整個區間。
所以嚴謹的說法只能是這次測試未發現與官方宣稱有系統性落差。差了 0.41 題，而測量工具的最小刻度是 1 題。
要得到可以直接相比的數字，得跑 avg@8 以上。以這台機器的吞吐估算，大約需要 8～16 小時，不過就太費時囉。
七、給想自己跑的人的建議
關於模型的部分，BF16 原精度在 DGX Spark 上跑得起來，AIME 2026 的表現與官方宣稱一致（在單次測試能分辨的精度內）。零截斷、推理鏈完整、多模態辨識（形狀、顏色、相對位置、圖中文字）也都通過驗證。
關於這台機器：
128 GB 統一記憶體讓 55.49 GiB 的 BF16 權重裝得下，但裝得下不等於跑得快。
真正的限制是 273 GB/s 的記憶體頻寬，換算成單序列 4.9 tok/s 的天花板。
要提升單人互動速度，唯一有效的手段是量化（NVFP4 應可翻倍），調整參數沒有用。
要提升總產出，就把工作批次化，24.7 倍的差距是可參考的。
如果你要重做這個測試，採用這幾個建議會省下你的時間，用官方容器，不要在 ARM 上自己 pip install vllm。同時呢，加上 --override-generation-config，否則不帶取樣參數的客戶端會靜默地跑 greedy。最後則是客戶端逾時設寬（4 小時起跳），並讓 benchmark 程序脫離終端工作階段。--max-model-len 放到原生長度，不要為了省 KV cache 而縮。
本文測試環境：NVIDIA GB10 (DGX Spark)、128 GB 統一記憶體、aarch64、vLLM 官方容器 vllm/vllm-openai:muse-glimmer、Muse-Glimmer-30B BF16、資料集 math-ai/aime26。
至於有網友敲碗，想知道 NVIDIA 24GB/16GB 的顯示卡能不能跑 ? Mac M5 能不能跑，請參考這些可下載的 Muse-Glimmer-30B 量化版模型 :
https://huggingface.co/unsloth/Muse-Glimmer-30B-GGUF
社群版給 NVIDIA 用的 NVFP4 版本也出來了 :
Unsloth 官方動態版本：unsloth/Muse-Glimmer-30B-NVFP4，結合了 Unsloth Dynamic 2.0 技術，能精準保留關鍵層的精度，其餘使用 FP4 提升推理速度。
Preyazz 社群版 (compressed-tensors)：Preyazz/Muse-Glimmer-30B-NVFP4，模型檔案體積從 BF16 的 56GB 縮減至約 22GB ~ 25GB，視覺編碼器維持在 BF16。
RadixArk 混合精度版 (vendor recipe)：RadixArk/Muse-Glimmer-NVFP4，採用混合 FP4/FP8 精度優化，模型本體進一步壓低到約 18.3 GiB。
