Meta のオープンウェイト Muse Glimmer 30B を DGX Spark で動かしてみた

はじめに

こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。

Meta が Muse Glimmer 30B のウェイトを公開しました。「常時動かしておくローカルのエージェント」を狙ったと明言している 30B のモデルで、ライセンスは Apache-2.0 です。

https://research.meta.ai/blog/introducing-muse-glimmer-open-agentic-model

Meta がオープンウェイトを出すのは、2025 年 4 月の Llama 4 以来です。1 年 4 か月ぶりということになります。配布元の組織も meta-llama から meta-models に変わっていて、名前から Llama が外れました。この間にオープンウェイトの中心は Qwen や DeepSeek、Gemma のあたりに移っていたので、ここに戻ってくるとは驚きのニュースでした。

公開されたその日に触ってみたのは、公式のレシピが DGX Spark を検証済みのハードウェアとして挙げていて、しかも既定の構成に指定していたからです。ところが vLLM 側にも SGLang 側にも、公開されているベンチマークの一覧に DGX Spark の行だけがありません。動くとは書いてあるのに、数字が無い。手元に 1 台あるので、ひとまず埋めてみることにしました。

先に結論を書いておくと、日本語もコード修正もツール呼び出しも全部通りました。比較対象の Qwen3.6-27B と Gemma4-31B も同じように全部通したところ、正誤では差がつきませんでした。差が出たのは、同じ答えにたどり着くまでに使うトークンと時間、そして呼び出しの作法のほうです。

とくにツール呼び出しを 1 メッセージに何件入れるかが、場面によって変わります。4 件まとめて返してくることもあれば、2 件を 1 件ずつに分けてくることもある。ここは既存のエージェント基盤に載せる前に確かめておきたい違いでした。

この記事では、Muse Glimmer 30B を DGX Spark 1 台で動かして、速度と日本語とエージェント用途を Qwen3.6-27B・Gemma4-31B と同条件で測った結果を紹介します。ローカルで動くエージェント向けモデルを探している方に刺されば嬉しいです。

30B の dense、しかも中身は VLM

「30B の dense モデル」と聞いて自分が最初に思い浮かべたのはテキスト専用の言語モデルだったのですが、モデルカードを開いてみると少し違いました。29.6B のうち約 1.8B は ViT-G/14 の画像エンコーダで、残りがテキストのデコーダです。つまり素の状態でマルチモーダルなんですね。

テキスト側は 52 層、hidden 6656、GQA は 32 対 2 の比率で、FFN は SwiGLU の中間次元 19,968。attention は Local を 3 つ並べて Global を 1 つ挟む並びの繰り返しで、Local 側の窓は 2048 トークンです。語彙は 202,048 で、うち 2,048 が特殊トークンに割り当てられています。学習時のコンテキスト長は 131,072 でした。

ライセンスは Apache-2.0、知識のカットオフは 2026 年 1 月 4 日、学習データは 100 言語以上とされています。上位モデルの Muse Spark からの蒸留で作られたという説明もありました。BF16 の重みは 59.55 GB なので、統合メモリ 128 GB の DGX Spark なら量子化しなくても収まる計算です。

Meta が公開している比較表のうち、今回測る 3 つの軸に関係する行を抜き出すと以下のようになります。比較対象は Gemma4-31B と Qwen3.6-27B の 2 つです。

ツールを何度も呼びながら進めるタスクでは Muse Glimmer が明確に前に出ていて、一方で単発のコーディングとターミナル操作では Qwen3.6-27B に負けています。「エージェント向け」を掲げているモデルなので、勝っている場所も負けている場所も看板どおりではあります。ここで気になるのが、この差が手元の環境でも同じ向きに出るのかどうかです。それを確かめるのがこの記事の主題になります。

JSON でツールを呼ばない

新しいモデルだから当然 JSON だろうと決めつけて叩いたら、返ってきたのは XML でした。1 ターンが宛先つきのメッセージの連なりとして書かれ、その中でツール呼び出しは XML で表現されます。

to=self<|message|>...思考...<|eom|>
<|start|>assistant to=<tool><|message|><atem:function_calls>
<atem:invoke name="<tool>">
<atem:parameter name="<arg>">値</atem:parameter>
</atem:invoke>
</atem:function_calls><|eom|>
<|start|>assistant to=user<|message|>...最終回答...<|eot|>

to=self が思考、to=<tool> がツール呼び出し、to=user が読者に見せる回答。宛先の切り替えでチャンネルを分けているわけですね。

ちなみに比較対象の Qwen3.6-27B のチャットテンプレートも <tool_call> の中に <function=名前> と <parameter=キー> を入れ子にする XML です。JSON のツール呼び出しを暗黙の前提にしていると足をすくわれる、というトラブルに最近はまっている気がします。。。Muse Glimmer で目新しいのは XML そのものより、思考とツールとユーザー向けの回答を宛先で切り分けているところでした。

DGX Spark 1 台に載せる

公式レシピは DGX Spark を verified なハードウェアとして挙げていて、しかも既定の構成として指定しています。GPU は 1 枚なので tensor parallel の設定もありません。

vllm serve Inferact/Muse-Glimmer-30B-NVFP4-W4A4 \
  --served-model-name muse-glimmer \
  --enable-auto-tool-choice --tool-call-parser muse_glimmer \
  --reasoning-parser muse_glimmer \
  --generation-config auto

--generation-config auto は飾りではなく、停止トークンを generation_config.json から拾わせるために要ります。ここで <|eom|> を停止トークンに足してしまうと、思考チャンネルの終わりでターンが切れてツール呼び出しが成立しなくなります。重みは 3 つの選択肢があります。

NVFP4 は 4bit なのに 25 GB もあります。これは全部を量子化しているわけではないからで、量子化されているのはテキスト側の 364 個の projection だけ。埋め込みと lm_head、そして画像エンコーダはそのまま残っています。均一に 4bit にした場合の 15 GB 前後にはならない、という理屈のようです。

自分は NVFP4 で起動しました。統合メモリ 121.69 GiB のうち、重みが 25.3 GiB、KV キャッシュに 76.6 GiB が割り当てられ、トークン数にして 4,819,435 トークン分のプールになりました。64K のコンテキストなら 73.54 倍まで同時に走らせられる計算です。公式レシピが GB300 の 4 枚構成で 26.8M トークンと書いているので、その 1/5.6 くらいという位置になります。ここで気になるのが起動時間です。

vLLM 側は重みのロードのあとに torch.compile と FP4 GEMM の autotune、CUDA グラフのキャプチャが順に走ります。ログを見ると engine の初期化だけで 145 秒、うちコンパイルが 28.77 秒、グラフのキャプチャが 33 秒でした。常駐させて使うなら気にならない時間ですが、「ちょっと試す」ときの体感はだいぶ違います。

どのくらい速いか

出力長を 256 トークンに固定して、同時に投げる本数を 1 から 8 まで変えながら測りました。比較対象の 2 機種も同じイメージ、同じ設定、同じプロンプトで測り直しています。

単発では Qwen がわずかに速く、8 並列では Muse Glimmer が前に出ます。1 本あたりの落ち込みも Muse Glimmer のほうが小さく、11.67 から 11.31 へ 3% の低下にとどまりました。Gemma4-31B は 3 機種の中では明確に遅く、単発で Muse Glimmer の 6 割ほどです。差がもっとはっきりしたのは KV キャッシュのほうでした。

同じ統合メモリから Gemma の 6.3 倍、Qwen の 2.2 倍のトークンを確保できています。4 層のうち 3 層がスライディングウィンドウで、KV ヘッドも 32 対 2 まで削った構成が効いているのでしょう。素の速度より、長い文脈を何本も並べるときに差が出てくる部分ですね。

投機デコードを載せると 2 倍前後になります

Muse Glimmer は DFlash という投機デコード用のドラフトモデルを、本体とは別のリポジトリで配っています。これを載せると、単発のデコードが 2 倍前後まで伸びました。

単発は SGLang が 2.13 倍で最速、vLLM は 1.85 倍。8 並列の合計では逆に vLLM が前に出ます。1 回の予測で通るトークン数はどちらも 2 〜 3 程度でした。どちらを選んでも 2 倍前後にはなるので、あとは並列の当て方しだいですね。

代償もあります。起動は 371 秒から 411 秒に伸び、KV キャッシュのプールは 4,819,435 トークンから 3,579,383 トークンへ 25% ほど減りました。ドラフトモデルのぶんを同じ統合メモリから取るためです。出力そのものは崩れず、日本語 4 問もツール呼び出し 5 問も投機ありで同じ結果でした。しかも日本語 4 問の所要は 202.9 秒から 77.9 秒へ縮んでいます。長さを固定した合成ベンチだけでなく、実際の課題でも効いてくれました。

エンジンごとの通り具合

3 つのエンジンで確かめた範囲を、まとめておきます。（2026年8月11日現在）

上の 4 行はどのエンジンでも同じように通りました。割れたのは下の 3 行です。速度がほしいなら SGLang か vLLM、画像も使いたいなら llama.cpp、という分かれ方ですね。SGLang の NVFP4 チェックポイントには画像側の重みが入っていないので、そちらで画像まで使うなら BF16 の 59.55 GB を読むことになります。

なお公開初日の時点では、vLLM も SGLang もモデル対応の PR はマージ前で、動かしているのは配布イメージでした。llama.cpp だけが当日のうちに本体へ取り込まれています。この並びは数日で変わるはずなので、試すときは各リポジトリの状況を見てからのほうがよさそうです。

画像も通りました

素の状態で VLM なので、画像も試しました。llama.cpp なら GGUF に付いてくる画像エンコーダ（mmproj）を --mmproj で渡すだけで、起動は 5 秒のままです。

課題は建設現場の写真から保護具を挙げさせるもので、別のモデルで正答が取れている画像を使いました。白いヘルメット（女性）、黄色いヘルメット（男性）、高視認性ベスト（女性）の 3 点が正解です。

左側の女性
* ヘルメット … 白色の安全ヘルメット
* 高視認性安全ベスト … 蛍光黄緑色の安全チョッキ／高視認性ベスト
右側の男性
* ヘルメット … 黄色の安全ヘルメット
* 保護衣 … 濃紺の作業用つなぎ／オーバーオール

手袋・安全靴・保護メガネ等は画像からは確認できません。

3 点とも当てています。そのうえで感心したのは最後の 1 行で、写っていないものを、写っていないと答えました。この写真の 2 人は素手で、片方はタブレット、もう片方は無線機を持っています。「安全保護具をすべて挙げてください」と聞かれると、それらしいものを埋めたくなるところですが、そうしませんでした。現場の写真を扱う用途では、見えたものを挙げる能力より、見えないものを見えたことにしない性質のほうが効いてきます。

所要は 1 問あたり 53 秒（630 トークン、思考 1,519 字）でした。画像でも、答える前によく考えるのは同じですね。

日本語はどうか

公式には 100 言語以上で学習したとあるだけで、日本語の数字は出ていません。そこで手元の 4 問を投げました。50 字以内という長さ制約、自由記述、コード生成、そして簡単な数値推論の 4 つです。長さとコードと計算の 3 つは自動で正誤を判定しています。

結論から書くと、4 問とも正解でした。50 字制約は 21 字で収め、dedup_sort は sorted(set(nums)) を返し、合計 360 円とみかん 1 個 40 円も両方当てています。日本語そのものも自然でした。

そのうえで、気になったのは正誤ではなく所要のほうです。reasoning strength を 4 段階すべて振ってみました。

どの段階でも全問正解で、変わったのは時間とトークンだけでした。xhigh は low のちょうど 2 倍を使って同じ答えに着いています。極端なのが 50 字制約の問題で、high では 21 字の答えを出すために 1,028 トークンを使い、90.55 秒かかりました。low なら 411 トークン、36.1 秒です。

medium と high の前後は、1 回ずつの測定なので実行ごとのブレに埋もれる範囲です。読み取れるのは「low かそれ以外か」まで。難しくない 4 問での話ではありますが、日本語の定型処理を回すだけなら low で足りる、という目安にはなりそうですね。

量子化を変えても結果は動きませんでした。活性化まで 4bit に落とす NVFP4 W4A4（25.4 GB）でも、15.9 GB まで縮めた K-quant でも、この 4 問では崩れません。出力トークンは 2,306 と 2,311 でほぼ同じ、コード生成にいたっては両者まったく同じ実装を返してきます。

では比較対象の 2 機種はどうだったか。同じ 4 問を、同じサンプリングと同じ上限で投げた結果がこちらです。

5 つの構成すべてが全問正解でした。正誤では並べる意味がないので、残るのは消費量の比較になります。そしてそちらは 14 倍の開きがありました。面白いのは順位の入れ替わりです。Gemma4-31B は単発のデコード速度では 6.84 tok/s と 3 機種で一番遅いのに、出力が 284 トークンで済むので実時間では最速でした。1 秒あたりのトークン数だけを見て速い遅いを判断すると、実際にかかる時間を読み違えることになります。この差の正体は、答える前に考えるかどうかです。

Muse Glimmer は答えを書き出す前に、必ず頭の中で考えます。「日本の首都を 50 字以内で説明してください」に対しても、まず 2,806 文字ぶん考えてから、21 字の答えを書く。そしてこの思考は止められません。強さを指定する Reasoning strength は low / medium / high / xhigh の 4 段階で、オフに当たる値がありません。チャットテンプレートは渡された文字列をそのまま埋め込むだけなので、試しに none や off を渡してみたのですが、思考は 1,243 字と 1,999 字。止まるどころか off のほうが長く考えました。文書にある一番軽い low にしても、まだ 1,244 文字は考えます。

Qwen と Gemma は違います。Qwen は enable_thinking を false にすると考える工程そのものを飛ばし、同じ問いに 18 トークンで答えました。Gemma は思考の強さを指定する仕組みを持っておらず、今回の 4 問ではいずれも考える工程を挟まずに答えています。

同じ答えにたどり着くのに、片方は考えてから書き、もう片方はいきなり書く。答えが変わらないなら、考えたぶんは丸ごと待ち時間になります。50 字の答えのために 1,028 トークンと 90 秒を使うか、18 トークンで即返すか、という違いですね。短い応答をたくさんさばく用途では、この差がそのまま処理時間と費用に乗ります。「まず考えてから動く」というエージェント向けの設計は、考えるまでもない仕事には割高につく、ということかなと思います。日本語の正しさそのものは十分なので、引っかかるのは答えの質ではなく、そこに至るまでの時間のほうですね。

コーディングとエージェント

エージェント向けを掲げているモデルなので、ツールを渡して仕事をさせたときにどうなるかを見ます。

ツール呼び出しは 5 問とも通る

まず単発の呼び出しから。天気を聞く最小のケース、2 つのツールから正しいほうを選ぶケース、入れ子のオブジェクトと enum と整数が混ざった引数、日本語を引数に入れるケース、そして「ツールを使わないのが正解」のケースの 5 問です。

5 問とも通りました。入れ子の引数も {"assignee": {"name": "Sato", "team": "infra"}, "estimated_hours": 8} と型どおりに組み立ててきますし、日本語も {"keyword": "ほうじ茶ラテ"} と素直に入ります。挨拶に対して余計なツールを呼ぶこともありませんでした。XML で書かれたものがクライアント側では普通の tool_calls として受け取れるので、ここまでは既存のコードがそのまま動きます。ストリーミングでも tool_calls と思考の両方が delta として流れてきました。

2 件は分けて返すのに、4 件はまとめて返す？

問題はここからです。東京と大阪の天気をまとめて聞くと、こうなりました。

1 回目の応答には東京ぶんの 1 件しか入っていません。結果を返してもう一度回すと、そこで大阪が来ます。同じ問いを比較対象の 2 機種に投げると、Qwen3.6-27B も Gemma4-31B も 1 回の応答に 2 件を並べて返すので、ここは Muse Glimmer の癖ということでしょうか。

ところが、別の課題では違う顔を見せます。壊れた小さなリポジトリを擬似ファイルシステムごしに調べさせるほうの課題です。

app/__init__.py、app/cart.py、app/discount.py、tests/test_cart.py の 4 件が、1 つのメッセージに並んで返ってきました。vLLM でも llama.cpp でも SGLang でも同じ形です。まとめて返せないのではなく、場面によってまとめたり分けたりするわけですね。

厄介なのは、どちらを前提にしても外れることです。「1 件ずつしか来ない」と決め打った実装は、この 4 件が来たときに 3 件を取りこぼします。「まとめて来る」と期待した実装は、天気 2 都市のような場面で余計な往復を踏みます。件数は毎回変わるものとして扱うのが無難で、載せ替える前に自分の課題で確かめておきたいところです。

tool_choice の required は当てにしない

レシピには「このモデルでは required と名前指定を使うな」と書かれています。実際に投げてみると、エラーにはならず、黙って 0 件が返ってきました。

どれも HTTP は 200 で、例外も出ません。40 秒使って何も呼ばずに返ってくるので、「必ず呼ばれる」前提で書いたクライアントは静かに壊れます。比較対象も並べてみると、守ったのは Qwen だけでした。llama.cpp のほうは、ツールが渡されると ATEM の書式がそのまま文法上の制約になるので required が効きます。

同じ重みに同じリクエストを投げても、エンジンとモデルの組み合わせで結果が変わるということですね。この指定には頼らない設計にしておくのが無難です。

バグ 3 つのリポジトリを直させる

最後に、テストが 5 本落ちている小さな Python プロジェクトを渡して、read_file と write_file と run_tests だけで直させました。採点はモデルの自己申告ではなく、ハーネス側で pytest を実行した結果です。

6 つの構成すべてが 12 本を緑にしました。引数の JSON が壊れたことも一度もありません。ここでも正誤で差はつかず、違ったのは往復の回数と所要です。

Muse Glimmer はエンジンを変えてもターン数とツール実行回数がぴたりと同じ 12 回と 11 回で、同じ道筋をたどって同じ場所に着いています。挙動が安定しているのは扱いやすい性質ですね。一方 Qwen は複数の呼び出しをまとめられるぶん 5 ターンで片づけ、Gemma は出力トークンが 784 と一番少ない代わりに 14 ターンかかりました。

進み方にも特徴がありました。high では最初の 7 ターンを read_file に使い、8 ターン目に 2,539 文字の思考を一気に回して修正方針を決め、そこからは迷わず書き込んで一発で緑にしています。往復は多いが手戻りは無い、という進み方ですね。

ファイルを 7 つ読むのに 7 ターン。さきほどの擬似ファイルシステムでは 4 件をまとめたのに、この課題では最後まで 1 ターン 1 件で通しました。ちなみに Gemma4-31B も同じく 1 件ずつの 14 ターンなので、Muse Glimmer に限った話ではありません。3 件ずつまとめた Qwen が 5 ターンで片づけたのと比べると、手数の差がそのまま所要に出ています。

ここまでの結果を、公称ベンチと突き合わせてみます。Meta は MCP Atlas 75.5 対 62.5、τ3-Banking 23.5 対 16.7 と、ツールを何度も呼ぶ仕事で Qwen3.6-27B を明確に上回ると書いています。一方でコーディングは SWE-Bench Verified 76.0 対 77.2、TerminalBench 51.7 対 60.7 と負けている。手元の結果は、その差がどちらの向きにも出ませんでした。正誤はすべて満点で並び、違ったのは往復の回数と所要だけ。しかもその効率では、まとめて呼べる Qwen のほうが有利に出ています。

これは今回の課題が易しすぎたということだと思います。5 問のツール呼び出しも、テストが 5 本落ちた小さなリポジトリも、どのモデルも一発で通してしまう難度でした。MCP Atlas や τ3-Banking のような、長い手順を踏み外さずに完走できるかを見るベンチとは、測っているものが違います。今回の課題では、看板の真偽までは判定できなかったというのが正直なところです。

まとめ

Muse Glimmer 30B は DGX Spark 1 台に素直に載りました。NVFP4 なら 25 GB で収まり、KV キャッシュに 480 万トークンぶんを確保できます。これは比較対象の Qwen3.6-27B の 2.2 倍、Gemma4-31B の 6.3 倍で、今回測ったなかでは一番はっきりした強みでした。長い文脈を何本も並べる使い方なら、ここが効いてきそうです。

一方で、能力そのものの差は測れませんでした。日本語 4 問、ツール呼び出し 5 問、擬似ファイルシステムでの原因特定、テストが 5 本落ちたリポジトリの修正 — 3 機種すべてが、思考の強さを変えても、エンジンや量子化を変えても、全部を通してしまいます。

差が出たのは、同じ答えに使うトークンと時間のほうでした。そしてその効率では、比較対象のほうが有利に出ています。Qwen は複数のツールをまとめて呼べるので往復が半分以下で済み、考える工程を飛ばせるぶん短い応答も軽い。Gemma にいたっては、素のデコードが 3 機種で一番遅いのに、考えずに答えるので日本語 4 問の実時間では最速でした。「まず考えてから動く」を売りにしたモデルとしては、少し肩透かしな結果です。

課題が易しすぎた、というのが自分の見立てです。Meta が差をつけていると主張しているのは、長い手順を踏み外さずに完走できるかを見る種類のベンチで、そこは 1 日で組めるハーネスの外にあります。day-1 に手元で測れる範囲では看板の真偽までは判定できなかった、感もあります。

実務に効いたのは、むしろ作法のほうでした。1 メッセージに入るツール呼び出しの件数が場面によって変わること、tool_choice の required がエラーにならず黙って無視されること、思考の取り出し口がエンジンで違うこと。どれも既存のコードが例外を出さずに静かに壊れる形なので、載せ替える前に確かめておくと事故が減ります。

エンジン選びのほうは、1 日で答えが変わりました。公開当日は SGLang だけが投機デコードまで通りましたが、翌日には vLLM も追いついて、手元では 1.85 倍が出ています。ただし配布イメージにはまだ入っていないので、これから試す人は当日と同じところで止まるはずです。画像を通すなら llama.cpp がいちばん手軽で、--mmproj を足すだけで済みました。しばらくは用途と時期で答えが動きそうですね。

もう少し難しい課題を用意して、公称どおりの差が出る条件を探すのが次の宿題です。Muse Spark 1.2 のウェイトも近く公開されるとのことなので、そちらも出たら試してみたいところです。

最後にもうひとつ。今回の結果は「手元の課題では差がつかなかった」という地味なものになりましたが、それとは別に、Meta が 1 年 4 か月ぶりにこの土俵へ戻ってきたこと自体が大きいと思っています。Apache-2.0 で、1 台に載る 30B。公開当日のうちに 3 つの推論エンジンが対応に動き、量子化も一晩で出そろって、この記事で追いかけた投機デコードの不具合まで翌朝には直っていました。大きな作り手が戻ってくると、まわりがこれだけ速く動くわけですね。今回の数字がどうであれ、この復帰がオープンウェイト界隈にどう効いていくのか、そちらのほうが楽しみです。

参考リンク

• Introducing Muse Glimmer（Meta AI Research）
• meta-models/Muse-Glimmer-30B
• vLLM recipes の Muse Glimmer ページ
• vLLM PR #51655（Muse Glimmer 対応）
• llama.cpp PR #26841（Muse Glimmer 対応）
• SGLang Muse Glimmer Cookbook
• unsloth/Muse-Glimmer-30B-GGUF