30Bのモデルが出ること自体は、もう驚きではない。この夏だけで何本も出ている。だからMetaが8月10日に公開したMuse Glimmer-30Bを見たとき、最初に確認したのはベンチマークではなく「どのくらいのVRAMに収まるのか」だった。答えは、量子化版で約24GB。RTX 4090やRTX 5090が1枚あれば、計画・マルチモーダル知覚・ツール呼び出しまで含んだエージェントが、ネットワークに一切つながずローカルで回る。新しいのはモデル単体ではなく、ローカルでエージェントを動かすための部品が一式そろって配られたことのほうだ。
一次ソースはHugging Faceのモデルカードと公式ブログの2つ。数値と手順はこの2つを突き合わせて確認した。
何を解決するモデルなのか
ローカルでエージェントを動かそうとすると、たいてい面倒が3つ重なる。モデルが大きすぎて手元のGPUに載らない。載っても遅い。そして画像やスクリーンショットを読ませたいのに、そのための知覚モジュールを別途つなぐ必要がある。Muse Glimmerは、この3つをまとめて1つの配布物に畳み込んできた。
本体は約29.6Bのdense(全パラメータが常に活性化する非MoE)構成で、内訳はテキストデコーダ約28Bと、凍結されたViT-G/14の視覚エンコーダ約1.8B。より大きいMuse Sparkからの蒸留で作られ、「消費者向けハードウェア上での自律エージェント」を明確な目的に据えている。文脈長は131,072トークン以上、語彙は202,048、学習データは100以上の言語、知識のカットオフは2026年1月4日だ。
注意機構は、ローカル注意を3層はさんで4層目にグローバル注意を置く[Local, Local, Local, Global]の繰り返しで、ローカル層のスライディングウィンドウは2,048トークン。KVヘッドは1つを16個のクエリヘッドで共有するGated GQA(32クエリ/2 KV)で、KVキャッシュのメモリを16分の1に抑えている。長文脈をローカルで回すための、素直だが効く設計だ。
ひとつ正直に書いておくと、位置エンコーディングについてはモデルカードが「RoPE(θ=500,000)」、公式ブログが「NoPE(位置エンコーディングなし)」と食い違っている。公開初日のドキュメントにありがちな不一致で、実装の確定情報として鵜呑みにはできない。この手のズレを潰しながら読むのが一次ソース突き合わせの地味な作業だ。
24GBに載せるための量子化
「1枚のGPUで動く」を実際に成立させているのは、キャリブレーション済みのGGUF量子化だ。モデルカードの数値を整理するとこうなる。
| 精度 | 必要VRAM(目安) | 品質劣化 |
|---|---|---|
| BF16(フル) | 約64GB | 基準 |
| K-Quant-Dynamic | 約32GB | 0.2% |
| K-Quant-17GB | 約24GB | 1.0% |
24GB版で劣化1.0%というのは、実務で使う判断がしやすい数字だ。フル精度は80GBのH100級が要るが、17GB量子化なら24GBのコンシューマGPUに素直に載る。GGUFはllama.cpp、LM Studio、Jan、Ollama向けに53種類が用意されていて、量子化を自分で回して精度を測り直す手間が省ける。ローカルLLMで一番だるいのがこの「どの量子化なら使い物になるか」の検証なので、公式が測って配ってくれる価値は大きい。
一緒に配られる高速化ドラフター DFlash
個人的にこの配布で一番おもしろいのは、投機的デコーディング用のドラフターモデルDFlashが同梱されている点だ。投機的デコーディングは、小さな下書きモデルに数トークン先を一気に提案させ、本体モデルでまとめて検証することで生成を速くする手法だが、普段は「本体と相性のいい下書きモデルを自分で探す/訓練する」ところでつまずく。Muse Glimmerはその下書きを純正で付けてきた。
DFlashはブロック拡散型の軽量ドラフターで、ブロックサイズ16(アンカー1トークン+提案15トークン)、5層構成。速度向上はRTX 5090で3.1倍、Apple M4 Maxで1.5倍、M5 Maxで1.8倍と報告されている。llama.cppなら1行のオプションで有効化できる。
# 通常起動
llama serve -hf meta-models/Muse-Glimmer-30B-GGUF
# DFlashドラフターで投機的デコーディングを有効化
llama serve -hf meta-models/Muse-Glimmer-30B-GGUF \
--spec-type draft-dflash --spec-draft-n-max 15
手法の裏付けは論文 DFlash: Block Diffusion for Flash Speculative Decoding にある。
エージェント用途としての中身
ベンチマークは、汎用というよりエージェント・マルチモーダルに寄せて選ばれている。モデルカードの主な数字を抜くと、ツール利用のMCP Atlas(Public)が75.5、SWE-Bench Verifiedが76.0、SWE-Bench Proが51.2、画面操作のScreenSpot Proが75.4、GPQA Diamondが83.5、AIME 2026が94.7。30Bとしては十分に強く、特に画面理解とツール呼び出しを一体で持っている点が、ローカルの操作エージェント用途を意識していることを示している。
Metaはさらに「マルチステップ推論・確実なツール利用・マルチモーダル理解・失敗からの復帰を1つのモデルに統合した」と説明している。ただし「失敗からの復帰(failure recovery)」については、それを単体で測る指標がモデルカードに見当たらない。失敗リカバリは本来モデルよりハーネス側の設計に依存する性質なので、ここは公式の主張として受け取り、実際の挙動は自分のワークフローで確かめる部分だと考えている。生成はtemperature=1.0, top_p=0.95, top_k=64が推奨で、推論の深さをシステムプロンプトでlow/medium/high/xhighと切り替えられる。
手元で動かす
Transformersで直接叩くなら、画像とテキストを混ぜたメッセージをそのまま渡せる。
from transformers import pipeline
pipe = pipeline("image-text-to-text", model="meta-models/Muse-Glimmer-30B")
messages = [
{
"role": "user",
"content": [
{"type": "image", "url": "https://example.com/screenshot.png"},
{"type": "text", "text": "この画面で次に押すべきボタンは?"},
],
},
]
pipe(text=messages)
サーバとして立てる場合、vLLMやSGLangがそのまま使える。マルチGPUに割るならテンソル並列を指定する。
# vLLM(OpenAI互換API)
vllm serve meta-models/Muse-Glimmer-30B \
--model-impl transformers --tensor-parallel-size 4
APIはOpenAI互換の/v1/chat/completionsで、image_urlを含むマルチモーダル入力を受け取る。Dockerで一発起動したいならdocker model run hf.co/meta-models/Muse-Glimmer-30Bも用意されている。GGUF一式はこちら。
ライセンスという地味だが大きい変化
見落とされがちだが、ライセンスがApache 2.0である点は実務上かなり効く。これまでMetaの主力オープンウェイトはLlama Community Licenseで、月間アクティブユーザ数の閾値や利用条件の制約が付いていた。Apache 2.0なら商用利用・改変・再配布の縛りが実質的に外れる。ローカルで動く多言語のマルチモーダルエージェントを、プロダクトに組み込みやすいライセンスで出してきたこと自体が、今回の一番の意思表示だと読んでいる。
まとめると、Muse Glimmerの新しさは「30Bのモデルが1つ増えた」ことではなく、量子化・高速化ドラフター・マルチモーダル知覚・エージェント設計・許容的なライセンスを、24GBのGPUに載る形で束ねて配ったことにある。ローカルでエージェントを組みたい人は、まず17GBのGGUFを落としてllama serveで立ち上げ、DFlashを有効にしたときの体感速度から試すのがいい。詳細は公式ブログとモデルカードにまとまっている。
※本記事は一次情報の調査をAIが行い、事実確認のうえ執筆・公開しています。