MetaがMuse Sparkの重みを公開：816B・100万トークンのコンテキスト、Mac Studio 2台で稼働可能、ローカルでのコーディングとエージェントタスクに対応

Metaはオープンウェイトモデル「Muse Spark Open」をリリースした。公式には現在最も高性能な米国のオープンウェイトモデルと位置づけられている。その主な特徴は以下の通りである。

• コードおよびエージェント向けに特化した設計：エンドツーエンドの複雑なソフトウェアエンジニアリング、長期的な計画立案、複数ステップの推論に焦点を当てている。
• マルチモーダル入力とテキスト出力：テキスト、画像、動画、音声の混合入力をネイティブでサポートし、テキストおよび構造化されたツール呼び出しを一元的に出力する。
• プライベート運用およびローカルデプロイに対応：クラウドAPIに加えて、自前のデバイス上での実行も可能。公式のデスクトップ向けアプローチでは、それぞれ512GBの統一メモリを搭載した2台のM5 Ultra Mac Studioを使用し、NVFP4量子化バージョンを稼働させる。

コーディングや動画編集のタスクをどのように処理するか

実際のタスクにおいて、Muse Spark Openはマルチモーダルの混合入力とプレーンテキストの出力をサポートし、最大100万トークン（1M）のコンテキストウィンドウを提供する。ただし1Mはウィンドウ容量の上限値であり、いかなる超長文の入力に対しても信頼性の高い検索や100%の実行成功を保証するものではない。

本モデルが想定する中核シナリオは、エンドツーエンドのエージェント開発である。モデルの重みをダウンロードしたからといって、コンピュータを直接操作する機能が即座に手に入るわけではない。モデル自体は入力の理解、ステップの計画立案、インターフェース仕様に沿ったツール呼び出しテキストの生成を担い、具体的なアクションはサンドボックス、ターミナル、OS上で外部のエージェントフレームワーク（Muse Codeやオープンソースの実行フレームワークなど）が代行する必要がある。この一連の処理は次のプロセスで進行する。

1. 入力と環境からのフィードバックの取得：モデルはコードファイル、ユーザーの要件、スクリーンショット、または直前のツール実行結果を受け取る。
2. ツール呼び出しの生成：モデルは現在の状態を分析し、次に呼び出すツール名とパラメータ（ファイルの編集、コマンドの実行、APIの問い合わせなど）を生成する。
3. 外部フレームワークによる実行と結果の返却：外部エージェントフレームワークが実環境を呼び出して操作を実行し、標準出力、エラーログ、新しいスクリーンショットをモデルにフィードバックする。
4. モデルによる分析と修正：依存関係の競合、コンパイルエラー、テスト失敗が発生した場合、モデルは返されたエラー情報に基づいてパラメータを調整し、コードを修正して再試行する。各ステップで結果の確認が不可欠となる。

例えば、典型的なUI修正タスクを想定してみよう。ユーザーがエージェントにスタイルの崩れた画面のスクリーンショットと該当するフロントエンドのコンポーネントコードを提示する。モデルはまずスクリーンショット上の視覚的な崩れとコード構造を突き合わせ、競合しているスタイル属性を推測して修正パッチを出力する。外部エージェントフレームワークがその変更をファイルに書き込み、ローカルのビルドコマンドを実行する。ビルドツールが構文エラーを返した場合、フレームワークはそのエラーログをモデルに送り返す。モデルはエラー内容を読み取ってコードを修正し、再びフレームワークに実行させて結果を検証させる。この例は動作の仕組みを説明したものであり、モデルが常に修正に成功することを意味するわけではない。

Metaが公開した技術事例でも、同様のワークフロー連携が示されている。

• iOSクライアント「Ice Cubes」の開発：ローカルデバイス（オンデバイス＝完全オフラインではない）上で、モデル駆動型のMuse CodeがオープンソースのMastodonクライアントのコードを読み込み、バグを特定し、パッチを作成してローカルプロジェクトのビルドを完了させた。
• DaVinci Resolveによる動画編集：モデルがエージェントとしてDaVinci Resolveを操作し、素材映像をフレーム単位で精査して見どころ（strongest moments）を見つけ出し、縦長動画へのリフレーミングを実行した。

計算に使うのは42Bパラメータのみなのに、なぜ816Bの重みをすべて保持する必要があるのか？

今回リリースされたモデルは、総パラメータ数が8160億（816B）に達する。Muse Spark Openが2台のデスクトップデバイスでの協調動作を実現できた核心は、そのスパース混合エキスパート（MoE）構造にある。

• MoEエキスパートアーキテクチャ：モデルの総パラメータ数は816Bで、全62層で構成される。各MoE層には256個のエキスパートFeed-Forwardネットワークが含まれ、単一トークンの生成時にはフロントエンドのルーターが最も関連性の高い8個のエキスパートを選択して計算に参加させる。モデル全体としてトークンあたりにアクティブとなるパラメータ数は約42Bである。
• 計算能力とメモリアクセスのオーバーヘッド：1トークンあたりにアクティブ化されるのは42Bパラメータにとどまるものの、実際の浮動小数点演算量やレイテンシは、同規模のデンスモデルと同等に扱えるわけではない。アテンション層、ルーティング処理、メモリアクセス帯域幅、さらにはマシン間の通信によって追加のオーバーヘッドが生じる。
• 重みの常駐：公式のデプロイ手法では、メモリまたはVRAM上にモデル全体の重みをロードしておく必要がある。呼び出されるエキスパートが少数であることは、各ステップの計算に関与する部分を削減しているだけであり、残りのパラメータがモデルから削除されたわけではない。

2台のMac Studioでこのモデルを実行するには、以下の条件が求められる。

1. 統一メモリ構成：Apple M5 Ultraチップを搭載し、各512GBの統一メモリを備えたMac Studio 2台（合計1TBの統一メモリ）、または256GBモデル4台を採用する。メモリ容量は「重みをどこに置くか」を解決し、帯域幅は「重みを読み出す速度」を決定する。M5 Ultraは1台あたり1.2TB/sの統一メモリ帯域幅を提供し、GPUが現在のトークンに必要な重みを迅速に読み取れるようにする。実際の生成速度は、演算処理と2台のマシン間通信にも左右される。
2. NVFP4量子化バージョン：実行されるのはNVFP4重みであり、主にMoEエキスパートの重みを4-bitに圧縮しつつ、一部の層はBF16を維持している。静的ファイルのサイズは約537GBである。ただし537GBは重みファイルのディスクサイズに過ぎない。実行時には、処理済みコンテンツをキャッシュするKV Cache、中間計算結果、OSシステム領域用のメモリを確保する必要があるため、「総メモリ容量から重みサイズを差し引いた差分」だけで1Mウィンドウを満杯まで実行できると判断することはできない。
3. MLXによるテンソル並列分割：最新版のApple MLXフレームワークを利用し、各層の256個のエキスパートは2台のマシン間でテンソル分割される。2台のデバイスはそれぞれ重みパラメータの一部を保持し（前半128個をマシンA、後半128個をマシンBに分ける方式ではない）、推論時には重みをローカルに保持したまま、デバイス間をThunderbolt 5で直結してRDMAを有効化し、中間アクティベーション結果を転送する。

Mac 2台によるデスクトップ環境のほか、公式ドキュメントにはデータセンター向けGPUの構成例も記載されている。

• NVFP4デプロイルート：静的重みは約537GBで、公式には最低700GBのVRAMが必要とされる。単一ノードのNVIDIA Blackwell Ultra 4基構成（TensorRT-LLM経由で実行）またはH200 8基構成で検証済みである。
• BF16リファレンスルート：フル精度の重みは約1.65TBで、ドキュメントの例では約2TBのVRAM予算が示されている（例：NVIDIA B300 8基のクラスタ）。

サードパーティのUnslothは、Dynamic GGUFによる単一ワークステーション向けルートも提供している。その2-bit版で記載されている総メモリ要件は約250〜316GBであり、これはシステムメモリとVRAMの合計、またはAppleデバイスの統一メモリを指す。最小のUD-IQ2_XXSは256GB構成に収まるが、Unslothはエージェントタスクには少なくともUD-IQ2_Sを選択することを推奨している。これより小さいバージョンでは一般的なタスクで性能劣化が発生する一方、チャットタスクであればより小さいサイズでも対応可能である。そのため、モデルに単純な会話をさせる場合と、連続してコードを修正させる場合とでは、最適な量子化ファイルが異なる可能性がある。また、コンテキストを長くするほどメモリ消費も増えるため、各バージョンのタスク品質や処理速度は個別に検証する必要がある。バージョンとその選定基準についてはUnslothガイドを参照されたい。

重みをメモリに収めた後は、投機的デコード（Speculative Decoding）によって生成の待機時間を短縮することも可能だ。小型のドラフトモデルがあらかじめ複数のトークン候補を提示し、Muse Spark Openがその候補群を一括で検証して要件を満たすものを採択することで、大規模モデルが1トークンずつ順番に生成するステップ数を削減する。SGLangではDFlash V2、vLLMではDSparkが対応している。公式の開発ガイドによると、DFlashはAMD MI355X上で単一リクエストのスループットが3.7倍、16並列リクエスト下で2.9倍に向上したと報告されている。ただしこれは該当するGPUおよびテスト構成における測定結果であり、Mac 2台環境の速度にそのまま換算することはできない。

低レベルの計算処理にも最適化が施されている。SGLangのHelion GPUカーネルは、NVIDIAおよびAMDのGPU上で1.03〜3.95倍のカーネルレベルの高速化を達成しているが、AMD MI350におけるエンドツーエンドの向上率は3%であった。局所的な演算カーネルの高速化と、リクエスト全体の処理速度向上は異なる指標である。

実環境のタスクにおいて、このベンチマークスコアをどう捉えるべきか

MetaはMuse Spark Openを「現在最も高性能な米国のオープンウェイトモデル」と位置づけている。公式の評価手法に関する説明によると、今回公表された評価データはすべてがMeta自社による測定ではなく、第三者の公式リーダーボード（Scale AI、Artificial Analysisなど）、Meta社内テスト、一部のベンダー自己申告データが混在している。各モデルの測定時には、それぞれ公式に推奨されている最高レベルの思考設定（Museはxhigh、GLMおよびKimiはmax、Nemotronはthinking有効）が適用されているが、最高レベルという呼称が似ていても、同等の計算量、時間、コストが費やされているとは限らない。

同一のスコア比較表の中でも、競合をリードしている項目と後れを取っている項目が混在している。

展開して公式の横断ベンチマーク比較図（原本）を確認

• 優位な項目：実務における業務プロセスを扱うJobBench（61.8）や、実際のMCPプロトコルによるツール呼び出しを評価するMCP-Atlas（89.2）において、Muse Spark Openはトップに立っている。また、ツールの支援を受けない難関知識・推論QAのHLE-Diamondで26.1ポイント、知識信頼性テストのAA-Omniscienceで25ポイントを獲得した。マルチモーダル視覚ベンチマークのZeroBenchでは50.0ポイントを記録した（ただし本項目はツール支援下で5回のサンプリング中少なくとも1回正解した割合を示すpass@5の基準であり、単一試行の正解率ではない点に留意が必要である）。
• 後れを取る項目：実環境のターミナル対話を実行するTerminal-Bench 2.1のスコアは76.4にとどまり、Kimi K3（85.0）、GLM 5.3（83.9）、Qwen3.8（82.0）、Beam（80.1、※Beamは実行フレームワーク未公開、その他のターミナルスコアはTerminus 2に基づく）を下回った。また、コードのバグ修正を評価するDeepSWE 1.1のスコアは60で、Kimi K3（68）やGLM 5.3（67）に及ばなかった。DeepSWEでは各モデルがそれぞれ最適なエージェント実行フレームワーク（Muse Code、Claude Code、Kimi Codeなど）上で動作しており、このスコアはモデルと実行フレームワークの組み合わせによる総合的な性能を反映している。

これらの結果が裏付けているのは、特定タスクにおける強みである。Muse Spark OpenはJobBenchやMCP-Atlasでは掲載モデルをリードしているものの、総合指数、Toolathlonのような長期ツールタスク、ソフトウェアエンジニアリングの全般で優位に立っているわけではない。採用にあたっては、まず自社の業務プロセスやMCPツールを使って検証してみるのが賢明だ。ターミナル操作、コード修正、複数ソフトウェアに跨る長期実行を重視するタスクであれば、同じ比較表にある他のモデルと実行フレームワークの組み合わせも比較検討すべきである。なお、本モデルには追加の安全性ポストトレーニングが施されているが、実際にツールと接続する際には、システムの外側で実行権限を管理し、不可逆な操作には人間の確認ステップを挟む必要がある。

どこから使い始めるか、費用はどう算出されるか

開発者や企業チームは、実際のニーズに合わせて適切な利用方法を選択できる。

1. クラウドホスティングAPI： サードパーティの推論プロバイダーがすでにモデルをサポートしている。Baseten、Fireworks AI、Modal、Nebius、OpenRouter、Together AI などが含まれ、Groq は現在、複数ステップのエージェントループ向けに限定プレビューを提供している。Museライセンスが付与する無償利用権はモデルの重み自体を指しており、クラウドAPIの推論が無償になるわけではない点に注意したい。各サービスプラットフォームは、それぞれのトークン使用量や専用の計算リソースに基づいて個別に課金を行う。

2. クラウドモデルカタログ： Amazon SageMaker AI、Google Cloud Model Garden、Microsoft Foundry Models のオンラインモデルカタログにおいて、モデル重みの取得およびプライベートデプロイへのアクセスが提供されている。

3. ローカルおよびプライベートクラスタへのデプロイ： 開発者はHugging FaceのモデルコレクションからNVFP4またはBF16の重みを入手できる。Mac 2台構成のルートはMeta公式Macデプロイガイドから開始する。各マシンでmacOS 26.2以降、MLX 0.30.1以降が動作している必要があり、マシン間はThunderbolt 5で直結してRDMAを有効化し、メイン機からパスワードなしSSHで他方のプログラムを起動できるように設定する。

   ディスクには完全なファイルを保持し、メモリにはそれぞれのシャードをロードする。 このガイドによると、各Macのディスクには約537GBの完全なNVFP4チェックポイントを格納する必要がある。起動時にMLXがそれぞれの担当するテンソルシャードを統一メモリにロードする仕組みだ。そのため、各マシンに重みファイルの半分のディスク容量しか用意しないということはできない。

   プライベートGPUノードではSGLang、vLLM、TensorRT-LLMと連携して実行できる。詳細な設定は開発ドキュメントを参照されたい。単一ワークステーションでの低ビット版を選択する場合は、前述のUnslothの手法を参考にする。

4. ポストトレーニングとカスタマイズ： 自社の業務に合わせて追加学習を行いたい場合は、PyTorchのTorchTitanなど対応済みのフレームワークを利用できる。

API呼び出し時には、reasoning_effortパラメータでlow、medium、high、xhighの4段階を選択できる。モデルカードのデフォルトはxhighであり、複雑なプログラミングやエージェントタスクにはhighまたはxhighが推奨され、迅速な応答を求める単純なタスクにはlowまたはmediumが適している。公式に推奨されているサンプリング設定は、temperature = 1.0、top_p = 1.0、およびtop_kの無効化である。

ライセンス条項（Muse Model License）

Muse Spark Openは、オープンウェイトを対象とするMuse Model Licenseを採用している。条項を満たす限り、改変、ファインチューニング、蒸留、マージ、再配布が可能であり、Metaはモデルが生成した出力に対する所有権を主張しないことを明記している。利用にあたっては、クレジット表記、利用規約（Usage Policy）、商用サービス条件を遵守する必要があり、主な制約は以下の3点である。

1. クレジット表記の要件：本モデルまたはその派生物に基づいて構築された製品やサービスのユーザーインターフェース、付属ドキュメント、ウェブサイト、または設定画面において、"Built with Muse Spark Open" を明瞭に表示すること。
2. 利用ポリシー（Usage Policy）の遵守：利用および配布は、ライセンスに付属するUsage Policyのセキュリティおよびコンプライアンス要件に準拠していること。
3. MaaSに関する追加契約の要件：第三者に対してモデルサービス（Model as a Service：API等のインターフェースを通じて第三者にモデル出力を提供する事業形態）を提供し、かつ当該事業体およびその関連会社の連続する任意の12か月間における総売上高が累計2,000万米ドル（US$20 million）を超える場合、事前にMetaへ通知し、別途書面による契約を締結しなければならない。

なお、このMaaS制限からは、社内利用、研究開発、その他の非MaaS商用活動、および自社の非MaaS製品の構成要素としてモデルを組み込み機能を提供する場合が明示的に免除されている。