はじめに

2026年8月、Meta Superintelligence Lab から Muse Glimmer 30B が Apache 2.0 でリリースされました。「ローカルのエージェント用途に最適化された 30B のマルチモーダルモデル」という位置づけで、vLLM は day-0 でサポートしています。

公式のリファレンス環境は DGX Spark や GB300 などの大容量メモリ機ですが、本記事では 手元の RTX 4090 24GB × 4枚（WSL2 + Docker）で BF16 フル精度を動かす ところまでを扱います。

公式が想定していない構成なので、そのままではハマります（実際に3回止まりました）
並列方式・並列数・バッチ設定を変えて実測し、最終的なパラメータを決めるまでを全部載せます
起動スクリプトはそのままコピーして使える形で置いてあります

同じ構成の方はもちろん、24GB クラスのカードを複数枚持っている方の参考になれば幸いです。

1. Muse Glimmer 30B とは

1.1 モデル概要

まず公式情報を整理します。

項目	内容
開発	Meta Superintelligence Lab
リリース	2026年8月
ライセンス	Apache 2.0
総パラメータ数	約 29.6B（Vision encoder 含む）
アーキテクチャ	Dense Causal Transformer + Perception Encoder
層数	52
Hidden dimension	6656
Attention パターン	[Local, Local, Local, Global] の繰り返し
Sliding window	2048
Attention heads (Q / KV)	32 / 2（GQA 比 16:1）
Head dimension	128
FFN	SwiGLU、中間次元 19,968
Vision encoder	ViT-G/14 約 1.8B（50層、width 1536、patch size 14）
語彙サイズ	202,048
コンテキスト長	131,072+
入出力	入力: テキスト + 画像 / 出力: テキスト
知識カットオフ	2026年1月4日
BF16 チェックポイント	59.58 GB

Muse Spark からの蒸留で作られており、自律的なエージェントタスク に主眼が置かれています。公式が挙げている強みは以下のとおりです。

エンドツーエンドのタスク遂行: DeepSearch QA、MCP-Atlas、𝛕3-Bench、SWE-Bench などのフルタスク系ベンチで高いスコア
確実なツール呼び出し: 長いワークフローでも正確なスキーマでツールを呼べる
多段推論: 長い時間軸にわたって一貫した計画を保持
失敗からの復帰: ツール呼び出しが失敗した際に、停止せず原因を診断して再試行する
マルチモーダル: 専用の Perception Encoder により、スクリーンショット・グラフ・文書を会話の中で解釈できる
推論強度の制御: low / medium / high / xhigh の4段階を選べる
多言語: 100言語以上のデータで学習

1.2 ベンチマークスコア（公式）

同クラスの Gemma4-31B / Qwen3.6-27B との比較で、公式が公開している数値の抜粋です。

カテゴリ	ベンチマーク	Muse Glimmer-30B	Gemma4-31B	Qwen3.6-27B
エージェント	MCP Atlas (Public)	75.5	54.2	62.5
エージェント	DeepSearch QA	74.6	61.7	71.1
エージェント	Gaia2	43.3	36.4	40.0
コーディング	SWE-Bench Verified	76.0	66.6	77.2
コーディング	SWE-Bench Pro	51.2	36.9	50.2
マルチモーダル	MMMU Pro	74	73	75
マルチモーダル	OmniDocBench v1.5	75.8	72.5	77.8
マルチモーダル	Charxiv Reasoning	78.8	77.7	78.4
一般	AIME 2026	94.7	89.2	94.1
一般	GPQA Diamond (AA)	83.5	85.7	84.2

日本語の文書 OCR 用途で気になる OmniDocBench v1.5 は 75.8。トップではありませんが、30B クラスとしては十分な水準です。

1.3 ローカル実行のための工夫

このモデルの面白いところは、最初から「手元のGPUで動かすこと」を前提に設計されている点です。

4bit 量子化前提の設計

公式は重みを約4bit に圧縮したバリアントを配布しており、言語モデル部分を 20GB 以下に収めています。これにより KV キャッシュ・Perception Encoder・投機デコード用ドラフタを含めて 24GB / 32GB の枠に収まる、という設計になっています。

	Full Precision	K-Quant-Dynamic	K-Quant-17GB
劣化率	-	0.2%	1.0%
想定ハード	64GB VRAM	32GB VRAM	24GB VRAM

DFlash による投機デコード

Muse Glimmer には DFlash という block-diffusion ベースの軽量ドラフタが付属します。1トークンずつではなく 16トークンのブロックを1回の forward でまとめて予測 し、本体が並列に検証する方式です。

公式の実測値：

GPU	投機なし (tok/s)	DFlash あり (tok/s)	高速化
RTX 5090	74.9	233.4	3.1x
Apple M4 Max	23.7	37.8	1.5x
Apple M5 Max	26.6	50.2	1.8x

なお本記事の構成では DFlash は使いません。理由は後述します。

1.4 出力フォーマットが特殊

ここが実運用で一番重要です。 Muse Glimmer は JSON形式のツール呼び出しを出力せず、推論を <think> タグで囲むこともしません。すべてのターンが channel-scoped なメッセージ列として書かれます。

to=self<|message|>...chain of thought...<|eom|>
<|start|>assistant to=<tool><|message|><atem:function_calls>
<atem:invoke name="<tool>">
<atem:parameter name="<arg>">value</atem:parameter>
</atem:invoke>
</atem:function_calls><|eom|>
<|start|>assistant to=user<|message|>...final answer...<|eot|>

このため vLLM では --tool-call-parser muse_glimmer と --reasoning-parser muse_glimmer を必ずセットで指定 します。reasoning parser 側が skip_special_tokens=False を強制するので、片方だけだとマーカーが除去されて2つのチャンネルが content に混ざってしまいます。

1.5 推奨サンプリングパラメータ

公式推奨は以下です。

temperature = 1.0
top_p       = 0.95
top_k       = 64

推論モデルなので greedy（temperature 0）は非推奨とされています。推論強度は system prompt に Reasoning strength: high のような行を入れて指定します。コーディングやエージェント用途では high か xhigh が推奨です。

2. 検証環境

項目	内容
GPU	NVIDIA GeForce RTX 4090 24GB × 4
GPU 接続	PCIe のみ（NVLink なし、P2P 非対応）
OS	Windows + WSL2 (Ubuntu)
ドライバ	591.86 / CUDA 13.1
ホストRAM	WSL2 に約 114GB 割り当て
コンテナ	Docker（nvidia runtime 有効）
イメージ	`vllm/vllm-openai:muse-glimmer`
vLLM	0.1.dev19075+gd89ec6d6a

重要な前提：コードはまだ main にマージされていない

執筆時点で、Muse Glimmer の vLLM 対応 PR（vllm-project/vllm#51655）は まだ open です。ただし公式が専用タグの Docker イメージ vllm/vllm-openai:muse-glimmer を配布しているので、そちらを使えばビルド不要で動きます。

3. 事前準備

3.1 GPU を空ける

TP（テンソル並列）は4枚の空きメモリが揃っている必要があります。他のコンテナが1枚でも掴んでいると起動しません。

nvidia-smi
docker ps

私の環境では別プロジェクトの OCR コンテナが GPU3 で 17GB 使っていました。自動起動を止めます。

docker update --restart=no <container-name>
docker stop <container-name>

3.2 WSL2 のメモリ確認

BF16 で約 60GB のチェックポイントを読み込むので、ホスト側のメモリが足りないとロード中に固まります。

free -g

足りない場合は Windows 側の C:\Users\<user>\.wslconfig を編集して wsl --shutdown します。

[wsl2]
memory=64GB
swap=32GB

3.3 モデルのダウンロード

pip install -U "huggingface_hub[cli]"
hf download meta-models/Muse-Glimmer-30B \
  --local-dir /root/HuggingFaceCache/Muse-Glimmer-30B

約 60GB です。WSL2 の場合、/mnt/c/...（9p 経由の Windows 側）ではなく /root/...（ext4）に置いてください。読み込み速度が段違いです。

4. ハマりどころ

先に、実際に踏んだ地雷を共有します。ここを飛ばすと3回止まります。

4.1 NVFP4 は Ada 世代では動かない

界隈の記事で NVFP4 量子化版の話をよく見かけますが、NVFP4 のカーネルは Blackwell 専用 です。RTX 4090 は Ada（compute capability 8.9）なので使えません。

今回は BF16 フル精度をそのまま使います。TP=4 なら 24GB × 4 に収まります。

4.2 `RuntimeError: UVA is not available`（WSL2 固有）

最初の起動でこれが出ました。

File "vllm/v1/worker/gpu/buffer_utils.py", line 47, in __init__
    raise RuntimeError("UVA is not available")
RuntimeError: UVA is not available

原因: WSL2 では is_pin_memory_available() が環境変数 VLLM_WSL2_ENABLE_PIN_MEMORY を参照し、デフォルトが 0 になっています（WSL2 では pinned memory に固定オーバーヘッドがあるためオプトイン化された経緯があります）。その結果 UVA が使えないと判断されるのですが、V2 Model Runner は初期化時に無条件で UVA バッファを確保するためクラッシュします。

vLLM の issue #47387 / #47292 として報告済みで、フォールバックを入れる PR #47579 はまだマージされていません。

対処: 環境変数を1つ足すだけです。

-e VLLM_WSL2_ENABLE_PIN_MEMORY=1

代替として VLLM_USE_V2_MODEL_RUNNER=0（V1 Model Runner にフォールバック）もありますが、Muse Glimmer の PR には mrv2（Model Runner V2 specific）ラベルが付いており V2 前提で検証されているようなので、pin memory を有効にして V2 を維持する方を選びました。

4.3 起動ログに出る警告（無視してよいもの）

SymmMemCommunicator: Device capability 8.9 not supported

→ Ada にはこの機能がないだけ。想定内。

Custom allreduce is disabled because it's not supported on more than two PCIe-only GPUs

→ 4090 は P2P 非対応なので PYNCCL バックエンドが選ばれます。動作に問題はありませんが、通信は遅くなります。

Auto-initialization of reasoning token IDs failed.
Please check whether your reasoning parser has implemented
the `reasoning_start_str` and `reasoning_end_str`.

→ Muse Glimmer の推論は開始/終了マーカーではなく channel 構造で区切られるため、そもそも実装されていません。パース自体は正常に動きます。

Multi-modal warmup failed
Readonly multi-modal warmup failed

→ ダミー入力でのウォームアップに失敗しているだけで、実際の画像入力は正常に動作しました（後述）。

5. 起動スクリプト

最終形です。~/myvllm/muse_glimmer_vllm.sh として保存し chmod +x してください。

#!/usr/bin/env bash
set -euo pipefail

MODEL_DIR="${MODEL_DIR:-/root/HuggingFaceCache/Muse-Glimmer-30B}"
IMAGE="${IMAGE:-vllm/vllm-openai:muse-glimmer}"
SERVED_MODEL_NAME="${SERVED_MODEL_NAME:-muse-glimmer}"
PORT="${PORT:-8000}"
API_KEY="${API_KEY:-sk-dummy}"

# Fixed 4-GPU setup. BF16 weights are ~60GB, TP=4 is mandatory.
GPU_DEVICES="${GPU_DEVICES:-3,2,1,0}"
TP_SIZE="${TP_SIZE:-4}"

# Model is trained at 128K, but 4x24GB leaves little room after weights.
MAX_MODEL_LEN="${MAX_MODEL_LEN:-65536}"

# 4 x RTX 4090 24GB. GPU0 also drives the display, so leave headroom.
GPU_MEMORY_UTILIZATION="${GPU_MEMORY_UTILIZATION:-0.88}"

MAX_NUM_SEQS="${MAX_NUM_SEQS:-16}"
MAX_NUM_BATCHED_TOKENS="${MAX_NUM_BATCHED_TOKENS:-8192}"

# Muse Glimmer takes image input only (no audio).
LIMIT_MM_PER_PROMPT="${LIMIT_MM_PER_PROMPT:-{\"image\":3}}"

ENABLE_TOOL_CALL="${ENABLE_TOOL_CALL:-true}"
ENABLE_PREFIX_CACHING="${ENABLE_PREFIX_CACHING:-true}"

if [ ! -d "${MODEL_DIR}" ]; then
  echo "ERROR: model directory not found: ${MODEL_DIR}"
  exit 1
fi

VLLM_ARGS=(
  --model /models/Muse-Glimmer-30B
  --served-model-name "${SERVED_MODEL_NAME}"
  --tensor-parallel-size "${TP_SIZE}"
  --max-model-len "${MAX_MODEL_LEN}"
  --gpu-memory-utilization "${GPU_MEMORY_UTILIZATION}"
  --max-num-seqs "${MAX_NUM_SEQS}"
  --max-num-batched-tokens "${MAX_NUM_BATCHED_TOKENS}"
  --limit-mm-per-prompt "${LIMIT_MM_PER_PROMPT}"
  --generation-config auto
  --api-key "${API_KEY}"
  --host 0.0.0.0
  --port "${PORT}"
  --kv-cache-memory 3879561728
)

if [ "${ENABLE_PREFIX_CACHING}" = "true" ]; then
  VLLM_ARGS+=(--enable-prefix-caching)
fi

# Muse Glimmer emits channel-scoped reasoning and ATEM (XML-style) tool calls,
# not JSON. Both parsers key off the same framing and must be used together.
# No --chat-template: the checkpoint ships its own.
if [ "${ENABLE_TOOL_CALL}" = "true" ]; then
  VLLM_ARGS+=(
    --enable-auto-tool-choice
    --reasoning-parser muse_glimmer
    --tool-call-parser muse_glimmer
  )
fi

docker run --rm -it \
  --name muse-glimmer-vllm \
  --gpus "\"device=${GPU_DEVICES}\"" \
  --network host \
  --ipc=host \
  --shm-size 32g \
  --ulimit memlock=-1 \
  --ulimit stack=67108864 \
  -v "${MODEL_DIR}:/models/Muse-Glimmer-30B:ro" \
  -e CUDA_DEVICE_ORDER=PCI_BUS_ID \
  -e CUDA_VISIBLE_DEVICES=0,1,2,3 \
  -e PYTORCH_NVML_BASED_CUDA_CHECK=1 \
  -e VLLM_WSL2_ENABLE_PIN_MEMORY=1 \
  -e TRANSFORMERS_OFFLINE=1 \
  -e HF_DATASETS_OFFLINE=1 \
  -e HF_HUB_OFFLINE=1 \
  -e HF_HOME=/root/HuggingFaceCache \
  -e HUGGINGFACE_HUB_CACHE=/root/HuggingFaceCache \
  -e VLLM_WORKER_MULTIPROC_METHOD=spawn \
  -e NCCL_P2P_DISABLE=1 \
  -e NCCL_IB_DISABLE=1 \
  -e NCCL_SHM_DISABLE=0 \
  "${IMAGE}" \
  "${VLLM_ARGS[@]}"

各設定の意図

設定	理由
`--tensor-parallel-size 4`	BF16 60GB を4枚に分散。この構成では必須
`--gpu-memory-utilization 0.88`	GPU0 は Windows の画面出力にも使われるため余裕を持たせる
`--kv-cache-memory 3879561728`	起動ログが提案してきた値。一番厳しい GPU0 基準で4枚を揃える
`--generation-config auto`	公式 recipe に含まれる。`generation_config.json` のサンプリング設定を採用する
`--reasoning-parser` / `--tool-call-parser`	前述のとおり必ずセットで
`VLLM_WSL2_ENABLE_PIN_MEMORY=1`	WSL2 の UVA エラー回避
`NCCL_P2P_DISABLE=1`	4090 はハードウェアとして P2P 非対応
`--trust-remote-code` を付けない	このイメージではネイティブサポートされているため不要
`--chat-template` を指定しない	チェックポイント同梱のものが使われる

起動時の実測メモリ（TP=4）

Free memory on device (22.26/23.99 GiB) on startup.
Actual usage is 16.58 GiB for consumed memory (weights + non-torch),
1.39 GiB for peak activation, and 0.19 GiB for CUDAGraph memory.
Current kv cache memory in use is 3.14 GiB.

初回起動は torch.compile を含めて約79秒（うちコンパイル約59秒）。2回目以降はキャッシュが効いて速くなります。

6. 動作確認

6.1 テキスト

curl -s localhost:8000/v1/chat/completions \
  -H "Authorization: Bearer sk-dummy" \
  -H "Content-Type: application/json" -d '{
  "model": "muse-glimmer",
  "messages": [
    {"role": "system", "content": "Reasoning strength: high"},
    {"role": "user", "content": "RAG について日本語で説明してください。"}
  ],
  "temperature": 1.0, "top_p": 0.95, "top_k": 64, "max_tokens": 512
}'

6.2 画像入力

起動時に Multi-modal warmup failed が出ますが、実際に画像を投げると正常に動きます。

curl -s localhost:8000/v1/chat/completions \
  -H "Authorization: Bearer sk-dummy" \
  -H "Content-Type: application/json" -d '{
  "model": "muse-glimmer",
  "messages": [{"role": "user", "content": [
    {"type": "image_url", "image_url": {"url": "https://llava-vl.github.io/static/images/view.jpg"}},
    {"type": "text", "text": "この画像には何が写っていますか？"}
  ]}],
  "max_tokens": 300
}'

640px の画像1枚で prompt_tokens は約 928 でした。モデルカードによれば 1画像あたり最大 4096 の visual token を消費するので、高解像度の文書画像を扱う場合はコンテキスト消費に注意が必要です。

レスポンスでは推論部分が reasoning フィールドに分離されて返ってきます。parser が正しく機能している証拠です。

7. ベンチマーク

vLLM 付属のベンチツールを使います。API キーを設定している場合は環境変数で渡します。

docker exec -it -e OPENAI_API_KEY=sk-dummy muse-glimmer-vllm \
  vllm bench serve \
  --backend openai-chat \
  --base-url http://localhost:8000 \
  --endpoint /v1/chat/completions \
  --model muse-glimmer \
  --dataset-name random \
  --random-input-len 1024 \
  --random-output-len 256 \
  --num-prompts 32 \
  --max-concurrency 8

7.1 同時実行数による違い

入力 1024 / 出力 256 トークン、--max-num-batched-tokens 8192 固定。

同時実行数	出力スループット	TPOT	TTFT 中央値	ITL P99
4	119 tok/s	31.0 ms	489 ms	210 ms
8	210 tok/s	32.8 ms	910 ms	225 ms
16	337 tok/s	37.7 ms	2701 ms	464 ms

考察

4 → 8 でスループットが 1.77 倍になるのに対し、TPOT の悪化はわずか 1.8ms。ほぼ無料の改善です
8 → 16 ではスループットは伸びるものの、TTFT が3倍、ITL P99 が2倍に悪化します
同時実行 8 前後がスイートスポット。ただし --max-num-seqs は 16 のままにしておき、バースト時の受け皿として残しています

TPOT が 31ms（単発で約32 tok/s）というのは、この構成としては妥当な数字です。理論上は各GPUが1ステップあたり約15GBの重みを読むので、4090 の帯域（約1TB/s）から60 tok/s 程度が上限。実測32ということは、PCIe 経由の allreduce がおよそ半分を持っていっている 計算になります。

7.2 `--max-num-batched-tokens` の影響

同時実行 8 固定で3水準を比較しました。

	4096	8192	16384
出力スループット	211.3	210.6	208.8
TPOT	33.1 ms	32.8 ms	33.4 ms
TTFT 中央値	963 ms	910 ms	1247 ms
ITL P99	419 ms	225 ms	419 ms

結論：この負荷では有効なチューニング対象ではありませんでした。

当初は「値を大きくすれば長いプロンプトの TTFT が改善するはず」と考えていましたが、逆に悪化しました。入力が1024トークンだと そもそも chunked prefill が発動しません（8192 の枠に8件分の prefill が丸ごと入る）。枠を広げても分割が減るわけではなく、1ステップに詰め込む prefill が増えて各ステップが重くなるだけ、というのが理由です。

なお 16K 入力での追試も行いましたが、--enable-prefix-caching が効いて TTFT 中央値が 107ms などという値になり、比較になりませんでした（コールドな値は P99 の約6.4秒）。実運用では prefix caching は有効にしておく前提なので、そこまで追い込む価値は薄いと判断しました。

7.3 Pipeline Parallel は 24GB カードでは使えない

「PCIe の allreduce が半分持っていく」なら、層ごとの全体同期が不要な PP（パイプライン並列）はどうか、と考えて試しました。結果は 起動失敗 です。

Model loading took 20.56 GiB    ← 4ランクすべて同じ値

TP=4 のときは 16.58 GiB/枚でした。PP のほうがメモリを食っています。

パラメータ数から逆算すると理由が見えます。

decoder 13層 ≈ 5.9B → 11.9 GB
ViT-G/14 vision encoder 1.8B → 3.6 GB
embedding（202048 × 6656）→ 2.7 GB
lm_head → 2.7 GB
合計 20.9 GB ≒ 実測 20.56 GB

つまり vision encoder・embedding・lm_head が各 PP ランクに複製 され、decoder 層だけが分割されている状態です。TP なら vision tower も embedding も次元方向に4分割されるので、素直に1/4強に収まります。

20.56（重み）+ 3.61（KV）+ 1.4（activation）+ 0.2（CUDA graph）= 25.8 GB > 24 GB となり、KV キャッシュ確保時に OOM します。

一方で、崩れる直前にこんなログも出ていました。

GPU KV cache size: 318,961 tokens
Maximum concurrency for 65,536 tokens per request: 4.87x

同じ 3.61GiB でも PP のほうが KV 容量は圧倒的に大きい（各カードが13層分の KV しか持たないため）。48GB クラスのカードなら PP のほうが有利になる可能性が高い ということです。24GB では複製分のオーバーヘッドに負けます。

8. 最終的なパラメータ

パラメータ	値	決定理由
並列方式	TP=4	PP は 24GB カードでは OOM
`--max-model-len`	65536	128K は KV が足りない。64K で実用上十分
`--gpu-memory-utilization`	0.88	GPU0 の画面出力分の余裕
`--kv-cache-memory`	3879561728	起動ログの提案値、最も厳しいカード基準
`--max-num-seqs`	16	バースト受け皿。実運用の推奨同時実行は8前後
`--max-num-batched-tokens`	8192	3水準の比較で最良。encoder cache 予算とも連動
`--limit-mm-per-prompt`	`{"image":3}`	要件が3枚。増やしても得はない

補足：画像枚数と encoder cache

起動ログにこんな行があります。

Encoder cache will be initialized with a budget of 8192 tokens

この予算は --max-num-batched-tokens に連動しています。1画像あたり最大 4096 visual token なので、8192 なら最大サイズの画像2枚分。ここを 4096 に下げると1枚分しか入らなくなり、複数画像のリクエストで不利になります。画像を複数枚扱う場合、--max-num-batched-tokens を下げすぎないでください。

9. DFlash（投機デコード）について

単発 32 tok/s をさらに上げたいなら、本命は投機デコードです。ただし現時点では見送りました。

公式イメージには DFlash のドラフタ登録が入っておらず、Model architectures ['DFlashMuseGlimmerAssistantModel'] are not supported で起動しません
修正パッチは存在しますが（xianbaoqian/vllm#1）、自前でイメージをビルドする必要があります
そのパッチの作者自身が「reference 実装はブロック内のマスクを非因果的に構築しているのに、vLLM 側は因果的として扱っており、この不一致はサイレントに受理率を下げる（エラーは出ず、出力も正しいまま）」と指摘しています

つまり今ビルドしても公式が謳う3倍の数字は出ません。PR #51655 が main にマージされるのを待って、リリース版イメージに --speculative-config を1行足す のが賢明だと判断しました。

なお使う際の注意として、num_speculative_tokens は 15 が固定値です（ブロックサイズ16のうち slot 0 が直前の確定トークンの再提示に使われるため、予測に使えるのは15枠）。チューニング対象ではないので 16 などに変更しないでください。

10. まとめ

RTX 4090 24GB × 4枚（WSL2 + Docker）で Muse Glimmer 30B の BF16 フル精度が動きます
WSL2 では VLLM_WSL2_ENABLE_PIN_MEMORY=1 が必須。これがないと UVA is not available で起動しません
NVFP4 は Blackwell 専用なので Ada では使えません
実測性能は 同時実行8で 210 tok/s、単発 TPOT 約33ms（約32 tok/s）
PCIe 接続（P2P なし）では allreduce が性能の約半分を消費します。ただし PP に逃げようとしても、24GB では vision encoder / embedding / lm_head の複製で OOM します
--max-num-batched-tokens は 8192 のままで問題ありません。画像を複数枚扱うなら下げないこと

日本語文書の OCR 用途としても、BF16 の ViT-G/14 をそのまま使えるのは GGUF 経由の vision projector 変換を気にしなくてよい点で有利です。この観点での比較検証はまた別記事で書こうと思います。

参考リンク