vLLM、AMD Instinct MI355X上でMiniMax M3のボトルネック最適化手法を公開

MiniMax M3 の day-0 投稿では、AMD Instinct MI355X 上で動作する vLLM の最初の実装について紹介しました。具体的には、MiniMax Sparse Attention (MSA)、マルチモーダル入力、推論とツール出力、MXFP8 重み、そして EAGLE3 です。

今回の続報では、モデル実行後に何が行われたかを解説します。得られた成果は単にスループット数値が向上しただけではありません。ボトルネックがどこへ移動するかを見極め、次に何を最適化すべきかを決めるための指針を得たことが重要です。

1 分間の結果

SemiAnalysis の InferenceX ベンチマーク（SemiAnalysis InferenceX benchmark）の公開データによると、AMD Instinct MI355X 上で MiniMax-M3 が現在達成している性能は以下の通りです。

• コンカレンシー 32 の条件下では、固定トポロジの MXFP8 標準サービングで、1 GPU あたりの出力トークン数が 109.1 から 342.4 tokens/s/GPU に向上し、day-0 の結果と比較して 3.14 倍となりました。Median TTFT は 1.46 秒から 0.67 秒に短縮され、平均 TPOT も 69.1 ミリ秒から 22.1 ミリ秒へと大幅に改善されました。

• コンカレンシー 128 の条件下では、TP4/EP1 を採用した 4 GPU パスにおいて、1 GPU あたりの出力トークン数が 297.8 から 623.7 tokens/s/GPU に向上し、2.09 倍の性能を達成しました。Median TTFT は 3.53 秒から 1.54 秒に短縮され、平均 TPOT も 100.7 ミリ秒から 48.8 ミリ秒へと改善されました。

• MXFP4 の場合も、同じく TP4/EP1 を採用した 4 GPU 構成でコンカレンシー 128 を実行すると、1 GPU あたりの出力トークン数が 212.1 から 716.8 tokens/s/GPU に急上昇しました。その後、TP2/EP1 の構成ではさらに 943.5 tokens/s/GPU を達成し、これは TP4 チェックポイントと比較して 31.6% 高く、初期の 1 GPU あたり結果に対しては 4.45 倍に達しています。

• さらに EAGLE3 の推測デコーディングを追加したことで、TP4/EP1 構成でコンカレンシー 128 を実行する際、1 GPU あたりの出力トークン数が 682.4 tokens/s/GPU に到達しました。

P/D 分離アーキテクチャの導入と、prefill/decode トポロジーの再調整により、コンカレンシー 512 の条件下で 6,370.5 total tokens/s/GPU というスループットを達成しました。また、1.32 秒という median TTFT を実現しています。

*Figure 1. Standard decoding at 8K input and 1K output. Compare points within a row. MXFP8 stays on TP4/EP1; the last MXFP4 point moves from TP4 to TP2, so it shows higher deployment density, not a fixed-topology speedup.*

各チェックポイントは累積的なものであり、複数の変更を束ねています。以下のセクションでは、個々の最適化効果を説明するために、個別の PR 測定値を用いた分析を行います。

デコードステップ 1 つ、5 つの問い

今回の最適化作業は、よくあるワークフローに従いました。まず主要なボトルネックとなるコストを推定し、それを計測します。次に反復的な処理をバッチ化し、不変量を事前計算します。そして、細部のプロファイルが平坦化された段階で、より上位のレイヤーへとアプローチを広げていきます。

MiniMax M3 は 60 層のデコーダーを持ち、そのうち 57 層はスパースな MoE（Mixture of Experts）とスパースアテンションを採用しています。1,000 トークンの応答を生成する際、1 層あたりのわずかなコストでも、1 つのリクエスト内で数万回にわたって発生します。この特性から、以下の 5 つの問いが重要となります。

• このランクに至るローカルな形状は何か？
• 各層やトークン処理で繰り返される作業は何なのか？
• どのデータ（バイト）が移動し、メタデータの移動で代替可能か？
• 意図した高速パスが実行され、期待通りの計算が行われたのか？
• カーネルの処理時間がもはや支配的でない場合、どのキューが成長しているのか？

*Figure 2. The top lane follows one sparse decoder layer in execution order; AR marks the tensor-parallel collectives after attention and MoE. The lower lane applies the same reasoning to P/D: validate the KV handoff, then add capacity where requests wait.*

この投稿の残りの部分では、これらの疑問にコードとベンチマークデータを用いて回答します。

1. なぜこのランクに至る形状なのか？

モデル図はグローバルな次元を示していますが、カーネルが実行するのはテンソル並列化、ヘッド複製、パディング、トークンルーティング後のローカルな M、N、K です。TP8 の構成では、MiniMax M3 の 64 クエリヘッドは 8 つのランクに分割され、各ランクあたり 8 つになります。一方、4 つの KV ヘッドと 4 つのインデックスヘッドは複製され、各ランクあたり 1 つずつとなります。したがって、融合された QKV プロジェクションが直面するローカルの N は 1536 であり、グローバルな N を 8 で割った値ではありません。

プリフィルとデコードでは、異なる M の値が現れます。プリフィルは一度に多くのトークンを処理するのに対し、デコードでは行数が限られることが一般的です。

vLLM #45725 ではランチャーを大規模 M と小規模 M の 2 つの領域に分割し、TP8 環境における 8K/1K の出力スループットを 7.8%–9.4% 向上させました。その後、vLLM #46117 では、完全なローカル形状からタイルを選択する方式を採用しました。これにより、デコードではより狭い N のタイルが独立した作業を多く露呈し、一方、K 方向のステップを大きくすることでループ回数を削減できます。プリフィルにおいては、M がすでに十分な並列性を提供している場合、より広いタイルを使用します。

*図 3. TP シャーディングとヘッド複製はローカル N を決定し、サービングフェーズが M を決定します。ランチャーは各ランクが実際に実行する形状に合わせてタイルを選択します。

同じプルリクエストでは、グループ化された MoE プログラムの順序も再編成されました。これにより、隣接するプログラム間で GPU キャッシュから活性化行やエキスパート重みタイルを再利用できるようになり、HBM からの再フェッチが不要になりました。TP4 のエンドツーエンドテスト全体を通じて、これらの変更により 1.08 倍～1.46 倍の性能向上が実現しました。特に並列処理が少ない低同時実行時において、その効果は最大となりました。

形状の特性も、利用可能なバックエンドを決定します。最終的な MXFP8 レシピで採用されている AITER のスパースアテンションパスでは、TP ランクごとに 1 つの KV ヘッドが必要です。TP4 はこの条件を満たしますが、TP2 では vLLM の Triton フォールバックが使用されます。つまり、TP を変更することは単に集合通信のサイズを変えるだけでなく、オペレーターグラフそのものも変化させることになります。

また、「最も高速なバックエンド」を一つに特定することもできませんでした。InferenceX #2003 では当初、一貫してエミュレートされた線形バックエンドが選択されました。しかし、後の InferenceX #2187 での測定結果では、低・中程度の並行処理時にはネイティブの MXFP8 リニアの方が高速であることが示され、エミュレーションが優位だったのは入力長が長く、かつ高い並行性を要するケースに限られました。スパースページドアテンションでも同様のクロスオーバー現象が見られました。最終的なレシピでは、これら両方の手法は 8K 入力で並行度が 64 以上の場合にのみ有効化されています。

これが最初の教訓です。実際に実行される形状の分布に基づいてチューニングし、適切なバックエンドを切り替えることが重要です。「プリフィル」「デコード」「TP4」といったラベルに惑わされてはいけません。

2. 何が繰り返されるコストなのか？

見過ごされがちな反復コストの一つに、起動オーバーヘッドがあります。初期のレシピでは eager モードで実行されていました。InferenceX #1754 と #1755 で、標準および EAGLE3 の推論サービスにおいてグラフ実行が有効化されました。この変更は累積的な改善履歴の一部ですが、公開された結果からはその単独の寄与度を切り離して評価することはできません。

構造的な大きな勝利は、共有エキスパートの導入でした。元々、各スパース MoE レイヤーでは、ゲート/上段投影、活性化、下段投影、中間保存、加算という一連のプロセスを、独立した密結合 MLP として実行していました。計算自体は必要でしたが、そのための別経路は不要だったのです。

vLLM #46545 では、共有エキスパートをルーティング済みエキスパートのテーブルに追加し、すべてのトークンに対して選択されるようにしました。これにより、グループ化された GEMM（行列積演算）でルーティング済みと共有の両方のエキスパートをまとめて処理できるようになりました。その結果、起動回数の削減や中間データの転送が不要になりながら、モデルの計算量（FLOPs）は維持されています。

この最適化により、並行度 1 でスループットが 30.2% 向上し、並行度 128 でも 5.6% の改善が見られました。並行度が上がるにつれて効果が増幅しないのは、起動コストの分散（アモタイゼーション）によるものだと考えられます。

*図 4. 融合により、共有エキスパートはすべてのトークンが選択するスロットとして追加されます。これにより、ルーティング済みと共有の両方のエキスパートで同じグループ化された GEMM を利用可能になり、モデル計算の整合性は保ちつつ、独立した MLP パスとその中間データ転送を排除しています。*

AITER のアプローチは、vLLM #46474 で同様のアイデアが採用されました。また、AITER #3811 を支える vLLM #46184 では、MXFP8 の重みとスケールの再配置をモデル読み込み時に実行するように変更されています。AITER は 1 トークンから最大 32,768 トークンまでの MoE（Mixture of Experts）設定や、TP4 や TP8 で生成されるローカル中間幅に対応する調整済み構成を引き継いでいます。レイアウト変換は一度だけ行われ、その後の推論ループでは準備された形式がそのまま消費されます。

スペキュレティブ・ディコーディング（予測デコード）は、反復的な処理をバッチ化する優れた事例を示しました。元の MSA インデクサーは、予測トークンごとに 1 つのワークグループを起動していましたが、vLLM #45743 ではリクエストごとに 1 つのワークグループを起動し、すべてのドラフト位置をまとめて処理することでキーの読み込みを再利用しています。また、スコアの正のスケール係数も削除されました。重要なのは上位 k 個の順序だけであり、すべてのスコアに同じ正の定数を掛けたとしてもその順序は変わらないためです。

インデックスカーネルの性能は最大で 48.9% 向上し、PR テストにおけるエンドツーエンドの推論速度も約 3.3% 改善しました。この差はアンダールの法則が作用している結果です。特定のカーネルでの大きな改善は実現可能ですが、それがアプリケーション全体のクリティカルパスをすべて支配するわけではないことを示しています。

3. どのバイトが移動するのか？

スパース・アテンション（疎な注意機構）は計算量を減らしますが、その分、制御プレーンが必要になります。具体的には、スコアブロックの管理、上位 k の選択、論理ブロックから物理ページへのマッピングを行い、それらのメタデータをアテンションカーネルへ渡す処理が追加されます。

vLLM #47269 で観測された通り、隣接するスパース層はほぼ同じブロックを選択する傾向がありました。インデックス共有を有効にすると、1 つの層がトップ k の決定を計算し、後の層でそれを再利用できます。その結果、並行度 1 では平均 TPOT が約 10% 低下し、高い並行度では約 4% 低下しました。

セレクターをスキップするだけでは不十分でした。融合された投影演算でも依然としてインデックス Q/K 値が生成され、正規化や RoPE の適用、インデックスキャッシュへの書き込みが行われていたからです。vLLM #47287 では、この再利用の可否を融合カーネルに明示的に伝えることで、不要なプロデューサー側の分岐をコンパイル時に削除できるようにしました。

同じ PR により、レイアウトの不整合を解消しながら AITER のスパースページアテンションも統合されました。MiniMax M3 は論理的に 128 トークン単位のブロックを選択しますが、AITER は 16 トークン単位のページを消費します。KV データをコピーするのではなく、vLLM は選択された各ブロック ID を 8 つのページ ID に変換し、コンパクトなページテーブルを構築します。KV キャッシュは元の場所に留まります。これは、コンテナごとコピーする代わりにビュー（参照）を渡すようなサービス側の最適化です。

*図 5. 選択された 128 トークンブロックは物理ブロックに解決され、さらに 8 つの 16 トークンページエントリに展開されます。AITER は既存の KV アロケーションに対するビューを通じてこれらを読み込みます。再構築されるのはテーブルのみです。*

TP4 環境で並行度 256 を設定した際、MXFP4 では出力スループットが 6.93%、MXFP8 では 5.56% 向上しました。これは個別の A/B テストでの結果です。

ここには重要なベンチマークの境界線が存在します。InferenceX の固定された 8K/1K レビューポリシーでは、アーキテクチャ作業を減らす要因となるため、クロスレイヤーインデックスの再利用は除外されています。一方、固定形状のレシピではページアダプターは使用されますが、top-k の再利用は行われません。AgentX はそのワークロードルールに基づき再利用を可能にします。そのため、実行されていない作業に対する成果を固定契約曲線に評価することはできません。

量子化（Quantization）を行うと、「どのバイトを使用するか」という問いはさらに重要になります。以下の 3 つの側面を分けて考えることが有益です：

これらのパスは、独立したディスパッチ条件と正しさの契約を有しています。「モデルは MXFP4 である」という記述だけでは、KV データ型や集合通信経路については不明です。

4. ファストパスは実行されたか、また正しいのか？

今回の監査により、投稿内の一つの主張が修正されました。当初は、約 1.5 MB のデコード集合通信に INT4 QuickReduce が使用されたと考えていましたが、利用可能な証拠からはそれを証明できません。

InferenceX #2104 では INT4 と 256 KB のコーデック閾値が設定されていましたが、QuickReduce の個別の適用条件閾値については明記されていませんでした。TP4 環境での BF16 において、ピン留めされた組み込みテーブルでは、INT4 適用には 16 MB のデータサイズが必要です。したがって、1.5 MB の集合通信はコーデック選択の閾値に達しておらず、256 KB の閾値が参照されるのは QuickReduce が適用条件を満たした後になります。

*図 6. QuickReduce は FP または INT4 を選択する前に適用条件をチェックします。ここでは集合通信が組み込みの適用条件ゲートを下回っているため、設定のみでは実行を確立することはできません。*

利用可能なログは INT4 が設定されたことを示しているだけで、QuickReduce カーネルが実行された証拠ではありません。したがって、#2104 は累積的な画像およびレシピのチェックポイントとして扱い、その曲線変化を INT4 のアールリダクションに帰因してはいけません。

この区別は一般化可能です：

configured  !=  eligible  !=  executed

バックエンドに対して性能向上係数を割り当てる前に、ディスパッチトレースやプロファイラーを使用してください。

正しさも同様の規律を必要とします。以下の 3 つの事例が、それぞれ異なる契約違反を検出しました：

• vLLM #45794 では、パッキングされた MXFP4 の Q/K/V およびゲート/アップチェックポイントテンソルを正しい融合パラメータスライスにマッピングし、MiniMax M3 の SwiGLU-OAI パラメータを MoE へ正しく渡しました。

• vLLM #45720 は、FNUZ ROCm デバイス上の FP8 KV ビューの不具合を修正しました。MI300X において、パッチ未適用のパスでは GSM8K の厳密一致スコアが 0.0099 でしたが、パッチ適用後のパスでは 0.9575 に達しました。これは MI355X の速度向上を主張するものではなく、正しさを保証するための修正です。

• vLLM #47158 は、AITER に渡されるエキスパート並列マスクの不具合を修正しました。バグのあるパスではコサイン類似度が 0.527 でしたが、修正後のパスでは 1.0 に達し、GSM8K の精度が回復しました。

最後の 2 つの事例は、TP4/EP1 という「英雄曲線」を説明するものではありません。これらは、他の設定が満たすべき契約を明らかにしたものです。パフォーマンス改善においては、「合格」とは以下の 3 つを満たすことを意味します：出力が正しいこと、意図したパスが実行されたこと、そして同じ契約条件下でエンドツーエンドの指標が向上していることです。

EAGLE3 が第 2 のデコードループを追加

EAGLE3 は、ドラフトモデルの追加、マルチトークン検証、受容動作、そして第 2 のアテンションメタデータセットを備えています。これは標準的なカーブ上の単なるフラグとして扱うことはできません。

vLLM #45546 で AMD モデルが EAGLE3 インターフェースに接続されました。その後、vLLM #45564 で微妙なキャッシュキーのバグが修正されています。ターゲットとドラフトではクエリヘッド数が異なるため、バックエンドや KV タイプが一致していても、アテンショングループビルダーを共有してはいけません。

これは一般的なキャッシュルールです。キャッシュされるオブジェクトに影響を与える不変要素はすべてキーに含まれる必要があります。

上記のリクエストレベルのインデックスバッチ処理の後、InferenceX #2107 で、ターゲットのアテンションバックエンド設定がドラフトに適用されていないことが判明しました。TRITON_ATTN をスペキュレーション設定内に固定することで、ドラフト側の低速なフォールバックを回避できました。

最後に、vLLM #47984 で AITER スパースページドアテンションが 1 トークンのデコードからマルチトークン検証へと拡張されました。これにより、平坦化されたクエリ行をそれぞれのリクエストとローカルのスペキュレーション位置にマッピングし、既存のページテーブルビルダーを再利用しつつ、1 トークンの高速パスも維持しています。TP4 テストでは、受容率に実質的な変化を与えずに、MXFP4 で出力スループットが 8.32%、MXFP8 で 7.90% 向上しました。

これらの取り組みにより、並列度 128 の環境で EAGLE3 の結果として、GPU あたり 682.4 トークン/秒の出力が達成されました。

5. どのキューが成長するか？

プリフィルとデコードの分離により、ボトルネックは一つの処理プロセスから別の場所へ移動しました。ワーカー数の調整を行う前に、まず KV（キー・バリュー）境界の設定が正確であることが必須です。

初期の MoRIIO 経路では、第 1 レイヤーの KV レイアウトが全レイヤーに共通すると仮定していました。しかし、MiniMax M3 は K/V テンソルを分離し、K/V テンソルをインターリーブさせ、さらにキーのみを格納するインデックスキャッシュも備えています。転送自体は完了し、スループットも健全に見えたものの、GSM8K のスコアは約 0.0008 にまで低下しました。これは実質的に意味のないトークンの羅列に過ぎません。

この問題を解決するには、以下の 3 つのステップが必要でした：

• vLLM #46039 で、レイヤーごとの転送ジオメトリとバイトオフセットを導出しました。
• vLLM #46290 では、各リクエストに対して実際にスケジュールされた書き込み数をカウントし、フォワード処理後にその値を確定させました。その後、これらの書き込みが完了するまでバッファの解放を行いませんでした。
• vLLM #46332 では、異種 TP（テンソル並列）ランクのマッピングと、確認応答の集約機能を追加しました。プリフィルが TP4、デコードが TP8 の構成の場合、1 つのプロデューサーランクに対して 2 つのデコードランクが消費できます。そのため、両方のデコードランクからの確認応答を待つまで、そのブロックは再利用されません。

これらすべての対策を講じて初めて、ワーカー割り当ての最適化に意味が生じました。

*図 7. 8K/1K の 2 つの P/D 動作ポイント。両端点は異なる GPU 数と並行度を使用しているため、これは制御された速度向上ではなく、システムの進化を示しています。*

最初の公開プロファイルでは、TP8 のプリフィルワーカーとデコードワーカーをそれぞれ 1 つずつ使用していました。並行度が 1024 の場合、GPU あたり合計 2,084.6 トークン/秒の処理速度を達成しましたが、中央値 TTFT は 223.20 秒に達しました (InferenceX #1762)。スループットの数値だけではこのシステムの実用性は保証できず、プロンプトキューの状況が重要な指標となりました。

InferenceX #2144 では、すべてのワーカーを TP4 に移行し、高速なシングルノードレシピに同期させた上で、プリフィルとデコードの比率を検証しました。8K/1K の設定では、TP4 のプリフィルワーカー 2 つが TP4 のデコードワーカー 1 つを支援する構成です。並行度 512 でテストした結果、GPU あたり合計 6,370.5 トークン/秒の処理速度と、中央値 TTFT 1.32 秒という成果を得ました。

平均 TPOT は 31.26 ミリ秒から 54.60 ミリ秒へと増加しました。これは矛盾する結果ではありません。プリフィル容量を増やすことで入場キューが解消された一方で、選択されたデコードの動作点は、アクティブなシーケンスをよりゆっくり生成しています。P/D（プリフィル/デコード）には少なくとも二つのレイテンシ目標が存在します。両方の指標を公開すべきです。

ある高並行度のテストでは、コンテナのファイルディスクリプタ制限が限界に達しました。nofile の値を引き上げることで TCP 接続の失敗は解消されました。プロファイルが上位層へ移行する際、OS の制限は GEMM タイルの制約と同様に現実的なボトルネックとなり得ます。

AgentX が示す次のボトルネック

固定された 8K/1K の設定は比較検討に優れていますが、エージェントによるコーディングは形状が固定されたトラフィックではありません。そこには長いマルチターン処理、再利用可能なプレフィックス、不規則な出力、そして KV キャパシティの限界点（knee）が存在します。

InferenceX #2487 は、MXFP4、EAGLE3-GQA、プレフィックスキャッシング、オプションの TP シャーディング LMCache、そして層間インデックス再利用を備えた、MI355X における MiniMax M3 エージェント X の最初のポイントです。スループット計測では、合成された受容長（acceptance length）をコミットして比較対象システムも同様の推論的作業を行えるようにし、評価では実際のターゲット検証を使用しています。

成功した実行 では、TP4 で並行度 28 を設定した結果、GPU あたり出力トークンレートが 127.4 tok/s、合計で 509.5 output tok/s、平均 QPS は 0.582、p50 TTFT が 645 ms、そして p50 TPOT が 41.3 ms を記録しました。

これらのサービス指標は、単なるスコア以上の意味を持ちます：

• 理論上のプレフィックスキャッシュヒット率：96.7%
• 実際に達成された GPU キャッシュヒット率：92.1%
• GPU KV キャッシュの使用率：88.5%
• GPU KV のキャパシティ：6,264,960 トークン

この段階では、別の GEMM（行列積演算）が自動的に次の最良のプロジェクトになるとは限りません。キャッシュ実現における 4.6 ポイントのギャップと、ほぼ限界に近い運用ポイントから、プレフィックスのアライメント、リクエスト受付・削除ポリシー、スケジューリング、そしてオフロードへの注目が集まります。これらは単一のランからの観察であり、まだ最適化を主張する段階ではありません。このポイントをベースラインとして、次のエージェント最適化ラウンドに活用します。

次のモデルに向けたチェックリスト

新しいサービングパスが機能しているものの、まだ高速ではない場合：

• シャーディング後にローカルの形状ヒストグラムを記録してください。複製されたヘッド数とルーティングトークンのカウントを含めます。
• 反復回数を推定します。層ごとの作業量を層数、出力トークン数、およびアクティブなリクエスト数で乗算します。

バイト平面を分離し、計算テンソル・永続状態・通信をそれぞれ独立して処理する。

すべての高速パスに対して、その適用条件を記録し、実行時に検証を行う。

性能向上のゲートの隣には、必ず正しさのゲートを設ける。

各成功の後には再度プロファイリングを行い、リーフカーネルが平坦化された場合は、キュー・所有権・キャッシュ容量・OS の制限などを精査する。

これが本稿の主要な成果である。MiniMax M3 が高速化したのは、チームが問いかけるレベルをタイルから反復パスへ、スパースメタデータへ、分散状態へと、そして最終的にはワークロードキューへと段階的に変え続けたからだ。

固定形状の結果の再現

公開されている InferenceX の実行記録には、コンテナイメージ・引数・アーティファクトが記録されている。最終的な MXFP8 TP4 チェックポイントでは以下の設定を使用した：

vllm/vllm-openai-rocm:nightly-9e57de7197f234f9d9187715d96e07e007048c0f

export VLLM_ENGINE_READY_TIMEOUT_S=3600
export VLLM_USE_BREAKABLE_CUDAGRAPH=0
export VLLM_ROCM_USE_AITER=1
export VLLM_ROCM_USE_AITER_FUSION_SHARED_EXPERTS=1

vllm serve MiniMaxAI/MiniMax-M3-MXFP8 \
  --tensor-parallel-size 4 \
  --block-size 128 \
  --no-enable-prefix-caching \
  --language-model-only \
  --moe-backend aiter \
  --max-model-len 10240 \
  --max-num-batched-tokens 32768 \
  --kv-cache-dtype fp8 \
  --attention-backend TRITON_ATTN \
  --tool-call-parser minimax_m3 \
  --reasoning-parser minimax_m3 \
  --enable-auto-tool-choice

図 1 で使用された高並度ディスパッチを再現するには、InferenceX #2187 のゲート付きレシピを使用すること。MXFP4 TP2 の場合は #2446、P/D モードの場合は #2144 を参照のこと。上記のフラグだけをコピーしても、異なるイメージ・トポロジ・ワークロードが再現されるわけではない。

並度 128 のベンチマークコマンドは以下の通り：

vllm bench serve \
  --backend vllm \
  --model MiniMaxAI/MiniMax-M3-MXFP8 \
  --dataset-name random \
  --random-input-len 8192 \
  --random-output-len 1024 \
  --random-range-ratio 0.8 \
  --num-prompts 1280 \
  --max-concurrency 128 \
  --request-rate inf \
  --ignore-eos \
  --num-warmups 256 \
  --percentile-metrics ttft,tpot,itl,e2el \
  --save-result

謝辞

MiniMax M3 の公開と、この推論パスの構築・最適化・検証に尽力された方々へ感謝いたします。ご協力いただいたのは、Aakif Nawaz 氏、Ajith Sirra 氏、Bryan Shan 氏、Bugen Zhao 氏、Cameron Quilici 氏、Chun Fang 氏、Duyi Wang 氏、Ethan Yang 氏、Fangzhou Ai 氏、Felix Marty 氏、functionstackx 氏、Hongxia Yang 氏、Isotr0py 氏、Jun Kang Chow 氏、Pin Siang Tan 氏、Qiang Li 氏、Seung Rok Jung 氏、Sun Peng 氏、Tian Di 氏、Tun Jian Tan 氏、Uma Kannikanti 氏、wangjiaxin99 氏、Ye Hur Cheong 氏、youkaichao 氏、Yue Liu 氏、Zheng Gong 氏です。

また、vLLM、AMD、Embedded LLM、Inferact、SemiAnalysis InferenceX の各レビューコミュニティの皆様にも深く感謝申し上げます。