Meta 發布 Muse Glimmer，這是一款約 30B 參數的多模態 Agent 模型，支援 128K 級上下文，可在 24GB 顯存設備上運行。該模型採用 Apache 2.0 許可證開放，透過 GQA 減少 KV Cache 占用，結合 Local 與 Global Attention 混合架構降低長上下文計算成本，並提供兩套量化版本適配不同顯存設備。視覺模組配備獨立 ViT Perception Encoder 處理截圖和螢幕資訊，訓練階段引入 On Policy Distillation 覆蓋長任務偏離狀態。DFlash 推理加速組件採用 Block Diffusion 並行預測 Token，在 RTX 5090 上實現約 3 倍解碼速度提升。模型在 MCP Atlas、DeepSearch QA 等 Agent Benchmark 表現優異，但在 OSWorld Verified 等純 GUI 場景中仍有提升空間。

文章作者、來源：雷峰網

昨天，Meta 發布了 Muse Glimmer。這是一款約 30B 參數的多模態 Agent 模型，支援 128K 級上下文，可以調用工具、執行代碼，也能處理圖片和螢幕資訊。

This model is open-sourced under the Apache 2.0 license, and also includes two 4-bit quantized versions, an independent vision encoder, and the DFlash inference acceleration component, with local deployment options available via llama.cpp, MLX, ExecuTorch, and more.

雖然 30B 的參數規模和 128K 的上下文在今天看來並不罕見，但問題在於，Meta 想讓它做的不是普通聊天，而是建立一套完整的本地 Agent 運行範式。

Muse Glimmer 面向長期運行的本地 Agent，會面臨嚴苛的工程限制：它必須在有限的 24GB 顯存中，一邊處理不斷產生的螢幕截圖，一邊維持長達數十步的任務邏輯。一次任務運行數十步後，先前的工具結果、程式碼日誌、頁面狀態和推理過程會不斷累積在上下文中。

這時，許多在聊天場景中不明顯的問題會迅速放大。128K 上下文如何塞進有限的顯存，截圖越來越多後如何管理歷史狀態，工具調用失敗後模型如何繼續往下走，大量 Reasoning Token 又會把 Decode 拖慢到什麼程度。

Muse Glimmer 的技術設計，基本上就是圍繞這些問題展開的。它並未依賴某個特別顯眼的新架構來解決所有問題，而是在 Attention、KV Cache、訓練方式、量化和 Decode 上進行了激進的取捨。

如果說以前的本地模型是「能跑起來」，Muse Glimmer 的目標是「能像雲端一樣好用且連續工作」。

將這些部分連起來看，比單看 30B 或 128K 更容易理解 Meta 為什麼會把它做成現在這個樣子。

如何將 128K 上下文壓入 24GB 顯存

Muse Glimmer 使用 52 層 Dense Transformer，Hidden Size 為 6656，有 32 個 Query Head，但只有 2 個 KV Head。

Attention 也不是每一層都處理完整上下文，而是採用三個 Local Attention 接一個 Global Attention 的循環方式。

Local Attention 僅處理附近 2048 個 Token，Global Attention 才負責更遠距離的資訊交換。

這兩個設計實際上同時增加了長上下文的成本。模型在生成新 Token 時，會快取前面 Token 的 Key 和 Value，也就是 KV Cache。上下文越長，這部分所佔用的記憶體就越大。

Muse Glimmer 每層只有 2 個 KV Head，每個 Head Dimension 為 128。按照 BF16 粗略計算，一個 Token 在一層裡的 KV 約佔 1024 Byte。

如果 52 層全部保存完整 128K Context，KV Cache 大約需要 6.5 GiB。但 Muse Glimmer 實際有 39 個 Local 層和 13 個 Global 層。Local 層只需要維護約 2048 Token 的滑動視窗，只有 Global 層需要保存完整的長上下文。

以同樣方式估算，KV Cache 可降至約 1.7 GiB 的量級。這不是官方公佈的運行時顯存，僅是根據公開架構參數所做的理論估算，但已足以說明此架構為何如此設計。

如果它不使用 2 個 KV Head，而是像傳統 MHA 那樣為 32 個 Head 各自保存獨立的 KV，在相同條件下，KV Cache 理論上還會擴大約 16 倍，直接達到 20 多 GiB。

單獨的 KV Cache 已經超過一張 24GB 顯卡。這裡實際上用了兩種方法。GQA 減少每個 Token 需要保存的 KV 數量，Local Attention 則減少需要長期保存完整 KV 的層數。

完成這一步後，權重量化才有意義。Muse Glimmer 的 K Quant 17GB 權重約為 16.8GB，視覺模組約 1.4GB，DFlash 約 1.6GB，幾部分加起來已接近 20GB。這個版本面向 24GB 顯存設備，另一套約 20GB 的 Dynamic K Quant 則面向 32GB 設備。

兩套量化不僅文件大小不同。Meta 提供的 15 項 Benchmark 平均精度損失中，Dynamic K Quant 約為 0.2%，K Quant 17GB 約為 1.0%。

也就是說，24GB 版本進一步壓低顯存，佔用更小，但需要接受稍微明顯一點的能力損失。32GB 版本則盡量保留原模型表現。

Muse Glimmer 的 128K Context 正是在這種組合下成立的。Attention 先降低計算量，GQA 再降低 KV Cache，最後通過量化壓低模型權重。

這種方案也有代價。39 個 Local 層只能直接存取附近 2048 個 Token，遠距離資訊需要經過 Global 層傳播。因此，能夠輸入 128K 和能夠穩定利用整個 128K 仍然不是一回事。

Meta 的 Beam128K 結果表明，這種本地與全局混合架構仍具備不錯的長距離資訊利用能力，但它解決的是長上下文，而非長期記憶。哪些資訊應被保存、哪些已過期、何時更新狀態，仍需由 Agent Runtime 處理。

這個問題在視覺 Agent 上會更加明顯。

128K 也不是無限空間

Muse Glimmer 另外配備了一個約 1.8B 參數的 ViT G 14 Perception Encoder，用於處理截圖、網頁、圖表和文檔。一張圖片最多可轉換為 4096 個 Visual Token。

它目前是文本和圖片輸入、文本輸出，並非將所有模態都放入同一個生成模型。

在 Agent 工作流程中，這種視覺能力主要負責讀取環境狀態。Computer Use Agent 先觀察當前螢幕，判斷頁面、按鈕和文字的位置，然後執行一次操作。頁面變更後，它會讀取新的截圖，繼續決定下一步。

因此，視覺輸入會不斷進入上下文。如果將數十步任務中的所有截圖完整保留，即使有 128K，上下文也會很快被視覺 Token 填滿。舊截圖還可能與當前狀態衝突：頁面已經變化，但之前的按鈕和視窗仍留在上下文中，模型需要額外判斷哪一個才是最新狀態。

Meta 在 OSWorld Verified 的評測中也沒有無限保留 Screenshot History，而是只保留最近的部分截圖。這說明 Perception Encoder 和 Context Management 是兩個不同的問題。

前者負責將當前螢幕轉換為模型能理解的資訊，後者則要決定哪些歷史狀態仍有價值，哪些應該刪除。因此，128K 更像是為 Agent 提供了更大的工作空間，而非取消狀態管理。

而當 Agent 不斷與環境互動以後，問題也開始從模型看到了什麼，轉向模型剛才做了什麼。

這就進入 Muse Glimmer 的訓練部分。

代理偏離後如何繼續

Muse Glimmer 是從更大的 Muse Spark 蒸餾出來的。

Meta 將訓練分為 Pre Training、Mid Training 和 Post Training。Pre Training 使用 Logit Distillation，Mid Training 增加更多長上下文、Reasoning Trace 和 Agent 數據，Post Training 再加入 SFT、On Policy Distillation 和 RL。

Logit 知識蒸餾與使用大模型答案訓練小模型略有不同。當教師模型預測下一個 Token 時，會為整個詞彙表提供一個概率分佈。學生模型學習的不僅是最終選中的 Token，還能看見教師對其他候選詞的相對判斷。

這對 Agent 非常有用，因為許多情境並不存在唯一動作。面對一個網頁，模型可以繼續搜尋、打開某個結果，或切換另一個工具。Teacher 的機率分佈會包含其對這些行動的偏好，而不僅僅是最終輸出的一段文字。

到了 Mid Training，訓練開始從單次回答走向完整任務軌跡。工具執行後，環境會改變。搜尋會返回新的結果，代碼運行失敗會出現報錯，GUI 點錯後頁面也會變化。也就是說，Agent 的輸出會直接改變下一步輸入。

假設 Teacher 的正確軌跡是從 A 到 B，再至 C，最後到 D。如果 Student 始終只學習 Teacher 的數據，它會反覆看到 A 到 B、B 到 C。但在實際運行時，Student 可能在第一步就抵達了另一個 B 狀態。

從這一刻開始，環境已經改變，訓練集中從 B 到 C 的資訊無法直接告訴它現在該如何處理。On Policy Distillation 正是在此發揮作用：Student 先自行進行 Rollout，進入其真實會產生的狀態，然後在這些狀態上接受更強模型的監督。

因此，訓練數據不僅包含教師的理想路徑，也開始涵蓋學生自身產生的錯誤狀態。這與 Muse Glimmer 強調的 Failure Recovery 相關。

參數填錯後，若模型能理解錯誤訊息並重新調整 Tool Call，任務仍可繼續。網頁走錯後，只要能識別當前狀態異常，也可回退或更換路徑。真正麻煩的是模型未察覺錯誤，反而基於錯誤狀態繼續執行，導致偏差不斷累積。

因此，評估 Agent 的能力不能只看單次 Tool Call 是否正確，還要看整個任務最終能否完成，以及在中間出錯後能否恢復。這也解釋了為什麼 Muse Glimmer 在一些長流程 Agent 基準測試中表現更佳。

不過任務能夠完成，並不代表本地運行已沒有問題。如果一次複雜任務要生成大量 Reasoning Token，新的瓶頸很快就會變成 Decode。

兩個前後相繼的問題

Muse Glimmer 支持 low、medium、high、xhigh 四檔 Reasoning Strength。這個設定可理解為運行時推理預算。

更高的等級通常會讓模型產生更多的 Reasoning Token，在複雜的 Coding 和 Agent 任務上可能獲得更高的成功機率，但代價也很直接：Context 增長更快，Decode 時間也更長。

Meta 在公開的 Benchmark 中使用的是 high Reasoning Strength。這就引出了 DFlash。

Transformer 的 Decode 是自回歸的。第 2 個 Token 必須等待第 1 個 Token，第 3 個又依賴第 2 個。對於幾百個 Token 的回答還可以接受，但 Agent 一次任務可能累計產生幾千甚至上萬個 Token。

Speculative Decoding 的做法，是增加一個更小的 Drafter。Drafter 先預測未來的一段 Token，再讓主模型一次性驗證。如果有多个候選可以連續接受，就能減少 30B 主模型執行 Decode Step 的次數。

傳統方案的問題在於，Drafter 本身通常也是自回歸模型。如果它要 Draft 16 個 Token，仍然需要一個一個生成。

DFlash 將這一段換成了 Block Diffusion。

Muse Glimmer 的 DFlash Block Size 為 16，可並行預測一組候選 Token。但僅僅 Drafter 更快還不夠。如果猜測不準，主模型會大量拒絕候選，先前的速度優勢將很快消失。

因此，DFlash 會直接讀取 Muse Glimmer 第 1、13、25、37、49 層的 Hidden Feature，並將這些中間表示傳送給僅有 5 層的 Drafter。這樣一來，Drafter 無需自行重新理解完整 Context，而是直接利用 30B 主模型已形成的內部表示。

這些 Feature 也不是只在輸入端使用一次，而是持續注入 Drafter 各層的 Key 和 Value，以避免隨著網路加深而逐漸變弱。

在訓練時還有一個細節。在一個 16 Token 的區塊中，前面的 Token 比後面的更重要。如果第 1 個 Token 就錯了，即使後面猜對了，連續接受長度也會很短。

因此，DFlash 會為 Block 前面的 Token 賦予更高的 Loss Weight，後面的則逐漸降低。它優化的是盡可能長的可接受前綴，而非單純追求 16 個位置的平均準確率。在 Meta 提供的 K Quant 17GB 數據中，RTX 5090 上的 Decode Speed 從約 74.9 Token/s 提升至 233.4 Token/s。

如果一個 Agent Task 累計生成 10000 個 Token，僅看 Decode，前者約需 134 秒，後者約 43 秒。真實任務還會包含 Prefill、工具執行和網絡等待，但對於高 Reasoning Strength 的 Agent，這種差距已會明顯影響完整任務體驗。

高 Reasoning Strength 會增加生成 Token，DFlash 負責縮短這部分時間。長 Context 會增加 KV Cache，GQA 和 Local Attention 負責壓低記憶體。量化則繼續把模型權重控制在消費級顯卡能夠承受的範圍內。

此外，Muse Glimmer 在 MCP Atlas、DeepSearch QA、Gaia2 等 Agent Benchmark 上表現出色。這些任務均需要較長的執行鏈。

MCP Atlas 需要模型在多個 MCP Server 之間選擇和調用工具。DeepSearch QA 需要不斷搜索、打開頁面、查找資訊，並根據新結果繼續執行。Gaia2 則模擬郵件、日曆、聯絡人等有狀態應用，環境本身還會在任務過程中發生變化。

這些任務與 Muse Glimmer 的訓練方式較為吻合。但在 OSWorld Verified、TerminalBench 和 SWE Bench Verified 上，它並未保持同樣的優勢。例如，在 OSWorld Verified 上，Muse Glimmer 得分為 65.9，Qwen3.6 27B 則為 75.6；在 TerminalBench 2.1 上，Muse Glimmer 為 51.7，對方則達到 60.7。

因此，其能力分佈較為清晰。Research Agent、工具協同和長流程狀態任務表現較強，而在純 GUI、終端和部分 Coding Agent 場景中仍有明顯提升空間。這些分數也不能完全按照傳統模型排名來理解。

Agent Benchmark 的結果還會受到 System Prompt、Tool Definition、Scaffold、最大執行步數、Sampling 參數甚至 Judge Model 的影響。Meta 自己也說明，第三方模型使用的 Agent Tools 和 System Prompt 不一定針對它們做過最佳優化。

因此，到了 Agent 階段，單獨比較 Checkpoint 已經越來越難以說明完整情況。安全也是類似的問題。

本地運行確實可以減少文件、截圖和私人 Context 頻繁發送到雲端，但這解決的是數據路徑。Prompt Injection、錯誤 Tool Call、權限越界和不可逆操作仍然存在。Meta 也單獨評估了 Agentic Risk、Privacy 和 Prompt Injection，並建議真實部署繼續增加 Guardrail 和必要的 Human in the Loop。

一條明確的能力路線

Muse Glimmer 的完整技術路徑最終可以連成一條較為清晰的鏈路。

模型規模控制在約 30B，GQA 和 Local Attention 降低 128K 上下文的顯存成本，量化使模型可運行於 24GB 和 32GB 設備，Perception Encoder 負責讀取視覺環境，On Policy Distillation 處理長任務中的偏離狀態，Reasoning Strength 讓開發者控制推理預算，DFlash 再處理大量 Reasoning Token 帶來的 Decode 延遲。

Muse Glimmer 並未證明本地 30B 模型可以取代雲端 Frontier Model，但它證明了本地 30B 模型的終局，不在於單純的規模，而在於系統級工程對各種硬性限制的綜合對沖。它已將本地 Agent 中最難處理的顯存、上下文、環境狀態感知與推理速度這四項限制，整合進同一套系統設計中。

Muse Glimmer 雖然還不能全面取代雲端旗艦模型，但已經為「人人都有私有 Agent」的目標，鋪好了一條可以工業級落地的路徑。