Tomas Koutskyが、MetaがMuse Glimmerを24 GBに収める方法を説明する

Why it matters

Muse Glimmer shows how a 30B local agent can preserve a 131K-token context without allowing its attention cache to consume most device memory. Actual performance still depends on prompt-processing time and whether the serving engine implements the sliding-window cache efficiently.

Meta は、24 GB または 32 GB のメモリを搭載したコンシューマ向けハードウェアで動作するよう設計された、300億パラメータのマルチモーダルエージェント Muse Glimmer を公開した。Tomas Koutsky（AI ワークフロースタートアップ Byteline の共同創業者）は、モデル本体、131,072 トークンのコンテキスト、ビジョンエンコーダ、スペキュレーティブ・デコーディングモデルを同一デバイス上に収める Meta の手法を検証した。

Koutsky はエージェントシステムの構築者としてそのアーキテクチャに接近している。彼は 2025 年に Byteline を共同創業し、自然言語会話を通じて複数の AI エージェントを調整できるようにした。以前は Pipedrive と Streetbees でのエンジニアリング職を経て、BRAHMA AI と Metaphysic.ai でエンジニアリングを率いた。彼の Muse Glimmer 分析（8 月 18 日公開）は、このモデルを狭いキー・バリューキャッシュを中心に構築されたメモリ階層として記述している。

Meta compresses the weights below 20 GB

Meta released Muse Glimmer on August 10 under the Apache 2.0 license. Meta describes it as a dense, multimodal model for local coding, function calls, tool use and extended agent workflows without a cloud connection. RuntimeWire オープンウェイトのリリースを報じた、Meta の量子化構成が 24 GB または 32 GB のメモリ環境内で動作し得るという主張を含めて報じている。

未圧縮のチェックポイントは 55 GB を超えて消費する。Meta によれば、概ね 4 ビットの量子化により言語モデルは 20 GB 未満に縮小され、キー・バリューキャッシュ、知覚エンコーダ、DFlash スペキュレーティブドラフターのための余裕が残されるという。

Koutsky は Muse Glimmer が約 297 億 7,700 万パラメータを含むと計算している。52 のテキスト Transformer ブロックは約 251 億 6,500 万パラメータを占め、ビジョンタワーは約 18 億 5,300 万を含むと見積もる。埋め込み、アンタイド出力ヘッド、および視覚と言語コンポーネント間のブリッジを含めた BF16 の総保存量は約 55.46 GiB と推定している。

Meta は K-Quant-17GB 構成を、量子化された DFlash ドラフターを用いて M4 Max と M5 Max の MacBook、および Nvidia RTX 5090 でテストした。ドラフターはメインモデルが並列に検証するトークンのブロックを提案する。Meta は RTX 5090 でデコード速度が 3.1 倍、M5 Max で 1.8 倍、M4 Max で 1.5 倍になったと報告している。

A narrow cache leaves room for long context

Muse Glimmer は各トークンごとに増加するメモリを制限している。52 のテキスト層のうち 39 層は 2,048 トークンのスライディングウィンドウに注目し、13 層は全シーケンスを参照できる。モデルは 32 のクエリヘッドと 2 つのキー・バリューヘッドを使用する。現在のトークンに対するクエリは破棄できる一方、以前のトークンのキーと値は生成中に利用可能なままである。32 個の代わりに 2 つのキー・バリューバンクを保存することで、各アクティブシーケンスで蓄積される状態を削減している。

Koutsky の推定では、完全な 131,072 トークンのコンテキストにおけるアクティブな BF16 または FP16 キー・バリューキャッシュは約 1.70 GiB になる。13 のグローバル層が約 1.625 GiB を占め、ウィンドウが埋まった後のローカル層には約 78 MiB が割り当てられる。

その見積もりはサービング実装に依存する。Koutsky は、エンジンがスライディングウィンドウ層の古いエントリを追い出すか循環的に再利用する必要があると述べ、そうすることで節約が実現されると説明している。シーケンス全体にわたる静的割り当ては著しく多くのメモリを消費するだろう。キャッシュ量子化、ページサイズ、断片化、ランタイム作業領域も測定使用量を変化させうる。

39 層が 2,048 トークンのスライディングウィンドウを使用し、4 層に 1 層の割合で全コンテキストに注意を払う。

Long context still carries a compute charge

Muse Glimmer の 13 のグローバルアテンション層はプロンプト処理中に完全なアテンションを行う。メモリ効率の良いカーネルが完全なアテンション行列の格納を回避しても、そのアテンション演算はシーケンス長に対して二次的に増加する。したがって Koutsky の分析はメモリ容量と処理時間を分離している：アーキテクチャは 131K トークンのコンテキストを収め得るが、事前入力（prefill）が短いプロンプトと同等の処理量になるわけではない。

ローカル層とグローバル層が検索作業を分担する。ローカル層は境界付けられたウィンドウ内で順序情報を保持する。周期的なグローバル層は、すでに近傍のコンテキストを含んでいる表現を検索する。Koutsky はグローバル層が rotary positional embeddings（RoPE）を省略しており、主にコンテンツによって遠隔の情報をマッチさせると指摘している。

順序は依然として因果マスクや、RoPE を備えた 3 層の直前のローカル層が生成する表現を通じてそれらの層に伝わる。Koutsky はこの配置が長距離にわたるコンテンツベースの検索をサポートし得ると主張している。ローカルコンテキストが十分な分離を提供しない場合、類似した箇所は区別しにくくなる可能性がある。

Meta reports limited quantization loss

Meta は量子化が「エージェントタスクにおいて最小限または無視できる劣化」をもたらすと述べている。リリースでは、フルプレシジョン、K-Quant-Dynamic、K-Quant-17GB の構成を比較したグラフィックで精度結果を提示しているが、本文中で単一の総合的な劣化数値は示していない。

Meta は Muse Glimmer を Gemma 4 31B および Qwen3.6 27B と比較している。同社の evaluation methodology report はこれらの比較の背後にあるフレームワークを説明している。報告された結果は Meta が選択した比較を確立するが、他のエージェント基盤や拡張された個人ワークフローにおける性能はその結果の範囲外にある。

Koutsky の分解は Meta のハードウェア主張の背後にあるメモリ算術を説明している。量子化は固定重みコストを削減し、grouped-query attention は永続的キャッシュを狭め、ローカル・グローバル層のスケジュールはほとんどの層が保持する履歴の量を制限する。プロンプト処理とサービング実装が依然としてモデルが最大コンテキスト付近でどのように振る舞うかを決定する。