深度拆解 Muse Glimmer，24GB 顯存跑 30B Agent，Meta 到底做了什麼？

128K 長上下文與 3.1 倍推理加速背後，Meta 正在重構本地 Agent 的底層邏輯。作者丨鄭佳美 編輯丨岑 峰 昨天，Meta 發佈了 Muse Glimmer。這是一款約 30B 參數的多模態 Agent 模型，支持 128K 級上下文，可以調用工具、執行代碼，也能處理圖片和屏幕信息。這個模型採用 Apache 2.0 許可證開放，同時還有兩套 4 bit 量化版本、獨立視覺編碼器和 DFlash 推理加速組件，並提供 llama.cpp、MLX、ExecuTorch 等本地部署方式。

雖然 30B 的參數規模和 128K 的上下文在今天看來並不稀奇，但問題在於，Meta 想讓它乾的不是普通聊天，而在於建立一套完整的本地 Agent 運行範式。Muse Glimmer 面向的長期運行的本地 Agent，會面臨著苛刻的工程約束：它必須在有限的 24GB 顯存裡，一邊處理不斷產生的屏幕截圖，一邊維持長達幾十步的任務邏輯。一次任務跑上幾十步以後，前面的工具結果、代碼日誌、頁面狀態和推理過程會不斷留在上下文裡。這時候，很多在聊天場景裡不明顯的問題會迅速放大。

128K 上下文怎麼塞進有限顯存，截圖越來越多以後怎麼管理歷史狀態，工具調用失敗後模型怎麼接著往下走，大量 Reasoning Token 又會把 Decode 拖慢到什麼程度。Muse Glimmer 的技術設計，基本就是圍著這些問題展開的。它沒有靠某一個特別顯眼的新架構解決所有事情，而是在 Attention、KV Cache、訓練方式、量化和 Decode 上進行了激進的取捨。如果說以前的本地模型是“能跑起來”，Muse Glimmer 的目標是“能像雲端一樣好用且連續工作”。把這些部分連起來看，比單看 30B 或 128K 更容易理解 Meta 為什麼會把它做成現在這個樣子。

01128K 上下文怎麼壓進 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。Context 越長，這部分佔用越大。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 結果說明這種 Local 和 Global 混合結構仍然具備不錯的長距離信息利用能力，但它解決的是 Long Context，並不是長期 Memory。哪些信息應該保存，哪些已經過期，什麼時候更新狀態，仍然需要 Agent Runtime 處理。這個問題到了視覺 Agent 上會更加明顯。02128K 也不是無限空間Muse Glimmer 另外帶有一個約 1.8B 參數的 ViT G 14 Perception Encoder，用來處理截圖、網頁、圖表和文檔。一張圖片最多可以轉換成 4096 個 Visual Token。

它目前是文本和圖片輸入、文本輸出，並不是把所有模態都放進同一個生成模型。放在 Agent 工作流裡，這種視覺能力主要負責讀取環境狀態。Computer Use Agent 先看到當前屏幕，判斷頁面、按鈕和文字的位置，然後執行一次操作。頁面變化以後，它再讀取新的截圖，繼續決定下一步。於是視覺輸入會不斷進入 Context。如果幾十步任務裡的所有截圖都完整保留，即使有 128K，上下文也很快會被 Visual Token 佔滿。舊截圖還可能和當前狀態衝突。頁面已經變化了，但之前的按鈕和窗口仍然留在 Context 中，模型需要額外判斷哪個才是最新狀態。

Meta 在 OSWorld Verified 的評測裡也沒有無限保留 Screenshot History，而是隻留下最近一部分截圖。這說明 Perception Encoder 和 Context Management 是兩個不同的問題。前者負責把當前屏幕轉換成模型能理解的信息，後者要決定哪些歷史狀態還有價值，哪些應該刪除。因此 128K 更像是給 Agent 提供了更大的工作空間，而不是取消狀態管理。而當 Agent 不斷和環境交互以後，問題也開始從模型看到了什麼，轉向模型剛才做了什麼。這就進入 Muse Glimmer 的訓練部分。

03Agent 走偏以後如何繼續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 Distillation 和普通拿大模型答案訓練小模型有一點區別。

Teacher 預測下一個 Token 時，會給整個 Vocabulary 一個概率分佈。Student 學到的不只是最終選中的 Token，還會看到 Teacher 對其他候選的相對判斷。這對於 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，進入它真實會產生的狀態，然後再在這些狀態上接受更強模型的監督。

訓練數據裡因此不只有 Teacher 的理想路線，也開始覆蓋 Student 自己會製造出來的錯誤狀態。這和 Muse Glimmer 強調的 Failure Recovery 是連著的。參數填錯以後，模型如果能讀懂報錯，再修改一次 Tool Call，任務仍然可以繼續。網頁走錯以後，只要能識別當前狀態不對，也可以回退或者換路徑。真正麻煩的是模型沒有意識到錯誤，而是繼續基於錯誤狀態執行，讓偏差一路積累。所以 Agent 的能力不能只看某一次 Tool Call 是否正確，還要看整個任務最終能不能完成，以及中間出錯以後能不能恢復。

這也解釋了 Muse Glimmer 為什麼在一些長流程 Agent Benchmark 上表現更好。不過任務能夠完成，並不代表本地運行已經沒有問題。如果一次複雜任務要生成大量 Reasoning Token，新的瓶頸很快就會變成 Decode。04一前一後的兩個問題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 Block 裡，前面的 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。05一條明確的能力路線Muse Glimmer 的整套技術路徑最終可以連成一條比較清楚的鏈路。

模型規模控制在 30B 左右，GQA 和 Local Attention 壓低 128K Context 的顯存成本，量化讓模型進入 24GB 和 32GB 設備，Perception Encoder 負責讀取視覺環境，On Policy Distillation 覆蓋長任務裡的偏離狀態，Reasoning Strength 給開發者控制推理預算，DFlash 再處理大量 Reasoning Token 帶來的 Decode 延遲。

Muse Glimmer 沒有證明本地 30B 模型可以替代雲端 Frontier Model，但它證明了，30B 本地模型的終局，不在於單純的規模，而在於系統級工程對各種硬約束的綜合對沖。它已經把本地 Agent 裡最難處理的顯存、上下文、環境狀態感知和推理速度這四項約束放進了同一套系統設計中，包括顯存、上下文、環境狀態和推理速度。Muse Glimmer 雖然還不能全面取代雲端旗艦模型，但已經為“人人都有私有 Agent”的目標，鋪好了一條可以工業級落地的路徑。參考鏈接：https://developer.meta.

com/ai/models/muse-glimmer/https://research.meta.ai/blog/introducing-muse-glimmer-open-agentic-model上車，帶你看遍全球 AI 頂會精華可獨家暢覽：專家演講PPT大會報告全文熱門論文解讀學術新星訪談掃描上方二維碼或點擊「閱讀原文」關注專區。