［開発者向け］Metaのオープンウェイトモデル「Muse Glimmer」をローカルで動かす——入手からプロンプト設計・高速化まで

2026-08-11

はじめに

　Metaが2026年8月、Muse Sparkから蒸留したオープンウェイトのマルチモーダルモデル「Muse Glimmer」を公開しました。Apache 2.0で重みが配布され、手元の機材で動かせる設計です。本稿では公式ドキュメントとモデルカードをもとに、入手から高速化までの手順を解説します。

参考記事

メイン記事:

タイトル: Muse Glimmer
発行元: Meta
発行日: 2026年8月
URL: https://dev.meta.ai/docs/muse-glimmer

要点

Muse Glimmerは、Muse Sparkの出力から蒸留された総パラメータ約296億のマルチモーダルモデルであり、重みはApache 2.0ライセンスで公開されている
テキストと画像を入力として受け取り、既定で12万8000トークンのコンテキストを扱う。学習データは100を超える言語を含む
約4ビットへの量子化により言語モデル部分は20GB未満に収まり、24GBまたは32GBのVRAM環境での実行が想定されている
DFlashと呼ばれる補助モデルを使った投機的デコーディングに対応し、Metaの計測ではNVIDIA RTX 5090で毎秒74.9トークンから233.4トークンへ、3.1倍の高速化が記録された
実行環境としてvLLM、llama.cpp、ExecuTorchの3系統に対応し、OllamaやLM Studioなどもローンチ時点のエコシステムに含まれる

詳細解説

Muse Glimmerとは——Muse Sparkからの蒸留モデル

　Muse Glimmerは、Metaが公開した密結合型（Dense）のマルチモーダル言語モデルです。Metaの説明によれば、ゼロから学習したのではなく、上位モデルであるMuse Sparkの出力を教師データとして学習する「蒸留（distillation）」という手法で作られています。蒸留とは、大きなモデルの振る舞いを小さなモデルに写し取る学習方法で、性能をある程度保ったままサイズを縮める目的で使われます。

　MetaのMuse Spark 1.1は7月に発表されており、Muse Glimmerはその系譜に連なるモデルにあたります。上位モデルがクラウドAPI中心の提供だったのに対し、重みそのものが配布され、ネットワーク接続なしで手元の機材だけで動かせる点が設計上の軸になっていると考えられます。ライセンスはApache 2.0で、フル精度（BF16）の重み、2種類の4ビット量子化済み重み、後述するDFlash用のドラフトヘッド、視覚エンコーダのすべてが同じ条件で配布されています。

アーキテクチャと基本仕様

　モデルカードによれば、総パラメータは約296億で、これには視覚を担当する知覚エンコーダ（Perception Encoder、約18億パラメータのViT-G/14）が含まれます。言語モデル部分は隠れ次元6656、52層で、注意機構は「Local, Local, Local, Global」の繰り返しパターンを採用し、局所層のスライディングウィンドウは2048トークンです。注意ヘッドはクエリ32・キーバリュー2のGQA（Grouped Query Attention、複数のクエリヘッドでキーとバリューを共有してメモリを節約する仕組み）で、比率は16対1になっています。

　語彙数は20万2048トークン、コンテキスト長は13万1072トークン以上、知識のカットオフは2026年1月4日と記載されています。入出力は「入力: テキスト＋画像、出力: テキスト」で、音声には対応していません。なお、公式ドキュメント側はコンテキストを「既定128Kトークン」と表現しており、モデルカードの記載と粒度が揃っていない点には注意が必要です。

前提条件とモデルの入手

　Metaのドキュメントが挙げている前提条件は、Python 3.10以降、huggingface_hub のCLI（コマンドラインインターフェース。ターミナルから文字で操作するツール）、そしてMuse GlimmerのリポジトリにアクセスできるHugging Faceアカウントの3点です。

　まず、Pythonのバージョンを確認します。

# インストール済みPythonのバージョンを表示するコマンドです
python --version

　次に、pip（Pythonのパッケージ管理ツール）でダウンロード用のツールを導入します。

# huggingface_hub をインストールします。CLIコマンドも同時に入ります
pip install huggingface_hub

　注意: 複数のプロジェクトでライブラリのバージョンが衝突しないよう、仮想環境（venvなど）を作ってからインストールすると既存環境を壊さずに済みます。

　準備ができたら、重みをダウンロードします。

# Muse Glimmer 30B の重み一式をダウンロードします
# --local-dir で保存先フォルダを指定しています
huggingface-cli download meta-models/Muse-Glimmer-30B --local-dir ./muse-glimmer-30b

　Metaによれば、リポジトリにはsafetensors形式の重み、トークナイザ、チャットテンプレート、画像の前処理設定が含まれ、テキストと画像の両方を扱うために必要なファイルが揃っています。ダウンロード後は次のコマンドでファイルの整合性を確認し、出力値をリポジトリの README.md に記載されたチェックサムと突き合わせます。

# ダウンロードした重みファイルのSHA-256ハッシュ値を計算します
sha256sum muse-glimmer-30b/model-*.safetensors

ハードウェアに応じたバリアントの選択

　Metaは用途別に3つのバリアントを示しています。単一GPUのサーバやワークステーションであればBF16のチェックポイント、量子化してローカルで動かすならGGUF形式（llama.cppやExecuTorchで扱える量子化フォーマット）の成果物、投機的デコーディングを使う場合は別途配布されるドラフト用チェックポイントを組み合わせる形です。

　量子化については具体的な劣化率が示されています。重みを約4ビット精度まで圧縮すると言語モデル部分は20GB未満に収まり、K-Quant-Dynamicでは平均0.2%、K-Quant-17GBでは1.0%の性能低下にとどまったとされています。想定ハードウェアはそれぞれ32GB VRAM、24GB VRAMで、フル精度は64GB VRAM相当です。この数値は15種類のベンチマークにおける精度指標の平均値と注記されています。

　1%前後という劣化は、KVキャッシュや視覚エンコーダ、投機的デコーディング用のドラフトモデルを同時に載せる余裕を確保する対価と考えると、実用上は許容しやすい水準だと考えられます。

プロンプト設計——チャットテンプレートと推論強度

　Muse Glimmerは役割マーカーを明示する構造化チャットテンプレートを使います。Metaのドキュメントは、プロンプト文字列を手で組み立てず、トークナイザ内蔵の apply_chat_template を使うよう繰り返し推奨しています。特殊トークンや発話の区切りを自動で挿入してくれるためです。

# トークナイザを読み込み、チャット形式のプロンプトを組み立てるコードです
from transformers import AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("meta-models/Muse-Glimmer-30B")

messages = [
    {"role": "system", "content": "You are a helpful assistant."},
    {"role": "user", "content": "Explain speculative decoding in two sentences."},
]

# tokenize=False で文字列のまま確認できます
# add_generation_prompt=True は「ここから生成せよ」という合図を末尾に付けます
prompt = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
print(prompt)

<|begin_of_text|><|start|>system<|message|>You are a helpful assistant.

Reasoning strength: high.

# Valid recipients: "self", "user".<|eot|><|start|>user<|message|>Explain speculative decoding in two sentences.<|eot|><|start|>assistant

　Muse Glimmerは推論（reasoning）モデルとして設計されており、最終回答の前に assistant to=self というターンで自分向けの思考を書き出し、その後に利用者向けの回答を別ターンで出力します。この挙動はプロンプトで誘導するものではなく、形式に組み込まれています。思考量は reasoning_strength で制御でき、xhigh high medium low の4段階（既定は high）が用意されています。

# 推論の強さを medium に落として、生成時間を抑える例です
prompt = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True,
    reasoning_strength="medium",
)

　注意: 思考の連鎖は数千トークン規模になることがあるとMetaは説明しています。max_tokens を小さく設定しすぎると、最終回答に到達する前に生成が打ち切られます。推論を伴う処理では上限に余裕を持たせ、ストリーミングを有効にしてリクエストのタイムアウトを避けることが推奨されています。サンプリング設定は、temperature 1.0、top_p 0.95、top_k 64が推奨値です。

ツール呼び出しとマルチモーダル入力

　ツール呼び出しには、ATEMと呼ばれる独自形式が使われます。OpenAI形式の関数スキーマを tools 引数として渡すと、テンプレートがシステムターンにツール一覧を書き込みます。

# 天気を取得する関数をツールとして定義する例です
tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get the current weather for a city.",
            "parameters": {
                "type": "object",
                "properties": {"city": {"type": "string"}},
                "required": ["city"],
            },
        },
    }
]

# tools を渡すと、ツールカタログがプロンプトに組み込まれます
prompt = tokenizer.apply_chat_template(
    messages, tokenize=False, add_generation_prompt=True, tools=tools
)

　モデルは assistant to=get_weather というターンでATEMブロックを出力し、結果を tool ロールのメッセージとして返すと会話が続きます。Metaの説明では、Muse Glimmerは1ターンにつき1つのツール呼び出しのみに対応し、並列呼び出しには対応していません。もっとも、vLLMやllama.cppのOpenAI互換サーバ経由で使う場合はサーバ側がATEMを解釈して標準的な tool_calls に変換するため、開発者がATEM形式を直接扱う場面は限られると考えられます。

　画像を渡す場合は、トークナイザ単体ではなく AutoProcessor を使います。画像の前処理はトークナイザの担当範囲外だからです。

# 画像とテキストを同時に渡すコードです
from transformers import AutoProcessor

processor = AutoProcessor.from_pretrained("meta-models/Muse-Glimmer-30B")

messages = [
    {
        "role": "user",
        "content": [
            {"type": "image", "url": "https://example.com/chart.png"},
            {"type": "text", "text": "What trend does this chart show?"},
        ],
    }
]

# return_tensors="pt" は PyTorch のテンソル形式で返す指定です
inputs = processor.apply_chat_template(
    messages, add_generation_prompt=True, tokenize=True, return_tensors="pt"
)

　注意: Metaがつまずきやすい点として挙げているのは、テンプレートを使わず手でプロンプトを組む、画像を素のトークナイザに通す、add_generation_prompt=True を付け忘れる、max_tokens が小さすぎて思考が途中で切れる、の4点です。出力品質が想定より低い場合は、まずこの4点を確認するとよいと考えられます。

投機的デコーディングによる高速化

　投機的デコーディング（speculative decoding）は、小さなモデルに次のトークンを先読みさせ、本体モデルがまとめて検証することで生成を速める技術です。Metaは、出力が通常の自己回帰生成と数学的に同一であり、近似ではないと説明しています。長い思考を生成するMuse Glimmerとは相性がよい手法だと考えられます。

　方式は2つあります。専用の補助チェックポイントを使うDFlashと、追加の重みが不要なn-gramプロンプトルックアップです。後者はコードや構造化テキストのように、プロンプト内にすでに現れた並びを繰り返す出力で採択率が高くなります。DFlashを使う場合は、本体モデルと補助モデルを一緒に読み込みます。

# 本体モデルとDFlashドラフトモデルを両方読み込むコードです
from transformers import AutoModelForCausalLM, AutoProcessor

TARGET_MODEL_ID = "meta-models/Muse-Glimmer-30B"
ASSISTANT_MODEL_ID = "meta-models/Muse-Glimmer-30B-assistant"

processor = AutoProcessor.from_pretrained(TARGET_MODEL_ID)

# device_map="auto" で利用可能なGPUに自動配置します
target_model = AutoModelForCausalLM.from_pretrained(
    TARGET_MODEL_ID,
    dtype="auto",
    device_map="auto",
)
assistant_model = AutoModelForCausalLM.from_pretrained(
    ASSISTANT_MODEL_ID,
    dtype="auto",
    device_map="auto",
)

　追加の重みを使わないn-gram方式は、vLLMのサーバ起動オプションで指定できます。

# vLLMのOpenAI互換サーバをn-gram投機ありで起動します
# num_speculative_tokens は1回に先読みするトークン数です
python -m vllm.entrypoints.openai.api_server \
  --model meta-models/Muse-Glimmer-30B \
  --speculative-config '{"method": "ngram", "num_speculative_tokens": 5, "prompt_lookup_max": 4}' \
  --port 8000

　先読みトークン数は5から始め、コード生成のように採択率が高い処理では8〜10へ、多様性の高い生成では3〜4へ調整するとされています。効果が出るのは単一リクエストの応答速度であり、高スループットのバッチ処理では本体モデルの計算がすでにGPUを埋めているため効果が薄れる、という注意も添えられています。

　実測値はモデルカードに掲載されています。K-Quant-17GBモデルと量子化済みDFlashドラフタの組み合わせで、NVIDIA RTX 5090では毎秒74.9トークンから233.4トークン（3.1倍）、Apple M4 Maxでは23.7から37.8トークン（1.5倍）、M5 Maxでは26.6から50.2トークン（1.8倍）と報告されています。いずれもバッチサイズ1・貪欲デコーディングでの計測です。

ランタイムの選択と実行

　Metaは3つのランタイムを提示しています。本番運用で高いスループットを求める場合はvLLM（NVIDIA GPU、OpenAI互換HTTP）、ノートPCなどCPUとGPUを混在させる環境ではllama.cpp（CPU、NVIDIA/AMD GPU、Apple Metalに対応）、モバイルやエッジのオンデバイス実行にはExecuTorch（ARM CPU、Apple/Qualcomm/MediaTekのアクセラレータ）という整理です。いずれも同じ重み、あるいはその量子化版を読み込みます。

　ローンチ時のエコシステムには、AMD、Arm、Dell、Fireworks AI、Hugging Face、Intel、llama.cpp、LM Studio、NVIDIA、Ollama、OpenRouter、SGLangとRadixArk、Together AI、Unsloth、vLLMとInferactが挙げられています。OllamaやLM Studioのようにコマンドラインを使わずに扱えるツールが含まれている点は、導入のハードルを下げる要素になると考えられます。

ベンチマークと安全性評価

　モデルカードでは、Gemma4-31BおよびQwen3.6-27Bの思考モードとの比較が示されています。エージェント系ではMCP Atlas（公開版）が75.5で、Gemma4-31Bの54.2、Qwen3.6-27Bの62.5を上回りました。DeepSearch QAも74.6と両者を上回っています。コーディングではSWE-Bench Proが51.2、SWE-Bench Verifiedが76.0、推論系ではAIME 2026が94.7、AA-LCRが80.0と報告されています。

　一方、OSWorld-Verified（65.9対75.6）やTerminalBench 2.1（51.7対60.7）ではQwen3.6-27Bが上回っており、GPQA Diamondなどでも他モデルが上位に立つ項目があります。同一サイズ帯で全項目に勝る構図ではなく、エージェント的なタスク遂行に重心を置いた結果だと考えられます。

　安全性は、コンテンツ安全性、エージェント固有のリスク、プライバシー、Preparedness（化学・生物、サイバー、制御喪失）の4軸で評価されたとされています。MetaのAdvanced AI Scaling Framework（AAISF）における「Frontier AI」には該当しないものの、念のため評価を行い、いずれの領域も「Moderate以下」と判定されたと説明されています。Metaは、モデルを単体のエンドポイントとして使わずガードレールを備えたシステムの一部として展開すること、とくに実世界に作用する用途では取り消せない操作の前に人間の確認を挟むことを推奨しています。

制約と注意点

　制約も明記されています。動画向けには最適化されておらず、動画入力は個々のフレームとして処理されます。事前学習データに含まれるすべての言語で評価されたわけではなく、強くサポートされる言語以外では性能が落ちる可能性があるとされています。量子化推論では特殊なケースでフル精度との品質差が出ることがあり、18歳未満の利用者による利用は想定されていないとも記載されています。

　実装面では、1ターン1ツールという制約が、複数の外部呼び出しを並行させる設計と噛み合わない場面が出てくると考えられます。エージェントのループを組む際は、この直列性を前提にした設計を検討する必要がありそうです。

まとめ

　Muse Glimmerは、Muse Sparkからの蒸留、約4ビット量子化、DFlashによる投機的デコーディングを組み合わせ、消費者向けハードウェアでエージェント処理を完結させることを狙ったモデルだと考えられます。ローカル実行の環境構築は、量子化モデルをllama.cppで動かす手順の記事もあわせてご覧いただければと思います。