Meta Muse Glimmer入門：手元のGPUで動く30Bのオープンエージェントモデル

2026年8月10日、Metaが Muse Glimmer という新しいAIモデルを公開しました。パラメータ数は300億（30B）、ライセンスはApache 2.0、そして「手元のGPU 1枚で動く」ことを前面に出したモデルです。

大規模言語モデルの話題は、ふだんクラウドのAPI越しに使う巨大モデルが中心です。Metaがここで狙ったのはその外側で、自分のPCの中で何時間も止まらずに動き続けるエージェントの頭脳になることを目標に置いています。

30Bが1枚のGPUで動くという話自体は珍しくありませんが、それをApache 2.0で、しかもエージェント用途に振って出してきたのはMetaとしてはかなりの方針転換です。公式ドキュメントとモデルカード、それにコミュニティの検証記事を読んだ範囲で、何者で、どう小さくして、どこが弱いのかをまとめます。実機で回した話ではないので、数字はすべて出典を付けて並べます。専門用語はひとつずつ説明します。

Table of contents

Muse Glimmerとは何か

Muse Glimmerは、Metaの Meta Superintelligence Labs が公開した、テキストと画像を入力として受け取り、テキストを出力するモデルです。公式ページのキャッチコピーは次のとおりです。

An open model built for always-on local agents. 30B parameters, licensed under Apache 2.0 and runs on a single GPU — tuned for tool use, long tasks, and failure recovery.

（常時稼働するローカルエージェントのために作られたオープンモデル。300億パラメータ、Apache 2.0ライセンス、GPU 1枚で動作し、ツール利用・長いタスク・失敗からの復帰に向けて調整されている）

— Muse Glimmer | Meta

エージェント とは、質問に一度答えて終わりではなく、目的を与えられたら自分で手順を組み立て、外部のツール（ファイル操作、Web検索、コマンド実行など）を呼び出しながら、何往復もしてゴールに近づいていくAIの使い方を指します。チャットボットが調べ物の相談相手だとすれば、エージェントは作業を任せられる担当者です。

担当者に仕事を任せるには、賢いだけでは足りません。指示どおりの書式で道具を使えて、途中で失敗しても立て直せることのほうが効きます。Metaはそこを狙って調整したと説明しています。

基本スペック

「Dense（密）」というのは、推論のたびにモデルの全パラメータを使う、という意味です。最近流行しているMoE（Mixture of Experts、専門家混合）は、パラメータの一部だけを選んで動かすことで巨大化と省コストを両立しますが、MetaはMuse Glimmerであえて素直な構成を採りました。300億という控えめなサイズなら、全体を使い切ったほうが性能を出しやすい、という判断でしょう。

Museファミリーの中での位置づけ

Muse Glimmerは、MetaのMuseシリーズの一員です。上位にはより大きなフラッグシップモデルの Muse Spark があり、Muse Glimmerはそこから知識を受け継いで作られています。Metaは Muse Spark 自体のオープンウェイト版も今後公開する予定だと報じられています（AOL / Reuters）。

つまりMuse Glimmerは、大きなモデルの知識を、動く場所を選ばないサイズに詰め直したモデルです。

Apache 2.0であることの意味

今回、技術面よりライセンスの変更のほうが話題になりました。

Metaはこれまで、Llamaシリーズを Llama Community License という独自ライセンスで配布してきました。無償で使えるものの、月間アクティブユーザー7億人を超える企業には別途許諾が必要、派生モデルの名前に「Llama」を含める義務がある、といった条件が付いていました。オープンとは呼ばれるものの、OSI（Open Source Initiative）の定義するオープンソースには当てはまりません。

Muse Glimmerは、この独自ライセンスをやめて Apache 2.0 を採用しました。Apache 2.0は広く使われている許諾的なオープンソースライセンスで、商用利用も改変も再配布も自由、特許条項も明示されています。企業が法務レビューを通しやすい、実務的に扱いやすいライセンスです。この転換は Phoronix をはじめ複数のメディアで、Metaのオープン戦略の再定義として報じられました。

オープンウェイトとオープンソースの違い

Apache 2.0で公開されたのは モデルの重み（weights） です。学習に使ったデータセットも学習コードも公開されていません（explainx.ai の解説）。

例えるなら、完成した料理のレシピ本ではなく、完成した料理そのものを「好きに食べても売ってもいい」という条件で渡された状態です。食べるのも、味を変えるのも、店で出すのも自由（＝推論もファインチューニングもサービスへの組み込みも自由）ですが、同じものをゼロから作り直すことはできません。

また、Apache 2.0ライセンスとは別に、Hugging Faceのリポジトリには 利用ポリシー が併置されています。ライセンス上の権利と、Metaが求める利用上の規範は別物です。

止まらないエージェントという狙い

Metaが前面に出しているのは、エージェントとして使い続けられるかどうかです。ベンチマークの点数はその次に置かれています。公式ページには次のようにあります。

Built for agents that don’t stop with reliable tool-calling, persistent state across restarts, and self-managed memory across hours-long sessions.

（止まらないエージェントのために作られている。信頼できるツール呼び出し、再起動をまたいで保持される状態、数時間に及ぶセッションでの自己管理型メモリ）

— Muse Glimmer | Meta

一方、同じMetaでも 研究ブログ側の記述 はもう少し抑制的です。挙げられているのは次の3つでした。

• 多段推論（Multi-Step Reasoning）：長いワークフローをまたいで推論をつなげる
• 失敗からの復帰（Failure Recovery）：エラーが起きたとき、停止せずに原因を診断して再試行するよう訓練されている
• 長文脈メモリ：131,072トークンの文脈長を活かした記憶の保持

再起動をまたいだ状態の保持と自己管理型メモリについては、研究ブログに仕組みの説明がありません。モデル単体でできることではなく、モデルを組み込むアプリケーション側（スキャフォールド）と組み合わせて成り立つ話です。製品ページのこの2行は、技術仕様ではなく到達目標として読んでください。

失敗からの復帰

具体例で考えてみます。「このリポジトリのテストを通るように修正して」とエージェントに頼んだとしましょう。

エージェントは、まずファイルを読み、修正案を書き、テストを実行します。ここでテストが落ちる。よくある挙動は2つです。

1. 「テストが失敗しました」と報告して止まる
2. エラーメッセージを読み、原因を推定し、別の修正を試す

人間の担当者に期待するのは当然2番です。ところがモデルにとって、エラー出力という想定外の入力を受け取ってから自分の前提を修正するのは、意外に難しい振る舞いです。Metaはこの2番の挙動を明示的に学習させたと説明しています。エージェント用モデルで効いてくるのは、1回の応答の賢さより、20回も50回も往復したときに脱線しないかどうかです。

アーキテクチャ

Muse Glimmerは、画像を理解する部分と、文章を生成する部分の2つに分かれています。

用語が多いので、効いているところだけ噛み砕きます。

知覚エンコーダ

ViT（Vision Transformer）は、画像を小さなタイル（パッチ）に切り分けて、それぞれをTransformerで処理する方式です。ViT-G/14 は「Giantサイズ、パッチ14ピクセル四方」を意味します。

この部分の役割は、画像をテキストデコーダが扱えるトークン列に翻訳することです。1枚の画像は最大4,096個の視覚トークンに変換され、文章のトークンと混ぜて同じ列に並べられます。デコーダから見れば、画像もテキストも区別なく並んだ入力にすぎません。

「凍結（frozen）」とあるのは、この視覚エンコーダの重みを学習中に更新していないという意味です。すでに十分な画像認識能力を持ったエンコーダを流用し、言語側だけを鍛えたことになります。

局所注意と大域注意

Transformerの注意機構（Attention）は、各トークンが他の全トークンを見に行く仕組みです。素朴に実装すると、トークン数の2乗に比例して計算量が増えます。131,072トークンの文脈に対してこれを全層で行うと、消費メモリも計算時間も現実的ではなくなります。

そこでMetaは層に役割を分けました。

• 局所注意層（4層のうち3層）：直近2,048トークンの窓の中だけを見る
• 大域注意層（4層のうち1層）：文脈全体を見る

会議の議事録に例えるなら、ほとんどの発言は直前の数分の話に反応すれば足りて、ときどき今日の議題全体を確認すればいい、という発想です。全層で全体を見る必要はありません。この配分で、長い文脈を保ったままメモリ消費を抑えられます。

GQAとKVキャッシュ

GQA（Grouped-Query Attention、グループ化クエリ注意）は、複数のqueryヘッドで少数のKey/Valueヘッドを共有する手法です。Muse Glimmerは32個のqueryヘッドに対してKVヘッドが2個、つまり16対1の比率です。

なぜこれが効くかというと、生成中に保持し続ける KVキャッシュ（過去トークンのKey/Valueを覚えておくメモリ）のサイズが、KVヘッド数に比例するからです。KVヘッドを16分の1にすれば、長い文脈を持ったときのメモリ消費も大きく減ります。ローカル実行で最初に枯渇するのはVRAMです。GPU 1枚で動かすという目標には、この設計が一番効いています。

Muse Sparkからの蒸留

Muse Glimmerが小さいまま高い性能を出せる理由の中心が、蒸留（distillation）です。

蒸留とは、大きくて賢いモデル（教師）の振る舞いを、小さいモデル（生徒）に真似させる学習手法です。肝心なのは、何を真似させるかです。

素朴なやり方は、教師が出した文章を正解データとして生徒に学習させることです。しかしMetaが使った ロジット蒸留（logit distillation）はもう一歩踏み込みます。教師が次のトークンを選ぶときの確率分布そのもの（＝ロジット）を生徒に近づけさせるのです。

教師が「次の単語は『猫』が60%、『犬』が30%、『鳥』が5%」と考えていたとします。文章だけを真似る方式では、生徒は「猫」という結果しか学べません。ロジット蒸留では「猫が最有力だが犬もかなりあり得る」という迷いの構造まで受け渡されます。同じデータ量からより多くの情報が伝わるため、小さいモデルでも教師の判断傾向を効率よく吸収できます。

学習は3段階で構成されています（Meta AI Research）。

中間学習でエージェント中心のデータと推論トレースを入れているのが特徴的です。推論トレースとは、答えだけでなく、そこに至る思考の過程を含んだデータのことです。考え方の型を覚えさせる段階になります。

事後学習のオンポリシー蒸留は、生徒自身が生成した文章の上で 蒸留を行う方式です。教師が書いた完璧な文章をなぞらせるだけだと、生徒が実際に踏み込みがちな筋道はそもそも学習データに現れず、そこでの判断を直せません。まず生徒に走らせ、その各トークン位置で教師と生徒の確率分布のずれを詰めていくので、実運用で生徒が陥りやすい失敗パターンに効きます。

ここは強化学習と混同しやすいところです。オンポリシー蒸留で使うのは教師モデルの確率分布であって、報酬モデルが回答全体に点数を付けるわけではありません（On-Policy Distillation of Language Models, ICLR 2024）。Metaは事後学習にオンポリシー蒸留と強化学習の両方を挙げていますが、それぞれをどう組み合わせたかまでは公表していません。

手元のマシンで動かす工夫

300億パラメータのモデルは、そのままでは家庭用GPUに載りません。Metaは量子化と投機的デコーディングを組み合わせて、この壁を越えました。

量子化

量子化（quantization）とは、モデルの重みを表す数値の精度を落として、必要なメモリを減らす技術です。BF16（16ビット浮動小数点）で保存されていた各パラメータを4ビット程度の整数に置き換えれば、単純計算でサイズは4分の1になります。

写真をJPEGで保存するのに似ています。厳密には情報が失われますが、見た目にはほとんど分からない範囲に収まっていれば実用上は問題ない、という考え方です。

Metaは3種類の精度を用意しています。

K-Quant-17GB は15種類のベンチマークで平均1.0%の低下、と報告されています（MarkTechPost）。24GB VRAMというのは、RTX 4090 / RTX 5090クラスのコンシューマ向けGPU 1枚が該当します。Apple SiliconのMacBook Pro（M4 Max / M5 Max）もユニファイドメモリで対応可能です。

この表の数字は、モデルの重みのサイズではなく 動かすために必要なVRAMの総量 です。変種名の K-Quant-17GB が示すとおり、4ビット量子化された言語モデルの重み自体は20GBを切ります。24GBや32GBというのは、その重みに加えてKVキャッシュ、視覚エンコーダ、DFlashのドラフタまで同時に載せて動かすことを想定した、対象ハードウェア側の容量です（モデルカード）。モデルが24GBまで圧縮された、と読んでしまうと、文脈を伸ばしたときにKVキャッシュでVRAMが足りなくなる理由が説明できなくなります。

なお、Metaの 量子化ドキュメント では、llama.cpp を使ったGGUF形式への変換（bf16経由で Q4_K_M へ）が案内されており、「デプロイ前に自分のワークロードで量子化チェックポイントを検証すること」「フル精度モデルとperplexityを比較して品質低下が許容範囲か確認すること」が推奨されています。ベンチマーク上の平均低下率と、自分のタスクでの体感品質は別物です。

投機的デコーディング（DFlash）

メモリに載っても、生成が遅ければエージェントとしては使えません。エージェントは1回の依頼で何十回もモデルを呼ぶため、1トークンあたりの遅延がそのまま作業時間に積み上がります。

そこで使われているのが 投機的デコーディング（speculative decoding）です。Metaは DFlash という専用の下書きモデル（ドラフタ）を組み合わせました。

仕組みはこうです。通常の生成は1トークンずつ順番に作るので、300億パラメータのモデルを1トークンごとにフル稼働させることになります。代わりに、小さくて速いドラフタに先の16トークンをまとめて予測させ、本体モデルには「この16トークンで合っているか」を1回でまとめて検証させます。合っていた分はそのまま採用し、外れた地点以降を捨てて作り直します。

採用されるのは 本体モデルが承認したトークンだけ なので、出力の品質は1トークンずつ生成した場合と変わりません。速くなるのは、本体モデルを呼ぶ回数が減るからです。

DFlashのドラフタは5層、スライディング窓2,048、32 queryヘッド / 8 KVヘッドで、1回の順伝播で16トークンを予測するブロック拡散型の構成です。

RTX 5090の毎秒233トークンは、体感としては人間が読む速度をはるかに超えます。エージェントループの中に置いても待たされない、という水準を目指した数字です。

ベンチマークを読む

比較対象は、同クラスのオープンモデルである Gemma4-31B と Qwen3.6-27B です。

全カテゴリのスコア

出典：Muse Glimmer | Meta（2026年8月11日参照）

他モデルとの比較

3モデルすべての数値が公表されているものを並べます。

得意なのは、ツールを介した多段作業です。MCP Atlas（MCPサーバー経由のツール操作を評価）の75.5は、Gemma4-31Bに21ポイント以上、Qwen3.6-27Bに13ポイント差をつけています。実世界のGitHub issueを解かせる SWE-Bench Pro でも首位です。Metaがエージェント向けに振って学習させた分が、そのままスコアに出ています。

苦手もあります。SWE-Bench Verified（人手で検証済みの比較的解きやすいissue群）では Qwen3.6-27B の77.2に対して76.0とわずかに劣ります。ターミナル操作を評価する TerminalBench 2.1 では51.7対60.7で9ポイントの差、デスクトップGUI操作の OSWorld-Verified も65.9で、Qwen3.6-27B の75.6に届きません。

万能ではありません。構造化されたAPIやツールスキーマを介した作業は強い一方で、シェルやGUIのように自由度が高く曖昧な操作環境では順位が入れ替わります。

なお、これらはすべてMetaが自社で測って公表した数値です。どのベンダーも自社に有利なベンチマークを選びます。この表は候補に残すかどうかの判断までに使って、採否は自分のタスクで測ってから決めてください。

使い方の基本

実際に触るときに知っておくべき仕様を、Metaの プロンプトガイド からまとめます。

チャットテンプレート

プロンプトを手で組み立てず、トークナイザの apply_chat_template を使ってください。ガイドでも強く推奨されています。ガイドには「特殊トークン、ロールヘッダ、ターン区切りといった細かな書式の違いが、出力品質に測定可能な影響を与える」とあります。

展開後の形式は次のようになります。

<|begin_of_text|><|start|>system<|message|>[content]<|eot|><|start|>user<|message|>[content]<|eot|><|start|>assistant

ロールと宛先（recipient）

メッセージは system / user / assistant / tool のロールを持ち、assistantのターンにはさらに「宛先」が付きます。

to=self が独立した宛先として定義されているのが特徴です。モデルが考えている最中の出力と、利用者に向けた出力を、出力レベルで区別できます。アプリ側は to=self のターンを画面に出さずに捨てる、といった制御が素直に書けます。

宛先の使い分けを含めた1往復の流れは次のとおりです。

推論の強さを切り替える

reasoning_strength パラメータで、思考にかける手間を low / medium / high / xhigh の4段階から選べます。既定値は high です。

簡単な分類タスクに毎回 xhigh を使えば、遅くなるだけでコストに見合いません。逆に難しい数学問題を low で解かせても精度が出ません。エージェントのステップごとに切り替えるのが実用的な使い方です。過去の推論内容は、assistantメッセージの reasoning_content フィールドで渡し直せます。

ツール呼び出しの制約

OpenAI形式の関数スキーマを apply_chat_template の tools 引数に渡すと、モデルは ATEM形式 と呼ばれる記法で assistant to=ツール名 のターンを出力します。ただしガイドには明記があります。「Muse Glimmerは1ターンにつき1つのツール呼び出しをサポートします。並列ツール呼び出しはサポートしません」。

つまり3つのファイルを同時に読むような並列呼び出しはできず、1件ずつ順番に往復することになります。独立した処理を並列化して待ち時間を縮める設計は使えないので、そのぶんステップ数が増える前提でアプリ側を組んでください。DFlashで生成を速くしているのは、この往復の多さを埋めるためでもあります。

3つのファイルを読むだけでも、往復回数はこれだけ変わります。

なお、コミュニティの検証記事では、実際の出力が <atem:function_calls> / <atem:invoke> / <atem:parameter> というXML風のタグとして観測されたと報告されています（explainx.ai）。パースを自作する場合の参考になりますが、公式にはテンプレート任せが推奨です。

画像を渡す

画像を含める場合はトークナイザではなく AutoProcessor を使います。メッセージの content を配列にして、{"type": "image", "url": "..."} と {"type": "text", "text": "..."} を並べる形式です。テンプレートが <|image|> というセンチネルトークンを適切な位置に挿入します。

サンプリング設定

推奨値は次のとおりです。

temperature が1.0というのは、他モデルでよく使われる0.0〜0.7と比べるとかなり高めです。モデルごとに最適な温度は違うので、他モデルの感覚で低く設定すると、かえって出力が単調になったり繰り返しに陥ったりすることがあります。まず推奨値から始めてください。

動かす環境の選び方

Metaは幅広い実行環境への対応を案内しています。ただし公開時点の発表は、統合の一部について「coming days（数日以内）」と書いていました。次の表は、初日に揃っていたものではなく、対応が表明された選択肢の一覧です。

出典：Meta AI Research

同じ名前が挙がっていても、リリース版に取り込まれているものと、開発版でしか動かないものが混在します。実際に使う前に、それぞれのランタイム側のリリースノートで現在の対応状況を確認してください。

7つ並べましたが、最初の1本は Ollama でいいと思います。量子化の指定もランタイムのビルドも要らず、ollama run だけで動くところまで行けます。そこで感触を見てから、Macで詰めるならMLX、サーバーに載せるならvLLMへ移ればいい。ExecuTorchとUnslothは、用途がはっきりしてから触るもので、最初に選ぶ理由はありません。

コードから叩くなら、Transformersのパイプラインが最短です。

from transformers import pipeline

pipe = pipeline("image-text-to-text", model="meta-models/Muse-Glimmer-30B")

OpenAI互換のAPIサーバーとして立ち上げるなら vLLM です。

pip install vllm
vllm serve "meta-models/Muse-Glimmer-30B"

SGLangも対応先として挙げられていますが、こちらはそのままでは動きません。SGLang公式のレシピ は現在も「Muse Glimmer support is not in a release yet」と明記しており、専用のPRブランチをビルドするか、開発用のDockerイメージを使うことを求めています。pip install sglang で入る通常のリリース版では、次の起動コマンドは失敗します。

# 注意: リリース版のSGLangは未対応。
# 公式レシピが指定するPRブランチのビルド、または開発用Dockerイメージが必要
python3 -m sglang.launch_server --model-path "meta-models/Muse-Glimmer-30B"

新しいモデルの公開直後は、発表済みだがリリース版には未着地、という状態がしばらく続きます。対応表に名前が載っていることと、pip install したもので動くことは別です。手順どおりに動かないときは、自分の環境を疑う前にランタイム側の対応状況を確かめてください。

とはいえ反応は速く、Ollama 0.32.7 が公開当日にMuse Glimmerのサポートを追加し、llama.cpp のサポートも同日にマージされています（Phoronix、explainx.ai）。Apache 2.0で配りやすくなったぶん、各ランタイムの開発者が動きやすかったのだと思います。

導入前に押さえておく注意点

モデル自身の限界

モデルカード には次の点が明記されています。

• 不正確な出力、偏った出力、不適切な出力を生成する可能性がある
• 多段推論、特に前例のない状況では誤りうる
• 動画には最適化されていない（個別のフレームとして処理される）
• 強くサポートされている言語以外では性能が落ちる可能性がある
• 量子化推論では、エッジケースでわずかな品質差が出うる
• 18歳未満の利用者は対象外

「多段推論で誤りうる」は、エージェント用途を掲げるモデルとしては素直な注意書きです。失敗からの復帰を学習させたとはいえ、間違った前提のまま自信を持って進み続けるリスクは残ります。取り返しのつかない操作（ファイル削除、外部への送信、決済など）は人間の承認を挟む設計にしてください。

プロンプトインジェクションへの耐性

エージェントとして使う以上、外部から取り込んだテキストに攻撃的な指示が埋め込まれる プロンプトインジェクション が現実的な脅威になります。

Muse Glimmerは Siren AgentDojo という評価で、攻撃成功率28.4%、有用性維持率94.2%と報告されています（MarkTechPost）。Metaは有用性をほぼ落とさずに攻撃を防げた、という文脈でこの数字を出していますが、4回に1回以上は攻撃が通る ということでもあります。エージェントに外部のWebページを読ませるつもりなら、これは使えない水準です。

モデル単体の耐性には頼らず、ツールの権限を最小限に絞る、外部から取得した内容を信頼しない、危険な操作は承認を挟む、というアプリケーション側の防御を前提にしてください。

学習データが非公開であること

前述のとおり、Apache 2.0で公開されたのは重みだけです。モデルカードには学習データについて「公開されているデータ、第三者から提供されたデータ、Metaの製品やサービスからの情報」を含むと記載されています。内訳を第三者が検証できません。著作権やプライバシーの監査が要る用途では、ここが通らない可能性があります。

要点

• Muse Glimmerは、Metaが2026年8月10日にApache 2.0で公開した300億パラメータのモデルです。独自のLlama Community Licenseから許諾的なオープンソースライセンスへ転換した点が、技術内容と同じくらい大きな変化でした。
• 設計目標は「単一の消費者向けGPUやMacで動く、止まらないエージェント」です。ツール利用、多段推論、失敗からの復帰に振った学習が行われ、MCP Atlas（75.5）やSWE-Bench Pro（51.2）といったエージェント系ベンチマークで同クラスの他モデルを上回っています。
• 4ビット量子化で言語モデルの重みは20GBを切り、KVキャッシュや視覚エンコーダ、DFlashドラフタまで含めて24GB VRAMのGPU 1枚に収まります（精度低下1.0%）。DFlashによる投機的デコーディングはRTX 5090上で3.1倍、233.4 tok/sを達成しています。この2つがローカル実行を成立させています。
• 一方で TerminalBench 2.1（51.7対60.7）や OSWorld-Verified（65.9対75.6）ではQwen3.6-27Bに劣り、ツール呼び出しは1ターン1件で並列非対応という制約もあります。自由度の高い操作環境や並列化前提の設計には向きません。
• 公開されたのは重みのみで学習データとコードは非公開です。プロンプトインジェクションの攻撃成功率も28.4%と報告されており、権限の最小化と人間による承認を前提にした設計が必要です。

個人的には、ライセンスのほうが本題だと思っています。24GBで動く30Bは半年もすれば他社も出してきますが、MetaがLlama Community Licenseを捨てたことは元に戻りません。

参考資料

• Muse Glimmer | Meta — 公式製品ページ。全ベンチマークスコアと配布・ドキュメントへの導線（2026年8月11日参照）
• Introducing Muse Glimmer: An Open Agentic Model That Runs on Your Device | Meta AI Research — 公式発表ブログ。学習手法、量子化、投機的デコーディング、対応ランタイム（2026年8月10日公開）
• meta-models/Muse-Glimmer-30B · Hugging Face — モデルカード。アーキテクチャ詳細、量子化変種、評価結果、制限事項（2026年8月11日参照）
• Prompting guide | Muse Glimmer Docs — チャットテンプレート、ロールと宛先、reasoning_strength、ツール呼び出し仕様（2026年8月11日参照）
• Quantization | Muse Glimmer Docs — GGUF変換手順と検証方法（2026年8月11日参照）
• Muse Glimmer - SGLang Documentation — SGLangでの導入手順。リリース版未対応であることとPRブランチのビルド方法（2026年8月11日参照）
• On-Policy Distillation of Language Models: Learning from Self-Generated Mistakes（ICLR 2024） — オンポリシー蒸留（GKD）の定式化。生徒の自己生成系列上で教師の分布へ近づける手法
• Meta Publishes Muse Glimmer As 30B Open Agentic Model - Phoronix — ライセンス転換の意義とエコシステムの初日対応（2026年8月10日公開）
• Meta AI Releases Muse Glimmer - MarkTechPost — アーキテクチャと量子化・投機的デコーディングの数値、安全性評価（2026年8月10日公開）
• Muse Glimmer: Meta’s 30B Open Model Runs on 24GB VRAM | explainx.ai — 実機での量子化検証、ツール呼び出しのタグ形式、オープンウェイトの範囲（2026年8月参照）
• Meta launches Muse Glimmer, an open-weight model that can run on a laptop - AOL / Reuters — Muse Sparkとの関係とMetaの今後の予定（2026年8月10日公開）