Muse Glimmerは30B Transformerに偽装されたメモリ階層である

← 執筆 2026年8月18日 Tomas Koutsky 19分読了 Muse Glimmerはどのようにエージェントをデバイスに搭載するか Muse Glimmerは、30B Transformerに偽装されたメモリ階層であることが答えです。glimmerlocal MetaはMuse Glimmerを、デバイス上で動作するエージェントとして提案しています。自律的で、マルチモーダル、クラウド不要です。これは製品の主張であると同時にエンジニアリングの問題でもあります。高性能な30Bクラスのモデル、長いワーキング履歴、そして知覚スタックをコンシューマーハードウェアに収めることです。答えは、30B Transformerに偽装されたメモリ階層であることが判明しました。そのモデルカードは目標について直接述べています。「Muse Glimmerは、コンシューマーハードウェア上での自律的なエージェントタスクのために特別に構築されており、クラウドインフラストラクチャやネットワークアクセスを必要とせずに動作します。」エージェントのワークロードは長期間にわたるため、この約束は要求が厳しいです。数時間の履歴とツールのトランスクリプトは常駐し、スクリーンショットやドキュメントはタスクの途中で再読され、それらすべてがMetaが量子化リリースで指定している24GBまたは32GBのエンベロープに収まる必要があります。Muse Glimmerは、約300億パラメータのデコーダーオンリーのマルチモーダルモデルです。ビジョンエンコーダー、プロジェクター、そして密な言語モデルで構成されています。BF16では、チェックポイントは約55GiBの重さがあり、これはコンテキストの1トークンも処理する前に両方のエンベロープをオーバーフローさせてしまうため、答えの一部は簡単に特定できます。Metaは、言語モデルを20GB未満に抑える約4ビット量子化バリアントを出荷しています。圧縮されたモデルは、131,072トークンのコンテキスト、常駐するビジョンタワー、および投機的デコーディングドラフターとカードを共有する必要がありますが、言語モデルが小さくなっても、それらのどれも小さくなりません。残りの答えはアーキテクチャにあります。モデルがメモリをどこに費やし、各レイヤーがどのような種類の情報を持つかということです。Muse Glimmerは、意図的な労働分担を中心に構築されています。ほとんどのレイヤーでは、アテンションはローカルです。RoPEによって配置され、2,048トークンのウィンドウに制限されています。4層ごとに、アテンションはコンテキスト全体に開きますが、RoPEをドロップし、主にコンテンツによって取得します。アテンションのみが交互になり、各ブロックの残りは同一です。32個のクエリヘッドは豊富な取得動作を提供しますが、KVキャッシュに保存されるキー/バリューヘッドは2つだけです。視覚側では、大きなViTが高価な知覚を一度実行し、隣接するパッチを4対1で圧縮し、それを通常のトークンとして言語デコーダーに渡します。これらをまとめると、部品は階層的なメモリシステムを形成します。ローカルレイヤーは順序付けられた、コンテキストリッチな表現を構築し、グローバルレイヤーはそれらの表現をシーケンス全体で検索し、KVキャッシュは各アクティブシーケンスの非常に狭いメモリトレースを保存します。シーケンスごとの状態は設計により非常に小さいため、実行中のインスタンスが必要とするメモリのほぼすべてはモデルのパラメータです。だからこそ、重み量子化はここで異常にうまく機能するのです。これらの固定された重みが圧縮されると、解放されたメモリは、より長いコンテキスト、より大きなバッチ、常駐する知覚タワー、または投機的デコーディングドラフターに転換できます。55GiBがどこにあるか リリースされたテンソル形状から合計した内訳は以下の通りです。コンポーネント 約パラメータ BF16ストレージ 52 テキストTransformerブロック 25.165B 46.87 GiB 入力トークン埋め込み 1.345B 2.50 GiB 非結合言語モデルヘッド 1.345B 2.50 GiB ビジョンタワー 1.853B 3.45 GiB ビジョンからテキストへのブリッジ 69.2M 0.13 GiB 合計 29.777B 55.46 GiB Muse Glimmerは密なモデルであるため、生成される各トークンは52個すべてのテキストブロックを通過します。メモリ内で未使用のまま待機しているルーティングされたエキスパートはありません。これにより予測可能な実行が可能になりますが、バッチサイズが小さい場合、デコーディングは非常に大きな重みセットを繰り返し読み取ることに大きく依存します。4層ごとにすべてを見る 52個のテキストレイヤーは厳密な繰り返しスケジュールに従います。したがって、39個のスライディングアテンションレイヤーと13個のフルアテンションレイヤーがあります。ローカルウィンドウは2,048トークンです。位置iにあるローカルレイヤーは、iで終わる最近の区間のみを直接読み取ることができます。しかし、ローカル受容野は深さと共に複合します。境界効果を無視すると、3つの積み重ねられた因果ウィンドウは、トークンを間接的に約1 + 3 × (2048 − 1) = 6,142の位置にさらします。6,141個の前置詞とトークン自身です。それに続くグローバルレイヤーは、生の孤立したトークンを受け取るのではなく、数千トークンの順序付けられたローカル構造をすでに要約した表現を受け取ります。4層サイクルの読み方の一つは、最初のローカルレイヤーが即時の語彙的および構文的な関係を構築し、次の2つがそれらをますます大きなローカル構造に組み合わせ、最後のフルレイヤーがコンテキストのどこからでも関連する要約を取得することです。分割はソフトです。ローカルレイヤーは残差ストリームにグローバル情報を前方に運び、グローバルレイヤーはローカルに注意を払うことができます。それでも、マスクは強い事前情報を課します。ほとんどの計算は近くの構造を洗練し、時折のレイヤーが長距離通信を処理します。これは、特にKVキャッシュの場合、すべての52レイヤーをグローバルにするよりもはるかに安価です。長コンテキスト計算は別の問題です。プリフィル中、13個のフルアテンションレイヤーは依然としてシーケンス長に対して二次的なアテンションワークを実行します。FlashAttentionライクなカーネルは、完全なアテンション行列を具体化することを回避しますが、ドット積を消去するわけではありません。Muse Glimmerは131Kコンテキストをメモリで実現可能にしますが、131Kプリフィルを4Kプリフィルと同等にはしません。RoPEなしのグローバルアテンション まず、フルレイヤーが何を失っているかのリマインダーです。RoPEは、各クエリとキーをトークンインデックスと共に増加する角度で回転させます。2つの回転は、ベクトルが互いにスコアリングされるときに合成されるため、アテンションロジットは相対的な変位j−iにのみ依存するようになります。その合成が、Transformerが通常距離を感じる方法です。Muse Glimmerは、すべてのローカルレイヤーでθ=500,000のRoPEを使用します。しかし、各フルアテンションレイヤーでは、レイヤーごとのRoPEシータはゼロであり、実装はアテンションに位置埋め込みを渡しません。これはNoPEと呼ばれる構成です。したがって、フルレイヤーは直接的な回転位置項なしでQ–K互換性をスコアリングします。順序は依然として2つのドアを通じてこれらのレイヤーに到達します。まず、因果マスクは、位置iがi以前の位置のみを読み取ることができることを伝えます。第二に、各グローバルキーとバリューは、RoPEを備えた3つのローカルレイヤーをすでに通過しています。「川」の近くの単語「銀行」を表すベクトルは、「ローン」の近くの単語「銀行」を表すベクトルとは異なり、両方のベクトルはそれらを生成したローカル順序をエンコードしています。後続のグローバルレイヤーは、以前のグローバルレイヤーによって変更された残差状態も受け取ります。したがって、正確なステートメントは、グローバルレイヤーがQ–Kスコアに直接の位置項を持たないが、位置を認識し、ローカルにコンテキスト化された表現で動作するということです。131Kトークンでこれがどのように役立つ可能性があるでしょうか？従来のグローバルRoPEレイヤーは、1トークンから10万以上の距離にわたる相対回転を解釈する必要があります。長距離検索は、通常の言語を支配する距離の範囲外の位相挙動と絡み合う可能性があります。代わりに、NoPEグローバルレイヤーはコンテンツアドレス可能なメモリのように動作します。関連アイテムは、単に80,000トークン離れているという理由だけで、一致するのが本質的に困難になるわけではありません。このアーキテクチャは、正確な順序付けを最も価値のある場所、つまり境界のあるローカルウィンドウ内に配置し、グローバルレイヤーに異なる質問をします。近くのピースがどのように配置されているかではなく、メモリのどこにあるコンテキスト化されたピースが現在のニーズに応えるかということです。トレードオフがあります。2つの真に類似した遠い出現は、グローバルスコアリングに明示的な位置項がない場合、絶対位置によって区別するのがより困難になります。Muse Glimmerは、各出現が周囲のローカルコンテキストを運ぶようにすることでこれを緩和しますが、曖昧さは完全に消えることはありません。この設計は、正確なグローバル座標マッチングよりも堅牢な意味検索を優先します。32個のクエリ、2つのメモリ Muse Glimmerは、32個のクエリヘッドと2個のキー/バリューヘッドのみを持つグループ化クエリアテンションを使用しているため、16個のクエリヘッドが各K/Vバンクを共有します。この非対称性は、生成が実際に何にコストをかけるかに一致しています。クエリe