【2026 最新】Muse Glimmer 30B 本機教學：24GB GPU 跑 Agent、DFlash 與長 Context 踩坑

下載 GGUF 只是第一關。這篇 Muse Glimmer 30B 本機教學要處理的，是同一個模型為什麼有時像能自己修測試的 Agent，有時卻用掉 21K 總 tokens、重複呼叫工具，最後連一個小網頁也沒完成。真正會改變結果的，通常是量化檔、llama.cpp 版本、每個 slot 的 Context、chat template、thinking budget，以及到底由誰控制 Agent loop。只要你會在 Terminal 貼指令，本文會帶你從選檔一路做到測試可驗收。

Meta 在 2026 年 8 月 10 日公開 Muse Glimmer，定位是可在消費級硬體本機執行的 30B 級 Agent 模型。熱度很高：Hacker News 討論在 8 月 12 日查核已達 1,164 points／631 comments；但社群同時出現成功 tool calling、任務耗掉 21K 總 tokens，以及 DFlash 變慢等互相衝突的回報。熱度證明需求，不等於每一組設定都可靠。

本文把可重現與推測分開：官方 GGUF、模型 metadata、llama.cpp 參數與公開 Issue 已逐項核對，並在 2026 年 8 月 12 日從原始碼成功建置 commit f785fc9 的 llama-server；本文環境只有 16GB unified memory，沒有假裝跑過 17GB 權重。RTX 3090 的 22–23GB、64–124 tok/s 與 150K needle 結果，都只當單一使用者現場紀錄，不是 AlphaLab 實測或硬體保證。

Muse Glimmer 30B 本機教學先說結論

• 24GB NVIDIA GPU：先用 Meta 官方 17GB text GGUF、-np 1、32K Context 跑通，再升到 131K；圖像與 DFlash 都後加。
• 24GB Apple Unified Memory：不是 24GB 獨立 VRAM，macOS 與應用程式共用同一池；17GB 權重可能載入，卻不代表 131K、mmproj、DFlash 能同時穩定常駐。
• 131K 才是原生設定：官方 config 與 GGUF metadata 都是 131,072；262K 是超出該 metadata 的實驗性 runtime extension。
• DFlash 目前先不要開：截至 8 月 12 日，官方 Meta GGUF 搭官方 drafter 有公開崩潰 Issue，修補 PR 仍未合併。
• Agent 成敗不等於模型分數：先固定任務、tool schema、loop 上限與測試，再和 Qwen 做同條件 A/B。

先記住一條公式：本機 Agent ＝ Muse（引擎）＋ llama.cpp（傳動）＋ OpenCode（駕駛）。mmproj 像眼睛，DFlash 像渦輪，都是選配；它們不會把錯誤的 runtime 或失控的 Agent loop 自動修好。

Muse Glimmer 30B 是什麼？先拆開四個檔案

Meta 官方 GGUF repo不是「選一個 Q4 就結束」，而是四個可相加的元件：17GB text model 實際為 Q4_K／Q6_K 等混合量化，檔案 16.76GB；較高品質的 Dynamic text model 是 19.65GB；mmproj-kquant.gguf 是 1.40GB 圖像 encoder；dflash-kquant.gguf 是 1.63GB speculative drafter。只做文字 coding Agent 時，mmproj 完全可以省下。

若改用 Unsloth 動態量化，Q4_K_XL 約 15.88GB、Q5_K_M 約 19.19GB、Q5_K_XL 約 21.79GB、Q6_K_XL 約 26.27GB。24GB 顯卡最務實的是官方 17GB 或 Q4_K_XL；Q5_K_M 即使 text-only 看似能塞，也容易把完整 131K KV cache 與 runtime headroom 擠掉。32GB unified memory 才較適合 Dynamic 或 Q5 再加周邊；48GB 才有餘裕考慮 Q6。16GB 裝置雖有 Q2／Q3 檔案，對長 Context Agent 不是本文建議起點。

這也解釋「24GB 能跑」的精確含義：Meta 是替 17GB build 標示 24GB target，不是保證任何 24GB 系統、任何 Context 與三個伴隨檔都不 OOM。想先理解權重、KV cache 與 runtime 的分工，可搭配 LLM 推論引擎白話教學。

步驟一：更新 llama.cpp，先建立沒有 DFlash 的基線

Muse Glimmer 支援從 llama.cpp b10353才正式進入 release。舊版可能不認得 architecture，或把原始 channel marker 當成正文。NVIDIA 建置加上 CUDA；Apple Silicon 不加，Metal 會自動啟用：

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
git pull --ff-only

# NVIDIA
cmake -B build -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON

# Apple Silicon 改用：
# cmake -B build -DBUILD_SHARED_LIBS=OFF

cmake --build build --config Release -j \
  --target llama-cli llama-mtmd-cli llama-server
./build/bin/llama-server --version

接著只下載 17GB text model。需要讀螢幕截圖時才補 mmproj；DFlash 先不下載也不影響模型回答：

python3 -m pip install -U huggingface_hub
hf download meta-models/Muse-Glimmer-30B-GGUF \
  --include "muse-glimmer-30B-kquant-17gb.gguf" \
  --local-dir Muse-Glimmer-30B-GGUF

第一次只開 32K。--jinja保留明寫，reasoning strength 從 low 開始，並把每次 generation 的 thinking 硬上限設成 4,096 tokens；這不是 12-step Agent 任務共用一個 4K 額度。Muse 的 template 會固定開啟 thinking channel；--reasoning off不是可靠的關閉方式。

./build/bin/llama-server \
  -m Muse-Glimmer-30B-GGUF/muse-glimmer-30B-kquant-17gb.gguf \
  -a muse-glimmer-30B \
  -ngl 99 -c 32768 -np 1 \
  --host 127.0.0.1 --port 8080 \
  --jinja \
  --temp 1.0 --top-p 0.95 --top-k 64 \
  --chat-template-kwargs '{"reasoning_strength":"low"}' \
  --reasoning-budget 4096

啟動 log 要確認 model architecture 是 Muse Glimmer、n_ctx_slot 是 32,768，而且 GPU layers 符合預期。再用 Chat Completions 做最小 smoke test；若 content以 to=self<|message|>開頭，通常代表 raw protocol 沒被正確解析，先更新 runtime 並檢查 reasoning parser，不要調 prompt 掩蓋問題。

curl -s http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model":"muse-glimmer-30B",
    "messages":[{"role":"user","content":"17 × 23 是多少？只回數字。"}],
    "max_tokens":4608
  }' | python3 -m json.tool

步驟二：跑到 131K，別被 -c 與 -np 偷切 Context

llama-server會把 -c除以 -np分給每個 slot。官方範例的 -c 131072 -np 4，單一請求其實只拿到 32,768；對會長時間 thinking 與反覆工具呼叫的 Agent，這個差異足以把正常結束變成無答案截斷。單一 full-context 任務應改成：

# 保留上一段所有參數，只改這兩項
-c 131072 -np 1

若真要四個 request 同時各拿 131K，總 Context 必須是 -c 524288 -np 4，這已不是合理的單張 24GB 設定。Context 越大也不代表推理越可靠：官方 config 是 131,072，Meta 的 BEAM-128K 成績也不是滿分。請至少在 10%、50%、90% 三個深度放不同 nonce，記錄套完 template 後的實際 token 數、prompt hash、首字時間、答案 exact match 與 peak memory；只找回一根 needle，不能證明長時程 Agent 能完成任務。

262K Context：可以試，不可叫原生上限

Unsloth 與社群把 Muse 延伸到 262,144，但官方 config.json與兩個 Meta GGUF 的 metadata 都是 131,072。若你接受「超出原生設定、可能 OOM、recall 可能退化」，才在純模型基線上把 runtime Context 改成：

-c 262144 -np 1

這一輪先不要同時加 mmproj 或 DFlash，並沿用同一組多深度測試。失敗順序要分清楚：載入 OOM 是容量問題；prompt ingestion 卡住是 prefill／runtime 問題；找到 nonce 卻做錯推理是能力問題；沒有 final answer 則先看 client 的 max_tokens、thinking budget 與每 slot Context。關於長 Context 為什麼需要管理而不是一味放大，可延伸看 Context Engineering 教學。

步驟三：接上 OpenCode，完成一個可驗收 Agent 任務

Agent harness 不是漂亮 UI，而是把 model、tool result、terminal 與下一輪請求串起來的迴圈。若概念還陌生，可先讀 AI Agent 三層架構。這裡用 OpenCode當外部 harness；不要同時啟用 llama-server --agent或內建 --tools，否則兩層都想管理工具，錯誤會很難定位。

curl -fsSL https://opencode.ai/install | bash
opencode --version

先確認已有 Node.js 20 以上，再建立一個可整包刪除的測試 repo；空白的實作與測試檔會讓每次起點一致：

node --version
mkdir muse-glimmer-smoke
cd muse-glimmer-smoke
npm init -y
npm pkg set scripts.test="node --test"
touch slugify.js

不要讓模型自己出題、自己打分。先把以下固定測試存成 slugify.test.js；A/B 時每個模型都面對相同 expected outputs：

const test = require('node:test');
const assert = require('node:assert/strict');
const { slugify } = require('./slugify.js');

test('English spacing', () =>
  assert.equal(slugify('Hello   World'), 'hello-world'));
test('accent marks', () =>
  assert.equal(slugify('Crème brûlée'), 'creme-brulee'));
test('Traditional Chinese', () =>
  assert.equal(slugify('繁體 中文'), '繁體-中文'));
test('duplicate hyphens', () =>
  assert.equal(slugify('Alpha---Beta'), 'alpha-beta'));
test('empty string', () =>
  assert.equal(slugify(''), ''));

接著在這個目錄建立 opencode.json，用 OpenAI-compatible provider 指向本機 API。這些是 OpenCode 工具層的限制：內建 web 工具、subagent、外部目錄與重複 loop 都關閉，其他未列操作先詢問：

{
  "$schema": "https://opencode.ai/config.json",
  "model": "llama.cpp/muse-glimmer-30B",
  "provider": {
    "llama.cpp": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "llama-server (local)",
      "options": {
        "baseURL": "http://127.0.0.1:8080/v1"
      },
      "models": {
        "muse-glimmer-30B": {
          "name": "Muse Glimmer 30B",
          "limit": {
            "context": 131072,
            "output": 32768
          }
        }
      }
    }
  },
  "agent": {
    "muse-bounded": {
      "description": "Bounded local coding-agent smoke test",
      "mode": "primary",
      "model": "llama.cpp/muse-glimmer-30B",
      "temperature": 1.0,
      "steps": 12,
      "permission": {
        "*": "ask",
        "read": "allow",
        "edit": "allow",
        "glob": "allow",
        "grep": "allow",
        "list": "allow",
        "doom_loop": "deny",
        "external_directory": "deny",
        "webfetch": "deny",
        "websearch": "deny",
        "task": "deny",
        "skill": "deny",
        "bash": {
          "*": "ask",
          "npm test": "allow",
          "npm test *": "allow",
          "node --test": "allow",
          "node --test *": "allow",
          "git status": "allow",
          "git status *": "allow",
          "git diff": "allow",
          "git diff *": "allow",
          "rm *": "deny",
          "git commit*": "deny",
          "git push*": "deny"
        }
      }
    }
  }
}

git init
git add .
git -c user.name="Muse Tutorial" \
  -c user.email="muse-tutorial@example.invalid" \
  commit -m "starter fixture"

opencode
# 進入後按 Tab，切到 muse-bounded

若你改用 Unsloth server 接 OpenCode，依其整合文件加上 --disable-tools，讓 tool call 回到 OpenCode；否則模型看似有回答，檔案卻可能完全沒改。先在可刪除的 Git repo 跑固定任務，不要拿主專案當第一個 sandbox：

在 slugify.js完成並 export 不依賴第三方套件的 slugify(text)。需求：NFKD、移除變音符號、轉小寫、空白變連字號、合併重複連字號；不得修改既有 slugify.test.js，完成後執行 npm test。先讀現有檔案再改；同一錯誤連續三次就停下，列出 blocker，不要繼續猜。

steps: 12限制的是 agent iterations，不是精確 12 次 tool calls；到上限後 OpenCode 會要求文字總結。完成標準不是「模型說好了」，而是 npm test exit code 為 0、Git diff 可讀，且 git diff --exit-code HEAD -- slugify.test.js確認測試沒有被改。這份設定允許 Agent 改寫 repo 內檔案，所以務必使用可丟棄目錄；permission 只管 OpenCode tool calls，不會攔截測試程式自己的檔案或網路 syscall，真正隔離不受信任程式仍要用 container／VM。本機模型不會把不可逆動作自動變安全。若想理解最小 loop 的結構，可參考 最小 AI Agent Harness 實作；密鑰與 session log 則看 AI Agent 密鑰安全教學。

DFlash 怎麼開？截至 8 月 12 日先等修補

DFlash 是五層 drafter，一次提出 16-token block，再由 Muse 驗證。正確 speculative decoding 應維持 target model 的分布；它解決的是 decode 速度，不會治療過度思考、錯工具 schema 或 150 次 loop。Meta 自報 RTX 5090 的 17GB model 從 74.9 提升到 233.4 tok/s；M4 Max／M5 Max 的 1.5×／1.8×則來自 ExecuTorch，不是 Apple 上的 llama.cpp保證。

更重要的是即時 blocker：Issue #26894由一名使用者在 llama.cpp b10349重現官方 Dynamic target GGUF 搭官方 DFlash，因 sliding_window_pattern的 array metadata 在 bind 時崩潰；修正的 PR #26900已獲 approve，但截至本文查核仍 open、未進 release。本文檢查到兩個官方 text GGUF 都帶相同 array encoding，因此在 17GB 配對也重新跑通前，最安全的教學就是關閉 DFlash，等第一個包含該修補的正式版本。

修補合併後，先更新、確認 release／commit 包含 PR，再在完全相同 prompt 下做 A/B；目前新版 help 對本機 drafter 明確提供的參數是：

--spec-type draft-dflash \
-md Muse-Glimmer-30B-GGUF/dflash-kquant.gguf \
-ngld 99 \
--spec-draft-n-max 15

記錄 baseline tok/s、DFlash tok/s、draft acceptance、平均接受長度與額外記憶體；若 acceptance 很低、總速度反而下降，就關掉。不要量化 draft KV cache 來硬擠 24GB 後，還把 acceptance 下滑誤判成模型變笨。

Muse 與 Qwen 怎麼公平比較？固定整條 bundle

同一模型換 runtime 或 harness 就可能像換了腦袋。公平 A/B 應固定 GPU、llama.cpp commit、OpenCode 版本、Context、KV precision、temperature、最大 output、tool schema、初始 repo 與上面的 slugify prompt；再替 Qwen 選能在同硬體常駐、量化品質相近的 27B 級 thinking GGUF。DFlash 關閉後先比能力，速度另開一輪。

• 成功率：乾淨 checkout 重跑 5 次，記測試通過、人工驗收與是否完成 final answer。
• 成本：wall time、prompt／completion／reasoning tokens、工具呼叫總數、重複呼叫數與最大連續失敗。
• Context：每 slot 實際上限、峰值使用量、是否因 client max_tokens或 Context 耗盡而截斷。
• 速度：prefill 與 decode 分開；DFlash 另記 acceptance，不能只貼最高 tok/s。

社群裡，一名使用者回報失敗任務共耗約 21K tokens，但沒有拆分 reasoning 與 content；另一名使用者回報約 150 次 tool calls。兩者都是有用警訊，也都只是單一使用者紀錄。診斷順序應是：把 reasoning strength 降到 low、每次 generation 的 budget 先設 4K；確認 n_ctx_slot；不要把 <|eom|>當 stop token；檢查 harness 是否把 tool result 原樣送回；三次相同錯誤即停。最後才換 quant 或模型。想把 loop 變成可觀察系統，可接著讀 Agent Observability 教學。

公開 benchmark 也只適合校準期待。Artificial Analysis測得 Muse 在 Terminal-Bench v2.1 為 51.7%，低於 Qwen3.6-27B Thinking 的 60.7%；Tau3-Banking 則是 Muse 23.5%、Qwen 16.7%。其 AA-Omniscience 6,000 題英文開放知識集，Muse 的 benchmark-specific hallucination rate 約 81.94%；這不能改寫成「日常回答有 82% 幻覺」，也不是本機 17GB 繁中測試。結論只能是能力分布不平均，不能宣布其中一方全面勝出。

一份可重現紀錄，至少要留下什麼？

不要只截一張「成功」畫面。每輪先建立環境指紋：GPU／unified memory 容量、OS、driver、llama.cpp release 與 commit、GGUF 完整檔名與 SHA-256、OpenCode 版本、啟動命令、n_ctx_slot及 KV precision。如此一來，DFlash 修補、runtime 更新或模型檔被替換後，才知道兩次結果是否仍在比較同一件事。

• 容量層：cold load 是否成功、峰值 VRAM／memory、swap、模型與 sidecar 各自大小。
• 速度層：prefill、首個可見字、decode tok/s 分開；DFlash 額外記 acceptance 與 accepted length。
• 行為層：reasoning tokens、agent iterations、工具呼叫、重複命令、第一次有效 edit 在第幾步。
• 結果層：五個 fresh checkout 各自 pass／fail、測試 exit code、Git diff 與人工驗收，不只報最好的一次。

比較順序也要固定：先用同一 quant 做 32K → 131K，接著才比較 Q4／Q5；能力結論完成後，再測 DFlash on／off；262K 永遠另列 experimental。若一次同時換 quant、Context、KV cache、sampler 與 harness，最後即使成功，也無法知道是哪一項真正改善。測試超時、OOM、沒有 final answer 與測試失敗要分成四種結果，不能全部塞進「模型不行」。

最後用讀者真正會做的任務判讀：若模型只是回答單一函式，長 Context 優勢沒有被測到；若任務要讀十個檔案、改碼、跑測試與修復失敗，就同時考驗記憶、工具與停止能力。每個模型至少重跑五次，報中位數與失敗分布；一次成功是 demo，穩定成功才接近日用。

什麼時候不該選 Muse Glimmer？

• 一次性 coding：若只是改一個函式，下載近 17GB、維護 runtime 與校正 harness 的成本可能大於 API；先以同任務和已熟悉的 Qwen 比成功率。
• 事實密集工作：早期 Omniscience 顯示校準偏弱；必須加檢索、引用與外部核對，不能靠長 Context 取代查證。
• 低於 24GB 的主機：極低 bit 量化雖可能載入，Context、OS 與 Agent loop 的餘裕太小。
• 需要穩定 262K：截至 2026 年 8 月 12 日，Meta model card 公開的是 BEAM-128K；本文查核的官方材料沒有提供 262K reliability 結果。
• 要立即用 DFlash 上線：官方配對仍卡在 open bug；等修補 release 與自己的 acceptance A/B。

Muse Glimmer 30B 本機教學常見問題

1. RTX 3090 24GB 真的裝得下嗎？

官方 17GB text weights 有合理空間，但不是所有組合保證。先用 32K、text-only、單 slot；成功後再升 131K。mmproj、DFlash 與 Dynamic 不要同時加入第一輪。

2. 24GB Mac 等於 24GB 顯卡嗎？

不等於。Apple unified memory 還要供 macOS、CPU、GPU 與其他程式共用；看到 17GB 檔案大小，不能直接推成完整 131K Agent 穩定可用。

3. 官方 17GB 是 Q4 還是 Q5？

它是混合 K-quant，不是單一 Q4／Q5 標籤。若要一般 Q4_K_XL 或 Q5_K_M，才看 Unsloth 版本；比較品質時要把 quant 檔名寫完整。

4. mmproj 一定要下載嗎？

只有圖像輸入需要。純文字與 coding Agent 可省下約 1.4GB；圖片 CLI 要用 llama-mtmd-cli，不是普通 llama-cli。

5. 為什麼設 131K，Agent 還是 32K 就截斷？

先看 -np。-c 131072 -np 4會分成四個 32,768 slot；單一 full-context request 要用 -np 1。

6. 現在可以直接開 DFlash 嗎？

官方 Meta GGUF 配對目前不建議。等 PR #26900 合併並進入 release，再以 DFlash on／off 做同 prompt A/B；不要照舊 README 當成已跑通。

7. 能不能完全關掉 Muse 的 thinking？

template 仍會固定開啟 thinking channel。--reasoning-budget 0可讓 llama.cpp立即結束該段，但這不等於 --reasoning off被 template 支援；較穩妥的起點是 reasoning_strength=low加有限 budget，再看任務品質。

8. 262K Context 可以拿來做 production 嗎？

目前不宜。它是超出官方 131,072 metadata 的實驗性 runtime extension；至少先通過多深度 recall、推理、Agent 任務與長時間記憶體測試。

給新手的 7 個重點

1. 24GB 先選官方 17GB 或 Q4_K_XL，不從 Dynamic／Q5_K_XL 開始。
2. text-only 先省略 mmproj，DFlash 等修補 release。
3. 32K smoke test 通過後，才升 131K；每次只改一個變數。
4. 單一 full 131K request 用 -np 1，並看 n_ctx_slot。
5. 262K 是 extension，不是原生可靠性承諾。
6. OpenCode 擁有工具與 loop；模型 server 只供 API。
7. 用測試、tool-call 數與截斷原因驗收，不用 tok/s 或模型自述代替成功。

如果你想把這條本機 Agent pipeline 延伸成自己的可驗收專案，可從 AlphaLab 課程練習部署、測試與停止規則，也可到 AI 專區追蹤 DFlash 修補與本機模型更新。