MiniMax-M3.1-Flashは、MiniMax-M3ファミリーの最新モデルであり、推論、コーディング、エージェント型、視覚タスクのすべてにおいて改善が図られています。また、推論効率性のために、ネイティブなNVFP4 KVキャッシュ、NVFP4量化されたMoE重み、そして推測的なデコード用のDSparkドラフトモデルが搭載されています。
vLLMは、NVIDIA Blackwell GPUで日付0においてMiniMax-M3.1-Flashをサポートし、NVIDIA Rubin GPUでは専用のRubinカーネルを使用し、AMD MI350シリーズGPUでは強力なパフォーマンスをもたらすエージェント型ワークロードに対応しています。
TL;DR
- ミニマックススパースアテンション（MSA） ハイに NVFP4 KVキャッシュ インデクサーと注意パスの両方に、 NVFP4 MoEの重み そして、 DSpark 設計者。
- Blackwell MSAカーネルは、カーネル内部でNVFP4をFP8にデクアンタイズするために、新しいCUDA 13.4の
QMUL4命令を使用する。これにより、インデックスer QKデコードが1.7倍速く、スパースアテンションデコードが1.3倍速くなる。 - NVFP4 MegaMoEは、MXFP8共有エキスパート融合方式および早期のTMEMを採用しており、予備データ入力時のカーネルレイテンシーが20％低減し、予備データ入力のスループットが7％向上します。
- インデクサー・デコード・コンテキスト・パラレル処理（DCP）: 512Kコンテキスト、4×GB300の場合、スパースレイヤーあたり3.3倍の速さのインデクサーが可能。
- QKV GEMM + norm + RoPE + KV-insert融合: 512以上のトークンでのプレフィルが1.1–1.6倍速く、TP4時のP50 TTFTが約19%低くなる。
- FlashInfer PrimiTSのDSpark drafter用バックエンドについて：FlashAttention 4より1.3～2倍速く、5％短い全体的な前処理時間です。
- Rubin (SM107) MSAカーネルも、最先端の性能を誇るvLLMに統合されています。
- AMD MI350シリーズ: NVFP4ネイティブのMSAカーネル、インデクサー・デコード・コンテキスト並列処理、ダブルバッチオーバーオフ、そしてモノカーネルにより、全体的に2～3倍の性能向上が実現します。
- エージェントサービス：NVIDIA GB300では、遅延が重要な場合、1ユーザーあたり418.9 tok/sまで；NVIDIA Rubinでは、1ユーザーあたり724.9 tok/sおよび1GPUあたり191.5K total tok/sまで；AMD MI355Xでは、SemiAnalysis AgentXベンチマークにおいて、TCOあたり1ドルあたり133.3M total tokensまで。
- Day-0 RLサポート: NVFP4チェックポイント上でveRL、FSDP2、LoRAを使用したエンドツーエンドRL。
すぐに始める
既成の画像は両方のベンダーで利用可能です：
- NVIDIA：
vllm/vllm-openai:minimax-m31-flash - AMD:
vllm/vllm-openai-rocm:minimax-m31-flash
コードがレビューされ、アップストリームにマージされるまで、モデルは夜間のPyPIウィールでしか利用できない。これには通常1週間ほどかかる。完全なレシピはvLLM Recipesにあり、チェックポイントはMiniMaxAI/MiniMax-M3.1-Flashにある。
TP4 on NVIDIA
最良の性能を得るためには、CUDA 13.4ツールキットを推奨します。
vllm serve MiniMaxAI/MiniMax-M3.1-Flash \
-tp 4 \
--reasoning-parser minimax_m3 \
--block-size 128 \
--kv-cache-dtype nvfp4 \
--attention-config '{"indexer_kv_dtype": "nvfp4"}' \
--speculative-config '{"method":"dspark","num_speculative_tokens":7,"attention_backend":"FLASHINFER_TS","kv_cache_dtype":"fp8","draft_sample_method":"probabilistic"}' \
--disable-hybrid-kv-cache-managerTP4 on AMD
vllm serve MiniMaxAI/MiniMax-M3.1-Flash \
-tp 4 \
--reasoning-parser minimax_m3 \
--block-size 128 \
--kv-cache-dtype nvfp4 \
--attention-config '{"indexer_kv_dtype": "nvfp4", "indexer_decode_cp": true}' \
--quantization-config.moe mxfp8 \
--speculative-config '{"method":"dspark","num_speculative_tokens":3,"attention_backend":"TRITON_ATTN","kv_cache_dtype":"fp8","draft_sample_method":"probabilistic"}' \
--disable-hybrid-kv-cache-managerMSA入門
MiniMax-M3モデルファミリーは、推論をより効率的に行うために、ブロック型スパース注意機構の変種（arXiv 2606.13392）を用いて完全な注意を代替する。KVキャッシュは128トークンのブロックに分割される。軽量なインデックスエンジンは、GQAグループごとに1回のインデックスクエリでコンテキスト内の各キーをスコアリングし、その後、それらのスコアを各ブロックごとに1つのスコアとしてマックスプールする。主な注意処理は正確に実行されるが、上記の16ブロックのみで行われ、最新のブロックが常に保持される。これにより、コンテキストがどれだけ長くても、各クエリは2,048個のキーに制限される。
デコード時の報酬が最大であり、これはメモリ帯域幅によって制限される。各ステップでは依然として全文脈を含むインデックスキーをスキャンするが、各トークンあたりのレイヤー当たりのサイズは128バイトに過ぎず、密集注意機構が読む1,024バイトのK/Vの8分の1に相当する（FP8、4つのKVヘッド×128次元）。その後、選択された2,048個のトークンだけを全てのK/Vから読み出す。長文脈のデコードでは、各ステップのHBMトラフィックは密集注意機構が読む量の約12.5％に低下する。
図1：MiniMax Sparse Attention。各GQAグループのインディケーターは、自身のトップKVブロックを選択し、そのグループ内の各クエリヘッドは、そのブロックのみに注意を向ける。このプロセスを進めていく。
MiniMax-M3.1アーキテクチャの新機能
MiniMax-M3.1は前世代よりも推論効率を大幅に向上させている。NVFP4 KVキャッシュに対してネイティブな量子化認識訓練が行われ、そのルーティングMoEの重みはNVFP4に保存されている。NVFP4エキスパートにより、チェックポイントは451.5 GB（MiniMax-M3-MXFP8）から250.1 GBへと、44.6％小さくなった。NVFP4 KVキャッシュでは、FP8の場合の61,440バイトに代わって34,560バイトが必要となり、1トークンあたり43.75％の削減が達成されている。 DEP4の実装が行われた4台のNVIDIA B300 GPUと256Kトークンシーケンスを用いる場合、M3.1は76の同時処理シーケンスを処理でき、一方FP8 KVキャッシュを持つM3は28の同時処理シーケンスしか処理できない。これは同じハードウェア上で約2.7倍多くの処理が可能であり、サービス処理能力が直接的に向上する。
図2：MiniMax-M3.1は、インデックスerとスパースアテンションの両方でNVFP4 KVキャッシュを使用するために、量子化に配慮したトレーニングが行われています。KVキャッシュのデータ型、並列性、GPU、またはコンテキスト長を変更して、どれだけのシーケンスが収容されるかを確認してください。
パフォーマンス最適化
vLLMは、複数のハードウェアプラットフォームにおいて優れたMiniMax-M3.1性能を実現しています。NVIDIA GPUでは、NVFP4 KVキャッシュに最適化されたカーネルを提供しています。私たちのMSAリポジトリ（vllm-project/MSA）には、異なるワークロードや操作に最適化されたカーネルが含まれています。これには、MSAインデックスャイラーのプリフィルとデコード、スパースアテンションのプリフィルとデコード、そしてMSA専用のtop-kカーネルが含まれます。
図3：デコード時のBlackwell上に配置された1つのMiniMax-M3.1スパースデコーダ層（M ≤ 32）、カーネルごとに。番号付きのバッジはこの記事における最適化を表しています。一つをクリックするとそのカーネルが強調されます。
NVIDIA Blackwellが最適化したMSAカーネル
KVキャッシュはNVFP4に保存され、クエリはFP8に保持されるため、行列乗算にはネイティブのNVFP4テンソルコア命令を使用することはできない。代わりにカーネルがNVFP4 KVキャッシュをFP8にデクオネティゼーションし、FP8 MMAを実行する。デクオネティゼーションコストを低く保つために、CUDA 13.4で導入された新しいBlackwell専用PTX命令mul.e4m3x4.e2m1x4.e4m3x4 (SASS QMUL4)を使用する。この命令は4つのNVFP4値をスケール因子でスケールし、1つの命令で4つのFP8値を生成する。これにより、以前のFP16ラウンドトリップパスよりもはるかに少ないCUDAコア命令が必要となる。その結果、インデクサーQKデコードカーネルでは1.7倍、スパースアテンションデコードカーネルでは1.3倍の速度向上が達成される。
NVFP4 MegaMoE
MegaMoEは、現代のエキスパート・パラレル（EP）デプロイメントの重要な構成要素です。私たちは、MXFP8共有エキスパートを組み合わせたNVFP4精度のDeepGEMMのMegaMoEを拡張しました。これは私たちのフォークにオープンソースとして公開されています（vllm-project/DeepGEMM）。MegaMoEにNVFP4のサポートを追加することは、単なるデータ型の変更に過ぎません。NVFP4では要素あたりのバイト数が半減し、以前のFP8×FP4パスと比べてテンソルコアの処理能力が2倍になります。カーネルの他の部分も変更する必要があります。そうでなければパイプラインがバランスを崩れます。
そのような変更の一つは、FC1エピローグの早い段階でTMEMステージを公開することです。以前は、TMEMステージはエピローグが終了した後にのみ公開されていました。その待ち時間は不要です。なぜなら、エピローグは完全にレジスタ内で実行されるからです。accumulatorがレジスタに読み込まれるとすぐにTMEMを公開でき、算術処理が行われる前に完了します。これにより、最も重要な高速なNVFP4計算を行うプリフィル時の全体のカーネルレイテンシが20％短縮され、また全体のプリフィルスループットも7％向上します。
NVFP4インデクサーDCP（デコードコンテキスト並列性）
低遅延サービスにおいて、各GPUは全コンテキストを対象に自身のインデックスヘッドを評価する。4つのGPU全体で、各インデクサーライブランズは全インデックスキャッシュを4回読み込むことになる。一方、インデクサーDCPはコンテキストに基づいて作業を分割する。各GPUはページの4分の1について4つのヘッドすべてを評価し、その後、各ヘッドの最上位16個をNVLinkを通じてそのヘッドを管理するGPUに送信し、候補を最終的な最上位16個に統合する。 選択は正確であり、512Kのコンテキストで4台のNVIDIA GB300 GPUを使用すると、スパース層あたり最大3.3倍の速さでインデクタが動作します。
QKV GEMM + ノルム + RoPE + KVインサートフュージョン
MiniMax-M3.1のQKVおよびインデクサープロジェクションを用いて、全てのQKVテンソルをHBMに書き込まれる。次に、2番目のカーネルがそれを読み返し、ノーマル性、RoPE、KVキャッシュの挿入を行う。我々はこの全チェーンを単一のGEMMカーネルに統合した。そのエピローグ部分では、FP32アクセラレータを一つずつ処理する。このカーネルはクエリおよびインデックスクエリに対してノーマル性とRoPEを適用し、K、V、およびインデックスキーをNVFP4に量子化し、それらを直接キャッシュに書き込む。QKVテンソルはHBMに触れることはない。 GB300では、512個以上のトークンを含むバッチを事前に填充すると、1.1～1.6倍速く動作し、TP4時点でP50時間単位での最初のトークン到達時間（TTFT）は約19%減少する。
DSparkドラフター用のFlashInfer PrimiTS
MiniMax-M3.1は、推測的なデコーディングドレッターとしてDSparkを使用している。このドレッターは、4096トークンのスライディングウィンドウを用いて非因果的GQAを実行する。以前はvLLMがFlashAttention 4上でこのドレッターを実行していたが、これはデコード形状に最適化されていない。今回はFlashInferのPrimiTSバックエンドに切り替えた。PrimiTSはFlashAttention 4よりも1.3～2倍速く、全体的なフローラインタイムを5％短縮する。
NVIDIA GB300上のエージェント型ワークロードベンチマーク
vLLMはエージェント型サービスワークロードにおいて優れた性能を発揮します。私たちはNVIDIA GB300を用いて、SemiAnalysis AgentXベンチマークでデイ-0画像を評価しました（詳細は前の記事です）。遅延に敏感な領域では、MiniMax-M3.1-Flashはユーザーあたり每秒418.9トークンを記録します。さらに先へ進むと、各ユーザーあたりは每秒200トークン以上を維持し、GPUあたりの総トークン数は每秒38.6Kとなります。スループットの領域では、GPUあたり每秒153.8Kトークンに達し、最もインタラクティブな点の約24倍ですが、各ユーザーは依然として每秒約127トークンを見ることができます。
図4：NVIDIA GB300上のMiniMax-M3.1-FlashにおけるAgentX Paretoフロントライン。7個の推測トークンと、3.16–3.26トークン（最初のトークンを含む）の合成受け入れ長を持つ。指でポイントを置くとその指標が表示される。
NVIDIA Rubinの最適化されたMSA
また、このモデルをNVIDIA Rubin GPU上で最適化しました。NVFP4からFP8への変換にかかるオーバーヘッドを軽減するために、NVFP4を直接FP16に変換し、インデクサーではFP16でMMAスコアを計算します。これにより、デケンタンスの命令数が約3分の1減少し、スコアはE4M3の再丸めによるFP8 MMA実行を避け、正確な値になります。
≤4回のクエリで、1ヘッドインデックスャイダー・デコーディングカーネルはさらに進化する。MMA結果ごとに各ブロックスケールを1回だけ適用し、SM107のパッキングされたfma.rn.f32x2.f16x2を使用する。これはK値ごとに1回ではなく、K値ごとに1回だけ適用される。また、SMごとに3回のCTAを実行することで、レンダリングの遅延をより多く隠すことができる。Rubinのより大きな共有メモリ（Blackwellでは228KB対328KB）と追加のTensorメモリ列（Blackwellでは512対576）がその実現を可能にする。
最後に、RubinのSM数がBlackwellより多いため、作業計画者はSM数に基づいてタブレットのサイズを決定する。その結果、作業はRubinの212個のSMに均等に分布する。
希薄な注意を埋め込むことも、局所領域最適化によって恩恵を受ける。私たちはCUDA仮想メモリAPIを通じて部分バッファを割り当てることで、2MBページが二つの領域間で交互に配置され、組み合わせたカーネルが各タイルを、そのタイルデータを保持する領域にSMを持つCTAに渡す。Rubinでは、プリフィルとデコードの注意カーネルは、各インスタンスでK=64の密なFP8 MMAを使用しており、これによりMMA命令数が半減し、BlackwellのFP8レートの2倍で動作する。
NVIDIA Rubin上のエージェント型ワークロードベンチマーク
NVIDIA Rubin、MiniMax-M3.1-Flashでは、同じベンチマークにおいてさらに先へ進んでいます。遅延に敏感な領域では、ユーザー1人あたり毎秒724.9トークンを維持しています。さらに先へ進むと、各ユーザーは毎秒200トークン以上を維持し、GPUあたり総計157.3Kトークン/秒を提供します。スループットの領域では、GPUあたり毎秒191.5Kトークンに達し、各ユーザーは依然として約134トークン/秒を実現し、同じユーザーあたりのレートで約1.5×GB300となります。
図5：NVIDIA Rubin上のMiniMax-M3.1-FlashにおけるAgentX Paretoフロンティア。ポイントをホバーして、その設定と指標を確認する。
AMD GPU対応
AMD GPUではNVFP4 KVキャッシュサポートを実装し、AMDの導入環境でも低精度フォーマットを利用してKVキャッシュメモリを削減できる。デコードに関しては、長いコンテキストのデコードを高速化するためインデクサーDCPを追加し、低遅延の推論を高速化するためモノキュラルカーネルも実装した。プリフィルに関しては、シーケンス並列性とデュアルバッチオーバーラップによりエンジン内の通信を削減し、新しいKVキャッシュレイアウトにより各KVブロックが単一の転送でデコードノードに移動できる。MSAおよびモノキュラルカーネルは、FlyDSLというAMDのGPUカーネル用Python DSLであり、FlyDSLチームの協力を得て構築されている。FlyDSL
NVFP4 MSAカーネル
MiniMax-M3.1は、メインアテンションとインディクサーの両方にNVFP4 KVキャッシュ（QAT）を使用してトレーニングされているが、CDNA4にはNVFP4をデカント化するためのネイティブな命令がない。MSAカーネルを高速に保つために、デカント化をテーブル検索に変換している。可能なE4M3スケールは256種類のみであり、E2M1の大きさも8種類であるため、各スケール値をFP8形式で丸めして、LDS方式で2KBのテーブルとして事前計算する。 v_perm_b32 ビットを交換し、符号ビットに対してXORを加え、次に4つのFP4値をFP8に変換する。カーネルは、共有プレフィックスページを64回のリクエストまで、一度だけデクアンタイズする。これらを合わせると、選択されたブロックをFP8に変換してFP8アテンションカーネルを実行するよりも、スパースデコードが2.5倍速くなる。
NVFP4インデックスer DCP
NVIDIAと同様にAMDでも同じインデクサーによるデコードコンテキスト並列処理を使用しており、CDNA4ではさらに有利な効果が得られる。DCPがない場合、TP4の各GPUは全コンテキストにおいて自分自身のインデックスヘッドを獲得するため、インデックスキャッシュが4回読み込まれる。これによりマトリックスコアが過度に使用されない状態になる。DSpark-3のデコードステップでは、リクエストごとに4行のクエリが行われ、16×16×128 FP8 MFMAの16列のうちわずか4列しか埋められない。 DCPでは、各GPUがコンテキストの4分の1を超える範囲で4つのヘッドすべてを評価するため、4つのヘッド×4行で16列全てが埋まる。単一のカーネルがインデックスクエリを行い、ブロックを評価し、各ヘッドのスコアをInfinity Fabric上の所有するGPUのメモリに直接書き込む。デバイス側のハンドシェイクにより、HIPグラフ内でこの動作が維持される。所有者は以前と同様にトップ16を選択し、スコアが単一GPU版とビットごとに同一であるため、その選択は正確である。 4× MI355Xでは、スパース層ごとにインデクサーが最大2.8倍速く動作し、30K～210Kトークンを含む45件のリクエストに対応可能です。
SP + DBOプレフィルドとワンリードKV転送
TP4では、MI355Xにおける長いプリフェルドのプリフィルは、ノード内のGPU間やプリフェルドノードとデコーディングノード間の通信によって制限される。エンジン内部では、デュアルバッチオーバーラップ（DBO）により、テンソル並列処理が他のマイクロバッチの計算の背後に隠れる。シーケンス並列性（SP）によりトラフィック自体が削減される。各GPUはトークンの4分の1を保持し、注意出力はMXFP8で全方向に交換されるため、各GPUは自身のトークンに対して完全なo_projを実行し、MoE出力は分散される。これにより、各GPUあたりのトークループトラフィックが約36KBから20KB/トークン/レイヤに減少し、ノーメント処理、量子化処理、ルーター処理はトークンの4分の1のみで実行される。
より高速なプレフィルエンジンは、KVキャッシュがデコードノードにも迅速に到達できる場合にのみ役立ちます。vLLMのレイヤーバイレイヤーのKVキャッシュ構造では、各KVブロックを125個の小さなページに分割し、各ページは独自のNIXL RDMA読み込みが必要です。私たちは、各ブロックを1.82MBの連続した行に保存するブロックアウター構造に切り替え、NIXLは単一の読み込みでそれを処理します。これらを組み合わせることで、エンジンとKVの転送作業により、16K以上のトークンを含むプレフィルバッチは4× MI355X上で1.8～2.1倍の速度で処理できます。
低遅延モノカーネル
低コンパンション時、AMD GPUでのデコードは起動に依存する：カーネル起動のオーバーヘッドが計算よりも長くかかります。Monoデコードでは、各スパースMoEデコーダ層を単一のFlyDSLカーネル起動として実行することでこれを解決します。この1回の起動で、QKV投影やスパースアテンションからテンソル並列化、MXFP4 MoEまで全てをカバーし、約1,170回のカーネル起動を削減できます。 MI350XのTP4で、この処理によりデコードステップは2.3倍速くなり、低同時処理時の8K入力/1K出力スループットが2倍に増加します。エージェント型コーディングのトレースでは、インタラクティビティが50～65％向上します。
AMD MI355X上のエージェント型ワークロードベンチマーク
私たちのAMD実装は、コスト対性能においても優れた性能を実現しています。InferenceX AgentXベンチマークでは、MiniMax-M3.1-Flashは遅延が重要な領域で、ユーザー1人あたり1秒間331.0トークンを保持します。さらに先へ進むと、各ユーザーは1秒間170トークン以上を保持し、TCOあたり34.6Mトークンを実現します。コスト効率の良い領域では、1ドルあたり133.3Mトークンに達し、最もインタラクティブな点のほぼ10倍になりますが、各ユーザーは依然として1秒間約79トークンを見ることができます。
図6：AMD MI355X上のMiniMax-M3.1-FlashにおけるAgentX Pareto frontier。TCOあたりの総トークン数を示す。c1とc4は合成受容長が3.2トークンで、7個の投機的トークンがある。他の点は2.45トークンで、3個の投機的トークンがある。各点の指標を表示するには、その点をホバーする。
Day-0 RLサポート
NVFP4のチェックポイントから始めて、MiniMax-M3.1上でRLを実行し、ランク-32のLoRAアダプターのみをトレーニングする。veRLトレーナーは、エンジンがベースモデルを処理する方法と同じように、ルーティングエキスパートにはNVFP4、他のプロジェクションにはMXFP8を用いてベースモデルを量子化し、各ステップ後にアダプターのみをエンジンに同期する。エンジンの側では、エキスパートLoRAはFlashInferのTRTLLM NVFP4 MoEカーネル内で実行されるため、ベースエキスパートは通常のサービングカーネル上で引き続き動作する。
トレーニング前に、トレーナーとエンジンが3つの点で一致しているかを確認しました。エンジンはトレーナーが送る正確な重みを受け取り、各トークンを同じエキスパートにルーティングし、同じトークンに対して同じlogprobsを割り当てます。
残りのギャップは、トークンレベル重要度サンプリング（TIS）によって修正され、重要度比率は2に制限される。各バッチには1回の最適化ステップが行われるため、トレーナーはロールアウトlogprobsを旧logprobsとして使用し、それらを再計算するための追加のフォワードパスを省略する。
DAPO-Math-17Kで16GB300GPUを使用し、200GRPOステップを行うことでAIME-2024の精度は36.3%から67.5%に向上した。同じ実行中、トレーニング報酬は−0.06から0.67に上昇し、トレーニング/ロールアウトKLは0.040から0.024に低下した。
図7：DAPO-Math-17K上のveRLを使用したMiniMax-M3.1-FlashにおけるDay-0 RL。16× GB300、200 GRPOステップ：AIME-2024の精度、トレーニング報酬、およびトレーニング/実行KL。タブを使ってそれぞれを切り替える。
謝辞
MiniMax-M3.1-Flashのオープンソース化に対して、MiniMaxチームに心から感謝します。また、vLLMにおけるモデルの日0時のサポートを提供したInferact、NVIDIA、AMD（mono kernelのHongxia Yang、Felix Marty、Andy Luo、Felix Li、Hattie Wu、Gilbert Lei、Peng Sun）や、AMDカーネルおよびvLLMコミュニティでの支援をしてくれたFlyDSLチームにも感謝します。