Meta「Muse Glimmer」無料開放、24GB VRAMで動く30Bエージェントの実力

この記事のまとめ

MetaのMuse Glimmerは、300億パラメータのオープンウェイトなエージェント向けモデルで、Apache 2.0で無償公開されました。手元のパソコンで動かせる点が最大の特徴で、クラウドを使わずに自分の環境でAIエージェントを組めます。要点は次のとおりです。

30Bパラメータのモデルが、4bit量子化で20GB未満に収まり、24GB VRAMのGPUで動きます。
Apache 2.0ライセンスで、商用利用も改変も無償で許されます。
ツール利用や失敗回復、画像入力に対応し、ローカルのエージェントやコーディング用途を想定しています。
ベンチマークではGemma4-31BやQwen3.6-27Bと項目ごとに勝敗が分かれます。

Muse Glimmerの概要と無料開放の位置づけ

Muse Glimmerとは

Muse Glimmerは、Metaが公開したローカル動作向けの生成AIモデルです。私が注目したのは、300億パラメータという規模のモデルを、手元のコンシューマGPUで動かせる点です。

Muse Glimmerは300億パラメータの因果言語モデルで、専用の知覚エンコーダを備え、Muse Sparkから蒸留してつくられたものです。常時ローカルで動くエージェント作業に最適化されており、MacやPCに単一のコンシューマ向けGPUを載せた構成でも動く小ささが特徴です（参照*1）。

多段の推論、ツール呼び出し、マルチモーダル理解、失敗からの復帰までを1つのモデルにまとめており、クラウドやネット接続を前提としない設計になっています（参照*2）。

一般的なチャット向けの汎用モデルとは違い、はじめから自律エージェントの現場作業に合わせて調整されている点が読みどころです。クラウドを経由しないため、情報を外に出したくない用途にも向く設計になっています。

Apache 2.0による無料開放の意味

Apache 2.0ライセンスの意味は、「無料で使える」という以上のものがあります。商用利用も改変も許可されており、社内プロダクトへの組み込みや派生モデルの開発が、ライセンス料なしに行えます。

Muse Glimmerは300億パラメータのオープンウェイト型モデルで、大規模なクラウドサーバーを経由せず、一般消費者向けのPCや単一のGPU上で直接動作します。開発者や企業はApache 2.0ライセンスに基づき、商用目的を含めて無償で利用でき、ローカル環境で独自のAIエージェントを構築できます（参照*3）。

Hugging Face上ではMuseから30Bに蒸留したうえでApache 2.0で公開されており、プライバシー確保やコスト削減、試作用途に向くとされ、コーディングや文書解析、個人アシスタント、ClawやHermesに似た構成での利用が想定されています（参照*4）。

ただし、無料開放とはいえライセンス文の遵守は必要です。商用製品に組み込むなら、社内配布や派生モデルの扱いをApache 2.0の条項に沿って整備しておくことを勧めます。後から確認して慌てるより、導入前に法務と確認しておくほうが現実的です。

Zuckerbergの声明と戦略的背景

MetaのAI戦略を読む上で、ザッカーバーグの発言は重要な文脈を与えます。

ザッカーバーグCEOは「未来はすべての人のために（The Future is for Everyone）」と題したマニフェストを発表し、少数の巨大企業や政府機関が高度なAIの管理権を独占するクローズド路線への懸念を示しました。対抗策として、AIモデルを広く無償提供することで技術を低価格化・コモディティ化するアプローチを採っています（参照*3）。ザッカーバーグは6,500語のエッセイを公開し、Metaのデータセンター近隣のコミュニティ向けに10億ドルの基金も発表しました。

同社は今後数週間のうちに、最上位モデルであるMuse Spark 1.2の重み公開も予定しています（参照*5）。

同日に「誰もがスーパーインテリジェンスへアクセスできるべきだ」という発言も出ており、オープンウェイトを単なる宣伝ではなく基本方針として位置づけたことがわかります。声明とモデル公開がセットで動いている点を押さえると、Muse Glimmerが単発のリリースではなく、継続的なオープン路線の一手であることがつかみやすくなります。私自身、生成AI事業に関わる立場として、この方向性はモデルのコモディティ化を加速すると見ています。クローズドなAPIに依存するビジネスモデルへの圧力は、今後さらに強まるでしょう。

24GB VRAMで動く仕組みと必要ハードウェア

4bit量子化とメモリ設計

なぜ300億パラメータのモデルが24GBのGPUに収まるのか。技術的な仕組みを理解しておくと、自分の環境で動かせるかどうかの判断がしやすくなります。

フル精度では、300億パラメータのモデルに55GBを超えるメモリが必要で、コンシューマGPUの容量を大きく上回ります。Metaは量子化技術で重みをおよそ4bit精度まで圧縮し、言語モデル部分を20GB未満にまで縮めました。この圧縮により、KVキャッシュと呼ばれる作業メモリ、画像理解のための知覚エンコーダ、投機的デコード用のドラフターまでを、24GBや32GBの枠内に同居させられます（参照*1）。

Hugging Faceの資料では、フル精度のターゲットが64GB VRAM、K-Quant-Dynamicが32GB VRAM、K-Quant-17GBが24GB VRAMという対応関係が示されました。15種類の一般的なベンチマークの平均精度で見た劣化率は、K-Quant-Dynamicで0.2%、K-Quant-17GBで1.0%となっています（参照*2）。

24GBで動かす場合はK-Quant-17GBが基本の選択肢で、精度をより残したい場合は32GB以上のカードでK-Quant-Dynamicを選ぶ、という役割分担になります。精度劣化が1.0%以内に収まるなら、実務上の差はほとんど気にならないケースが多いと思います。まずは手持ちの環境で試し、精度が問題になってから上位構成を検討する順番が現実的です。

DFlash投機的デコードによる高速化

続いて、生成速度を伸ばす仕組みを見ておきます。エージェント用途では、1回の作業で多くのトークンを生成するため、速度は実用性に直結します。

言語モデルは通常、1トークンずつ文章を生成するため、長い推論やツール呼び出しが続く場面では時間がかかります。Muse GlimmerはDFlashをベースにした軽量なドラフターモデルを同梱しており、この小さな伴走ネットワークがトークンのかたまりを一気に提案します。本体モデルは提案を並列に検証し、正しいものは受け入れ、誤っているものだけ直します（参照*1）。

DFlashは16トークン分のブロックを1回のフォワードパスで予測し、通常の1トークン生成と同じ品質を保ちながら生成を大きく速めます（参照*2）。

実測では、NVIDIA RTX 5090が非投機時74.9tok/sから投機時233.4tok/sで3.1倍、Apple M4 Maxが23.7tok/sから37.8tok/sで1.5倍、Apple M5 Maxが26.6tok/sから50.2tok/sで1.8倍という結果でした（参照*7）。Apple Siliconでの倍率がNVIDIAより低く見えますが、絶対値の差と消費電力を合わせて見ないと判断を誤ります。数値はbatch=1、greedy decoding条件の値なので、自分の環境と条件をそろえて比較することが重要です。

推奨ハードウェアと現実解

実際に手元で動かすためのハードウェア候補を整理します。「動かせる」と「快適に動く」は別の話で、最低要件と推奨構成を分けて考えておく必要があります。

Muse Glimmer 30Bは18GBのRAMまたはVRAM構成でローカル動作し、MacやGPUを積んだPCで動きます。NVIDIA側ではRTX 5090が32GB VRAMと第5世代Tensor Coreを組み合わせ、コードを端末内にとどめたまま、トークン単位の推論コストなしで開発者のマシンに落とし込めます（参照*8）。

ローカルAIとして見たとき、Muse Glimmerはダウンロード可能な重み、寛容なライセンス、コンシューマ向けの公式量子化、マルチモーダル入力、長時間のエージェント作業に合わせた構成という要素を初めてそろえました。実質のエントリポイントは24GB VRAMであり、8GBや12GB、16GBのカードでは不足します（参照*9）。

本格運用の目安として、デュアルRTX 5090のワークステーション（約64GB VRAM）は初期投資4,500〜6,000ドル、Apple Mac Studioの128GBユニファイドメモリ構成は3,800〜4,800ドルとされています（参照*10）。私が企業へのAI導入支援で繰り返し見てきたパターンは、「まず小さく試し、用途が固まってから投資を増やす」です。RTX 3090やRTX 5090などの24GBクラスから始め、常時稼働の必要性が見えてきた段階で32GB・64GB構成を検討する順番が、無駄の少ない進め方です。

エージェント能力とベンチマーク性能

エージェントとしての中核能力

エージェントとしてどんな仕事ができるのかを見ておきます。「エージェント向けモデル」という説明は抽象的なので、具体的な能力に落として確認することが重要です。

Muse Glimmerは、DeepSearch QA、MCP-Atlas、τ3-Bench、SWE-Benchなどのフルタスク型のベンチマークで高い成功率を示し、スキャフォールドの中でコードを書き、デバッグし、複数ターンの依頼を最後まで解決する力を測られています。関数呼び出しにも幅広く対応し、長い作業の中で正確なスキーマに沿ってツールを呼び出せます（参照*2）。

ツール呼び出しが失敗したり想定外の結果を返したときには、エラーを診断してリトライするよう学習されており、停止せずに作業を続けます。専用の知覚エンコーダを介してテキストと画像を交互に受け取れるため、会話と並行してスクリーンショットやグラフ、書類を解釈できます（参照*1）。

なお、音声入力は対象外で、動画はフレーム単位で扱う設計です。音声や動画を入力したい場合は、前処理でテキスト化・フレーム化してから渡す運用が必要になります。この制約を事前に把握しておかないと、実装段階で想定外の手戻りが起きます。

同クラスモデルとの比較

他モデルとの数値比較を見ておきます。ただし、ベンチマークの数字だけで判断するのは危険です。自分の用途に近いタスクの数値を重視することが、現実的な選択につながります。

Hugging Faceのブログでは、主要ベンチでMuse Glimmer-30B、Gemma4-31B Thinking Mode、Qwen3.6-27B Thinking Modeが並べられました。MCP Atlasは75.5対54.2対62.5、DeepSearch QAは74.6対61.7対71.1、SWE-Bench Proは51.2対36.9対50.2、SWE-Bench Verifiedは76.0対66.6対77.2、AIME 2026は94.7対89.2対94.1という結果でした（参照*4）。

クラウド勢との比較も報告されており、SWE-bench VerifiedはMuse Glimmer 30Bが76.0、Claude 3.5 Sonnetが49.0、o3-miniが70.5、MCP Atlasは75.5対81.2対80.0、DeepSearch QAは74.6対82.0対84.1、AIME 2026は94.7対78.3対91.0となっています（参照*10）。

第三者評価では、Artificial AnalysisがGlimmerを総合ではQwen3.6 27Bより低く採点しつつ、サイズの割にツール利用性能が際立って強いと評しており、ホスト提供のMuse Spark 1.2はもう一段上のクラスに位置づけられました（参照*9）。

項目ごとに勝敗が分かれており、どのモデルが「最強」かは用途次第です。私が複数モデルを実務タスクで比較してきた経験から言うと、ベンチマークの総合順位よりも、自分の主戦場となる用途での数値を軸に選ぶほうが後悔が少ない。数値はMetaや各評価元の公表条件に依存するので、条件の違いを踏まえて読み解くことが必要です。

ローカル導入の手順と主要ツール

重みの入手とライセンス確認

公開されている成果物と入手時の注意点を整理します。選択肢が複数あるため、最初にどれを落とすかを決めておかないと無駄なダウンロードが発生します。

Hugging Faceでは、Apache 2.0のもとでBF16のフル精度重み、24/32GBコンシューマ機向けに最適化された4bit量子化重み（2種類）、投機的デコード用のDFlash drafterヘッド、約18億パラメータの凍結ViT-G/14知覚エンコーダが公開されています（参照*2）。GGUF版では、24GB VRAMに収まるMuse-Glimmer-30B-KQuant-17GB-Q4_K_M.ggufが16.8GB、32GB VRAM向けに高品質を狙ったMuse-Glimmer-30B-KQuant-Dynamic-Q4_K_XL.ggufが19.7GBというラインナップが用意されました（参照*7）。

ExecuTorch PTEのリポジトリは合計372GBあり、そのままダウンロードすると16種類のバリアント全部を取りに行きます。–includeで1つのバリアントと共有ルートファイルだけを指定するよう案内されており、この手順を飛ばすと数百GBを無駄に落とすことになります（参照*11）。まずは24GB向けのK-Quant-17GBから始め、環境に余裕が出てからDynamic版やBF16に上げる順番が失敗を減らします。

推奨ランタイムの選び方

どの実行環境を選ぶかは、用途と技術スタックによって変わります。選択肢ごとの特徴を把握しておくと、後から環境を変える手間が減ります。

MetaのOSSクックブックでは、チームへのサービス提供やツール呼び出しにはvLLM（BF16）、ループの学習や純粋なPython実装にはHF Transformers（BF16）、ワンコマンドで動かすビルド不要な用途には量子化GGUFのOllama、GUIやApple SiliconのMLXにはLM Studioという使い分けが示されました（参照*12）。

Ollamaでは「ollama run muse-glimmer」で導入と実行が完結し、Apple Silicon向けにはDFlashと画像入力に対応したMLXエンジンが提供され、「ollama run muse-glimmer:30b-mlx」で使えます（参照*13）。

Hugging Faceのブログでは、公開初日からtransformers、llama.cpp、vLLM、Inference Endpointsなど複数のライブラリでday-0対応が提供されたと案内されています（参照*4）。まず触ってみるならOllamaやLM Studio、チームで共有する本番用途ならvLLMという順で検討するとわかりやすい。ただし、vLLMは専用イメージが必要で、pip install vllmだけでは動かない構成なので、公式ガイドに沿って準備してください。生成AI導入で私が何度も見てきた失敗は、試用環境と本番環境の差を甘く見るケースです。最初の環境選定が後の工数を左右します。

エージェントとして動かすまで

実際にエージェントとして動かす際の技術的な要点を見ておきます。エージェント用途では、チャット利用とは異なる設定上の注意点があります。

Muse Glimmerはツールを呼び出すときにATEMブロックを出力します。ATEMはMuse Glimmerのツールブロック形式の名称で、XMLに似た構造を持ち、厳密なXMLパーサーではなく正規表現で解析されます（参照*14）。

スキャフォールド側ではOpenClawなどエージェント指向のオーケストレーションパターンと互換で動作するよう設計されています（参照*1）。

実装で特に注意したいのが、<|eom|>を停止トークン扱いにしないことです。<|eom|>はメッセージ終端の区切りで、推論ブロックや途中の並列ツール呼び出しの間を分ける役割を持ち、ここでターンは終わりません。eos_token_idには<|end_of_text|>と<|eot|>を設定するのが正解で、サーバー側が<|eom|>で止めてしまうと単一ターン内の並列ツール呼び出しはほぼゼロにまで落ちます（参照*15）。テンプレート適用時の–jinja指定と併せて、停止条件を最初に確認しておきましょう。

活用ユースケースと注意点

想定ユースケース

実際にどんな仕事に使えるかを整理します。「エージェント向け」という説明は広いので、具体的なユースケースに落として考えるほうが、自分の業務に使えるかどうかを判断しやすくなります。

Muse Glimmerは商用と研究の両方の利用を想定した自律エージェント向けモデルで、コンシューマ端末上で完結する多段プランニング、逐次的なツール呼び出し、失敗回復、長い作業の遂行を担うローカルAIエージェント、さらにSWE-Bench型のワークフローに沿ってコードを書き・デバッグし・現実の開発課題を解くコーディングエージェントに最適化されています（参照*2）。

日常寄りの用途としては、コーディング、スケジュール管理、ファイル整理、関数呼び出し、LLM-as-a-judge評価に向いており、失敗したツール呼び出しの自動リトライも備え、知覚エンコーダによりスクリーンショットや図表、書類の解釈まで会話と一緒に扱えます（参照*8）。

プライバシー配慮が必要な用途では、コーディング、文書解析、個人アシスタント、ClawやHermesに似た構成での利用が推奨されています（参照*4）。ローカル実行によるプライバシー確保は、企業がクラウドAPIに社内情報を送ることをためらう場面での代替手段になりえます。ただし、「ローカルだから安全」という思い込みは禁物で、端末やネットワークのセキュリティは別途設計が必要です。また、18歳未満への配布は想定されていないので、家庭内の共有端末で使う場合はアカウント分離などを事前に決めておきましょう。

セキュリティと運用上の注意

安全に運用するための注意点を見ておきます。ローカル実行だからといって、セキュリティ設計を省いてよいわけではありません。

ローカル実行はプライバシーを高め、外部への露出を減らす一方で、モデル自体にはサンドボックス化、許可リスト方式のツール、リトライ上限、承認ゲート、プロンプトインジェクションや破壊的操作への対策が必要です。Metaは、取り消せない操作に対する人手の確認（human-in-the-loop）を含むガードレールと組み合わせて広いシステムの一部として展開するよう推奨しています（参照*8）。

評価は主に4軸で行われ、コンテンツ安全性、エージェント関連リスク（取り消せない操作の確認、データ最小化、スキャフォールド境界の尊重、間接的なプロンプトインジェクション耐性のポリシー）、プライバシー（適切な情報フロー）、化学・生物・サイバー・制御喪失を含む備えの領域が扱われました（参照*2）。

運用コストの目安として、デュアルNVIDIAワークステーション（ピーク750W）では1日8時間の重いエージェント負荷で電力費が月35ドル前後（年420ドル）、24時間連続運用では月86ドル前後（年1,036ドル）になります。Apple Silicon Mac Studio（ピーク130W）では同じ8時間運用で月5.90ドル前後（年71ドル）、24時間運用でも月15ドル前後にとどまり、PC GPU構成と比べて80%以上のエネルギー削減が示されました（参照*10）。常時稼働のエージェントを想定するなら、Apple Siliconの電力効率の優位は無視できません。想定稼働時間と電力単価を先に計算しておくと、ハード選定と回収計画を合わせて考えられます。

おわりに

Muse Glimmerの無料開放は、300億パラメータ級のエージェント向けモデルを、Apache 2.0のもとで手元のGPUに載せられる形に整えた点で大きな意味を持ちます。4bit量子化とDFlashによる高速化、知覚エンコーダやツール呼び出しの一体化により、24GB VRAMというコンシューマ帯からエージェント運用に踏み出せるようになりました。私が生成AI事業を通じて感じているのは、モデルそのものの性能差よりも、「どの業務工程に入れるか」と「検証・運用の仕組みをどう作るか」が成果を左右するということです。Muse Glimmerのようなオープンモデルは、試せる選択肢が増えるという意味で歓迎ですが、動かすこと自体がゴールではありません。

まずはOllamaやLM Studioでの試用から始め、用途が固まったらvLLMや32GB・64GB構成へ段階的に広げる進め方が現実的です。運用に入る前に、サンドボックス設計、人手承認の仕組み、電力コストの試算を合わせて整えておく。そうして初めて、ローカルエージェントの実力を業務の文脈で確かめられます。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、95万部（2026年6月時点）を売り上げる。
（“2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））