Meta、コンシューマーハードウェアでローカルAIエージェントを実行できるMuse Glimmer 30Bをオープンソース化

Metaは、ローカルで常駐するAIエージェント向けに設計された、300億パラメータのオープンウェイトモデル「Muse Glimmer」をリリースしました。このモデルは、2026年8月10日にMetaによって発表されました。

发布于 2026年8月11日•general•GEO 评分: 0•1 次阅读

选择语言

العربية Deutsch English Español Français Italiano 日本語 한국어 Português Русский 中文

画像は、MetaがMuse Glimmer 30Bをオープンソース化することを宣伝する画像で、背景は濃い青色、左上にMetaのロゴがあります。中央の大きな見出しには「Meta Open-Sources Muse Glimmer 30B」と書かれ、その下の副題には「Local AI Agents on Consumer Hardware」とあります。画面下部には、ノートパソコン、ロボット、コード、データベースなどのアイコンがあり、右側には「Local AI」の文字が描かれた回路基板があります。この画像は、文書内で紹介されているMetaによるMuse Glimmer 30Bのオープンソース化とローカルAIエージェントへの適用という内容に合致し、テーマを直感的に表現しています。

Meta、オープンソースのMuse Glimmer 30Bを公開 — コンシューマ向けハードウェアでローカルAIエージェントを実行可能に

はじめに

Metaは、ローカルで常時稼働するAIエージェント向けに設計された、300億パラメータのオープンウェイトモデル Muse Glimmer をリリースしました。

このモデルはMetaスーパーインテリジェンス研究所によって2026年8月10日に発表され、そのウェイトは寛容な Apache License 2.0 の下で提供されます。

Muse Glimmerが対象とするデプロイメントモデルは、現在ほとんどの人が利用しているクラウドファーストのフロンティアモデルとは異なります。

すべてのプロンプト、スクリーンショット、ドキュメント、ツール呼び出しをホスト型モデルAPIに送信する代わりに、適切なコンシューマ向けハードウェアを備えたMacまたはPC上で直接実行するように設計されています。

Metaはこれを以下のタスク向けに位置付けています：

ローカルパーソナルエージェント
関数・ツール呼び出し
マルチステップワークフロー
コーディングとデバッグ
スクリーンショットとドキュメントの理解
ファイル指向ワークフロー
長周期推論
LLMアズ・ジャッジによる評価

このモデルはテキストと画像の入力を受け付け、テキスト出力を生成します。専用の知覚エンコーダーを通じて、スクリーンショット、チャート、ドキュメント、その他の視覚入力を解釈できます。

そのトレーニングデータは100以上の言語をカバーしています。

核となるコンセプトはシンプルです：

個人のコンテキスト
+ ローカルモデル
+ ツール
+ 長期実行エージェントループ
=
クラウドモデルに依存せず動作するAIアシスタント

このローカルファーストの設計は、ファイル、メッセージ、スケジュール、仕事用ドキュメントなどの個人データへのアクセスを必要とする可能性のあるエージェントにとって特に重要です。

ただし、「オフラインモデル」は「すべてのエージェントタスクがオフラインで実行できる」と誤解されるべきではありません。Muse Glimmer自体はネットワークなしで動作できますが、クラウドカレンダーを呼び出したり、メールを送信したり、ウェブ検索をしたり、その他のリモートサービスを使用するエージェントには、対応するネットワーク接続と認証情報が引き続き必要です。

Muse GlimmerはMuse Sparkから蒸留された30Bモデル

当初のAIBaseレポートでは、GlimmerをMetaの初期モデルMuse Sparkのオープンバージョンと説明していました。

この説明は精神に近いものですが、技術的には正確ではありません。

Metaの公式説明では、Muse GlimmerはMuse Sparkから蒸留されたと述べられています。

このモデルは多段階のトレーニングプロセスを通じて構築され、より大きな教師モデルから、ローカルハードウェアにより適した小型アーキテクチャへと能力を移転しています。

Metaは主要な3つのトレーニング段階を説明しています：

事前学習： GlimmerはMuse Sparkの出力に対してロジット蒸留を使用してトレーニングされ、類似のデータ混合を採用しています。
中期トレーニング： Metaはより長いコンテキストと、より豊富な推論軌跡を含む、よりエージェント集約的なデータを追加しました。
後期トレーニング： チームは教師あり微調整、ポリシー内蒸留、および汎用・推論・コーディング・エージェントタスク向けの強化学習を組み合わせました。

したがって、両者の関係は次のように要約するのが適切です：

Muse Spark
    ↓
教師出力と推論
    ↓
蒸留 + エージェント指向トレーニング
    ↓
Muse Glimmer 30B

Glimmerは、Sparkの同じチェックポイントを単に直接オープンにしたものではありません。

これは、ローカル推論の制約に合わせて最適化された、独立した小型モデルです。

アーキテクチャと主要仕様

Metaの現在のモデルカードには、視覚エンコーダーを含めて約 296億 の総パラメータが記載されています。

仕様	Muse Glimmer 30B
アーキテクチャ	知覚エンコーダーを備えた高密度因果Transformer
総パラメータ	約296億
Transformer層数	52
隠れ次元	6,656
アテンション	反復的なローカル/ローカル/ローカル/グローバルパターン
スライディングウィンドウ	2,048
コンテキスト長	131,072+トークン
視覚エンコーダー	約18億パラメータのViT-G/14
画像あたりの最大視覚トークン数	4,096
入力	テキスト+画像
出力	テキスト
トレーニング言語	100以上の言語のデータ
知識カットオフ日	2026年1月4日
ライセンス	Apache 2.0

このモデルは、専門家混合（Mixture-of-Experts）ではなく、高密度モデルです。

これにより、推論中にモデルのすべてのウェイトをロードする必要があるため、ローカルデプロイがより困難になります。

Metaは主に量子化を通じてこの問題に対処しています。

24GBまたは32GB VRAM向けに設計された30Bモデル

全精度では、この規模のモデルに必要なメモリは、一般的なコンシューマ向けGPUが提供する容量を超えます。

Metaによると、全精度モデルには55GB以上のメモリが必要で、その参照全精度ターゲットは64GB VRAM構成です。

ローカルデプロイ向けに、Metaは約4ビット量子化のバリアントを提供しています。

公式の比較は以下の通りです：

バリアント	ターゲットハードウェア	平均精度低下*
全精度	64GB VRAM	—
K-Quant-Dynamic	32GB VRAM	0.2%
K-Quant-17GB	24GB VRAM	1.0%

*Metaは、低下率は15の一般的なベンチマークにおける精度指標の平均値であると報告しています。

圧縮後の言語モデルのウェイトは20GB未満に収まり、以下のためのスペースを確保します：

KVキャッシュ
知覚エンコーダー
DFlashドラフトモデル
実行時オーバーヘッド

このエンジニアリング上の変更により、高密度30Bマルチモーダルエージェントが高性能なコンシューマ向けデバイス上で実際に実行可能になりました。

「コンシューマ向けハードウェア」には、依然として文脈の説明が必要です。

データセンタークラスターと比較すると、24GBまたは32GBのメモリ要件は到達可能ですが、これは低スペックのノートPC構成ではありません。

フルモデルは依然として高い要求を課します。

マルチステップエージェントワークフロー向けに構築

Muse Glimmerは主に軽量チャットモデルとして位置付けられているわけではありません。

Metaはエージェントタスク完了を中心にトレーニングと評価を行っています。

モデルカードでは、いくつかの関連する能力が強調されています。

エンドツーエンドのタスク完了

Glimmerは、1回の応答で停止するのではなく、タスク全体を完了するように設計されています。

エージェントは次のことが可能です：

目標を理解する
→ 計画を立てる
→ ツールを呼び出す
→ 結果を確認する
→ 計画を修正する
→ 別のツールを呼び出す
→ タスクを完了する

これは、正しい答えが中間操作に依存するシナリオで特に有用です。

信頼性の高いツール使用

このモデルは、拡張ワークフローで構造化パターンを使用して関数を呼び出すようにトレーニングされています。

これにより、以下のようなツールを公開するさまざまなシステムに適しています：

ファイル
シェルコマンド
データベース
カレンダー
ドキュメント
ブラウザ
社内アプリケーション

モデル自体がこれらのシステムへのアクセスを自動的に取得するわけではありません。

エージェントのスキャフォールディングが、どのようなツールが存在し、モデルがどのような権限を得るかを決定します。

マルチステップ推論

Glimmerは、より長いワークフローでの継続的なプランニングをサポートします。

また、4つの推論強度設定もサポートしています：

低
中
高
非常に高

Metaは、より困難なコーディング、推論、エージェントタスクには「高」または「非常に高」レベルを推奨しています。

遅延が深い推論よりも重要な場合には、低いレベルの方が適している場合があります。

失敗からの回復

エージェントのより重要な特性の1つは、ツール呼び出しが失敗した後も実行を継続できることです。

Metaは、Glimmerが予期しない結果を診断して即座に停止するのではなく再試行するようにトレーニングされていると述べています。

長期稼働するローカルアシスタントにとって、これは生のベンチマーク性能と同じくらい重要です。

実際のツールは失敗します。

ファイルは移動されます。コマンドはエラーを返します。APIはタイムアウトします。プログラムはコンパイルに失敗する場合があります。

回復できないエージェントは、小さな失敗をすべて人間の介入を必要とする中断に変えてしまいます。

テキストと画像の入力によりスクリーンショットがより有用に

Muse Glimmerには、約18億パラメータの専用視覚エンコーダーが含まれています。

これにより、インターリーブされたテキストと画像の入力を処理できます。

Metaは特に以下のシナリオを含むユースケースを強調しています：

スクリーンショット
チャート
ドキュメント
ビジュアルインターフェース

これはコンピュータ操作型エージェントにとって特に重要です。

ローカルエージェントはアプリケーションのスクリーンショットを検査し、その視覚コンテキストを次の推論ステップで使用できます。

Ollama は以下の例を提供しています：

ワイヤーフレームに基づくアプリケーション構築。
スクリーンショット駆動型のコンピュータ操作ワークフロー。
レシート、ドキュメント、図表の読み取り。

動画はネイティブに最適化された入力モダリティではありません。

Meta のモデルカードによると、動画は個別のフレームとして処理できますが、このモデルは動画理解のために明示的に最適化されているわけではありません。

音声入力と出力もサポートされていません。

100以上のトレーニング言語をカバー

AIBase の報告によると、Glimmer はテキストと画像のインタラクションをサポートし、100以上の言語のトレーニングデータをカバーしています。

Meta のモデルカードは、そのトレーニングデータが100以上の言語から来ていることを確認しています。

これは、すべての言語で同じパフォーマンスが保証されるという意味ではありません。

Meta は、このモデルが事前学習データ内のすべての言語で評価されているわけではなく、主要サポート言語以外ではパフォーマンスが低下する可能性があることを明示しています。

ローカル多言語アプリケーションでは、開発者は品質が均一であると想定せず、対象言語を直接テストすべきです。

DFlash によるローカルエージェントループの高速化

ローカルエージェントのワークフローは、1つのタスクに複数回の推論とツール呼び出しが必要な場合があるため、遅く感じられることがあります。

20または50のエージェントステップにわたって繰り返される小さな遅延ペナルティは、目立つようになります。

Muse Glimmer には、DFlash ベースの軽量な投機的復号コンパニオンモデルが付属しています。

ドラフトモデルは将来のトークンのブロックを提案します。

その後、Glimmer メインモデルがこれらの提案されたトークンを並行して検証します。

簡略化されたフローは以下の通りです：

DFlash がブロックを起草
→ Muse Glimmer が検証
→ 正しいトークンが受け入れられる
→ 誤ったトークンが修正される

Meta によると、DFlash モデルは前方伝播で一度に16トークンのブロックを起草できます。

その目標は、通常のトークン生成における順次ボトルネックを減らすことです。

Meta は、K-Quant-17GB モデルと量子化された DFlash ドラフトモデルを組み合わせた場合の復号速度を報告しています：

デバイス	ベースライン	DFlash 使用時	報告された高速化率
NVIDIA RTX 5090	74.9 tok/s	233.4 tok/s	3.1×

上記は Meta が報告した測定データです。

同社によると、テストではバッチサイズ1の貪欲復号が使用され、M4/M5 の測定は ExecuTorch を介して、RTX 5090 の測定は llama.cpp を介して行われました。

実際のアプリケーション速度は以下の要因によって異なります：

プロンプトの長さ。
コンテキストサイズ。
量子化方式。
ツールの遅延。
ハードウェア。
ランタイム。
画像入力。
推論の強度。
投機的復号が有効かどうか。

ベンチマーク性能

Meta は Muse Glimmer を、Gemma4-31B や Qwen3.6-27B など、同じサイズクラスの他のオープンウェイトモデルと比較しました。

報告された一部のスコアは以下の通りです：

ベンチマーク	Muse Glimmer 30B
MCP Atlas	75.5
DeepSearch QA	74.6
WildClawBench	47.6
OSWorld-Verified	65.9
SWE-Bench Pro	51.2
SWE-Bench Verified	76.0
TerminalBench 2.1	51.7
ScreenSpot Pro	75.4
MMMU Pro	74.0
AIME 2026	94.7
GPQA Diamond	83.5

全体的なパフォーマンスは競争力がありますが、全面的にリードしているわけではありません。

例えば、Meta 自身のグラフでは、複数のベンチマークで他のモデルが Glimmer を上回っていることが示されています。

これは予想通りです。

Muse Glimmer の主な製品ポジショニングは「すべてのベンチマークで最高のスコアを達成すること」ではありません。

その代わりに、以下の要素の組み合わせです：

エージェント能力
+
マルチモーダル入力
+
ローカル実行
+
オープンウェイト
+
コンシューマー向けメモリをターゲットにした設計

ベンチマーク手法は文脈を踏まえて理解する必要がある

Meta は独立した評価方法論のドキュメントも公開しています。

そのドキュメントによると、比較データは以下のソースの混合から得られる可能性があります：

内部での再現。
モデル提供者による自己報告の結果。
Artificial Analysis。

エージェントベンチマークは以下の要因に特に敏感です：

システムプロンプト。
エージェントの足場（スキャフォールディング）。
ツール定義。
時間またはターン数の制限。
サンプリング設定。
ランタイム環境。

ベンチマークの表は有用な証拠です。

しかし、特定のモデルがあらゆる実世界のエージェント展開で最適であることの証明と見なすべきではありません。

ローカルプライバシーが主要な戦略的ユースケース

原文では個人のプライバシーに焦点が当てられています。

これはローカルでエージェントを実行する最も重要な理由の1つでもあります。

有用な個人エージェントは以下にアクセスする必要があるかもしれません：

ローカルドキュメント。
メッセージ。
ノート。
仕事用ファイル。
スクリーンショット。
個人のスケジュール。
アプリケーションの状態。
プライベートなプロジェクトのコンテキスト。

これらすべての素材をリモートのモデルサービスに送信することは、ユーザーのデバイス上で処理するのとはまったく異なるデータフローパターンを形成します。

Muse Glimmer の設計により、コア推論ループはローカルで実行を維持できます。

Meta 公式の Muse Glimmer レシピドキュメントによると、そのローカルファーストのレシピは以下を必要とせずに実行できます：

クラウドインフラストラクチャ。
ホスト型推論。
API キー。
ネットワークアクセス。

これにより、デバイスから送信される個人データの量を減らすことができます。

ローカルは自動的にプライベートを意味しない

この区別は依然として重要です。

ローカルモデルは、データを他の場所に送信するツールに接続できます。

例えば：

ローカル Glimmer モデル
→ クラウドメールサービス
→ リモートカレンダー
→ ウェブ検索
→ サードパーティの MCP サーバー

このシステムでは、モデル推論はローカルですが、ワークフロー全体が完全にオフラインというわけではありません。

プライバシーは完全なエージェント

アーキテクチャに依存します。

開発者は以下を監査すべきです：

ツールの権限。
リモートエンドポイント。
ログ。
永続メモリ。
ブラウザアクセス。
シェルアクセス。
認証情報。
テレメトリ。
プラグインまたは MCP の動作。

ローカル推論は有用なプライバシープリミティブですが、万能の保証ではありません。

ネットワークがなくてもパーソナルエージェントは機能する

完全にローカルリソースを中心に構築されたワークフローでは、Muse Glimmer はネットワークが利用できない場合でも実行を継続できます。

ローカルパーソナルエージェントは理論上、以下のタスクを処理できます：

ローカルノートの検索。
ファイルの整理。
オフラインドキュメントの要約。
後で送信するメッセージの下書き。
ローカルコードの作成とデバッグ。
スクリーンショットからの情報抽出。
ローカルレポートの構築。
ローカルストレージ上のタスクリストの管理。

これはまさに、Meta が Glimmer を常時稼働のローカルエージェントモデルと表現している意味です。

このモデルはクラウドエンドポイントを待つことなく利用可能です。

また、ユーザーがハードウェアと電気代を支払った後は、推論によるトークン単位の API 費用もかかりません。

モデルには依然としてエージェントの足場が必要

Muse Glimmer をダウンロードしても、完全なパーソナルアシスタントが自動的に作成されるわけではありません。

モデルは単なるコンポーネントです。

有用なエージェントには、依然として実行環境が必要です。

典型的なコンポーネントは以下の通りです：

Muse Glimmer
+
システム命令
+
ツール定義
+
エージェントループ
+
権限制御
+
メモリ
+
ローカルまたはリモートアプリ

Meta のモデルカードによると、Glimmer は OpenClaw や Hermes Agent などのエージェントオーケストレーションパターンと連携できます。

Meta は Muse Glimmer も公開しています。

料理マニュアル。以下の内容を網羅：

クイックスタート
ツール使用の基本
エージェントレシピ
推論サーバー
特定ハードウェアへのデプロイ
ホスティングの代替手段

これにより、今回のリリースは単なるウェイト公開以上の価値を持つものとなっている。

Apple Silicon で Ollama を使ってクイックスタート

Ollama は8月10日、Muse Glimmer の初期サポートを追加した。

本稿執筆時点で、Ollama 自身のリリースノートによると、初期サポートは Apple Silicon 上の MLX エンジン 経由で提供されている。

今後、Apple Silicon、NVIDIA、AMD、その他のプラットフォーム向けのさらなる最適化が予定されている。

現在のバージョンの Ollama をインストールして、以下を実行：

ollama run muse-glimmer:30b-mlx

サポートされているコーディングエージェント統合については、Ollama ドキュメントに以下のような例がある：

ollama launch claude --model muse-glimmer:30b-mlx

OpenClaw の場合：

ollama launch openclaw --model muse-glimmer:30b-mlx

Hermes の場合：

ollama launch hermes --model muse-glimmer:30b-mlx

新しいモデルリリース後、ローカルランタイムのサポートは急速に進化しているため、Windows、Linux、NVIDIA、AMD で同じモデルタグとバックエンドサポートを前提とする前に、最新の Ollama ドキュメントを確認すること。

vLLM でモデルを実行する

現在の Hugging Face モデルページには、vLLM クイックスタートガイドが用意されている。

vLLM をインストール：

pip install vllm

Muse Glimmer をサーブ：

vllm serve "meta-models/Muse-Glimmer-30B"

生成されたサーバーは、OpenAI 互換の API を公開する。

これにより、ローカルの OpenAI スタイルのチャットエンドポイントを呼び出す方法をすでに知っているアプリケーションは、より簡単に接続できるようになる。

全精度でサービスを提供するために必要なメモリは、24GB/32GB の量子化バージョンよりもはるかに高い。

デプロイパス。

実際に利用可能なハードウェアに応じて、モデル成果物とランタイムを選択すること。

SGLang で実行する

公式モデルページには SGLang のパスも用意されている：

pip install sglang

その後：

python3 -m sglang.launch_server \
    --model-path "meta-models/Muse-Glimmer-30B" \
    --host 0.0.0.0 \
    --port 30000

その後、ローカルサーバーの OpenAI 互換エンドポイントを介してモデルを呼び出すことができる。

Docker モデルランナー

現在の Hugging Face インテグレーションページには以下も記載されている：

docker model run hf.co/meta-models/Muse-Glimmer-30B

Docker ベースのデプロイはパッケージングを簡素化できるが、ハードウェア互換性、メモリ要件、ランタイムサポートはターゲットマシン上で検証する必要がある。

公開された成果物は BF16 チェックポイントだけではない

Meta の Hugging Face コレクションには、現在複数の公式成果物が含まれている：

Muse-Glimmer-30B — 研究およびファインチューニング用の BF16 ウェイト。
Muse-Glimmer-30B-GGUF — ローカル推論用の公式 K-quant ファイル。
Muse-Glimmer-30B-ExecuTorch-PTE — デバイス上ビルド向けで、Metal 向けデプロイメントオプションを含む。
Muse-Glimmer-30B-assistant — DFlash 投機的デコーディング用コンパニオンモデル。

Meta のモデルカードは、今回のリリースに以下が含まれることを示している：

全精度 BF16 ウェイト。
2 つの 4 ビット量子化バリアント。
DFlash ドラフトモデル。
知覚エンコーダー。

これらはすべて Apache 2.0 ライセンスで公開されている。

単一の大規模な研究チェックポイントのみを公開するよりも、開発者にとってはるかに親しみやすい。

ローカルコーディングが主要なターゲットシナリオ

コーディングは、ローカルエージェントの最も明確なユースケースの 1 つである。

コーディングエージェントは通常、以下へのアクセスを必要とする：

コードリポジトリ
ローカルファイル
シェル
ビルドツール
テスト
コンパイラ出力
スクリーンショットまたはデザインモック

これらのマテリアルをローカルに保持することは、以下のシナリオにとって魅力的であり得る：

プロプライエタリソフトウェア
企業内部コード
未発表の製品
機密性の高いクライアントプロジェクト
隔離ネットワークまたは低接続環境

Meta は SWE-Bench や TerminalBench などのコーディングタスクで Glimmer を評価し、コーディングエージェントを想定されるユースケースの 1 つとして挙げている。

それでも、ローカルデプロイはコーディングエージェントの通常のリスクを排除するものではない。

シェルまたはファイル書き込み権限を持つモデルは、以下の可能性がある：

ファイルを削除する
設定を変更する
安全でないコマンドを実行する
信頼できない依存関係をインストールする
接続されたツールを介してデータを漏洩させる

権限制御とサンドボックス分離は依然として不可欠である。

Meta は現実世界の操作に対して追加のガードレールを推奨

Meta のモデルカードは、Glimmer を無制限のアクセスを許可すべき自律システムとして説明していない。

これは、モデルをより広範なシステムの一部として、コンテキストに適した保護措置を備えてデプロイすることを推奨している。

エージェント的な使用シナリオでは、Meta は特に元に戻せない操作に対する人間の確認などの制御を実装することを推奨している。

これは、以下のようなタスクにとって特に重要である：

電子メールの送信
データの削除
コンテンツの公開
送金
本番インフラストラクチャの変更
セキュリティ設定の変更

ローカルモデルはクラウドへの依存を減らすことはできるが、エージェントの設計には依然として慎重さが求められる。

準備評価：中程度以下

Meta は、Muse Glimmer の全体的な能力が Muse Spark よりも低いため、Meta の

Meta の「先進AI拡張フレームワーク」におけるフロンティアAIの定義には達していないと述べている。

それでも、Meta は今回のオープンソースリリースを Preparedness プロセスを通じて評価した。

モデルカードは以下の評価を示している：

リスク領域	Meta 評価
化学/生物	中低以下
サイバーセキュリティ	中低以下（推定）
自律性喪失	中低以下（推定）

Meta は、サイバーセキュリティと自律性喪失に関する結論は推定であると述べている。その理由の一部は、Glimmer が総合的に Muse Spark 1.0 より弱く、後者がこれらの領域で同じ評価を得ていたためである。

これらは Meta 自身の安全評価であり、独立した認証ではない。

同社はまた、テストがすべてのシナリオを網羅できるわけではないことも認めている。

個人向けスーパーインテリジェンスがより大きな戦略

AIBase 記事の終盤では、Muse Glimmer をマーク・ザッカーバーグの個人向けスーパーインテリジェンスのビジョンと結び付けている。

この結びつきは公式のものである。

Meta は繰り返し、その最近のモデルと製品を次のように位置づけている：先進AIは、インテリジェンスを少数の企業や政府に集中させるのではなく、個人が自身の目標を追求するのを支援すべきである。

ザッカーバーグが8月10日に発表した記事**「未来はすべての人のもの」**の中で、彼は先進AIが広く配布されるべきだと主張している。

彼が個人エージェントが支援できるシナリオとして挙げたものには、以下が含まれる：

人間関係
健康
キャリア
財務
家庭管理
学習
創造性
新しいビジネス

彼はまた、Meta がこれらのツールを無料または可能な限り低価格でユーザーに提供するつもりであり、数十億人が利用できる無料バージョンも含まれると述べている。

Muse Glimmer は、この哲学の一部を実際に示すものである：

強力なエージェントモデル
→ ダウンロード可能なウェイト
→ ローカル推論
→

ユーザー制御のハードウェア

オープンソースモデルを権力バランス戦略として

ザッカーバーグの主張は開発者の利便性を超えている。

彼はオープンソースAIを権力集中を減らす一つの方法と見なしている。

その論理は：

少数の組織が最強のAIを支配
→ 知能が集中する

多くの人が強力なモデルを実行可能
→ 能力がより分散される

これがより良い安全上の結果につながるかどうかは、議論の余地がある問題である。

ザッカーバーグは、幅広いアクセスが抑制と均衡を形成できると考えている。

一方で、高性能なオープンソースモデルは悪用のリスクも高める可能性があると主張する者もいる。なぜなら、ウェイトが広く配布されると、特定の安全対策の実施が困難になるからである。

Muse GlimmerはMetaの最強モデルではないという事実が、この議論において極めて重要である。

Meta自身のPreparedness評価では、GlimmerはMuse Sparkより明らかに弱く、主要なフロンティアリスクカテゴリーで中低以下と評価されている。

これにより、ローカル/オープンソース戦略を実施するためのリスクが比較的低い入り口となる。

Metaのオープンソースとクローズドソースのモデル戦略は元記事が示唆するよりも柔軟である

AIBaseの記事は単純な二分法を示している：

Muse Glimmer = オープンソース
Muse Spark = クローズドソース

これはMetaの製品現状の一部を正確に説明しているが、長期戦略としては静的すぎる。

Muse Sparkは当初、Meta AIおよびプライベートAPIプレビューを通じてリリースされ、ダウンロード可能なウェイトとしては提供されなかった。

Glimmerはオープンウェイトである。

しかし、ザッカーバーグは8月の

第10条声明で、Metaスーパーインテリジェンスラボが稼働を開始したため、Metaは一部のオープンソースモデルのリリースを再開するとも述べている。

同じ発表に関する同時期の報道では、Metaがより多くのオープンウェイトのMuseバージョンをリリースする計画であることも言及されている。

したがって、より正確な理解は次の通りである：

Metaは異なる能力レベルと製品に対して異なるアクセスモードを採用しつつ、将来的にオープンリリースを継続することを公に約束している。

これにより、Metaがより強力なMuseモデルを永久にクローズドに保つと決定したと断定するのは、あまりにも断定的である。

ローカルエージェントがコンシューマー向けAI競争に不可欠な理由

クラウドAIには明らかな利点がある：

膨大な計算リソースを利用可能。
モデルアップグレードの速度が速い。
集中型ツールインフラ。
超大規模フロンティアモデルをサポートしやすい。

ローカルAIには別の利点がある：

推論プロセスがプライベート。
オフラインで使用可能。
トークン単位のクラウド料金が不要。
一部のワークフローでネットワークレイテンシが低い。
ローカルデータへの直接アクセス。
開発者の制御力が強い。

Muse Glimmerが注目に値するのは、強力なエージェント機能をこのトレードオフのローカル側に持ち込もうとしているからである。

その目標は、いくつかの決まった質問に答えるだけの小さなアシスタントではない。

それは以下のことができるモデルである：

計画を立てる。
ツールを使用する。
失敗から回復する。
スクリーンショットを理解する。
コードを書く。
長いコンテキストを処理する。
マルチステップタスクを完了する。

これこそが24GB/32GBのデプロイメントターゲットの重要性である。

これにより、エージェント機能が個人開発者やパワーユーザーが実際に所有できるデバイスに入る。

確認済みの事項とさらなる精査が必要な事項

声明	現在のステータス
Metaが2026年8月10日にMuse Glimmerをリリース	確認済み
モデルは約300億パラメータ	確認済み
モデルウェイトはApache 2.0ライセンスでリリース	確認済み
GlimmerはMuse Sparkから蒸留された	確認済み
Glimmerは完全に同じMuse Sparkモデルがオープンソース化されたもの	いいえ
モデルはテキストと画像入力を受ける	確認済み
テキスト出力を生成する	確認済み
100以上の言語のデータでトレーニング	確認済み
コンテキスト長は131,072+トークン	確認済み
量子化バージョンは24GBおよび32GBメモリ環境向け	確認済み
適切なコンシューマー向けハードウェアを搭載したMacまたはPCで実行可能	Metaが確認
クラウドインフラやネットワーク接続なしでローカル実行可能	モデル自体については確認済み
すべてのエージェントタスクをオフラインで完了可能	いいえ；ネットワークツールにはインターネット接続が必要
DFlashアクセラレーテッドデコード	確認済み
MetaはRTX 5090で最大3.1倍の高速化を報告	会社の主張
Muse Glimmerはローカルエージェントおよびコーディング用途向け	確認済み
ダウンロード後にメール、カレンダー、ファイルを自動管理	いいえ；エージェントフレームワークとツールの許可が必要
Muse Sparkは永久にクローズドのまま	未確認
ザッカーバーグはパーソナルスーパーインテリジェンスが広く利用可能で手頃な価格であることを望んでいる	確認済み

よくある質問

Meta Muse Glimmerとは何か？

Muse Glimmerは、Metaスーパーインテリジェンスラボが開発した約300億パラメータのオープンウェイトのマルチモーダルモデルである。ローカルエージェントワークフロー、ツール使用、コーディング、スクリーンショット理解、長文脈推論、マルチステップタスク向けに最適化されている。

完了。

Muse Glimmerはオープンソースか？

Metaは寛容なApache 2.0ライセンスでモデルウェイトと関連アーティファクトをリリースし、このリリースをオープンソース/オープンウェイトと説明している。技術的な正確性の観点から、リリースの主要アーティファクトがトレーニング済みモデルであるため、一般的にはオープンウェイトモデルと説明される。

Muse GlimmerにはどれくらいのVRAMが必要か？

Meta公式の量子化バージョンは、K-Quant-Dynamicが32GB VRAM、K-Quant-17GBが24GB VRAMをターゲットとしている。全精度モデルには55GB以上のメモリが必要で、Metaモデルカードでは64GBのターゲット構成が示されている。

Muse Glimmerは完全にオフラインで実行できるか？

できる。モデルはクラウドモデルやネットワーク接続なしでローカルに推論できる。ただし、エージェントがウェブ検索、クラウドメール、リモートカレンダー、オンラインデータベース、その他のインターネットツールを使用する場合、これらのツール呼び出しの実行にはネットワーク接続が必要である。

Muse Glimmerは画像をサポートしているか？

サポートしている。専用の約18億パラメータの知覚エンコーダーを備え、テキストと画像の入力を受け付ける。スクリーンショット、チャート、ドキュメント、その他の視覚コンテンツの推論分析が可能である。

OllamaでMuse Glimmerを実行できるか？

できる。OllamaはApple SiliconのMLXエンジンにMuse Glimmerの初期サポートを追加している。リリース時点で、Ollamaは今後さらなる最適化とプラットフォームサポートを提供すると述べており、他のハードウェアユーザーは最新のリリースノートを確認すべきである。

Muse GlimmerはMuse Sparkのオープンソース版か？

完全にはそうではない。Muse GlimmerはMuse Sparkから蒸留され、ローカルエージェントワークロード向けに独立した30Bモデルとしてトレーニングされた。より大規模な教師モデルの能力を受け継いでいるが、Sparkチェックポイントにオープンライセンスを付けただけのものではない。

Muse GlimmerのDFlashとは何か？

DFlashは投機的デコードのコンパニオンモデルであり、将来のトークンブロックを提案し、メインモデルが並行して検証する。Metaはテスト構成において、DFlashがM4 Maxでデコード速度を1.5倍、M5 Maxで1.8倍、RTX 5090で3.1倍向上させたと報告している。

要約

Muse Glimmerは、Metaスーパーインテリジェンス研究所が発表した新しい30Bオープンウェイトモデルで、ローカル常駐型AIエージェント向けに設計されています。Muse Sparkからの蒸留によって作られており、Sparkの直接的なオープンソースコピーではなく、マルチモーダル入力、ツール呼び出し、コーディング、長文脈推論、障害復旧、100以上の訓練言語を統合しています。

エンジニアリングの重点はローカル展開に置かれています。Metaは24GBおよび32GBメモリ環境向けに設計された量子化構成、128K以上のコンテキストウィンドウ、そしてDFlashと呼ばれる投機的復号のコンパニオンモデルを提供しており、生成速度を大幅に向上させるとしています。

ローカル実行により、開発者はプライベートファイルや個人コンテキストに対するより多くの制御を得られると同時に、ホスト型推論への依存を減らせます。しかし、これは接続されたエージェントワークフローを自動的にプライベートまたはオフラインにするものではありません。リモートのメール、カレンダー、ブラウザ、MCP、その他のサービスは依然としてそれぞれのデータフローを生成します。

今回のリリースは、Metaのより広範なパーソナルスーパーインテリジェンス戦略とも合致しています。ザッカーバーグは、高度なAIは広く流通し、無料または手頃な価格で提供され、少数の機関に集中するのではなく、個人がますます掌握すべきだと考えています。

Muse Glimmerの意義は、30Bモデルが最大のクラウドモデルに取って代わることではなく、本格的なマルチモーダルエージェント機能が、個人開発者やパワーユーザーが所有・制御できるハードウェアに登場しつつあることです。