Metaの新しい300億パラメータのMuse Glimmerは、MacBook Pro M2 Proにおいて、30億パラメータのLlama 3.2よりも56倍遅く動作します。これにより、ほとんどのローカルエージェントのワークフローを支える迅速で反復的な呼び出しにおいて、このモデルは実用的ではありません。
ローカルエージェントにとって速度が重要な理由
ローカルエージェントのループは、1分間に数十回、時には数百回のモデル呼び出しを行います。呼び出しのたびにレイテンシ（遅延）が加わり、その累積的な遅延がレスポンスを損なう可能性があります。そのため、開発者は精度を満たす最小のモデルを使用し、真に深い推論が必要な場合にのみ、より大きなモデルに切り替えるという手法をとります。Metaは、Muse Glimmerをこれらのループ向けに構築された「思考型（thinking）」モデルとしてマーケティングしており、オンデバイスの利点を損なうことなく、より豊かな推論を約束しています。
ベンチマークの設定
32GBのRAMを搭載したMacBook Pro M2 Proでテストを実施し、代表的な3つのタスクを測定しました。
- コンテキストの再読み込み速度 – モデルがすでに見たプロンプトをどれだけ速く処理できるか。
- 制約付きJSON抽出 – ツールを呼び出す前の一般的なステップである、自由形式のテキストから構造化データを抽出すること。
- ツール呼び出し – 正しくフォーマットされた関数呼び出しを生成すること。
3つのモデルを比較しました：
| モデル | プロンプト速度 (tok/s) | 生成速度 (tok/s) | JSON成功率 (5試行) | 1回あたりの時間 |
|---|---|---|---|---|
| Llama 3.2 3B | 702.9 | 56.7 | 5/5 | 0.6 s |
| Qwen 3 14B | 161.8 | 14.6 | 5/5 | 16.1 s |
| Muse Glimmer 30B | 56.7 | 7.1 | 5/5 | 33.4 s |
3つのモデルすべてが正確性の目標を達成し、すべての試行で同じJSON出力をもたらしました。3Bモデルはパイプライン全体を1秒未満で完了しましたが、30Bモデルは30秒以上を要しました。
数値が意味すること
56倍の低速化は、CPU使用率と実時間を直接的に増大させ、それがエネルギー消費の急増を招き、1台のマシンで同時に実行できるエージェントの数を制限します。「思考」モードをオフにしても、Muse Glimmerは熟考のために追加のトークンを消費し続けており、このレイテンシがオプションの機能ではなく、アーキテクチャ自体に組み込まれていることを示唆しています。
チャットボット、パーソナルアシスタント、または「カレンダーの予定を取得して」や「新しいメールを要約して」といった即時の反応が求められる自律型スクリプトを構築する開発者にとって、Llama 3.2の0.6秒というレイテンシは、人間が許容できる範囲内に収まっています。Muse Glimmerによる33秒の停止は、目に見えてしまい、本番環境ではおそらく受け入れられないでしょう。
Muse Glimmerが依然として役割を持つ場面
このベンチマークは、短期的で決定論的なタスクに焦点を当てました。Muse Glimmerが真価を発揮するのは、生成される追加のトークンが答えに落ち着く前に複数の解決策を探索できるような、オープンエンドな推論の場面です。複雑なコード合成、多段階のプランニング、あるいは曖昧なユーザーの意図の解釈など、微妙な判断を必要とするシナリオでは、より深いモデルが待ち時間を正当化できるほどの高品質な出力を生成する可能性があります。
コストに関する考慮事項
30Bモデルをローカルで実行すると、3Bモデルと比較して、より多くのGPUメモリと電力を消費します。ノートPCクラスのマシンでは、スループットが遅いことでCPUのアイドル時間も長くなり、バッチリクエスト全体の実行時間が延びます。クラウドと同等のコストを意識するチームにとって、このトレードオフは明白です。低速なローカルモデルは、ホストされた大規模モデルへの高速なAPI呼び出しよりも、推論あたりのコストが高くなる可能性があります。
今後の注目点
MetaはMuse Glimmerの詳細なパフォーマンスチューニングのガイドラインを公開していません。将来のファームウェアやドライバのアップデートにより、特に推論能力を損なわずにモデルを量子化または枝刈り（pruning）できる場合、速度差が縮まる可能性があります。複数の呼び出しをバッチ処理したり、中間プロンプトをキャッシュしたりするコミュニティ主導のツールキットも、特定のワークロードにおけるレイテンシを軽減する可能性があります。
開発者は以下を注視すべきです：
- 量子化の進展 – 低精度演算により、1秒あたりのトークン数（TPS）が向上する可能性があります。
- ハイブリッド・パイプライン – 定型的な抽出には小型モデルを使用し、信頼性の閾値を下回った場合にのみMuse Glimmerにフォールバックする。
- ハードウェアの進化 – 新しいAppleシリコンは、30Bの重み行列をより効率的に処理できる可能性があります。
まとめ
Muse Glimmerは30Bモデルが約束する深みをもたらしますが、現在のコンシューマー向けハードウェアでは、ほとんどのローカルエージェントを駆動する高頻度なループに対しては、あまりにも動作が遅すぎます。オンデバイスモデルは外部APIのように扱うべきです。まず精度要件を満たす最小のモデルから使い始め、重量級の思考モデルは、その高度な推論能力が真に必要とされるタスクのために取っておきましょう。Metaが速度の差を埋めるまでは、日常的な抽出、フォーマット、単純なツール呼び出しには3BのLlama 3.2が引き続き実用的な選択肢であり、Muse Glimmerは時折発生する深い思考を要する課題のためのエスカレーション層として位置づけられます。