GLM 5.2 が最近 AI のタイムラインを席巻しており、議論の中心は Opus との比較になっています。それが注目すべき点です。しかし、実際の使用状況は別の静かな物語を語っています。私が一緒に仕事をしている開発者たちは、MiniMax M3 を大規模に使い続けています。なぜなら、M3 は同等の長期的な能力を、はるかに低いコストで提供するからです。実際、MiniMax M3 は Open Router 上のトークン使用量で、依然として GLM 5.2 を 50% 以上リードしています。
長期的なエージェントの主な制約は、知能ではなく、増大するコンテキストに対するアテンションのコストでした。 @MiniMax_AI M3 は、その制約を取り除くために作られています。500K トークンのコンテキストウィンドウは、オープンウェイトモデルで利用可能な最長クラスの一つですが、重要な能力は、コンテキストが増え続ける中で、何時間も単一のタスクに集中し続けられることです。M3 はマルチモーダルであり、ネイティブの画像・動画理解機能を備えているため、同じエージェントがテキスト、コード、視覚的入力を1回の実行で処理できます。
Fireworks のローンチ記事は、インフラストラクチャの観点から同じ点を指摘しています。M3 を、フロンティアレベルのコーディング、ネイティブの画像・動画理解、そして 500K トークンのコンテキストウィンドウを1つのシステムで組み合わせた、Fireworks 初のオープンウェイトモデルとして位置づけています。この記事で重要な実際的な主張は、Fireworks がそのローンチ記事で報告しているものです。M3 は、長いコンテキストのデコードで M2.7 比で最大 15 倍高速化、長いコンテキストでのトークンあたりの計算コストは 1/20 に削減され、Fireworks は論文再現や CUDA カーネル最適化タスクにおいて 12 ～ 24 時間の自律実行が可能だと述べています。
長期的なタスクは、コンテキストが増え続けるため要求が厳しくなります。数時間にわたるエージェントの実行では、コード、ログ、ツールの出力、中間的な推論が蓄積され、標準的な高密度アテンションでは、新しいトークンごとに事実上これらすべてを再読み込みすることになります。コストは長さの二乗に比例して増加するため、エージェントが長く動作すればするほど、各ステップのコストが高くなります。これが、ほとんどの長時間実行エージェントが途中で打ち切られる実際的な理由です。
この状況を変えるメカニズムが、MiniMax の最近のレポート MiniMax Sparse Attention で文書化されている MiniMax Sparse Attention (MSA) です。MSA は、各ステップでモデルが読み取るものを変更します。アテンションの前に、軽量な事前フィルタリングパスを実行します。インデックスブランチがコンテキストをブロック単位でスコアリングし、現在のトークンに最も関連性の高いブロックを選択し、モデルはそれらのブロックにのみアテンションを適用します。ライブラリ全体ではなくインデックスを読み取るため、コンテキストが数十万トークンに増えても、各ステップのコストはほぼ一定に保たれます。
MiniMax Sparse Attention: 軽量なインデックスブランチがキー・バリューブロックをスコアリングし、クエリグループごとに上位 k 個を選択します。メインブランチはそれらのブロックにのみアテンションを適用します。出典: MiniMax Sparse Attention 論文。
M3 を使って開発する場合、これが意味することは次のとおりです。
- 任意の長さで予測可能なコスト。 論文では Bk = 128、k = 16 と設定されているため、各クエリと GQA グループは 16 ブロック、つまり 2,048 のキー・バリュートークンを選択します。長時間の実行でもインデックス作成のオーバーヘッドは発生しますが、メインのアテンション予算は固定されたままです。
- 安価な長いコンテキスト。 論文のモデル構成では、同じヘッド設定下で、極端なシーケンス長において高密度 GQA と比較して、トークンあたりのアテンション FLOPs が 28.4 倍削減されると報告されています。
- 本番環境での高速性。 H800 での長いシーケンス長において、プリフィルで 14.2 倍、デコードで 7.6 倍のウォールクロック速度向上が報告されています。別の top-k ベンチマークでは、MiniMax の専用カーネルが、テストされたすべての設定で torch.topk や TileLang よりも高速であることが示されています。
- 最小限の品質低下。 109B MoE 実験では、トークンあたり 6B のアクティブパラメータが報告され、MSA-CPT は長いコンテキスト拡張後も完全アテンションベースラインに近い状態を維持すると述べられています。各クエリが 2,048 トークンにアテンションする中で、MMLU、GSM8K、HumanEval、RULER、HELMET など多くのベンチマークで評価されています。
シーケンス長が増加するにつれて、MSA のトークンあたりのアテンション FLOPs とレイテンシはほぼ一定に保たれるのに対し、高密度 GQA (グループ化クエリアテンション) は急激に上昇します。極端なシーケンス長では、計算量が 28.4 倍削減、プリフィルが 14.2 倍高速化、デコードが 7.6 倍高速化されます。出典: MiniMax Sparse Attention 論文。
これによって可能になること
興味深い点は、M3 がより多くのトークンを保持できることだけではありません。長いコンテキストが、時間の経過とともに状態を維持する必要がある反復システム内に収まるほど安価で高速になることです。
- 自己改善エージェント。 これが私が最初に注目するアプリケーションです。自己改善エージェントは、次の変更を提案する際に、現在のコード、以前の失敗した編集、評価ログ、ベンチマーク結果、そして自身の仮説をすべて視野に入れておく必要があります。スパースアテンションは評価を解決するわけではありませんが、長期間にわたる提案、検証、修正のループが、コンテキストコストによって崩壊する可能性を大幅に減らします。
- リポジトリ規模のエンジニアリング。 Fireworks は、リポジトリ全体のコード理解と強力なエージェントコーディングを強調しています。これは、実際のエンジニアリング作業がきれいなプロンプトに収まることがほとんどないため重要です。コードベース全体でのデバッグ、回帰の追跡、複数ファイルにわたる変更はすべて、リポジトリ、テスト出力、編集履歴を1つのセッションで維持できるエージェントの恩恵を受けます。
- 科学およびシステム研究。 Fireworks は、論文再現と CUDA カーネル最適化に関する長時間の自律実行を指摘しています。これらは有用な例です。なぜなら、その作業は単一の答えではなく、継続性こそが製品の特徴である一連の実験、ログ、失敗、修正、測定だからです。
- マルチモーダルな長いコンテキストワークフロー。 M3 はネイティブにマルチモーダルであり、テキストのみにビジョン機能を後付けしたものではありません。長いコンテキストとネイティブの画像・動画理解を組み合わせているため、1回の実行でテキスト、コード、スクリーンショット、図、動画フレームを横断して推論できます。これにより、モックアップやスクリーンショットからのビジュアル to コード、動画分析、マルチモーダル文書レビュー、そして長時間のセッションにわたってコードやツールのトレースとともに視覚的コンテキストを維持するエージェントへの道が開かれます。
これが、このモデルが開発者にとって興味深い理由です。長いコンテキストを、文書読み取り機能から、メモリ、反復、検証を必要とするエージェントの実行基盤へと移行させます。
なぜ今これが登場しているのか、注目に値します。MiniMax は M2 世代の間にスパースアテンションを導入しましたが、インフラがまだ成熟していなかったため保留しました。M3 では、カーネルに焦点が当てられました。MSA はコンテキストをブロックに分割し、各ブロックを連続メモリアクセスで1回読み取り、関連するブロックにのみアテンションを適用します。これにより、品質を維持しながら、他のオープンなスパースアテンション手法よりも数倍高速に実行できます。
これは、私が焦点を当ててきたコンテキストエンジニアリングの取り組みに直接つながります。長年にわたり、私は開発者にコンテキストウィンドウに入れるものを厳選するよう奨励してきました。MSA は、モデルがウィンドウ内でアテンションを適用する対象を厳選することを学習するものです。同じ原理が、アーキテクチャの1層下に移動します。
開発者や研究者にとって、これは短いデモと、信頼できるツールの違いです。つまり、リポジトリ全体を1回で読み取り、コードベース全体を1回の持続的なセッションでデバッグし、あるいは研究タスクを何時間もの実験、ログ、修正を通じてコンテキストを失うことなく実行できるエージェントを意味します。MiniMax 自身の長期的な実行では、最も強力な結果は、ほとんどのモデルが頭打ちになり停止するであろう、数時間にわたるセッションの深いところで現れることがよくありました。手頃な価格の長いコンテキストこそが、エージェントにそのような持続力を与えるのです。
これが私が最も魅力的だと感じる部分です。私が構築するエージェントは、通常、モデルが弱いからではなく、長期的なタスクを維持できないために失敗します。そして、信頼性の高い長いコンテキストは、ついにこれに対処する基盤となるインフラなのです。
MiniMax M3 を始めるには
技術チームにとって、@FireworksAI_HQ のポイントは実用的です。M3 のスパースアテンション設計は、サービングレイヤーが長いコンテキストでもレイテンシ、スループット、コストを安定して維持できる場合にのみ有用になります。Fireworks は、MiniMax のファーストパーティ API 推論を強化し、MiniMax モデルシリーズで最速のエンドポイントを提供し、M3 の価格を入力トークン 100 万あたり 0.60 ドルから、サーバーレスおよびオンデマンドデプロイメントオプションで設定していると述べています。このレートでは、M3 は同等の使用量で GLM 5.2 よりも約 75% 安くなり、より大きなコンテキストウィンドウというよりも、長期的なエージェントが本番環境で経済的に実行できるかどうかという話になります。
この価格設定は、M3 を単なる新しいフロンティアモデルではなく、M2.7 からのアップグレードパスとして位置づけるため有用です。Fireworks は、オープンウェイトのローンチ価格が標準的なサーバーレス使用で M2.7 と同等になったと述べており、チームは前世代にプレミアムを支払うことなく、M3 の長いコンテキストとネイティブのマルチモーダル理解を利用できます。
M3 をテストするには、他の Fireworks モデルと同じ Fireworks チャット補完エンドポイントを使用します。モデル ID は accounts/fireworks/models/minimax-m3 で、モデルはマルチモーダルであるため、1 つのリクエストにテキストと画像 URL を同じメッセージに含めることができます。
1import json2import requests34url = "https://api.fireworks.ai/inference/v1/chat/completions"56payload = {7 "model": "accounts/fireworks/models/minimax-m3",8 "max_tokens": 32768,9 "temperature": 0.6,10 "top_p": 1,11 "top_k": 40,12 "messages": [13 {14 "role": "user",15 "content": [16 {"type": "text", "text": "この画像について説明してもらえますか？"},17 {18 "type": "image_url",19 "image_url": {20 "url": "https://images.unsplash.com/photo-1582538885592-e70a5d7ab3d3?auto=format&fit=crop&w=1770&q=80"21 },22 },23 ],24 }25 ],26}2728headers = {29 "Accept": "application/json",30 "Content-Type": "application/json",31 "Authorization": "Bearer <FIREWORKS_API_KEY>",32}3334response = requests.post(url, headers=headers, data=json.dumps(payload), timeout=120)35response.raise_for_status()36print(response.json())
より難しいエージェントタスクや推論タスクの場合は、ペイロードに "thinking": {"type": "enabled"} を追加します。本番環境のワークロードでは、Fireworks はサーバーレスを評価への最速のパスとして、オンデマンドデプロイメントを予測可能なスループットのオプションとして位置づけています。
こちらでお試しください：Fireworks AI
