Muse Glimmer 30Bをローカルで動かすには？24GB GPU・GGUF・DFlashを整理

Muse Glimmer 30Bは、24GB級のGPUでローカルエージェントを動かしたい人にとって検討しやすい30Bクラスのモデルだ。Metaはモデル本体だけでなく、24GB・32GBをそれぞれ想定した4bit量子化、画像入力用の画像認識エンコーダー、DFlash用のドラフターモデル、GGUFまで公式に公開している。

ただし、「24GB向け」という表記を、そのまま最低VRAMや快適動作の保証に置き換えることはできない。モデルの重み以外にもKVキャッシュや画像入力用ファイル、DFlash、実行時バッファがメモリを使い、必要量はコンテキストや使い方で変わる。

24GB級なら有力候補。ただし最初はテキストだけで確認する

Muse Glimmer 30Bを試しやすいのは、RTX 3090やRTX 4090のような24GB級GPU、またはそれ以上のメモリを持つ環境だ。Meta自身が24GB向けのK-Quant-17GBを用意しているため、コミュニティ量子化を探す前に公式配布から始められる。

32GB級では、より大きいK-Quant-Dynamicが候補になる。Metaの15ベンチマーク平均では高精度からの劣化がK-Quant-17GBで1.0%、K-Quant-Dynamicで0.2%とされている。ただし、これはMetaによる評価値であり、すべての用途で体感差が同じになるわけではない。

公式構成	配布ファイルの目安	Metaの想定ハードウェア	Meta公表の平均劣化
K-Quant-17GB	16.8GB	24GB VRAM	1.0%
K-Quant-Dynamic	19.7GB	32GB VRAM	0.2%
高精度	GGUF配布なし	64GB VRAM	基準

24GB環境では、最初から画像入力・DFlash・長いコンテキストをすべて有効にせず、まず短いテキスト入力で読み込みと生成を確認する。その後、必要な機能を一つずつ足す方が、メモリ不足や速度低下の原因を切り分けやすい。

Muse Glimmer 30Bはどんなモデルか

Muse Glimmerは、Muse Sparkから蒸留されたエージェント用途向けの密な構造の因果Transformerだ。モデル全体は約29.6Bパラメータで、その中に画像理解を担う約1.8BパラメータのViT-G/14画像認識エンコーダーを含む。入力はテキストと画像、出力はテキストで、公式コンテキスト長さは131,072トークン以上となっている。

項目	公式情報
総パラメータ	約29.6B
アーキテクチャ	密な構造の因果Transformer + 画像認識エンコーダー
画像認識エンコーダー	約1.8B、ViT-G/14
コンテキスト長	131,072+トークン
入力	テキスト + 画像
出力	テキスト
学習言語	100言語以上
ライセンス	Apache 2.0

用途として強く意識されているのは、ツール利用、複数段階の推論、失敗からの復帰、コーディング、スクリーンショットや文書を含む画像理解だ。一般的なチャットモデルとしても使えるが、Muse Glimmerの特徴を生かしやすいのはエージェントやツール呼び出しを組み合わせる場面になる。

16.8GBのGGUFだけで24GBに収まるわけではない

公式GGUFリポジトリには、テキストモデルのほかに画像入力と投機的生成処理用のファイルが分かれている。

公式GGUF	容量	役割
Muse-Glimmer-30B-KQuant-17GB-Q4_K_M.gguf	16.8GB	24GB向けテキストモデル
Muse-Glimmer-30B-KQuant-Dynamic-Q4_K_XL.gguf	19.7GB	32GB向けテキストモデル
mmproj-Muse-Glimmer-30B-Q4_K_M.gguf	1.4GB	画像入力用画像認識エンコーダー
dflash-Muse-Glimmer-30B-Q4_K_M.gguf	1.6GB	DFlash用ドラフターモデル

16.8GBという数字は、24GB GPUで約7GBが必ず自由に残るという意味ではない。実行時にはKVキャッシュや実行時バッファが加わり、ディスプレイにも同じGPUを使っていればその分のVRAMも消費する。画像入力ではmmproj、DFlashではドラフターモデルも追加される。

量子化ファイルの容量と実行時VRAMを分けて考える基本は、量子化でVRAMと品質がどう変わるかで詳しく整理している。

llama.cppはビルドb10353以降が必要

公式GGUFページは、Muse Glimmerをllama.cppで使う場合にビルドb10353以降を要求している。Muse Glimmer対応は2026年8月10日に取り込みされ、b10353で初めてリリースへ入った。b10344以前ではアーキテクチャ自体を認識できない。

そのため、GGUFを正しい場所へ置いても読み込めない場合は、量子化ファイルを疑う前にllama.cppのビルド番号を確認したい。

llama-cli --version

b10353以降ならMuse Glimmerのアーキテクチャを認識できる。公式GGUFページにはllama.cpp向けのllama-cli、llama-server、画像入力用llama-mtmd-cliの手順も掲載されている。

なお、GGUFが読み込めることと、すべての周辺機能がどのアプリでも同じように使えることは別だ。LM StudioやOllamaなどを利用する場合も、使用中の実行環境が十分に新しいか、画像入力やDFlashまで対応しているかを個別に確認する必要がある。

DFlashは生成をどこまで速くするのか

Muse Glimmerには、投機的生成処理用のDFlash用ドラフターモデルが用意されている。DFlashは16トークンのブロックをまとめて提案し、本体モデルがその候補を検証することで、通常の1トークンずつの生成より高速化を狙う仕組みだ。

MetaはK-Quant-17GBと量子化DFlashを組み合わせた測定値を公開している。

ハードウェア	DFlashなし	DFlashあり	高速化
RTX 5090	74.9 tok/s	233.4 tok/s	3.1x
Apple M4 Max	23.7 tok/s	37.8 tok/s	1.5x
Apple M5 Max	26.6 tok/s	50.2 tok/s	1.8x

この値はMetaによる提供元測定だ。バッチサイズ1、貪欲法による生成、Metaのプロンプト集合という条件で、RTX 5090はllama.cpp、M4/M5 MaxはExecuTorchを使っている。独自実測ではなく、RTX 5090なら常に233.4 tok/s出るという意味でもない。

DFlashを評価するときは、同じプロンプトとサンプリング条件で有効・無効を切り替え、速度と追加メモリ使用量を自分の環境で比較するのが確実だ。

画像入力では1.4GBのmmprojも使う

Muse Glimmerはスクリーンショット、グラフ、文書、写真などを入力できる。公式GGUFでは画像理解部分が1.4GBのmmprojとして分離されており、テキストモデルだけを読み込んだ状態とは必要メモリが変わる。

24GB環境で画像入力も使うなら、最初は1枚の画像と短いコンテキストから始める方がよい。テキストのみで余裕があっても、画像枚数や画像トークン、コンテキストを増やせばVRAM使用量のピークは上がる。

また、公式モデルカードの対応済みモダリティはInput: text + image, Output: textであり、ネイティブな動画入出力モデルとして公開されているわけではない。動画を扱う実装があっても、フレームを画像として処理する経路と「動画モダリティを直接持つこと」は分けて考える必要がある。

131K超コンテキストは「24GBで常用できる長さ」ではない

131,072+トークンはモデルが対応するコンテキスト長さであり、K-Quant-17GBを24GB GPUへ載せたときに常にその長さを快適に使えるという保証ではない。

コンテキストを伸ばすほどKVキャッシュが増える。さらに画像入力やDFlashを組み合わせれば、重み以外に使えるメモリは減る。エージェント用途では最大値から始めるより、実際のタスクに必要なコンテキストへ抑え、検索機能やメモリ機能で必要情報だけを渡した方が扱いやすい場合がある。

24GBという対象は「試せる入口」として有用だが、実務上のコンテキスト上限は実行環境、KVキャッシュ形式、画像入力、同時実行アプリなどを含めて確認する必要がある。

エージェント性能は提供元ベンチマークとして読む

Metaのベンチマークでは、Muse GlimmerはMCP Atlas 75.5、DeepSearch QA 74.6、SWE-bench Pro 51.2などの値を示している。一方、比較対象のQwen3.6-27BがOSWorld-VerifiedやTerminalBench 2.1などで上回る項目もある。

この結果から言えるのは、MetaがMuse Glimmerをツール利用や長時間のエージェントワークフローへ強く最適化していることまでだ。「30Bクラスで常に最強」と結論づける根拠にはならない。

エージェント用途では、公開ベンチマークに加えて、自分が使うエージェント構成でツール呼び出しの成功率、失敗時の復帰、長時間タスクでの安定性を確認したい。性能値はすべてMetaの測定として扱い、独自ベンチマークとは区別する。

Apache 2.0で公式配布ファイルが揃う

Muse Glimmerの公開配布ファイルはApache 2.0で配布されている。BF16重み、2種類の4bit量子化、画像認識エンコーダー、DFlash用ドラフターモデルが公式経路で揃うため、第三者量子化だけに依存せず導入できる点は扱いやすい。

ただし、モデル本体がApache 2.0でも、エージェントから呼び出すツール、データセット、LoRA、外部API、生成物の利用条件は別に確認する必要がある。導入前の確認項目はAIモデルのライセンスを確認する方法も参考になる。

24GB GPUで試す順番

24GB環境では、次の順に負荷を足すと問題を切り分けやすい。

1. llama.cppがb10353以降か確認する
2. K-Quant-17GBをテキストのみ、短いコンテキストで読み込む
3. tok/sとVRAM使用量のピークを記録する
4. 必要ならmmprojを追加して1枚の画像を試す
5. DFlashを有効にして同じプロンプトで速度差を見る
6. エージェント側のツール呼び出しを追加する
7. 最後にコンテキストを実務上必要な長さまで伸ばす

最初から長いコンテキスト、複数画像、DFlash、ブラウザエージェントを同時に有効にすると、どこがボトルネックか分かりにくい。1項目ずつ増やす方が、Muse Glimmerそのもの問題と実行環境・メモリの問題を分けやすい。

どんな人に向いているか

Muse Glimmer 30Bは、24GB以上のGPUをすでに持ち、ローカルでツール利用やコーディング、画像理解を組み合わせたい人と相性がよい。公式GGUFから始めたい場合や、クラウドへ入力を送らずエージェントを構成したい場合にも候補になる。

一方、8GBや12GB GPUでGPU内完結を狙う用途では重い。CPUオフロードやさらに低bitのコミュニティ量子化で動かせる可能性はあるが、Metaが示す24GB/32GBの公式対象とは別のトレードオフになる。

GPUの購入まで含めて考える場合は、Muse Glimmerだけでなく、他のLLM、画像生成、動画生成で必要なVRAMも合わせて確認したい。ゲーミングPCとクリエイター向けPCの違いでは、VRAMだけでなくシステムRAMや冷却も含めた見方を整理している。