Meta 在 2026 年 8 月發布 Muse Glimmer 30B，這是一款能在消費級硬體執行的開放權重多模態模型。它將工具呼叫、多步驟規劃、圖片理解與錯誤恢復整合在約 30B 參數中，官方把長時間運行的本機 Agent 列為主要用途。推論與工具都在本機執行時，檔案與操作過程不必送到雲端。
官方提供完整 BF16 權重、兩種 4-bit GGUF 量化版、圖片編碼器與 DFlash drafter。入門版本的模型檔是 16.8GB，目標硬體為 24GB VRAM；品質較高的版本是 19.7GB，目標為 32GB VRAM。Muse Glimmer 在訓練與評測時就納入工具使用、失敗重試與完整 Agent 任務，不是只提供一般聊天能力。
Muse Glimmer 30B 是什麼
Muse Glimmer 是 Meta Superintelligence Labs 開發的 29.6B dense causal Transformer，其中約 1.8B 參數是讀取圖片的 perception encoder。模型接受文字與圖片輸入，輸出仍是文字，context length 為 131,072 tokens 以上，knowledge cutoff 是 2026 年 1 月 4 日。
Dense 代表每次生成都會使用整個模型，不像 MoE 只啟用部分參數。它需要搬動接近 30B 的權重，因此硬體需求不算低；好處是執行方式與記憶體占用相對容易預估，也能交給 llama.cpp、ExecuTorch 等本機推論工具處理。
Muse Glimmer、Muse Spark 與 Llama 的關係
Muse Spark 是 Meta Superintelligence Labs 在 2026 年推出的模型家族。Muse Glimmer 則是從 Muse Spark 蒸餾而來，把較大型模型的 Agent 能力壓進 30B 尺寸，兩者不是同一個模型換名稱，也不能把 Glimmer 的成績當成 Muse Spark 1.2 的成績。
Llama 是 Meta 先前的開放權重模型家族，Muse Glimmer 採用不同的模型架構與 chat template。GGUF metadata 使用的是 muse-glimmer.* namespace，舊版 llama.cpp 甚至無法辨識。這也表示只把檔案改名成 Llama，或沿用 Llama 的 prompt template，不會得到正確結果。
為本機 AI Agent 訓練的能力
一般聊天模型也能放進 Agent 框架，但會不會呼叫工具只是起點。實際任務可能經過數十次讀檔、搜尋、執行與修正，只要其中一次 function call 格式錯誤，或工具回傳與預期不同，整個工作就可能中斷。
- 多步驟規劃：在較長的工作流程中保留目標與已完成步驟。
- 工具呼叫：依照 JSON Schema 產生參數，持續使用不同工具。
- 錯誤恢復：工具失敗時分析錯誤並重試，不是直接停止。
- 圖片理解：讀取畫面截圖、圖表與文件，再決定後續操作。
- Agent 框架相容性：官方點名 OpenClaw、Hermes Agent，也能放進其他支援自訂模型與工具呼叫的框架。
- 推理強度：支援 low、medium、high、xhigh 四種 reasoning strength。
模型本身不會因為下載到電腦就自動變成 Agent。它仍需要外層程式提供 shell、瀏覽器、檔案與 MCP 等工具，並決定哪些操作要經過人工確認。可以把 Muse Glimmer 想成負責規劃與選工具的大腦，Agent framework 才是讓它動手的執行環境。
這個差別也牽涉安全性。先前的 AI Agent 沙盒事故整理 顯示，模型能力、工具權限與網路隔離必須分開看。本機執行能減少資料送往雲端，卻不代表 Agent 可以直接取得整台電腦的最高權限。
24GB 與 32GB 硬體需求
Meta 把 Muse Glimmer 權重量化到約 4-bit，官方提供以下三個選擇：
| 版本 | 模型或權重大小 | 官方目標硬體 | 平均品質衰退 |
|---|---|---|---|
| BF16 | 約 59.6GB | 64GB VRAM | 基準 |
| K-Quant-Dynamic | 19.7GB | 32GB VRAM | 0.2% |
| K-Quant-17GB | 16.8GB | 24GB VRAM | 1.0% |
這裡的 24GB 不是只看模型檔能不能塞進去。17GB 版本加上 1.4GB 圖片編碼器與 1.6GB DFlash drafter，大約會使用 20GB，還要保留 KV cache、推論程式與作業系統空間。NVIDIA 24GB 顯卡可以把主要元件放進 VRAM，但 context 開得越長，剩餘空間越少。
Mac 的 Unified Memory 同時由 macOS、一般程式與 GPU 使用。24GB Mac 雖然可能載入純文字的 17GB 量化版，實際可用空間比 24GB 獨立顯卡更緊，開啟圖片與 drafter 後容易發生記憶體壓力。若目標是長時間跑 Agent，32GB 只能算入門，36GB 以上會比較有餘裕。
官方測得的生成速度
DFlash 會先一次猜測 16 個 tokens，再由主模型平行驗證。候選 tokens 通過主模型驗證時便一次接受，錯誤才由主模型修正。依官方說明，這不改變主模型的輸出分布，但不必永遠逐 token 生成。
| 硬體 | 一般生成 | 搭配 DFlash | 加速幅度 |
|---|---|---|---|
| RTX 5090 | 74.9 tok/s | 233.4 tok/s | 3.1 倍 |
| Apple M4 Max | 23.7 tok/s | 37.8 tok/s | 1.5 倍 |
| Apple M5 Max | 26.6 tok/s | 50.2 tok/s | 1.8 倍 |
以上是 Meta 以 batch size 1、greedy decoding 測得的數字，M4／M5 使用 ExecuTorch，RTX 5090 使用 llama.cpp。實際速度還會受到量化版本、context、記憶體頻寬與 Agent 每次輸入長度影響，不能把表格當成所有電腦固定會得到的速度。
llama.cpp 本機執行方式
目前官方明確提供 Meta GGUF 與 llama.cpp 操作方式。Muse Glimmer 需要 llama.cpp build b10353 以上，舊版尚未註冊這個架構，載入時會直接失敗。截至本文撰寫時，Ollama 與 LM Studio 官方模型目錄尚未收錄 Muse Glimmer。一般本地模型的安裝概念可參考 Ollama 入門教學。
17GB 量化版下載
先安裝 Hugging Face CLI，再下載文字模型與圖片編碼器：
# 安裝 Hugging Face CLI
pip install huggingface_hub
# 下載適合 24GB 顯卡的模型與圖片編碼器
hf download meta-models/Muse-Glimmer-30B-GGUF \
--local-dir Muse-Glimmer-30B-GGUF \
--include "Muse-Glimmer-30B-KQuant-17GB-Q4_K_M.gguf" \
--include "mmproj-Muse-Glimmer-30B-Q4_K_M.gguf"如果電腦有 32GB 以上可用顯示記憶體，可以把文字模型換成 Muse-Glimmer-30B-KQuant-Dynamic-Q4_K_XL.gguf。要使用 DFlash，再多下載 dflash-Muse-Glimmer-30B-Q4_K_M.gguf，會增加約 1.6GB 占用。
文字對話設定
# 確認版本，build number 必須是 10353 以上
./build/bin/llama-cli --version
# 以 32K context 啟動文字對話
./build/bin/llama-cli \
-m Muse-Glimmer-30B-GGUF/Muse-Glimmer-30B-KQuant-17GB-Q4_K_M.gguf \
-ngl 99 -c 32768 \
--jinja \
--temp 1.0 --top-p 0.95 --top-k 64--jinja 不能省略，因為 Muse Glimmer 使用自己的 ATEM tool-calling template。模型支援 131K 以上 context，不代表每台電腦都該一開始開滿。先用 32K 確認速度與記憶體，再依工作需求增加，會比載入失敗後才找原因省時間。
圖片輸入設定
文字用 llama-cli，圖片則要改用 llama-mtmd-cli 並指定 perception encoder：
./build/bin/llama-mtmd-cli \
-m Muse-Glimmer-30B-GGUF/Muse-Glimmer-30B-KQuant-17GB-Q4_K_M.gguf \
--mmproj Muse-Glimmer-30B-GGUF/mmproj-Muse-Glimmer-30B-Q4_K_M.gguf \
-ngl 99 -c 32768 \
--jinja \
--temp 1.0 --top-p 0.95 --top-k 64 \
--image screenshot.png \
-p "說明畫面上的錯誤訊息，列出可能原因與檢查順序。"Muse Glimmer 不是圖片生成模型。圖片能力用來理解 screenshot、圖表與文件，最後仍輸出文字；如果工作流程需要生成圖片，還是要另外接 Muse Image 或其他圖片模型。
Benchmark 表現與評測限制
Meta 把 Muse Glimmer 與相近尺寸的 Gemma 4 31B、Qwen 3.6 27B 比較。在 Meta 公布的這組測試設定下，Muse Glimmer 在 MCP Atlas、DeepSearch QA 與 SWE-Bench Pro 分數較高，Qwen 則在 OSWorld-Verified、TerminalBench 2.1 與多項多模態評測較高。
| Benchmark | Muse Glimmer 30B | Gemma 4 31B | Qwen 3.6 27B |
|---|---|---|---|
| MCP Atlas | 75.5 | 54.2 | 62.5 |
| DeepSearch QA | 74.6 | 61.7 | 71.1 |
| SWE-Bench Pro | 51.2 | 36.9 | 50.2 |
| SWE-Bench Verified | 76.0 | 66.6 | 77.2 |
| OSWorld-Verified | 65.9 | 58.5 | 75.6 |
| TerminalBench 2.1 | 51.7 | 43.4 | 60.7 |
這些是 Meta 依各模型 thinking mode 與指定 Agent scaffold 跑出的官方成績，不等於在不同工具權限、prompt、context 與硬體上仍會維持相同排序。在這組官方測試中，Muse Glimmer 分數較高的項目集中在工具使用與完整任務；如果需求只是一般問答，載入 30B dense 模型未必比尺寸更小的模型划算。
開放權重與 Apache 2.0 授權
Muse Glimmer 的 BF16、GGUF、DFlash drafter 與 perception encoder 都以 Apache 2.0 發布，可用於研究、修改與商業產品。這次沒有沿用部分 Llama 版本的自訂授權。
不過，「開放權重」仍是比較精確的說法。Meta 公開了模型檔、架構資料與評測方法，不代表完整訓練資料、資料清理流程及所有訓練程式都能從頭重現。開發者可以下載、微調與部署這個模型，但無法只靠公開內容重新訓練出完全相同的 Muse Glimmer。
本機模型沒有 token 費用，仍有顯卡、記憶體、電力與維護成本。若每天只問幾個問題，雲端服務可能更省事；若要反覆處理內部文件、長時間執行 Agent，或不能把資料送出設備，本機部署的價值才會放大。
Agent 安全與模型限制
Meta 將 Muse Glimmer 的化學／生物、網路攻擊與失控能力評為 Moderate 或更低，其中 cyber 與 loss of control 是根據它整體弱於 Muse Spark 所作的推定。這不是保證模型不會做出危險操作，而是未達 Meta 對 frontier model 設定的風險門檻。
官方在 Siren AgentDojo 測得 28.4% attack success rate，Gemma 4 31B 是 25.6%。不同評測不能直接套到所有環境，但至少說明 prompt injection 並未消失。讓模型讀取網頁、郵件與外部文件時，裡面的惡意文字仍可能誘導 Agent 呼叫工具。
- 刪除檔案、付款、發信與公開發布前要求人工確認。
- 工作目錄採用 allowlist，不要直接開放整個使用者家目錄。
- 工具帳號使用最低權限，測試環境與正式環境分開。
- 無需網路的工作關閉出站連線，需要網路時限制目的地。
- 保存 tool call、輸入來源與結果，方便事後找出錯誤步驟。
此外，模型仍可能產生錯誤、偏見或不適當內容；影片不是原生輸入，而是拆成個別影格；語言支援超過 100 種，也不表示每種語言品質相同。官方平均評測衰退為 0.2% 至 1.0%，個別任務仍可能不同。
Muse Spark 1.2 開放權重計畫
Meta 同時預告會在接下來幾週開放 Muse Spark 1.2 的一個權重版本。Muse Spark 1.2 是更大型的 foundation model，Muse Glimmer 則是從 Spark 蒸餾、針對消費級硬體縮小的版本。即使兩者都開放權重，也不表示 Spark 1.2 能放進 24GB 顯卡。
這項預告目前只有「接下來幾週」的時間範圍，尚未公布參數量、實際授權、量化版本與硬體需求。Muse Glimmer 已經有可下載的模型卡與 GGUF；Muse Spark 1.2 則要等正式模型卡出現後，才能判斷是否適合本機使用。
Muse Glimmer 適合哪些工作
Muse Glimmer 比較適合已經有 24GB 以上顯示記憶體，而且需要本機工具使用、程式開發、文件處理或圖片理解的環境。企業內部文件不能上傳、Agent 需要反覆讀寫大量檔案、網路不穩定，都是合理的部署理由。
只有 8GB、16GB 記憶體的筆電不建議執行。即使靠 CPU offload 勉強載入，長時間 Agent 的速度與記憶體壓力也很難實用。這類電腦改用較小模型，或直接使用 Muse Spark、ChatGPT、Claude 等雲端服務，通常更符合成本。
如果已有 24GB NVIDIA 顯卡，可以先下載 17GB 版，以 32K context 測試實際工作；32GB 以上再考慮 Dynamic 量化、圖片編碼器與 DFlash。先把模型、工具權限和工作流程分開驗證，比一開始就讓 Agent 接管所有應用可靠。
常見問答
Muse Glimmer 30B 可以在 Mac 執行嗎？
可以。Meta 提供 Apple Silicon 使用的 ExecuTorch PTE，也實測過 M4 Max 與 M5 Max。Mac 的 Unified Memory 會和系統共用，建議至少 32GB，36GB 以上更適合同時使用圖片編碼器、DFlash 與較長 context。
Muse Glimmer 需要多少 VRAM？
官方 17GB 量化版以 24GB VRAM 為目標，Dynamic 量化版以 32GB VRAM 為目標。完整 BF16 權重需要約 64GB VRAM。圖片編碼器與 DFlash 會另外占用約 1.4GB、1.6GB。
Muse Glimmer 有更低參數的模型嗎？
目前 Meta 只發布 30B 的 Muse Glimmer，沒有官方 7B、8B 或其他更小版本。17GB 與 19.7GB GGUF 只是同一個 30B 模型的不同量化方式，不是較低參數模型。硬體不足時只能改用其他小型開放權重模型，但工具使用、圖片理解與長時間 Agent 能力不一定和 Glimmer 相同。
Muse Glimmer 有線上版嗎？
目前沒有 Meta 官方代管的 Muse Glimmer 網頁版或 API，它的定位是下載權重後自行部署。Meta AI、meta.ai 與 Meta Model API 提供的是 Muse Spark 1.1，不是 Muse Glimmer；想免安裝使用 Meta 的 Muse 模型，可以選擇 Spark，但兩者的模型、context、費用與資料處理方式並不相同。
顯卡記憶體不夠怎麼辦？
先選 17GB 量化版並降低 context，例如從 32K 或更小開始；只處理文字時，可以不載入圖片編碼器與 DFlash drafter，同時避免平行執行多個請求。llama.cpp 也能把部分運算交給 CPU 與系統記憶體，不過速度會明顯下降。若連模型和基本 KV cache 都放不下，使用更小的模型或 Muse Spark 等雲端服務，通常比依賴 swap 硬撐更實用。
Muse Glimmer 可以用 Ollama 執行嗎？
本文撰寫時，Ollama 官方模型庫尚未提供 Muse Glimmer。llama.cpp 已從 build b10353 支援新架構，可以先使用官方 GGUF 與 llama.cpp。之後即使 Ollama 出現同名社群模型，也要核對來源、量化方式與圖片工具是否完整。
Muse Glimmer 能離線執行嗎？
模型檔與推論工具下載完成後，可以在沒有網路的環境生成文字、讀取本機圖片及使用本機工具。需要網頁搜尋、雲端信箱或其他線上服務時，Agent 仍然必須連網，離線指的是模型推論不依賴 Meta API。
Muse Glimmer 是開源模型嗎？
權重與官方發布的相關檔案採 Apache 2.0，允許修改與商業使用。由於完整訓練資料與流程未公開，較精確的分類是開放權重模型。
Muse Glimmer 和 Muse Spark 1.2 哪個比較強？
Muse Spark 1.2 是較大型的 foundation model，Muse Glimmer 是從 Spark 蒸餾、為消費級硬體設計的 30B 模型。Spark 的能力定位較高，Glimmer 的優勢是權重已公開，而且能完全在本機執行。