「またMetaがMuseを出した」で流しかけた人、ちょっと待ってください。
Muse Glimmerはゼロから作られた新モデルではなく、クローズドで提供されてきたMuse Sparkの中身を手元のGPU1台に落とし込んだ蒸留モデルです。
ここを押さえると、このリリースの意味がまるっきり変わります。
Muse Glimmerの正体は Muse Sparkを教師にした蒸留モデル
Meta Superintelligence Labs(MSL)が2026年8月10日に公開したMuse Glimmerは、パラメータ数300億(30B)のオープンウェイトモデルです。
中身をもう少し正確に書くと、29.6Bのdenseな言語モデルに、約1.8BのViT-G/14ベースの知覚エンコーダーが付いた構成になっています。
面白いのは学習のさせ方です。
事前学習の段階から、Muse Sparkの出力を教師にした logit distillation を使っています。
logit distillation は、正解ラベルを当てさせるのではなく、教師モデルが「次のトークンとして何がどれくらいありえるか」に付けた確率分布そのものを生徒に真似させる手法です。
「正解はA」だけを渡すのと、「Aが7割、Bが2割、Cが1割」まで渡すのとでは、生徒が受け取る情報量がまるで違います。
教師の迷い方まで含めて継承する、というイメージです。
学習パイプラインは3段階です。
事前学習でMuse Sparkの出力を蒸留し、mid-trainingで長いコンテキストとエージェント寄りのデータを流し込み、post-trainingでSFTとon-policy distillation、強化学習を重ねています。
つまりMuse Glimmerは「小さいから弱いモデル」ではなく、「大きいモデルの判断の癖を移植した圧縮版」です。
この前提を持っているかどうかで、以降のスペックの読み方が変わります。
60GBのモデルが20GBを切るまで
30Bのモデルは、BF16のフル精度だと重みだけで約60GBあります。
当然ながら個人のGPUには載りません。
Meta側もそこは分かっていて、量子化した派生を最初から用意してきました。
公式ブログとvLLMのレシピに出ている数字を並べるとこうなります。
ここで引っかかりやすいのが、同じ「4bit相当」でも方式によって17GBから25GBまで幅があることです。
「4bitなら動く」ではなく、自分の環境で使えるフォーマットを先に確認してから落とすほうが早いです。
判断の目安としては、RTX 4090の24GBやRTX 5090の32GB、あるいはMシリーズMacのユニファイドメモリ32GBに収まるかどうか。
コンテキスト長は128Kトークンで学習されていて、実行環境によっては131,072トークンまで扱えます。
エージェントを長時間走らせるなら、この長さは効いてきます。
高速化まわりではDFlashという投機的デコードが用意されていて、RTX 5090で3.1倍、M5 Maxで1.8倍、M4 Maxで1.5倍という数字が出ています。
5.11GBのドラフトモデルを別途読み込む構成なので、メモリに余裕がある人向けです。
発表当日に10以上の実行環境が対応した理由
公開初日の時点で、llama.cpp、MLX、ExecuTorch、vLLM、SGLang、Ollama、LM Studio、Unslothが対応しています。
クラウド側もTogether AI、Fireworks AI、OpenRouterが即日で乗せてきました。
AMDも公式でRyzen AI MaxとRadeon向けの動かし方を出しています。
これまでのOSSモデルは、公開されてからコミュニティが数日かけて量子化とローダー対応を進めるのが普通でした。
今回は最初から揃っている。
公開前に各エンジンのチームへ重みを配って合わせ込んでいた、と考えるのが自然です。
ただ、ここは正直に書いておきます。
執筆時点でOllamaに並んでいるタグは muse-glimmer:30b-mlx だけで、これはApple Silicon向けです。
NVIDIAやAMD環境は「近日対応」の表記になっています。
「Ollamaがday-0対応」という見出しだけ読んで ollama run すればすぐ動くと思っていると、環境によっては足止めを食らいます。
Muse Spark Muse Image Muse Glimmer 3つのMuseを整理する
MSLは短期間に「Muse」を冠したモデルを3つ出しているので、一度整理しておきます。
そしてもう1つ、見落とされがちな話があります。
Muse Spark 1.2そのもののオープンウェイト版も、数週間以内に出る予定とされています。
Muse Glimmerは単発のオープン化ではなく、フラッグシップまで開いていく流れの先頭にいるわけです。
海外メディアはこれを「Metaのオープンソース回帰」と書いていますが、Meta自身は回帰とは言っていません。
公式ブログにあるのは「基礎研究を共有してきた長年の伝統に沿って公開する」という趣旨の一文です。
4ヶ月前に「フラッグシップをクローズドに寄せた」と読めた前提は動いていますが、Meta側の建て付けとしては一貫した動きだ、ということになります。
ローカルで常時動かすエージェントにこそ効く
Metaが出しているベンチマークは、DeepSearch QA、MCP-Atlas、τ-Bench、SWE-Benchといったエージェント寄りのものが中心です。
数値としてはSWE-Bench Verifiedが76.0、MCP-Atlas(Public)が75.5と報告されています。
ただしこれは自社公表値で、第三者の再現はまだ出ていません。
30Bでこの水準なら十分に強い、という程度の受け止め方が安全だと思います。
ベンチより実務で効きそうなのは、画像を受け取れることです。
テキストと画像をインターリーブで入力でき、1枚あたり最大4,096の視覚トークンを使います。
スクリーンショットや図表、書類を読ませる用途が想定されていて、画面を見て判断する系のタスクを外に出さずに回せます。
100以上の言語のデータで学習されている点も公式に明記されています。
日本語のドキュメントを読ませる用途でも、最初から選択肢に入ります。
使い分けとしては、重い設計判断や込み入ったデバッグはクラウドのフロンティアモデル、動かしっぱなしにする軽いタスクはローカルのGlimmer、という切り分けが現実的です。
実行回数が読めない監視系や、社外に出せないデータを触るジョブは特に向いています。
まず何から触るか
Apple Silicon環境なら、Ollamaのmlxタグが一番早いです。
21GBなので32GBのMacでも余裕を持って載ります。
NVIDIA環境なら、vLLMのレシピが精度別に整理されているので、そちらから入るほうが確実です。
NVFP4の25.42GBは動くGPUがBlackwell世代に限られるので、まずFP8か、llama.cppのGGUFで試すのが無難だと思います。
重みは meta-models/Muse-Glimmer-30B で配布されていて、ライセンスはApache 2.0。
商用利用に制限がないので、社内ツールに組み込んで検証するくらいまでは気軽にやれます。
個人的に一番注目しているのは、この先に控えているMuse Spark 1.2のオープンウェイト版のほうです。
Glimmerで蒸留の出来を確かめておくと、本命が来たときに判断が速くなります。
💬 コメント
ログイン か 会員登録 するとコメントできます