AI・機械学習
Kimi K3をMI355XでB300よりも優れたコストパフォーマンスで実行する
Running Kimi K3 on MI355X at Better Performance per Dollar Than B300 (wafer.ai)
要約
この記事では、大規模言語モデルKimi K3をAMDのMI355X GPUで実行する際のコストパフォーマンスについて論じています。MI355Xの288GB HBM容量は、2.8兆パラメータを持つKimi K3のような巨大モデルの搭載に不可欠であり、NVIDIAのB300/B200と比較して優れたコスト効率を実現できる可能性を示唆しています。ソフトウェアサポートの課題は残るものの、AMDがKimi K3向けにゼロデイサポートを提供したことで、実用的な性能向上が達成されました。
全文翻訳
過去数ヶ月間、オープンソースモデルの能力の爆発的な進化を見てきました。
DeepSeek V4-ProとGLM5.2がOpusレベルに近い知能に達し、オープンソースは私たちが依存してきたクローズドソースモデルの、現実的で費用対効果の高い代替手段として浮上しました。
しかし、Kimi K3のようなモデルはまだ見ていません。
Fable/Solレベルの知能を約束するKimi K3は、オープンソースの新時代の幕開けを告げます。
しかし、よりスマートなモデルはより大きなモデルを意味します。これらのモデルは、その能力と同様の速さでサイズも拡大しています。
GLM5.2は753Bパラメータ、DeepSeek V4-Proは1.6T、そしてKimi K3は2.8T(!!)パラメータです。
これは、100万トークンのコンテキストに対するKVキャッシュを割り当てる前に、1.5TB以上のVRAMを必要とします。
B200ノード(8基のGPU)でさえ、Kimi K3を搭載することはできません。
これにより、選択肢は限られます。1基あたり288GBのVRAMを持つB300のノードでサービスを提供するか、Kimiのサービス提供に2基のB200ノード(TP16)を割り当てるかです。
しかし、他に288GBのVRAMを持つNVIDIA以外のGPUは何でしょうか?AMDのMI355Xです。
私たちがこれらのチップを気に入っていることがもうお分かりでしょうか?
平均してB300よりもGPUあたり約2.4倍、B200よりも約1.7倍安価なMI355Xは、同等のハードウェア仕様を持つBlackwellに対する費用対効果の高い代替手段です。
AMDの唯一の問題はソフトウェアサポートです。推論フレームワークにおけるカーネルの遅さや、ゼロデイサポートの不足は、AMDで最先端モデルをサービス提供することを真のエンジニアリング作業にしています。
Waferでの私たちの主張は、エージェントがカーネルとモデルの最適化を改善しており、まさにこのギャップを埋めているということです。
しかし、AMDがKimi K3向けにゼロデイサポートを出荷したことで、作業のほとんどは私たちにとって完了していました。
結果は素晴らしいです。1024トークンの入力/400トークンの出力ベンチマークでは、MI355Xはノードあたり952トークン/秒、シングルストリームで118トークン/秒を達成しました。
これは、TP16 B200デプロイメント(498トークン/秒は16基のGPU、2ノード合計で約249/ノード)のノードあたりの集約スループットの3.8倍以上、シングルストリームデコードの1.3倍以上です。
B300ノードは依然としてMI355Xに対して集約スループットで約1.65倍優れていますが、価格が2.4倍であるため、MI355XはパフォーマンスあたりのドルでB300を圧倒します。
8x MI355X (TP8)
2x8 B200 (TP16)
B300 (TP8+DCP8)
デコードトークン/秒 (ストリームあたり)
118 tok/s
90 tok/s
172 tok/s
ピーク集約スループット
952 tok/s
498 tok/s
1,568 tok/s
ピーク集約スループット (GPUあたり)
119 tok/s
31 tok/s
196 tok/s
ピーク集約スループット (ドル/GPU-hrあたり)
48 tok/s/$
7 tok/s/$
33 tok/s/$
パフォーマンス/ドル
MI355XはGPU-hrあたり2.50ドル、B300は6.00ドル、B200は4.25ドルと仮定。
B200の弁護としては、デコードのクリティカルパスでクロスノードのall-reduce(RoCE v2、約195 Gb/s)を支払う必要があるという事実により、その数値はいくぶん低下しています。
これは、Kimi K3の重みと100万トークンのKVプールが単一の8x192GBノードに収まらないため、この構成で唯一2つのノードにまたがるものです。
しかし、まさにそこがポイントです。Kimi K3はそのサイズにおいて、MI355XがHBM容量に焦点を当てていることが、B200に対する実用的で測定可能な優位性を与える最初のモデルの1つです。
どうやって実現したか
Kimi K3はすぐに使える状態で提供されましたが、現在のスループット数を得るためにはまだ作業が必要でした。
主なテコは、投機的デコードでした。
K3はゼロドラフトテンソル(MTP、EAGLEなし)を出荷するため、唯一の投機的パスは外部ブロック拡散ドラフト、RadixArkのKimi-K3-DSparkです。
CUDAでは動作します。
ROCmでは、最初の実際の要求がスケジューラをこのエラーでクラッシュさせます:NameError: name 'top_k_renorm_prob' is not defined. Did you mean: 'top_p_renorm_prob'?
sglangのaccept-sampling verifierには、ターゲット分布を構築する2つの方法があります。
1つはtop_k_renorm_probを呼び出すdenseパス、もう1つはtorch.topkを直接ルーティングするsparse fastパスです。
CUDAビルドはsgl_kernelからtop_k_renorm_probをインポートします。
ROCmビルドはTritonのtop-pカーネルのみをエイリアスし、top_k_renorm_probを未定義のままにします。
gfx950用のtop-k renormカーネルはありません。
そのため、リクエストがdenseパスに着地した瞬間、verifierはそのNameErrorに遭遇し、スケジューラをダウンさせます。
修正は単一のPyTorch関数です。
Top-k renormは小さな操作です。
モデルの確率ベクトルを取り、上位k個のエントリを保持し、残りをゼロにし、残りを1に合計するように再スケーリングします。
ソート、masked_fill、除算。
sglangのROCmサンプリングブランチに直接ドロップすると、CUDAビルドがsgl_kernelから取得するのと同じ計算が行われます。
カスタムカーネルは不要です。ROCmでの反射は、カスタムカーネルが必要だと想定することですが、ここではカスタムカーネルではなく、定義の欠落でした。
spec decが修正され、強化されたことで、シングルストリームで約2.2倍、中程度の負荷でのストリームあたり約1.7倍、ピーク集約スループットが+18%向上しました。
さらに重要なのは、ピーク集約スループットがより高い並行性(specなしのc64対c24)で達成されたことです。
Prefill最適化
モデルパフォーマンスに関する議論は、デコードトークン/秒を強調する傾向があります。
しかし、多くの場合、デコードトークン/秒は偽の金です。デコードは過度に称賛され、ユーザーが最も感じるtime-to-first-tokenが見過ごされています。
MI355Xはここで苦労します。
同様の172kトークンのコールドプリフィルは、MI355Xで約51秒かかったのに対し、B300では約23秒でした。
100万コンテキストのモデルでは、多くのワークロードで巨大なプリフィル(時々コールド)があり、GPUがプリフィルで数分間スピンすると、ノード全体が無駄になる可能性があります。
このギャップは、ほぼ完全に1つのカーネルによるものでした。
K3 on ROCmは、高速なAITER MLAプリフィルカーネルがロードされないため、遅い汎用Tritonアテンションにフォールバックしていました。
問題はカーネルの欠落ではなく、形状の不一致でした。
K3はTP8でランクあたり12のアテンションヘッドを提供しますが、AITERのMLAパスは4、8、または16の倍数用に構築されています。
修正は非常に単純でした。
ヘッド数をゼロパディングして12→16にし、高速カーネルを実行し、出力から実際の12ヘッドを抽出します。
結果:同じ172kコールドプリフィルで、AITER MLAプリフィルASMはTritonフォールバックの約4〜7kに対し、約13kトークン/秒の定常状態で実行され、プリフィルを約2〜3倍高速化しました。
これは集約スループットを向上させるものではなく、time-to-first-token(TTFT)のレバーです。
デコードは変更されないため、上記の数値を移動しません。
最初のトークンが表示される前にユーザーが待つ数値を移動させます。
結論
MI355Xで最高のパフォーマンス/ドル比を達成することは、比較的すぐに実現できました。
予想されるフレームワーク関連のバグはいくつかありましたが、GLM5.2よりも少なく、今回はカスタムカーネルを必要としませんでした。
AMDでの最先端技術は目前です。
CUDAの牙城は終わったのでしょうか?
2026年7月17日
Rishiraj Dutta GuptaとWaferチーム
TrueFoundry AI GatewayとのWaferインテグレーション
Waferの高速でOpenAI互換のサーバーレス推論が、統一ルーティング、オブザーバビリティ、ゼロデータ保持のためにTrueFoundry AI Gatewayとどのように統合されるか。
2026年7月3日
Ian Ye
パフォーマンス/ドルはより速く、より安くなっている
AMD MI355XでGLM5.2をノードあたり2626トークン/秒、シングルストリームで213トークン/秒で、Blackwellの2倍以上の低コストでサービス提供する方法。