Metaは、約30Bパラメータを有するマルチモーダルAgentモデル「Muse Glimmer」を発表しました。このモデルは128Kレベルのコンテキストをサポートし、24GBのVRAMを備えたデバイス上で動作可能です。Apache 2.0ライセンスのもとでオープンソース化されており、GQAを採用してKVキャッシュの占有を削減し、ローカルとグローバルアテンションのハイブリッドアーキテクチャを組み合わせることで、長コンテキストの計算コストを削減しています。また、異なるVRAM容量のデバイスに適応できるよう、2種類の量子化バージョンを提供しています。ビジュアルモジュールには、スクリーンショットや画面情報を処理する独立したViT Perception Encoderが搭載されており、トレーニング段階ではOn Policy Distillationを導入して長期間タスクにおける状態の逸脱をカバーしています。DFlash推論加速コンポーネントはBlock Diffusionを用いてトークンを並列に予測し、RTX 5090上で約3倍のデコード速度向上を実現しています。このモデルはMCP AtlasやDeepSearch QAなどのAgentベンチマークで優れた性能を発揮していますが、OSWorld Verifiedなどの純粋なGUIシナリオではさらなる改善の余地があります。記事執筆者、出典：雷峰網
昨日、MetaはMuse Glimmerをリリースしました。これは約30Bパラメータを備えたマルチモーダルエージェントモデルで、128Kレベルのコンテキストをサポートし、ツールの呼び出しやコードの実行、画像およびスクリーン情報の処理が可能です。
このモデルはApache 2.0ライセンスでオープンであり、4bit量子化バージョンが2種類、独立したビジュアルエンコーダー、およびDFlash推論加速コンポーネントを備え、llama.cpp、MLX、ExecuTorchなどのローカルデプロイ方法を提供しています。
30Bのパラメータ規模と128Kのコンテキストは今日の基準では珍しくないが、問題はMetaがこれを通常のチャットではなく、完全なローカルAgent実行パラダイムの構築に利用したいということである。
Muse Glimmerが対象とする長期実行型ローカルエージェントは、厳しいエンジニアリング制約に直面します。24GBという制限されたVRAM内で、次々と生成されるスクリーンショットを処理しながら、数十ステップに及ぶタスクロジックを維持しなければなりません。一度数十ステップのタスクを実行すると、以前のツールの結果、コードログ、ページステータス、推論プロセスが次第にコンテキストに蓄積されていきます。
このとき、チャットシーンでは目立たなかった多くの問題が急速に拡大する。128Kのコンテキストを限られたVRAMにどう収めるか、スクリーンショットが増えるにつれて履歴状態をどう管理するか、ツール呼び出しが失敗した際にモデルがどのように継続するか、大量のReasoning Tokenがデコードをどの程度遅らせるか。
Muse Glimmerの技術設計は、基本的にこれらの課題を中心に展開されています。特定の目立つ新アーキテクチャに頼ってすべてを解決するのではなく、Attention、KV Cache、トレーニング方法、量子化、およびDecodeにおいて積極的なトレードオフを行っています。
以前のローカルモデルが「動かすことができる」レベルだったのに対し、Muse Glimmerの目標は「クラウドと同じように使いやすく、連続して動作すること」です。
これらの部分を一緒に見ると、Metaがこれを現在の形にした理由を、30Bや128Kだけを見るよりも理解しやすくなります。
128Kのコンテキストを24GBのGPUメモリに収めるには
Muse Glimmerは52層のDense Transformerを使用し、Hidden Sizeは6656、Query Headは32個、KV Headは2個です。
Attentionは各層で常に完全なコンテキストを処理するわけではなく、3つのLocal Attentionと1つのGlobal Attentionを繰り返す方式を採用しています。
Local Attentionは周囲の2048個のトークンのみを処理し、Global Attentionが遠距離の情報交換を担当します。
これらの設計は、実際には長文コンテキストのコストを同時に増加させています。モデルが新しいトークンを生成する際、以前のトークンのキーとバリュー（KVキャッシュ）をキャッシュします。コンテキストが長くなるほど、この部分の占有量が大きくなります。
Muse Glimmerは各層に2つのKVヘッドを持ち、各ヘッドの次元は128です。BF16で概算すると、1つのトークンあたり1層のKVは約1024バイトを占めます。
52層すべてを128Kコンテキスト全体で保存した場合、KVキャッシュは約6.5 GiB必要です。しかし、Muse Glimmerには実際には39のLocal層と13のGlobal層があります。Local層は約2048トークンのスライディングウィンドウを維持するだけでよく、長距離コンテキストを保存するのはGlobal層のみです。
同様の方法で推定すると、KVキャッシュは約1.7 GiBの規模に低下します。これは公式に発表された実行時のVRAMではなく、公開されたアーキテクチャパラメータに基づく理論的な推定ですが、この構造がこのような設計になった理由をすでに示しています。
もし2つのKVヘッドではなく、従来のMHAのように32のヘッドすべてに独立したKVを保存すると、同じ条件下でKVキャッシュは理論的に約16倍に拡大し、20GiB以上になります。
単独のKVキャッシュですでに24GBのGPUを超過しています。ここでは実際には2つの方法を用いています。GQAは各トークンが保存する必要のあるKVの量を減らし、Local Attentionは長期的に完全なKVを保存する必要のあるレイヤー数を減らします。
このステップを完了した後で、重みの量子化が意味を成します。Muse GlimmerのK Quant 17GBの重みは約16.8GB、ビジュアルモジュールは約1.4GB、DFlashは約1.6GBで、これらの合計はすでに20GBに近づいています。このバージョンは24GB VRAMのデバイスを対象としており、もう一つの約20GBのDynamic K Quantは32GBデバイスを対象としています。
二つのクオンタイズ手法はファイルサイズの違いだけでなく、Metaが提供する15のベンチマークにおける平均精度損失では、Dynamic K Quantが約0.2％、K Quant 17GBが約1.0％です。
つまり、24GB版はVRAMをさらに削減し、占有スペースを小さくしますが、やや明確な性能の低下を受け入れる必要があります。32GB版は、元のモデルのパフォーマンスを可能な限り維持します。
Muse Glimmerの128Kコンテキストは、この組み合わせによって実現されています。Attentionが計算量を削減し、GQAがKVキャッシュを削減し、最後に量子化によってモデルの重みを圧縮します。
この手法にも代償があります。39のLocal層は隣接する2048個のトークンのみ直接アクセスでき、遠距離の情報はGlobal層を介して伝播する必要があります。したがって、128Kを入力できることと、その128K全体を安定して活用できることは別問題です。
MetaのBeam128Kの結果は、ローカルとグローバルのハイブリッド構造が依然として優れた長距離情報活用能力を有していることを示しているが、これはロングコンテキストを解決するものであり、長期メモリーを解決するものではない。どの情報を保存し、どの情報が既に古くなったか、いつ状態を更新するかは、依然としてAgent Runtimeが処理する必要がある。
この問題はビジュアルエージェント上でより顕著になります。
128K也不是無限空間
Muse Glimmerには、スクリーンショット、ウェブページ、チャート、ドキュメントを処理するための約1.8BパラメータのViT G 14 Perception Encoderが付属しています。1枚の画像は最大4096個のVisual Tokenに変換できます。
現在はテキストと画像の入力、テキストの出力であり、すべてのモダリティを同じ生成モデルに統合しているわけではありません。
Agentワークフロー内では、この視覚能力が環境状態の読み取りを主に担当します。Computer Use Agentはまず現在の画面を認識し、ページ、ボタン、テキストの位置を判断した後、1回の操作を実行します。ページが変化した後、新しいスクリーンショットを読み取り、次の行動を決定します。
したがって、視覚入力は継続的にコンテキストに取り込まれます。数十ステップのタスクにおけるすべてのスクリーンショットを完全に保持すると、たとえ128Kのコンテキスト長であっても、視覚トークンですぐに埋まってしまいます。以前のスクリーンショットは現在の状態と矛盾する可能性があります。ページの状態が変化しているにもかかわらず、以前のボタンやウィンドウがコンテキストに残ったままになり、モデルはどの状態が最新であるかを追加で判断する必要があります。
MetaはOSWorld Verifiedの評価においても、スクリーンショット履歴を無制限に保持するのではなく、最近の一部のスクリーンショットのみを残しています。これは、Perception EncoderとContext Managementが二つの異なる問題であることを示しています。
前者は現在の画面をモデルが理解できる情報に変換し、後者はどの履歴状態が価値があり、どの状態を削除すべきかを決定する。したがって、128Kは状態管理を廃止するのではなく、エージェントにより広い作業空間を提供するようなものである。
エージェントが環境と継続的に相互作用するにつれて、問題はモデルが何を見たかから、モデルが直前に何をしたかへと移行し始めた。
これでMuse Glimmerのトレーニング部分に入ります。
エージェントが逸れた場合、どのように継続しますか
Muse Glimmerは、より大きなMuse Sparkから蒸留されたものです。
メタはトレーニングをPre Training、Mid Training、Post Trainingに分割しています。Pre TrainingではLogit Distillationを使用し、Mid Trainingではより長いコンテキスト、Reasoning Trace、およびAgentデータを追加します。Post TrainingではSFT、On Policy Distillation、およびRLを追加します。
Logit Distillationは、大規模モデルの回答を用いて小規模モデルを訓練する通常の方法とは少し異なります。教師モデルは次のトークンを予測する際に、語彙全体に対する確率分布を生成します。学生モデルは、最終的に選択されたトークンだけでなく、教師モデルが他の候補に対して行った相対的な評価も学びます。
これはエージェントにとって役立ちます。多くのシナリオでは唯一のアクションが存在しないため、モデルは検索を継続したり、ある結果を開いたり、別のツールに切り替えたりできます。ティーチャーの確率分布には、最終的な出力テキストだけでなく、これらのアクションに対する好みが含まれます。
Mid Trainingに到達すると、訓練は単一の回答から完全なタスクのトラジェクトリーへと移行します。ツールを実行した後、環境が変化します。検索は新しい結果を返し、コードの実行に失敗するとエラーが発生し、GUIで誤った操作をするとページが変更されます。つまり、エージェントの出力は次の入力に直接影響を与えます。
Teacherの正しい経路がAからB、次にC、最後にDであると仮定する。StudentがTeacherのデータのみを学習する場合、AからB、BからCを繰り返し観測することになる。しかし実際の動作では、Studentが最初のステップで別のB状態に到達する可能性がある。
この瞬間から、環境は変化しており、訓練データ内のBからCへの遷移は、現在どのように対処すべきかを直接教えることはできません。On Policy Distillationは、ここで機能します。Studentはまず自らRolloutを行い、実際に生じる状態に進み、その後、これらの状態でより強力なモデルからの監督を受けます。
したがって、トレーニングデータには教師の理想的な経路だけでなく、学生自身が生成する誤った状態も含まれるようになります。これはMuse Glimmerが強調する失敗からの回復と連動しています。
パラメータを間違えた場合、モデルがエラーを理解してツールコールを修正すれば、タスクは継続できます。ウェブページを間違えた場合も、現在の状態が不適切であることに気づけば、戻ったり経路を変更したりできます。真正に厄介なのは、モデルがエラーに気づかず、誤った状態に基づいて継続して実行し、ずれが蓄積してしまうことです。
したがって、エージェントの能力は、ある1回のツールコールが正しかったかどうかだけでなく、タスク全体を最終的に完了できるかどうか、そして途中でエラーが発生した際に回復できるかどうかによって評価される必要があります。これこそが、Muse Glimmerが一部の長尺プロセスエージェントベンチマークでより優れたパフォーマンスを発揮する理由です。
タスクが完了できても、ローカルでの実行に問題がないとは限りません。複雑なタスクで大量のReasoning Tokenを生成する場合、新たなボトルネックはすぐにDecodeになります。
前後の二つの質問
Muse Glimmerは、low、medium、high、xhighの4段階のReasoning Strengthをサポートしています。この設定は、実行時の推論予算と理解できます。
より高いランクは、モデルがより多くのReasoning Tokenを生成する傾向があり、複雑なコーディングやエージェントタスクでの成功率が向上する可能性がありますが、その代償は明確です。コンテキストの増加が速くなり、デコード時間が長くなります。
Metaが公開ベンチマークで使用しているのはhigh Reasoning Strengthです。これによりDFlashが導かれました。
Transformerのデコードは自己回帰的です。2番目のトークンは1番目のトークンを待たなければならず、3番目のトークンは2番目のトークンに依存します。数百のトークンの回答であれば受け入れ可能ですが、エージェントの1回のタスクでは、数千、さらには数万のトークンが累積して生成される可能性があります。
スペキュレーティブ・デコードのアプローチでは、より小さなドラフターを追加します。ドラフターはまず将来の複数のトークンを予測し、その後メインモデルが一度にそれらを検証します。複数の候補が連続して受け入れられる場合、30Bのメインモデルのデコードステップの実行回数を削減できます。
従来の手法の問題は、Drafter自体が通常自回帰モデルであることです。16個のトークンをDraftする場合でも、依然として1つずつ生成する必要があります。
DFlashはこのセクションをBlock Diffusionに置き換えました。
Muse GlimmerのDFlashブロックサイズは16であり、複数の候補トークンを並列で予測できます。しかし、Drafterは速いだけでは十分ではありません。予測が不正確だと、メインモデルが多数の候補を拒否し、前の速度優位性はすぐに失われてしまいます。
したがって、DFlashはMuse Glimmerの第1、13、25、37、49層のHidden Featureを直接読み取り、これらの中间表現を5層のみのDrafterに送信します。これにより、Drafterは独自に完全なContextを再理解する必要なく、30Bメインモデルがすでに形成した内部表現を直接活用できます。
これらのFeatureは入力端で一度だけ使用されるのではなく、ネットワークが深くなるにつれて弱まらないように、Drafterの各層のKeyとValueに継続的に注入されます。
トレーニング時にはもう一つの細部があります。16トークンブロックにおいて、前のトークンの方が後のトークンよりも重要です。最初のトークンが間違っていると、その後のトークンをどれだけ正しく予測しても、連続して正解する長さは短くなります。
したがって、DFlashはBlockの前のトークンに高いLoss Weightを割り当て、その後は徐々に低下させます。これは単に16つの位置における平均精度を追求するのではなく、可能な限り長い許容可能なプレフィックスを最適化することを目的としています。Metaが提供するK Quant 17GBデータでは、RTX 5090でのDecode Speedは約74.9トークン/秒から233.4トークン/秒へ向上しました。
あるAgentタスクが累計で10,000個のトークンを生成する場合、Decodeのみを考慮すると、前者は約134秒、後者は約43秒かかります。実際のタスクにはPrefill、ツール実行、ネットワーク待機が含まれますが、Reasoning Strengthが高いAgentでは、この差が全体のタスク体験に明確な影響を及ぼします。
高Reasoning Strengthは生成トークンを増加させ、DFlashがこの時間を短縮します。長すぎるコンテキストはKVキャッシュを増加させ、GQAとLocal Attentionがメモリ使用量を抑制します。量子化は、モデルの重みを消費級GPUが処理可能な範囲に保ち続けます。
また、Muse GlimmerはMCP Atlas、DeepSearch QA、Gaia2などのAgentベンチマークで優れたパフォーマンスを発揮しています。これらのタスクはすべて長い実行チェーンを必要とします。
MCP Atlasは、複数のMCPサーバー間でツールを選択し呼び出します。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は、それらに最適化されているとは限らないと明言している。
したがって、エージェント段階に至ると、チェックポイントを単独で比較しても、全体の状況を十分に示すのがますます難しくなっています。セキュリティも同様の問題です。
ローカルで実行することで、ファイル、スクリーンショット、プライベートなコンテキストをクラウドに頻繁に送信する問題は軽減されますが、これはデータのパスに関する問題を解決するにすぎません。Prompt Injection、誤ったツール呼び出し、権限の越境、および不可逆的な操作は依然として存在します。Metaはまた、Agentic Risk、プライバシー、Prompt Injectionを個別に評価し、本番デプロイではGuardrailの強化と必要なHuman in the Loopの継続的追加を推奨しています。
明確な能力の道筋
Muse Glimmerの完全な技術パスは、比較的明確な連鎖を形成できます。
モデル規模は約30Bに制御し、GQAとLocal Attentionにより128KコンテキストのGPUメモリコストを削減。量子化によりモデルを24GBおよび32GBデバイスに実行可能にし、Perception Encoderが視覚的環境を読み取り、On-Policy Distillationが長期間タスクにおける逸脱状態をカバー。Reasoning Strengthは開発者が推論予算を制御可能にし、DFlashが大量のReasoningトークンによるデコード遅延を再処理する。
Muse Glimmerは、ローカルの30Bモデルがクラウド上のFrontierモデルを置き換えることを証明していないが、ローカル30Bモデルの最終形態は単なる規模ではなく、システムレベルのエンジニアリングによってさまざまなハード制約を総合的にヘッジすることにあることを示した。これにより、ローカルエージェントで最も対処が難しいメモリ、コンテキスト、環境状態の認識、および推論速度という4つの制約を、同一のシステム設計に組み込んだ。
Muse Glimmerは、クラウド上のフラグシップモデルを完全に置き換えることはできませんが、「誰もが独自のエージェントを持つ」という目標に向けて、産業レベルで実現可能な道を切り開きました。