TL;DR
- Meta が1年以上ぶりに公開したオープンウェイト Muse Glimmer 30B（ミューズ・グリマー）（dense 29.6B・ネイティブ VLM・Apache 2.0）を DGX Spark (GB10) で実測し、①速度、②日本語知識、③コーディング、④マルチモーダルの4軸で性能を比較した
- 速度はバックエンドと並列度で大きく変わる。1人利用（c=1）では llama.cpp Q4_K_M 素で 11.9 tok/s、DFlash 投機デコードで 27.0 tok/s。vLLM + NVFP4（ネイティブカーネル）では c=1 の 11.02 tok/s から、実用上の上限である c=128 の 412.61 tok/s まで、合計スループットが約37倍に伸びた
- 【v1.1 追測】vLLM でも公式ドラフタで DFlash が動いた。 高速化率は c=1 で 2.16倍と llama.cpp（2.27倍）とほぼ同じで、c=2 以降は vLLM + DFlash が全域で最速になった。「1人なら llama.cpp」の結論は c=1 に限れば維持だが、その差は 12% まで縮んだ
- 同一イメージ・同一カーネルで揃えた dense 対 dense の比較では、高並列域の c=32〜64 で Muse が線形アテンション主体の Qwen3.8 を 37〜45% 上回った。前回記事の「Gated DeltaNet 主体の構成が速度差の主因」という解釈は、単純には維持できなくなった（自己訂正）
- 同梱の先読み機構 DFlash は、候補トークンの採用率が 14.9% と低い一方、候補生成の計算コストが小さい。そのため c=1 では 2.27倍に高速化した。前回測った MTP は候補生成が重い代わりに採用率が 48〜56% と高く、両者では投機デコードの効き方が対照的だった。採用率は llama.cpp / vLLM の両実装で 14% 前後に一致しており、ドラフタとモデルの組に固有の性質とみられる
- モデルの性格は Qwen3.8 と同型: 日本語知識（JamC-QA）は 52.62% で比較群最下位、コーディング（Aider Polyglot）は 48.0% で上位同等圏、VLM の構造化出力は parse rate 100%。知識を削り、作業能力に振った エージェント設計である
- 今回いちばん高くついた教訓: 推論の思考過程を長く出力するモデルを、ベンチハーネスの既定
max_tokensのまま測ると、モデルの実力ではなく設定の不足を測ってしまう。Aider Polyglot は設定次第で 7.6% → 48.0% まで動いた
1. Muse Glimmer 30B とは
一言でいえば、ローカルで動くエージェント基盤として設計された dense VLM である — 4軸の実測を終えた本記事の結論だ。以下、そのモデルの素性から順に見ていく。
Meta が1年以上ぶりにオープンウェイトに戻ってきた
2026年8月10日、Meta Superintelligence Labs が Muse Glimmer 30B（ミューズ・グリマー）を公開した。Meta にとって1年以上ぶりのオープンウェイトモデルである。
この1年、Meta とオープンソースの関係は微妙だった。かつて Llama はローカル LLM ムーブメントの起点そのものだった（r/LocalLLaMA というコミュニティ名がその名残だ）。しかし Llama 4 は期待に届かず、AI 部門は Superintelligence Labs として再編され、ザッカーバーグ自身が「何をオープンソースにするかはより慎重になる」と発言する — オープンウェイトからの撤退が既定路線と見られていた時期すらあった。
そこへの回答が Muse Glimmer である。ザッカーバーグは X で「ローカルで動く 30B dense モデルの重みを公開する」「近く Muse Spark 1.2 の重みも公開する」と投稿し、r/LocalLLaMA の初動はそのまま「Meta is back」の空気だったと伝えられている。英国の老舗ITメディア The Register は "glimmer"（かすかな光）というモデル名に掛けて、ルーツを捨てたかに見えた Meta が一筋の光を差し出した、という書き方をした。
同時に冷めた評価もある。「30B では Kimi K3 や Qwen 3.8-Max、DeepSeek V4 Flash といった中国勢のフロンティア級に対抗するには小さすぎる」— 同じ The Register の指摘だ。ただ、これは土俵がずれていると筆者は考える。Muse はフロンティア級と殴り合うモデルではなく、24〜32GB のローカル環境で動くことを最初から狙って設計されたモデルである。Meta 自身が「4bit 圧縮で 20GB 未満に収め、KV キャッシュ・vision encoder・投機デコードのドラフタが 24GB / 32GB の枠内で同時に動く余裕を残した」と説明している。その土俵での相手は Qwen の中型帯と Gemma4 だ。
実際、Meta 公式の発表資料は、Qwen3.6-27B と Gemma4-31B を比較対象に据えている。公式ブログと HF モデルカードに掲載された 24項目のベンチマーク比較表（エージェント / コーディング / マルチモーダル / 安全性 / 一般推論の3モデル対照表）がそれで、エージェント系で Muse が大きく勝ち（MCP-Atlas 75.5 vs Qwen 62.5 / Gemma 54.2、DeepSearch QA 74.6 vs 71.1 / 61.7）、Terminal-Bench や OSWorld-Verified では Qwen が勝つ、という凹凸のある表になっている。
主要項目を公式モデルカードから転記する（太字は3モデル中の最高値）。
| 分類 | ベンチマーク | Muse Glimmer 30B (High Reasoning) |
Gemma4-31B (Thinking) |
Qwen3.6-27B (Thinking) |
|---|---|---|---|---|
| General Agentic | MCP Atlas (Public) | 75.5 | 54.2 | 62.5 |
| DeepSearch QA | 74.6 | 61.7 | 71.1 | |
| τ³-Banking | 23.5 | 15.1 | 16.7 | |
| WildClawBench | 47.6 | 37.6 | 43.2 | |
| Gaia2 | 43.3 | 36.4 | 40.0 | |
| OSWorld-Verified | 65.9 | 58.5 | 75.6 | |
| Agentic Coding | SWE-Bench Pro | 51.2 | 36.9 | 50.2 |
| SWE-Bench Verified | 76.0 | 66.6 | 77.2 | |
| TerminalBench 2.1 | 51.7 | 43.4 | 60.7 | |
| 一般推論 | AIME 2026 | 94.7 | 89.2 | 94.1 |
| AA-LCR | 80.0 | 68.3 | 73.3 |
（出典: Meta, Muse Glimmer 30B モデルカード Benchmarks 節より抜粋。マルチモーダル・安全性を含む全24項目は原典を参照。GDPVal-AA v2 と SkillsBench は Qwen 優位、安全性2指標は Gemma 優位）
ただし前回記事の Qwen3.8 と同様、この表の数字はすべて Meta 自身の測定である（Meta 自身も、他社モデル向けにツールやプロンプトを調整しきれていない可能性があると注記している）。本記事はそれを検証するものではなく、いつも通り「実ハードで走らせたら実際に何が起きるか」を測る。比較群の選定は、この Meta の想定に沿ったものだ。
スペックは dense 29.6B + 約2B の vision encoder（Perception Encoder）を内蔵したネイティブ VLM、128K コンテキスト、Apache 2.0、知識カットオフ 2026-01-04。注意機構はスライディングウィンドウ注意（窓 2,048 トークン）と全域注意を交互配置するハイブリッド注意である — この点は後の §3-4 で効いてくる。
設計のすべてが AI エージェント用途を指向している
(1) 出力形式が独特。 JSON 形式の tool call も <think> タグも使わない。to=self<|message|> 形式のチャンネル分割出力（思考用チャンネルと、ユーザーに見せる回答チャンネルを分けて出力する方式）と、XML 風の ATEM 形式 tool call を出す。vLLM では --tool-call-parser muse_glimmer と --reasoning-parser muse_glimmer の併用が必須。一方 llama.cpp では --jinja だけで正しく分離された。ここは実際に試すまで分からなかった。
(2) 投機デコード用の先読み機構 DFlash を同梱。 ここが Muse のいちばん独特な部分なので、図で説明する。
LLM の生成が遅い根本原因は、1トークン出すたびにモデル全体の重みをメモリから読むことにある。投機デコードはこれを緩和する仕組みで、軽量な先読み機構（ドラフタ）が数トークン先まで候補を生成し、本体モデルがまとめて検証する。候補のうち正しい部分を一度に採用できるため高速化でき、採用されなかった部分は本体モデルの出力に置き換わるので、原理上は生成品質を変えずに速度だけを上げられる。
一般的な方式では、小さな別モデルが先読みを担当する。前回測った Qwen3.8 の MTP ヘッド（3.0GB・別ファイル）もこの系譜である。DFlash は違う。52層ある本体の途中 — 層 1, 13, 25, 37, 49 — の計算結果を直接読み取る、わずか5層のヘッドであり、独立したモデルというより、本体に聴診器を当てて次の 16 トークンを先読みする器官に近い。この方式は Inco AI が今年1月に公開したもので、llama.cpp / vLLM / SGLang が対応済み。Meta は Muse Glimmer 用に学習した公式ドラフタを同梱した。
(3) ネイティブ VLM。 vision encoder が本体に内蔵されており、llama.cpp では mmproj ファイルを渡すだけで画像入力が有効になる。
2. 前提の整理
用語ミニ解説 — dense / MoE / ハイブリッド
- dense: 毎トークン、全パラメータを使う通常構成。知識の密度で有利だが、DGX Spark (GB10) ではメモリ帯域が律速になり 1人利用（c=1）で 10 tok/s 帯に張り付く
- MoE: トークンごとに一部の「専門家」だけ使う構成。速いが、同サイズ帯なら知識は dense に劣る傾向（当ラボ実測）
- ハイブリッド注意: dense のまま、注意機構の大半を軽い方式に置き換えた構成。Qwen3.8 は線形アテンション（Gated DeltaNet）、Muse と Gemma4 はスライディングウィンドウ注意を使う
比較の相手 — 直前に測った Qwen3.8-27B + MTP
当ラボでは本測定の直前に Qwen3.8-27B を同じ環境で測定している（前回記事）。Qwen3.8 の MTP は、3.0GB のヘッドによる追加計算が必要な代わり、候補トークンの採用率は 48〜56% と高く、効果が高い並列度まで続いた。一方の DFlash は採用率が 14.9% と低いが、5層の軽量な構成によって c=1 では 2.27倍に高速化した。候補生成の軽さを重視する DFlash と、候補採用率を重視する MTPという対照的な2例が揃ったことになる。この違いは §4 で詳しく考察する。
比較群は Muse を含め5モデル: Qwen3.8-27B（dense・線形アテンション）/ Qwen3.6-35B-A3B（MoE）/ Gemma4-31B（dense）/ Gemma4-26B-A4B（MoE）。前述のとおり Qwen3.6 と Gemma4 は Meta 自身が比較対象に据えた相手である。
測定方法 — 当ラボ標準の方式
サーバ（llama-server または vLLM）を vllm bench serve クライアントで叩き、どのバックエンドもクライアント・プロンプト集合（ShareGPT、200問）・問数を完全に揃える。c（同時実行数）の読み方は前回と同じだ: c=1 は一人で対話するときの体感、c=8〜16 は部門サーバ、c=32〜 は本格運用。
主要条件のみ示す（全条件の一覧は文末「測定条件の記録」に統合した）。
| 項目 | 値 |
|---|---|
| ハード | DGX Spark (GB10)、128GB unified memory |
| llama.cpp 系列 | b10423 / Q4_K_M + mmproj + DFlash ドラフタ |
| vLLM 系列 | 公式イメージ + NVFP4（ネイティブカーネル動作を確認済み）。投機なし系列と、公式ドラフタによる DFlash 系列の両方を測定（§3-6） |
| プロンプトキャッシュ | 無効化。理由は §3-5 |
3. 速度 — 使い方でバックエンドの選択が逆転する
Muse Glimmer をローカルで動かす手段は Ollama、LM Studio、MLX など数多いが、本記事では当ラボの標準測定系である llama.cpp と vLLM の2バックエンド・4構成を測る: (a) llama.cpp Q4_K_M（素）、(b) 同 + DFlash、(c) vLLM + NVFP4（素）、(d) 同 + DFlash（公式ドラフタ、v1.1 追測）。結論を先に言うと、同じモデル・同じハードでも速度はバックエンドと並列度で大きく変わる。vLLM + NVFP4 では、c=1 の 11.02 tok/s から c=128 の 412.61 tok/s まで、合計スループットが約37倍に伸びた。そして前回記事と違う点が一つある。どのバックエンドが速いかが、使い方（c）で逆転する。
3-1. llama.cpp — DFlash の効きと限界
| c | DFlash ON | DFlash OFF | 優劣 |
|---|---|---|---|
| 1 | 27.03 | 11.90 | ON 2.27倍 |
| 2 | 30.34 | 15.22 | ON 2.00倍 |
| 4 | 39.15 | 20.53 | ON 1.91倍 |
| 8 | 41.86 | 27.01 | ON 1.55倍 |
| 16 | 46.27 | 34.07 | ON 1.36倍 |
| 24 | 48.32 | 52.69 | OFF 1.09倍 |
| 32 | 53.11 | 87.68 | OFF 1.65倍 |
ON と OFF の優劣は c=16〜24 の間で逆転する。 ON は c=16 以降ほぼ頭打ち（46 → 48 → 53）、OFF は加速し続ける（34 → 53 → 88）。低並列では余っている演算資源を先読みに回せるが、高並列では演算側が飽和し、候補トークンの生成・検証コストが本体モデルの処理と演算資源を取り合う — 前回記事 §4 で MTP に見たのと同じ構造が、DFlash ではより低い c で、より鋭く現れた。
候補トークン採用率の温度依存も測った: temperature 1.0（公式推奨）で 14.6%、0.6 で 17.2%、0.2 で 18.3%。低温ほど上がるが幅は小さい。16トークンを先読みしても、実際に採用されるのは平均2〜3トークンであり、公式推奨の広いサンプリング設定だけが低い採用率の原因ではない。
3-2. 投機デコードで日本語性能は落ちないのか — JamC-QA 300問で確認
投機デコードは本体が全トークンを検証するため品質は原理的に落ちない（§1）。それを日本語で実測確認した。使ったのは JamC-QA — 日本固有の知識を問う4択ベンチマーク（詳細は §5）— の固定300問で、DFlash ON 53.33% / OFF 53.67%、差 0.34pt。この測定では実質的な差は見られなかった。したがって本記事の品質評価（②日本語知識、③コーディング、④マルチモーダル）はすべて DFlash ON で測定している。
⚠️ 検証方法の教訓を一つ。当初「同一 seed で出力を突き合わせて完全一致率を見る」方法を試したが、これは何も証明しない。投機デコードは乱数の消費順序が変わるため temperature 1.0 では一致しなくて当然で、不一致が乱数由来か品質劣化かを切り分けられない。採点できる客観指標で A/B を取るのが正解だった。
3-3. vLLM + NVFP4 — c=128 で 412 tok/s に到達し頭打ち
| c | 1 | 8 | 16 | 32 | 64 | 128 | 256 |
|---|---|---|---|---|---|---|---|
| tok/s | 11.02 | 81.77 | 149.25 | 250.69 | 340.04 | 412.61 | 416.95 |
（全点 200/200 成功）
高並列側の代償は遅延に出る。
| c | 1 | 8 | 64 | 128 | 256 |
|---|---|---|---|---|---|
| TTFT (ms) | 156.1 | 326.3 | 1,148.0 | 3,283.4 | 7,002.2 |
| TPOT (ms) | 90.1 | 92.8 | 137.2 | 192.0 | 228.3 |
c=256 では合計スループットが +1% しか増えないのに、最初の応答まで7秒待たされ、1トークンあたりの間隔も2.5倍になる。c=128 を超えて詰め込む意味はない。
c=128 → c=256 は +1% で、実効的な上限は c=128 付近。このときの KV キャッシュ使用量は 5.97M トークンだった。DGX Spark (GB10) 一台で 400 tok/s 級、実用上の並列上限は 128 前後 — 24〜32GB 想定で設計されたモデルを 128GB の環境に載せると、ここまで伸びる。
3-4. dense 対 dense — 同一イメージで統制して比べる
前回記事 §3-4 は、Qwen3.8 が Gemma4-31B を 1.35〜1.50倍上回ることを「64層中48層を線形アテンション（Gated DeltaNet）にした構成の効率が数字に出た」と解釈した。今回、その解釈を検証する対照群が加わった。Muse は線形アテンションを使わない dense だからである（注意機構はスライディングウィンドウ交互配置で、この点はむしろ Gemma4 と同系だ）。
イメージ差の交絡を除くため、Qwen3.8 と Gemma4-31B を Muse と同一の vLLM イメージで測り直した。前回記事の値との差は Qwen3.8 で -1.4%、Gemma4-31B で +3.9% — ランタイム差は小さく、数字はモデル由来と言える。
| c | Muse Glimmer 30B （dense・SWA） |
Qwen3.8-27B （dense・線形アテンション） |
Gemma4-31B （dense・SWA） |
|---|---|---|---|
| 8 | 81.77 | 73.55 | 48.21 |
| 16 | 149.25 | 122.80 | 85.97 |
| 32 | 250.69 | 182.63 | 142.57 |
| 64 | 340.04 | 233.87 | 187.33 |
Muse が Qwen3.8 を全点で上回った。しかも優位幅は c=32 の +37.3% から c=64 の +45.4% へ拡大している（対 Gemma4-31B は +75.8% → +81.5%）。
これは前回記事の解釈への反証である。線形アテンション化が dense 対 dense の速度差の主因なら、それを持たない Muse は Gemma4-31B 側に沈むはずだった。実際は逆で、しかも同じ SWA 系の Gemma4-31B は最下位のまま。注意機構の分類だけでは、vLLM 上の速度序列は説明できない — というのが3モデルを統制して並べた現時点の正直な結論だ。カーネルとの相性、層構成の細部、量子化チェックポイントの作りが重畳しているとみられ、分解は宿題として持ち越す。
3-5. ハマりどころ — プロンプトキャッシュとチャットテンプレート
本記事の測定条件に「プロンプトキャッシュ無効化」とあるのは、次の実害を踏んだためだ。
llama-server 既定のプロンプトキャッシュ（--cache-ram 8GB・--cache-idle-slots 有効）のまま 200問測定を回すと、キャッシュの退避処理がリクエスト処理に割り込み、TTFT を大きく歪める。しかも影響度がモデルごとに違う。 Gemma4-31B では mean TTFT が 8,893ms → 587.6ms（15.1倍）、Qwen3.8 では 2,953.7ms → 485.6ms（6.1倍）も変わった一方、Muse と Qwen3.6 はほぼ無風だった。既定のまま複数モデルを比較すると、モデルではなくキャッシュとの相性を測ることになる。
もう一つ、Gemma4 系はチャットテンプレートの不整合に注意。outdated gemma4 chat template 警告がリクエストごとに発火し、それだけで TTFT が13倍膨らんでいた。--chat-template-file で同梱のテンプレートを明示指定して解消した。
（前回記事に掲載した Qwen3.8 の TTFT には、このキャッシュ退避の影響が乗っている。訂正値は測定済みで、前回記事の次回更新で反映する）
3-6. どのバックエンド・設定を選ぶか【v1.1 全面更新】
v1.0 時点では vLLM 側の DFlash が未測定で、「c=1 は llama.cpp + DFlash 一択（vLLM の 2.5倍）」と書いた。その後、公式ドラフタ meta-models/Muse-Glimmer-30B-assistant を --speculative-config（method: dflash）で指定すれば NVFP4 本体と組み合わせて動くことが確認できたため、c=1〜32 を追測した。結果、この節の結論は書き換えになった。
| c | llama.cpp + DFlash | vLLM 素 | vLLM + DFlash |
|---|---|---|---|
| 1 | 27.03 | 11.02 | 23.78 |
| 2 | 30.34 | 21.91 | 44.58 |
| 4 | 39.15 | 43.23 | 87.12 |
| 8 | 41.86 | 81.77 | 154.24 |
| 16 | 46.27 | 149.25 | 237.40 |
| 32 | 53.11 | 250.69 | 310.99 |
| 64〜 | — | 340.04（c=64）/ 412.61（c=128） | 未測定 |
逆転点は c=2〜4 から c=1〜2 に前倒しになった。 llama.cpp が最速なのは c=1 のみで、その差も 27.03 対 23.78（12%）まで縮んでいる。
- 1人で対話・コーディング（c=1）: 依然として llama.cpp + DFlash が最速。ただし vLLM + DFlash も 23.78 tok/s（TPOT 34.6ms）まで来ており、実用上の体感差は小さい。運用の手軽さ（GGUF 1ファイル + mmproj）を含めれば llama.cpp を推すが、「一択」ではなくなった
- c=2 以上のすべての領域: vLLM + DFlash が最速。c=32 で 310.99 tok/s は、投機なし（250.69）の 1.24倍
- 興味深いのは高並列側の挙動の違いである。llama.cpp の DFlash は c=16〜24 で OFF に逆転されたが、vLLM 側は c=32 でも 1.24倍の正の効果を維持している。連続バッチングを前提とした vLLM の実装では、先読みの追加計算が高並列時に相対的に安く済んでいる可能性がある
- 改良版ドラフタ「DFlash 2」（incoai 公開）も試みたが、現行の vLLM イメージが DFlash2DraftModel アーキテクチャに未対応で起動できなかった。対応イメージが出た時点での測り直しを宿題とする
ここで一つ注意。c を上げても「体感」は良くならない。c=64 の TPOT 137.19ms は1ユーザーあたり約 7.3 tok/s で、c=1 の 11.02 より遅い。c=1 から c=64 で合計スループットが約31倍になっても、個々のユーザーの体感は落ちている。合計スループットと体感速度は別物 — 1人で使うなら c=1 の値だけを見てほしい。
4. 考察 — DFlash と MTP では、なぜ高速化の効き方が違うのか
投機デコードの効果は、候補トークンの採用率だけでは決まらない。少なくとも、次の2つの要因で決まる。
- 候補トークンを生成するための追加計算コスト
- 生成した候補のうち、本体モデルに採用される割合
DFlash と MTP は、この2要因のバランスが対照的である。
| 項目 | DFlash（Muse） | MTP（Qwen3.8） |
|---|---|---|
| 先読みの方法 | 本体の中間層の計算結果を利用する5層ヘッド | 3.0GBの独立したヘッド |
| 候補生成の追加計算 | 小さい | 大きい |
| 候補トークン採用率 | 14.9% | 48〜56% |
| c=1 の高速化 | 2.27倍 | 1.29倍 |
| 効果が薄れる並列域 | c=16〜24 | c=32〜64 |
DFlash — 候補生成が軽く、低並列で大きく効く
DFlash が先読みする16トークンのうち、実際に採用されるのは平均2〜3トークンにすぎない。それでも c=1 で2.27倍に高速化したのは、候補を生成するための追加計算が小さいからだ。採用されない候補が多くても、その候補を作るコスト自体が小さいため、1人で使うような低並列環境では大きな効果が得られる。
一方、並列度が上がると本体モデルの処理だけで演算資源が埋まり、先読みの追加計算が競合し始める。その結果、DFlash の効果は c=16〜24 で消え、さらに並列度を上げると DFlash OFF の方が速くなった。DFlash は、低並列時の応答速度を大きく引き上げる設計といえる。
MTP — 候補採用率が高く、効果が高並列まで続く
Qwen3.8 の MTP は、3.0GB の独立したヘッドで候補を生成するため、DFlash より追加計算が重い。そのため c=1 の高速化は1.29倍にとどまった。一方、候補トークンの採用率は48〜56%と高く、1回の検証でより多くのトークンを確定できる。このため、並列度が上がっても効果が残り、c=32〜64まで高速化が続いた。
つまり MTP は、低並列での瞬間的な伸びよりも、並列度が高くなっても投機デコードの効果を維持する設計といえる。
【v1.1 追記】採用率は実装をまたいで一致した — 高並列側の挙動は実装で違った
vLLM × DFlash の追測（§3-6）で、この考察に2つの材料が加わった。
第一に、候補トークン採用率が実装をまたいでほぼ一致した。llama.cpp で 14.9%、vLLM で 13.7〜14.4%（c=1〜32 でほぼ一定）。バックエンドの実装がまったく異なっても採用率が同じ水準に収まったことは、採用率がドラフタとモデルの組に固有の性質であり、実行環境の性質ではないことの傍証になる。
第二に、効果が消える並列域は実装で違った。llama.cpp の DFlash は c=16〜24 で OFF に逆転されたが、vLLM では c=32 でも 1.24倍の正の効果を保っている。採用率が同じでも、候補生成・検証の追加計算をどれだけ安く処理できるかはバックエンドの設計に依存する — 投機デコードの「効果が続く範囲」は、ドラフタだけでなく実行系にも左右されるということだ。
ただし、DFlash と MTP は異なる本体モデルに接続されており、同じモデル上で先読み機構だけを差し替えた A/B テストではない。したがって、速度差のすべてを先読み機構の設計だけに帰属させることはできない。ここで確認できたのは、2つの構成で投機デコードの効き方が対照的だったという点であり、各要因の寄与を厳密に分解するには追加検証が必要である。
5. 日本語知識 — JamC-QA で測る
使ったのは JamC-QA（SB Intuitions 構築）— 日本固有の知識（文化・風習・制度など）を問う4択ベンチマークで、全2,309問。従来の日本語ベンチが上位モデルで満点近くに張り付いて差が出なくなったため、当ラボでは新規モデル評価の主軸をこれに置いている。測定条件は前回と同一: 3-shot / 4択一致判定 / DFlash 有効のまま（§3-2 で品質不変を確認済み）。parse 失敗 2件。
| モデル | 構成 | JamC-QA |
|---|---|---|
| DeepSeek-V4-Flash-0731 | MoE | 63.92% |
| Gemma4-31B | dense | 61.28% |
| Nemotron 3 Super 120B | dense | 59.33% |
| Gemma4-26B-A4B | MoE | 58.08% |
| Qwen3.6-35B-A3B | MoE | 55.26% |
| Qwen3.8-27B | dense | 53.44% |
| Muse Glimmer 30B | dense | 52.62% (1215/2309) |
比較群の最下位である。 ただし Qwen3.8 との差は 0.82pt で実質同等、トップ帯の Gemma4-31B とは 8.66pt 差。
副次データを一つ。本測定の前に reasoning strength=medium（思考出力あり）でも全2,309問を測っており、そちらは 53.01% だった。思考を出させても +0.39pt しか動かない — JamC-QA が測る日本固有知識は、考えて導ける類のものではなく、知っているかどうかであることの傍証になっている。表の値は Qwen3.8 と条件を揃えた思考出力なし（52.62%）を採用した。
これは失敗ではなく設計の帰結だと考えている。Muse は100以上の言語で訓練された汎用モデルで、公式が押し出すのは多段推論・ツール利用・長いタスクの遂行・コーディング環境との互換性 — 日本固有知識に最適化する動機が最初からない。前回記事 §5 で Qwen3.8 に立てた「パラメータの使い道を知識から作業能力へ振り直した」という仮説が、Meta のモデルにもそのまま当てはまるかは、次章のコーディング測定で検証する。
6. コーディング — Aider Polyglot で測る
Aider Polyglot は、Exercism 由来の 225題を C++ / Go / Java / JavaScript / Python / Rust の6言語で解くベンチマークだ。単発のコード生成クイズではなく、次の3点で「エージェントとしてコードを直せるか」を測る。
- 既存ファイルへの差分編集 — 渡されたコードに対して、所定フォーマットどおりの差分を出力する。フォーマットを外せばその試行は無効
- 6言語 — Python の暗記量では通用しない
- テスト往復（2回まで） — 1回目が失敗するとテストのエラー出力を渡され、2回目の修正機会を得る。エラーを読んで直す実務そのものの動作
結果 — 上位3モデルは同等圏
| モデル | quant | rate_1 | rate_2 | 挽回幅 |
|---|---|---|---|---|
| Qwen3.6-35B-A3B | MXFP4_MOE | 24.0% | 49.8% | +25.8pt |
| Muse Glimmer 30B | Q4_K_M | 20.4% | 48.0% | +27.6pt |
| Qwen3.8-27B | Q4_K_M | 15.6% | 47.6% | +32.0pt |
| Gemma4-31B | Q4_K_M | 9.3% | 43.1% | +33.8pt |
（全モデル n=225 完走。比較3モデルは前回記事と同一の値）
上位3モデルの差は2.2pt以内であり、n=225 では確定的な優劣とみなすのは難しいため、上位3モデルは同等圏と見た。Muse は Gemma4-31B を 4.9pt 上回る。日本語知識で最下位に沈んだモデルが、コーディング実技では前世代 MoE 首位と並んだ — Qwen3.8 と同じ「知識を削って作業能力に振った」プロファイルが、Meta のモデルでも再現した。
well_formed（差分フォーマットを守れた率）は 98.7%。不整形3件のうち2件は後述のトークン切れと無関係で、ATEM 形式そのものに起因するとみられる。独自形式でも 98.7% は通るが、完全ではない。
本章の主役 — 設定で 7.6% → 48.0% まで動いた
実は上の 48.0% にたどり着くまでに、同じモデル・同じ 225題を3回測っている。
| 条件 | pass_rate_2 |
|---|---|
スロットあたり 1,024 トークン・max_tokens=4096
|
7.6% |
同 16,384 トークン・max_tokens=4096
|
25.0%（n=20 中間値） |
同 16,384 トークン・max_tokens=8192
|
48.0% |
最初の 7.6% は測定ミスの産物だ。サーバの並列数設定に対してコンテキスト長を据え置いたため1スロットが 4,096 トークンしかなく、しかも max_tokens=4096 — 思考過程を長く出力する Muse には、考え終わる前にトークンが尽きる設定だった。トークン切れ（exhausted_context_windows）は 450試行中328回（73%）。この 7.6% が測っていたのは実力ではなく設定の不足である。
スロット長を16倍にしてもトークン切れは 60% 残り、max_tokens を 8192 に上げて初めて 48.0% に到達した。足りなかったのは入力側ではなく生成側の上限だった。
最終条件でも、450試行中114回（25.3%）でトークン切れが残った。問題単位では、2回の試行のうち少なくとも1回トークン切れが起きた85題の失敗率は 88.2%、一度も起きなかった140題の成功率は 70% だった。トークン切れは明確に失敗側へ偏っている。したがって、48.0% には生成上限による打ち切りの影響が残り、実力を過小評価している可能性がある。比較群の Qwen3.8 は思考出力を切った設定（--reasoning off）でトークン切れなしの 47.6% なので、条件は完全には対等でない。この点は正直に書いておく。
7. マルチモーダル — VLM としての実力を測る
画像はテキスト以上にクラウドへ送りにくいデータであり（人が写る・書類に個人情報が載る）、VLM がローカルで実用になるかは切実な問いだ。当ラボの VLM ベンチは実写8枚に対する3タスク構成で、視覚情報を機械可読な形式で返し続けられるか（form-following）を測る。
- Caption 生成（5枚）— 見えているものの言語化。所要時間の参考として扱う
- JSON 構造化抽出（5枚）— 指定スキーマの JSON で返させる。parse できなければ後段の自動処理はすべて死ぬ
- PPE 検出（3枚）— 作業現場写真からヘルメット・安全ベスト等の装着状況を判定。複数対象への複合判断で、単純な抽出より一段難しい
測定条件は前回と同一のハーネス・画像で、Muse は DFlash ON・max_tokens=2048。
| モデル | JSON 抽出 | PPE 検出 |
|---|---|---|
| Gemma4-31B (dense) | 100% | 33.3% |
| Qwen3.6-35B-A3B (MoE) | 100% | 100% |
| Qwen3.8-27B (dense) | 100% | 100% |
| Muse Glimmer 30B (dense) | 100% | 100% |
Gemma4-31B が崩れた PPE の複合スキーマを、Muse は守り切った。 知識は最下位、form-following は満点 — §5・§6 と同じ縦糸がここでも確認できた。
ここでも max_tokens の壁 — 33.3% → 100% の顛末
条件に max_tokens=2048 とわざわざ書いたのには理由がある。ハーネス既定の 1024 で最初に測ったときは JSON 80% / PPE 33.3% だったからだ。
失敗ケースを調べると、3件すべて completion_tokens=1024 の切断で、JSON の構造自体は正しく書き出せていた（Muse はコードフェンスも付けず { から直接始める）。象徴的だったのが PPE の1枚（ppe02）で、max_tokens=2048 で測り直すと:
-
finish_reason=stop（完走） -
completion_tokens=1484（旧上限 1024 を超過） - 思考チャンネル 4,037字 + 可視出力 968字
旧上限では、可視出力が1文字も出る前に、思考チャンネルだけでトークンが尽きていた。 チャンネル分割出力を持つモデル特有の落とし穴である。なお PPE 33.3% という数字は奇しくも Gemma4-31B と同値だが、崩れ方は違う — Gemma4-31B は 371〜482字の可視出力を出した上での切断、Muse は 0字。同じ 33.3% でも中身は別物であり、parse rate という物差しの粗さがここにも出ている。
8. 総括
Muse Glimmer 30B は、DGX Spark (GB10) で単機運用できる エージェント特化型の dense VLM である。日本語知識の評価では比較群中最下位だが、コードを直させ、構造化出力をパイプラインに流す用途では上位同等圏。そして速度は — バックエンドと設定の選択がすべてという前回記事の結論に、もう一つ条件が加わった。使い方（c）でバックエンドの正解が逆転する。c=1 だけは llama.cpp + DFlash（27 tok/s）、c=2 以上は vLLM が全域で最速だ（DFlash 併用で c=32 311 tok/s、投機なしで c=128 412 tok/s）。
dense 対 dense の統制比較では、高並列域の c=32〜64 で Muse が線形アテンション主体の Qwen3.8 を 37〜45% 上回り、前回記事の「Gated DeltaNet 主体の構成が速度差の主因」という解釈に反証が付いた。注意機構の分類だけでは速度は説明できない — この分解は宿題として持ち越す。
今回いちばん高くついた教訓
思考過程を長く出力するモデルを、ベンチハーネスの既定 max_tokens のまま測ってはいけない。 本記事では同じ穴に3回落ちた。
| 軸 | 既定設定での値 | 上限を引き上げた値 |
|---|---|---|
| ③ Polyglot | 7.6% | 48.0% |
| ④ VLM (JSON) | 80% | 100% |
| ④ VLM (PPE) | 33.3% | 100% |
②だけは4択で出力が短く無事だった。前回記事 §7 で「このベンチは飽和が見え始めている、v2 を用意する」と書いたが、v2 で最初に直すべきは問題の難度ではなく max_tokens の設計だと分かった。思考を出力するモデルとそうでないモデルを同じ上限で並べると、実力ではなく設定を比較することになる。
所感 — ソブリン AI 文脈での選択肢
ここからは私見である。
行政・金融・重要インフラなどでは、性能評価とは別に、調達・ガバナンス上の理由から中国企業が開発したモデルを検討対象外とするケースがある。その制約下では、オープンウェイトモデルの有力な選択肢として、これまで米 Google の Gemma 4 が挙げられることが多かった。そこに Apache 2.0 の 30B dense VLM がもうひとつ加わった意味は、日本語スコアの優劣より大きいかもしれない。なお Gemma 4 も Apache 2.0 である。したがって両者の選択はライセンスでは決まらず、モデル固有の能力特性で決まる。
| Muse Glimmer 30B | Gemma4-31B | |
|---|---|---|
| 日本語の下地 | 52.62% | 61.28% |
| コーディング | 48.0% | 43.1% |
| VLM form-following（PPE） | 100% | 33.3% |
| 高並列速度（c=64、vLLM） | 340.04 | 187.33 |
日本語追加学習のベースモデルとしてどちらを選ぶか — 日本語知識の下地が厚い Gemma 4 から始めるか、エージェント能力の高い Muse に日本語知識を補うか。Muse はツール呼び出し・長いタスクの遂行・form-following がすでに高水準であり、それらの能力を一から構築するより、追加学習で日本語知識を補う方が低コストではないか、というのが個人的な見立てだ。ただし、日本語知識の下地が足りず苦戦する可能性も同じくらいある。ザッカーバーグは Muse Spark 1.2 の重み公開も予告しており、この議論はそちらが出ればもう一段動くはずだ。
測定条件の記録
| 項目 | 値 |
|---|---|
| ハード | DGX Spark GB10 / 128GB unified / 帯域 273GB/s |
| llama.cpp | b10423（Muse 対応は b10353 が初出）/ CUDA / Q4_K_M + mmproj + DFlash ドラフタ（GGUF） |
| llama.cpp 起動 | -ngl 99 -fa on -c 32768 --parallel 32 --jinja |
| DFlash 有効時 | -md <dflash>.gguf --spec-type draft-dflash --spec-draft-n-max 15 --spec-draft-ngl all |
| vLLM |
vllm/vllm-openai:muse-glimmer + Inferact/Muse-Glimmer-30B-NVFP4-W4A4（25.42GB）/ FlashInferCutlassNvFp4LinearKernel 確認済み |
| vLLM × DFlash（v1.1） | 公式ドラフタ meta-models/Muse-Glimmer-30B-assistant / --speculative-config method=dflash, num_speculative_tokens=15 / c=1〜32（2026-08-22 測定）。DFlash 2（incoai）は現行イメージ未対応で未測定 |
| vLLM 比較2モデル | Qwen3.8 NVFP4 / Gemma4-31B NVFP4 を同一イメージで再測定（2026-08-18） |
--max-num-seqs |
測定する並列数に一致（c=8 は監査後に再測定。差は3モデルとも1%未満） |
| プロンプトキャッシュ | 無効（--cache-ram 0 --no-cache-idle-slots） |
| Gemma4-31B |
--chat-template-file で同梱テンプレートを明示指定 |
| サンプリング | temperature 1.0 / top_p 0.95 / top_k 64（Meta 公式推奨。greedy は公式非推奨） |
| クライアント |
vllm bench serve / ShareGPT_V3 200 prompts（全バックエンド共通） |
| ②JamC-QA | 2,309問 / 3-shot / 4択一致 / DFlash ON / max_tokens=2048
|
| ③Aider Polyglot | 225題 / DFlash ON / reasoning strength high / max_tokens=8192 / 16,384 tok/slot / サーバ8並列 |
| ④VLM | 13タスク / DFlash ON / max_tokens=2048 / -c 16384 --parallel 1
|
生データ・判断ログは GitHub リポジトリに公開予定。
更新履歴
- 2026-08-23 v1.1: vLLM × DFlash（公式ドラフタ）c=1〜32 を追測。§3-6 全面更新、§4 に実装間の採用率比較を追記、TL;DR 更新
- 2026-08-22 v1.0: 初版公開