這是前一篇 DGX Spark + NAS 實測 Muse-Glimmer-30B 跑 AIME 2026 的續集。上一篇問的是這個模型的推理能力有沒有官方宣稱的成績 ? 而本文篇問的是另一件事，Muse-Glimmer-30B 能不能真的搭配一個 AI 代理人用呢? 畢竟考試歸考試，能不能做事才是真的，實務上，官方宣稱的成績，通常在正式任務工作上都會打折扣。
AI 代理人實作建議採用量化版本
Meta 官方這次的模型卡，把 Muse-Glimmer-30B 的用途寫得很明確，「本地 AI 代理人：多步規劃、連續工具呼叫、失敗復原、長時程任務執行」，這四個重點就是這篇文章要逐一驗證的東西。
CyberQ 設計的驗證方式，是規劃了四個可以逐項核對答案的任務，讓 Hermes Agent 依序實際去跑，再拿它的回答跟我們放在記事本中的答案資料比對。四個任務可說是分別對應那四種能力，而且每一個都設計成不能單步完成， AI 模型被迫得思考才能做到下一步。
結果一：能力全過，零捏造與幻覺
| 任務 | 能力 | 結果 |
|---|---|---|
| 1 | 連續工具呼叫 | 三個檔案大小吻合 |
| 2 | 多步規劃 | 68 個頂層鍵、34 個 timeout 設定，與獨立計算一致 |
| 3 | 失敗復原 | 精確路徑→遞迴搜尋→模糊比對→列舉替代→帶資訊回問 |
| 4 | 長時程 | 12 個檔案全對，主動限定結論範圍 |
兩輪都跑過，答案穩定。第二輪的失敗復原甚至比第一輪多做了一層更寬的搜尋，找出一個名字相近的候選檔案主動提出來。
結果二：速度要疊兩層最佳化才能符合可用區間
同一台機器、同一個模型，每秒 token 速度差了六倍：
| 組態 | 速度 | 相對 | 一輪 6,000 token 推理 |
|---|---|---|---|
| BF16 原精度 | 4.31 tok/s | 1.00x | 23.2 分鐘 |
| NVFP4 量化 | 12.67 tok/s | 2.94x | 7.9 分鐘 |
| NVFP4 + DFlash 投機解碼 | 26.53 tok/s | 6.16x | 3.8 分鐘 |
（同一映像、300 token、三次取樣、單序列）
這三個數字對應三種截然不同的使用方式，23 分鐘只能當批次工作丟出去，7.9 分鐘勉強能等，3.8 分鐘可以坐在前面看它做事。 如果只用上一篇提到的 BF16 來跑，這台機器就不適合跑 AI 代理人，但是把兩層最佳化都疊上去之後，結論反過來證明它是可用的。
而且 26.53 這個數字還是保守，因為它量的是散文生成。CyberQ 於下方內容提到實測代理人任務時，投機解碼的接受率幾乎翻倍，尖峰吞吐衝到 58.9 tok/s，也可以說這種任務用投機模型可協助 token 輸出是原本 BF16 版本的 12 倍，原因在本文的第四部分。
CyberQ 企業用地端 AI 環境架構
┌─────────────────────────────┐ ┌──────────────────────────┐
│ DGX Spark (GB10) │ │ NAS (QNAP) │
│ 121 GB 統一記憶體 │ │ │
│ │ │ ┌────────────────────┐ │
│ ┌───────────────────────┐ │ HTTP │ │ Hermes Agent │ │
│ │ vLLM │◄─┼────────┼──┤ (容器) │ │
│ │ Muse-Glimmer-30B │ │ :8001 │ │ 終端機/程式碼工具 │ │
│ │ NVFP4 │ │ │ └────────────────────┘ │
│ └───────────────────────┘ │ │ │
└─────────────────────────────┘ └──────────────────────────┘模型跑在 GB10 上，代理人框架跑在 QNAP NAS 的容器裡，兩者透過 OpenAI 相容端點溝通。這個拆法很自然，GPU 在哪裡，推論就在哪裡，代理人本身不吃 GPU，放在一直開機的 NAS 上更合理。
實際跑的溫度還可以，代理人任務和跑影片不同，後者會比較熱且較長的推論時間。
但它也帶來一個後果，著名的 AI 代理人框架 Hermes Agents 呢，它原本的所有預設值都是為每秒數十 token 的雲端 API 設計的，接上一個 4～13 tok/s 的本地端點之後，那些預設值會一個接一個需要調整，這是我們在使用 DS4 跑 DeepSeek V4 Flash 時不會碰到的問題，如果是前面提到最佳化並加上投機模型後的 Muse-Glimmer-30B ，對 Hermes Agents 來說就會更合用。
第一部分：模型端該怎麼部署 ?
為什麼是 NVFP4，以及它到底快多少 ?
先說一個必須先接受的事實，在這台機器上，模型的速度由權重大小決定，跟算力無關。GB10 的統一記憶體頻寬約 273 GB/s。自迴歸生成每產生一個 token，都必須把全部權重讀過一遍。所以：
BF16 權重 55.49 GiB → 273 ÷ 55.49 ≈ 4.9 tok/s 理論上限
NVFP4 權重 21.81 GiB → 273 ÷ 21.81 ≈ 12.5 tok/s 理論上限
CyberQ 實測（同一支腳本、同一個 prompt、300 token 上限、三次取樣）：
| 精度 | 權重 | 實測中位數 | 三次取樣 | 相對 |
|---|---|---|---|---|
| BF16 | 55.49 GiB | 4.31 tok/s | 4.31 / 4.31 / 4.31 | 1.00x |
| NVFP4 | 21.81 GiB | 12.67 tok/s | 12.66 / 12.67 / 12.67 | 2.94x |
三次取樣的離散度呢，BF16 三次只差 0.01，NVFP4 三次只差 0.04。這種近乎零的變異就是頻寬受限的指紋，時間由記憶體匯流排決定，沒有波動的空間。
官方沒有出 NVFP4。meta-models 底下到本文完成為止只有四個 repo：BF16、GGUF、assistant、ExecuTorch。因此，CyberQ 這次實作測試先用的是 RedHatAI/Muse-Glimmer-30B-NVFP4（RedHatAI 即 Neural Magic，vLLM 裡 compressed-tensors 格式的維護者，repo 附完整的 recipe.yaml）。
vLLM 官方 recipe 點名的則是另一個社群版本 Inferact/Muse-Glimmer-30B-NVFP4-W4A4。
如果你也需要測試或先部署，先確認硬體支援再下載。 GB10 是 sm121，而 NVFP4 的 kernel 早期只支援 sm100（B100/B200）。在拉 23 GB 之前，可以直接問 vLLM：
docker exec <容器> python3 -c "
import vllm.model_executor.kernels.linear as L
for n in [n for n in dir(L) if 'NvFp4' in n and 'Kernel' in n]:
k = getattr(L, n)
if hasattr(k, 'is_supported'):
print(n, k.is_supported())
"這台的結果是五個原生 kernel 可用（FlashInfer 的 B12x / Cudnn / Cutlass / Trtllm，加上 Marlin），只有 cutedsl 因為要求 sm_10x 而不可用。確認不是走 emulation 路徑很重要，模擬路徑會把 4-bit 反解成 BF16 再算，速度可能比原生 BF16 還慢。
第二部分：把 Hermes Agent 接上本地端點
Hermes 有兩套機制，用途完全不同：
| 機制 | 用途 | 金鑰怎麼給 | 端點欄位 |
|---|---|---|---|
providers: 字典 | 具名端點，可多組並存，用 /model <模型> --provider <名稱> 切換 | inline api_key 可以 | api: |
fallback_providers: 陣列 | 主要端點掛掉時自動接手（429/500/401/404） | 只吃 key_env（環境變數名） | base_url: |
注意 providers 用的是 api: 而不是 base_url:。 這個欄位名如果照 model: 區塊的寫法猜成 base_url，設定會被靜默忽略，沒有錯誤訊息，只是連不上。
CyberQ 在這一輪採用的設定長這樣：
model:
provider: glimmer
default: muse-glimmer
context_length: 128000
providers:
glimmer:
api: http://<推論主機>:8001/v1
api_key: <你的金鑰>
discover_models: false
models:
- muse-glimmer
request_timeout_seconds: 3600
stale_timeout_seconds: 1800第三部分：代理人能力實測
任務的設計原則是可驗證性
CyberQ 認為，因為要測 Meta 官方宣稱的「多步規劃」和「失敗復原」，因此任務不能是開放式的問答，否則無法判斷它到底做對了沒有，這次設計的四個測試任務都滿足兩個條件，第一個是不能單步完成，後一步的參數必須來自前一步的輸出。第二個條件則是答案已經先準備好在記事本裡面了，到時候可以逐項核對，抓出 AI 有沒有捏造 ?
素材用的是 Hermes 容器內自己的檔案，主要是它自己的設定檔（68 個頂層鍵）和日誌目錄，你要比對它的檔案是相對容易的，資料可以掛載在 QNAP NAS 上，方便核對。
任務 1：連續工具呼叫
列出你的 logs 目錄裡最大的三個
.log檔案（含檔名與大小），然後讀取其中最大那一個的最後 5 行，告訴我那 5 行在講什麼。
第二步的檔名必須來自第一步的輸出。這次測試呢，Muse-Glimmer-30B 它的工具呼叫序列：
Terminal("find /opt/data -type d -name logs")
Terminal("find /opt/data/logs -type f -name '*.log' -exec ls -lh {} +")
Terminal("find /opt/data/logs -type f -name '*.log' -printf '%s\t%p\n'")
Terminal("tail -n 5 /opt/data/logs/errors.log")結果正確，資料吻合：errors.log（1,916,077）、gateway.log（852,374）、gateway-shutdown-diag.log（356,988），引用的五行日誌經核對確實存在於它宣稱的時間點。
有趣的是原本放在記事本的正解反而是錯的，原本應該是 agent.log.1這個檔案才對，但測試期間發生了 5 MB 日誌輪替，而且任務問的是 .log 檔案，所以 Muse-Glimmer-30B 很聰明地用了 -name '*.log' 正確排除了 .log.1 這類輪替檔，這種小任務的實作上它確實有嚴謹到。
任務 2：多步規劃
第二個問題是，你的
config.yaml裡有多少個頂層設定鍵？其中有幾個設定的名稱包含 timeout（含巢狀層級）？把前八個列出來，附上完整路徑與數值。
這題需要讀檔、解析 YAML、遞迴走訪所有層級再計數，不是 AI 它下單次 grep 指令就能完成的。
測試結果答案完全正確，68 個頂層鍵、34 個含 timeout 的設定，跟實際的數字一模一樣。前 8 項它按字母排序列出，路徑與數值全對。當中有一個數字它是猜不到的，這一題證明它真的走完了整個規劃思考鏈。
任務 3：失敗復原（最有價值的一題）
讀取你目錄下的
notes.md，摘要它的內容。
答案是，該檔案不存在。 這一題是代理人與聊天機器人的真正分界。這是因為 AI 模型在這種問題下，有可能出現三種行為，這當中的差距極大，比方說一直重試同一招（差）、直接說找不到（及格）、主動擴大搜尋並提供替代方案（算好）。
而 Muse-Glimmer-30B 它的處理順序是這樣的：
read_file('/opt/data/notes.md') → File not found
find /opt/data -type f -name "notes.md" → 空
find /opt/data -type f -iname "notes*" → 空 ← 主動放寬為模糊比對
列出實際存在的 .md 檔案 → SOUL.md, memories/MEMORY.md, ...
結論：沒有此檔，若你指的是其他路徑請提供，我可立即讀取精確路徑 → 遞迴搜尋 → 模糊比對 → 列舉替代品 → 帶著具體資訊回問。 Muse-Glimmer-30B 沒有重試同一招，沒有捏造內容，而且最後那句回問是帶著可用選項的，不是空泛的請提供更多資訊這種看了會想揍人的回答。
第二輪跑同一題時，它又多做了一層。 前兩次搜尋落空後，這次它把範圍再放寬成 find /opt/data -iname "*notes*"，翻出了一個藏在技能目錄深處的 PORT_NOTES.md，並在結論裡把它連同 SOUL.md、MEMORY.md 一起列為候選，AI 它是這樣寫的：
若你指的是其他路徑或檔案名稱（例如 SOUL.md、MEMORY.md、PORT_NOTES.md）， 請提供正確路徑，我可立即讀取並摘要。
CyberQ 核對過，那個檔案確實存在於它說的路徑。從「找不到，這裡有哪些 .md」進步到「找不到，但這幾個名字看起來可能是你要的」，後者才是真正有用的失敗回報。
任務 4：長時程
逐一檢查你 logs 目錄裡的每一個
.log檔案，回報每個檔案最後一行的時間戳記，最後總結哪一個最新、哪一個最舊。
這次的測試因為有十幾個檔案、跨越多輪，所以要看 AI 它會不會中途偷懶只做前幾個，以及上下文變長後是否還記得原始目標。
測試結果是 12 個檔案全部處理，時間戳記全部正確。 更值得肯定的是它主動限定了結論範圍，也就是呢，把「最舊（有時間戳記者）」找出來，而不是硬把四個沒有時間戳的檔案塞進排序。這是正確的推理習慣，不是每個 AI 模型都會這樣做。
換上更快的組態之後，重跑一輪
上述四個任務第一輪是在 12.67 tok/s（純 NVFP4）之下跑的，投機解碼上線後，我們又請 Hermes 重跑了一遍。
答案完全穩定。 任務 1 的三個檔案大小仍然位元組級吻合（檔案在期間持續增長，它報的是讀取當下的值），任務 2 仍然是 68 與 34，而且這次前八項按 YAML 文件順序列出，與實際計算逐項相同、連順序都一樣，任務 3 如上所述還更進一步成長。
值得一提的是這一輪 Hermes 端的錯誤日誌是乾淨的，輔助任務的 fallback 鏈錯誤與標題產生逾時全部消失。第一輪那些錯誤每一筆都在拖慢實際體感，只是它們不會讓任務失敗，所以很容易被忽略。
觀察到的兩個缺陷
不過呢， Muse-Glimmer-30B 也是有一些不好的部分，這邊先挑二個出來。
推理內容洩漏到回答裡。 任務 1 的輸出中夾雜了這樣一段：
Second execute_code gave later lines about auxiliary client unavailable etc. … Let’s do final terminal tail to confirm.
那是模型的內部推理，不該出現在 content 通道顯示給人類看。可能與 muse_glimmer 的 reasoning parser 加上串流輸出的互動有關，原因目前未知。
重複的工具呼叫。 任務 1 用了 5 次工具呼叫，其中 tail -n 5 errors.log 執行了兩次，第二次是說要再確認一下，這雖然不算錯誤，但在 13 tok/s 的機器上，每次多餘的往返都是浪費大家時間哪。
第四部分：投機解碼，衝六倍速度的最後一塊
這一節是全文最曲折的部分，最後的結果也最好，達到 26.53 tok/s，相對純 NVFP4 是 2.09 倍，相對 BF16 是 6.16 倍。
Muse-Glimmer 附了一個 DFlash 草稿模型（meta-models/Muse-Glimmer-30B-assistant，2.56B 參數、5 層、5.11 GB）。它一次前向傳遞預測 16 個 token 的區塊，主模型再平行驗證。
投機解碼正是頻寬受限機器的正解，原本機器的瓶頸會耗費在大的權重上，而投機解碼小模型的機制，讓一次權重讀取產出多個被接受的 token，只要接受率越高，猜中的命中率提高，直接打破那個天花板。
但要讓它跑起來，這次測試比較辛苦連撞五道關卡，且有個轉折，原本只清掉四道，第五道判定為無解而停手，隔天官方映像更新，五道關卡全部消失。
稍微保留完整的診斷過程，理由是那些診斷後來被上游的修法一一驗證，如果你手上是舊映像，那些繞法仍然有效，而什麼時候該自己修、什麼時候該等上游這個判斷本身，比任何一道關卡都值得思考。
| # | 障礙 | 性質 | 需要處理的地方 | 新映像檔 |
|---|---|---|---|---|
| 1 | 架構名被無條件加上 DFlash 前綴 | vLLM bug | 改草稿設定繞過 | 補上帶前綴的註冊別名 |
| 2 | 排程槽位算成負數 | 設定不足 | 兩個參數補上 | 仍需要（本來就不是 bug） |
| 3 | .model 屬性斷言 | vLLM bug | 本地函式庫 | 上游修法相同 |
| 4 | 滑動視窗大小讀不到 | 設定缺漏 | 補 swa_window_size | 不再觸發 |
| 5 | 缺少 encoder 子模組 | 版本落差 | 停手 | 補上權重名稱映射 |
| 5 | 實作缺少 encoder 子模組 | 映像版本落差 | ❌ 無解 | 更新後即解 |
每一關的錯誤訊息都不會告訴你下一關在哪。這也解釋了為什麼初期的成功案例並不多。
隔天：映像更新，五關全消
vllm/vllm-openai:muse-glimmer 這個 tag 更新了。
實測結果
五關全消之後，唯一還需要的設定是第二關那兩個參數，是投機解碼模型機制需要的：
- '--speculative-config={"method":"dflash","model":"/draft","num_speculative_tokens":15}'
- --max-num-seqs=16
- --max-num-batched-tokens=8192同一個映像上的對照：
| 組態 | 單序列速度 | 三次取樣 | 相對 |
|---|---|---|---|
| NVFP4 | 12.67 tok/s | 12.66 / 12.67 / 12.67 | 1.00x |
| NVFP4 + DFlash | 26.53 tok/s | 26.13 / 26.53 / 27.39 | 2.09x |
引擎回報的投機解碼統計：
Mean acceptance length: 3.05 ~ 3.52 Drafted throughput: 127.49 tokens/s Accepted throughput: 17.40 ~ 20.80 tokens/s
草稿模型每次提出 16 個 token 的區塊，主模型平行驗證後平均接受 3.3 個。也就是一次權重讀取產出 3.3 個 token 而不是 1 個，這正好對應約 2 倍的實測加速，其餘的差額被草稿模型本身的計算成本吃掉。
同時呢，三次取樣的離散度變了。本文最前面原本有提到在 BF16 測三次差 0.01、NVFP4 則差 0.04，那是純頻寬受限的零變異特徵，而投機解碼這三次則差到 1.26。因為速度不再只由頻寬決定，還取決於草稿被接受多少，而接受率隨內容而變。日誌裡的平均接受長度在 3.05 到 3.52 之間跳動就是這個原因。
一個必須標明的限制
WARNING: Draft model DFlashQwen3ForCausalLM does not support external
multimodal embeddings. Embeddings from the target model will not ...目前草稿模型不支援多模態嵌入。 Muse-Glimmer 的視覺能力本身沒問題，CyberQ 在之前的測試有驗證過，但在有圖片輸入的情境下，這個加速不一定拿得到。如果你的用途以視覺為主，這 2 倍記得要再打折扣。
確實是可擔任 AI 代理人的較小型可用模型
Meta 說它適合代理人，這件事在能力層面是成立的。 四個任務全過、零捏造、失敗復原的處理還不錯。這不是那種「看起來會用工具」的模型，它是真的在規劃、真的在根據結果調整。
但「適合本地代理人」這句話隱含了硬體前提，而那個前提要靠兩層最佳化才補得起來。 官方宣稱的場景假設 6,000 token 的推理只要幾秒。在 273 GB/s 的統一記憶體上跑 BF16 需要 23 分鐘，改用量化模型 NVFP4 則是 7.9 分鐘，如果再疊上 DFlash 投機解碼則可快到 3.8 分鐘。
CyberQ 歸納，這三個數字對應三種截然不同的使用方式，23 分鐘只能當批次工作丟出去，7.9 分鐘勉強能等，3.8 分鐘可以坐在前面看它做事。 同一台機器、同一個模型，差別全在部署方式。
如果你要在類似的機器上做這件事，CyberQ 提供三個建議：
NVFP4 加投機解碼，兩層都要。 單獨量化是 2.94 倍，再加投機解碼是 6.16 倍。BF16 只在需要跟官方 benchmark 數字對照時才有意義，所以要日常工作用不會拿來用。
把 --max-model-len 開到原生長度。
檢查代理人框架的每一個逾時預設值。 Hermes 那三個坑全都是同一件事的不同面貌，雲端 API 的預設值接上慢速端點之後失效，所以要放寬秒數。
最後一點值得我們思考，慢速本地模型其實會暴露出框架裡所有隱含的速度假設。 逾時、上下文長度探測、fallback 鏈、壓縮觸發點，這些在雲端 API 上從來不會出問題的設計，接上一個 13 tok/s 的端點之後全部浮上檯面。這既是麻煩，也是理解這些框架實際如何運作的好機會。
測試環境：NVIDIA GB10 (DGX Spark)、128 GB 統一記憶體、aarch64、vLLM 官方容器 vllm/vllm-openai:muse-glimmer、Muse-Glimmer-30B（BF16 與 RedHatAI NVFP4）、Hermes Agent 執行於 QNAP NAS 容器。
