効率的な推論のための MiniMax-M3 の提供：後悔のない 100 万トークンコンテキストとマルチモーダル性の解放

• Together AI は MiniMax M3 の優先的なクラウドパートナーです。Together AI は、公開リリース時にオープンウェイトモデルを開発者向けエンドポイントとしてホストします。
• 当社の推論およびカーネルチームは、M3 を効率的に提供するために重要なエンジニアリングのブレークスルーを達成しました。これには、KV-Block-Major スパースアテンションカーネル、MSA 向けの革新的なページドアテンション統合、高度に最適化されたインデックススコアリングカーネル、そして Rust ベースのマルチモーダル前処理ゲートウェイといった主要な最適化が含まれており、異なる並行度レベル全体でスループットが 81–125% 向上しました。
• 本番環境で大規模に MiniMax M3 を提供することは、現実世界のデプロイを可能にする困難なシステム問題においてフロンティアを押し広げるモデルにとって、Together AI が推論プラットフォームとしての最適解であることを実証するものです。

MiniMax は最新かつ最先端のモデル M3 を発表し、Together AI がその主要なクラウドパートナーとして選定され、大規模な本番環境で MiniMax が M3 を効率的に提供できるよう支援しています。今後数日以内に MiniMax M3 がオープンウェイトモデルとしてリリースされると、Together AI は開発者向けのエンドポイントとしてもこのモデルをホストします。このスケールを支えているのは、推論チームとカーネルチームの卓越した取り組みです。彼らは深いパフォーマンス最適化を推進し、1M トークンのコンテキストウィンドウ、ネイティブなマルチモーダル性、そして効率的に提供するために高度なエンジニアリングを要するアーキテクチャを持つ、フロンティアを押し広げるモデルに対して本番グレードの信頼性を確保しました。この記事では、その実現に至ったプロセスを追って解説します。MiniMax チームによる画期的なモデル発表と継続的なイノベーションに対し、おめでとうございます。

MiniMax M3 は、最先端のコーディング性能、エージェントワークフローのサポート、そしてネイティブなマルチモーダル推論を統合したオールインワンのモデルです。これらの機能に加え、1M コンテキストをサポートしながらも、提供コストが極めて経済的になるよう設計されています。これにより、長いドキュメント、コードベース、ツール利用、画像、反復的な推論などが頻繁に複合的に現れる実世界のタスクに対して、非常に適したモデルとなっています。前世代と比較すると、M3 の提供はより多くの課題を伴います。新しい機能には、スパースアテンション計算、大規模な KV キャッシュ管理、マルチモーダル処理など、複数の次元における最適化が必要となるためです。

アーキテクチャ / 特徴

M3 における最も革新的なアーキテクチャの変更点は、MiniMax Sparse Attention (MSA) です。これは MiniMax M2.7 で見られたアテンション計算のボトルネックに対処するために設計されたものです。そのブロックスパースアテンション機構は、各クエリが参照できるトークンの最大数を制限することで、長文コンテキスト処理のコストを削減し、より長いコンテキストウィンドウを実用的なものにします。これにより、プリフィリング段階で 9 倍以上、デコーディング段階で 15 倍以上の速度向上をもたらします。

本質的に、MSA の計算は 2 つの部分で構成されています。まず、各 KV グループに対して参照すべき最も関連性の高い K ブロックを決定するためのスコア計算を行い、次にクエリトークンとそれらのブロックの間で密なアテンション（dense attention）を実行します。この設計により、KV グループ次元における表現力は維持されつつも、クエリトークンが参照する KV トークンの最大数には制限が設けられます。アテンション計算自体はコンテキスト長に対して N^2 でスケーリングしなくなるため、長文コンテキストワークロードに非常に適しています。

B200 上で、並行度 8 の条件下でエージェント型トラフィック形状（60k プレフィックスキャッシュ）におけるカーネル実行時間の内訳を測定しました。MSA は、各イテレーションあたりの実際のアテンション計算にかかる壁面時間（wall time）の割合を大幅に低下させます。

アテンションアーキテクチャの変更に加え、M3 はビジョンコンポーネントと新しい画像・ビデオ前処理機能を備えたマルチモーダルサポートも搭載されています。

これらの根本的な変更により、Together AI は MiniMax のエンジニアリングチームと緊密に協力し、新たに浮上した課題に取り組んできました。主な課題には以下が含まれます：

• MiniMax のスパースアテンション計算自体は非常に効率的ですが、1M トークンのコンテキスト長をサポートすることは、エンジニアリングの観点からは依然として困難です。
• ビデオおよび画像処理は、テキストトークン化よりも本質的に複雑です。

最適化

KV ブロック主軸スパースアテンション

プリフェッチ（prefill）段階においても、長文コンテキスト入力に対して注意計算が大きな要因となり得ます。各トークンについて Selected *Block* * *KV Head Group* * *Tokens を計算する必要があるためです。ブロックスパースアテンションの性質上、複数のクエリが同じキー・バリュー（KV）ブロックにアテンションを向けることができます。したがって、各クエリを反復して KV ブロックとのアテンションを計算すると、GPU 上の HBM から SRAM への KV の移動が重複して行われることになります。一方、外側ループでキー・バリューグループを反復し、内側ループでクエリトークン間のアテンションを計算することで、KV キャッシュは一度だけ移動されるため、演算強度（arithmetic intensity）の向上が可能になります。

これを実現するには、{q, kv block} から {kv block, q} へのマッピングを再構成し、アテンションカーネルを再実装する必要があります。KV ブロックに対して部分的な O 出力のみを計算しているため、最終的に Log-Sum-Exp（対数和指数）に基づく「リダクション」を実行して、出力 O を再スケーリングし合計する必要があります。その手順は以下の通りです。

MSA を Paged Attention と統合する

現代の推論エンジンでは、リクエストごとの KV キャッシュ（Key-Value Cache）コンテキストを管理するために、ページ化アテンション（Paged Attention）が頻繁に使用されています。高度に最適化されたアテンションカーネルの多くは、固定サイズのページセットをサポートするように記述されています。これらのカーネルを使用できない要因は、KV グループ間で選択されるブロックが異なる点にあります。

Together AI では、MiniMax スパースアテンション（Sparse Attention）をエンジンに統合する新たなアプローチを提案します。デコード（Decode）時には、まず選択されたブロックに基づいてページテーブルを構築し、KV グループ次元をバッチ次元に平坦化します。さらに、KV キャッシュテンソルのストライド付きビュー（Strided View）を活用して、アテンションカーネルに必要なポインタを提供し、KV ページの取得を可能にします。その鍵となるのはストライドです：ページアドレスは D ずつ進んで仮想ページの開始位置を選択し、トークンは Hkv * D ずつ進みます。これにより、1 つの物理テンソンがヘッドごとのページにデインターリーブ（Deinterleave）され、各平坦化された行で異なるページテーブルを使用できるようになります。

この設計により、スパースアテンションをゼロから実装する必要なく、GQA（Grouped Query Attention）をサポートする既存のアテンションカーネルを利用できるようになりました。各クエリに対して選択されるブロック数は限られているため、ブロックとページ間のマッピングを検出するためのカーネルは非常に低いオーバーヘッドで動作します。この設計により、デコードスループットが 5% 向上しました。

Decode Index Scoring Kernel Optimization

デコード処理において、MSA（Multi-Sequence Attention）はコストの大部分を密なアテンション計算からスコアリング/トップ-k インデクサへ移行します。すべてのデコードクエリに対して、エンジンがクエリ側のインデックスベクトルと候補となるキー側のインデックスベクトルを比較し、各 128 トークンの KV ブロック（Key-Value Block）を単一のスコアに集約し、実際のアテンションカーネルのために上位のブロックのみを保持します。このスキャンは生成されるトークンごとにクリティカルパス上にあり、長いコンテキスト長においては候補となるブロック数がコンテキスト長とともに増加します。デコードスコアリングは「小規模クエリインデックス・大規模キーインデックス」という形状を持ちます。デコードクエリのバッチを一つの大きな GEMM（General Matrix Multiply）として扱うのは魅力的に思えますが、スコアリング/インデクシングステップは単なる密行列乗算ではありません。各リクエストおよび K グループには独自の候補ブロック範囲、マスキング、ブロックごとの集約、そしてトップ-k の境界条件が存在します。クエリを連結しても GEMM 周辺に「不規則なガザー＆リダクション」の問題が残ったままとなり、クリティカルパス上にパディングや追加の管理オーバーヘッドを強いることになります。そのため、最適化された経路では *AB-swapped HMMA レイアウト* を採用します。128 トークンのキーインデックスブロックを MMA の M 次元とし、クエリ側はより小さな*N*次元にのみパディングします。カーネルは非同期コピーで 128 トークンの K インデックスをステージングし、次のページをプリフェッチし、HMMA を用いて bfloat16 で内積計算を行い、各ページを単一のブロックスコアに集約します。

‍

ゲートウェイにおけるマルチモーダル前処理

SMG（Serving Model Gateway）は、OpenAI 互換 API と推論エンジン間に位置する Rust ベースのモデルゲートウェイです。ルーティングやトークン化を超えて、SMG は特にマルチモーダルモデルにとって重要な役割を担います：リクエストが GPU ワーカーに到達する前に、すべてのビジョン前処理を CPU で実行します。

画像およびビデオ入力には、ビジョンエンコーダで有用な形にするまでに相当量の CPU 処理が必要です。具体的には、ダウンロード、デコード、フレームサンプリング、リサイズ、そしてパッチテンソルへの変換です。これらを推論エンジン内で実行すると、生成に割くべきリソースが拘束されてしまいます。SMG はこれをゲートウェイ側で全て処理するため、リクエストが GPU に到達した時点では、すでにテンソルは準備完了しています。

M3 の場合、これは以下を意味します：ビデオを取得し、FFmpeg を用いてフレームを抽出し、FPS（Frames Per Second）に基づいてサブセットを選択し、リサイズと正規化を行い、時間次元を組み込んだ状態でパッチ化します。出力されるのはフラットなパッチテンソルと小さなグリッドメタデータテンソルで、これらは gRPC メッセージにパックされます。ワーカー側ではビジョンエンコーダを直接実行するだけで、その側での前処理は不要です。

また、SMG のマルチモーダルパイプラインは、モデル固有の前処理ロジックとパイプラインの基盤を分離する Rust トレイトを中心に構築されています。M3 のマルチモーダルサポートを追加するには、これらのトレイトを実装し M3 固有の定数を使用すればよく、パイプライン自体の変更は不要でした。このアーキテクチャは、ビジョン機能を備えたオープンソースモデルの大半に適用可能であり、推論エンジンランタイム全体で一般化されています。

パフォーマンス結果

MiniMax M3 の重みとモデルアーキテクチャを受け取って以来、推論パフォーマンスの向上に努めてきました。その結果、一般的なエージェント形状のトラフィックにおいて、さまざまな並行度レベルで 81% から 125% の性能向上を達成しました。

今後の取り組み

新しいアーキテクチャは、新たなインフラおよびエンジニアリング上の課題をもたらします。Together AI では、最高の推論パフォーマンスを提供することを目指しています。M3 に関して現在積極的に取り組んでいるトピックはいくつかあります:

1. スパースアテンション（sparse attention）アーキテクチャにより、より小さなカーネルが増加しました。例えば、KV ブロックに対する topk や、Q-KV マッピングを KV-Q に再マッピングするなどです。これらにはさらに多くのカーネル融合の機会があります。当社の Kernel Agent Research チームは、本番環境で直接使用可能なレベルのカーネルを作成するエージェントを開発中です。
2. CPU キャッシュへのオフロードにおいて、K インデックスと実際の KV キャッシュを分離して扱うことが可能になりました。現在、topk 選択に基づいて K インデックス全体を読み込み、KV キャッシュはオンデマンドで読み込む仕組みの開発を進めています。