GLM5.2がAMD MI355Xで2626トークン/秒/ノードを達成、Blackwellより2倍以上低コスト

AMDがお好きだとお気づきでしょうか？推論の需要は急増しており、供給を上回っています。Claude Fable、GLM5.2、Minimax M3など、最先端のモデルがほぼ隔週でリリースされており、トークンへの熱狂はますます激しくなるばかりですが、それを支えるBlackwell GPUは十分に出回っていません。そのため、NVIDIA GPUの価格は急速に上昇し、トークンは非常に高価になっています。そこでAMDの登場です。平均してGPUあたり約2.75倍安価（MI355X対B300）でありながら、同等のハードウェア仕様を持つ、安価な推論の解決策は目の前に隠されています。これは、Waferが数ヶ月間提唱してきたメッセージです。AMDのInstinct MI350シリーズはシリコンレベルではBlackwellと競合しますが、NVIDIAのソフトウェアの優位性とゼロデイサポートにより、通常、プロバイダーはより少ない摩擦で、より高速に推論を提供できます。逆に、MI355X / ROCmスタックでは、これらの最先端モデルで最高のパフォーマンスが標準で得られることはめったにありません（時には得られることもありますが！）。実際、それらが動作するイメージを見つけられただけでも幸運です。このゼロデイサポートなしでは、最新モデルの構築と最適化には数週間のエンジニアリングとコンピューティングが必要になる場合があります。その頃には、最新モデルがすでにリリースされており、AMDは常に追いつこうとしている状態になります。しかし、エージェントがカーネルとモデルの最適化を改善するにつれて、このギャップはリアルタイムで縮まっています。Waferでは、これを何度も、そして再び証明してきました。そして再び、20k入力 / 1k出力、キャッシュヒット率60%のワークロードで、定義されたニー（膝）が5秒未満のTTFTで、ノードあたり2626トークン/秒の集約スループットを達成しました。これはB200で測定されたパフォーマンスのわずか80%ですが、2倍以上安価です。持続的なRPS 集約トークン/秒/ノード TTFT p50 / p95 成功 0.5 449 0.59秒 / 0.60秒 100% 1.0 974 0.60秒 / 0.81秒 100% 1.5 1913 0.62秒 / 1.03秒 100% 2.0 1944 0.62秒 / 1.05秒 100% 2.25 2089 0.63秒 / 1.23秒 100% 2.4（飽和） 2626 0.81秒 / 2.22秒 100% TensorWaveから提供されたAMD MI355X容量で、Artificial Analysisの基準に従って、10k入力トークン / 1.5k出力トークンのシングルストリームでGLM5.2で213トークン/秒も達成しました。この数値はAAリーダーボードのトップではありませんが、パフォーマンスあたりのドルで依然として優れています。どのように達成したか どのモデル作業でも最初のステップは、量子化とフレームワークを選択することです。bf16のベースGLM-5.2をAMD QuarkでMXFP4に量子化しました。z-aiの公式FP8量子化と比較して、当社のMXFP4はロスレスでした（GPQA-Diamond、tau2、GSM8K）。評価 FP8ベースライン MXFP4 Δ (MXFP4 − FP8) GSM8K (200q, 5-shot, greedy) 0.965 ± 0.013 0.955 ± 0.014 −0.010 GPQA-Diamond (198q × 2シード, temp 1.0) 0.9217 ± 0.027 0.9026 ± 0.029 −0.019 tau2 macro 0.819 0.834 +0.015 推論フレームワークとしては、vLLM、ATOM、sglangの3つの選択肢がありました。そのうち、sglangを選択しました。vLLMにはMXFP4 + GlmMoeDsaパスが機能しなかったため、MXFP4ウェイトはメリットがなく、ATOMの出力は長コンテキストで低下しました。Sglangは、ネイティブサポートへの摩擦が最も少ない推論エンジンであり、量子化を活用しながら一貫性を保つことができました。スループットを向上させるための次の自然なステップは、sglangで投機的デコードを有効にすることでした。しかし、sglang ROCmイメージは標準ではこれをサポートしていません。MTPが正しく機能する前に、2つの修正が必要でした。まず、MTPヘッドは、他のすべてのレイヤーと同様に、bf16で保存された単一の共有エキスパートを保持しており、MXFP4ではありません。しかし、MTPヘッドは、メインデコーダスタックとは異なるモジュールプレフィックスの下で登録されています（Quarkはbf16共有エキスパートをmodel.layers.78.mlp.shared_experts.*と名付け、MTPレイヤーの実際のプレフィックスはmodel.decoder.*です）。この不一致により、sglangの量子化ルックアップが失敗し、デフォルトでその共有エキスパートをMXFP4として構築します。ロード時に、フル幅のbf16ウェイトをハーフ幅の4ビットスロットに読み込もうとし、初期化は形状の不一致でクラッシュします。Quarkは、どのウェイトを量子化せずに残すかをレイヤー名のリストとして記録するため、レイヤー78のエントリをsglangが実際に使用するデコーダ名の下に再度コピーしました。この修正により、投機的デコードがブロック解除され、シングルストリームスループットで約3倍のゲインが得られました。第二に、深い投機的デコード（z-aiが提案する5/1/6構成など）はまだブロックされていました。ドラフト深度が4以上で必要な融合マルチステップメタデータカーネルは、ROCmガードなしで#include <cuda_runtime.h>を書き込んでいました。修正：1つの#ifdef USE_ROCmガード。投機的デコードを最大限に活用するために必要な、2つの些細だが不可欠な変更。spec decが正しく機能するようになり、いくつかの設定最適化（--kv-cache-dtype fp8_e4m3や--enable-aiter-allreduce-fusionなど）と合わせて、213トークン/秒のヘッドラインシングルストリームデコード数に到達しました。しかし、集約スループット、特に定義されたワークロードでは、デコード最適化は必要ですが、それだけでは不十分です。キャッシュが60%の20k入力では、ワークロードは主にプリフィルバウンドです。シングルストリームデコード用に最適化されたTP8構成では、MI355XはGLM5.2-MXFP4をノードあたり1461トークン/秒で実行できます。このワークロードではTP4×DP2に切り替えることで大幅な改善が得られ、RPS 2.0でノードあたり1944トークン/秒に達しました。これは、3.0 RPSでノードあたり3192トークン/秒に達した測定されたBlackwellパフォーマンスと比較すると、依然として比較的遅いです。MI355Xでのプリフィルパフォーマンスが低い大きな理由の1つは、sglangイメージでは、GLM-5.2のfp4 MoEが、遅いFlyDSLヒューリスティックフォールバック（aiterはa8w8/fp8パスのみで調整済み構成を出荷）でサイレントに動作していたことです。GLMのfp4形状（model_dim 6144、moe_inter 2048、E=256、topk=8）でMoEカーネル選択を独自に調整したことにより、RPS 2.4でノードあたり2626トークン/秒に到達することができました。はるかに良いです。なぜこれが重要なのか ある程度の摩擦はあったものの、MI355Xで最高のパフォーマンス/ドル比を達成することは、特に困難ではありませんでした。フレームワーク関連のバグはいくつかありましたが、Qwen3.5 397Bでの作業とは異なり、今回はカスタムカーネルを実際に記述しませんでした。この調査ではマルチノードパフォーマンスは考慮されていませんが、シングルノードデプロイメントは実際には依然として非常に普及しています。AMDでのSOTAは、ソフトウェアではなくサポートの問題になりつつあります。CUDAの堀はリアルタイムで侵食されています。2026年6月10日 Balaji Varadarajan および Wafer チームThe Inference Alpha: Maximizing Frontier Models on AMDHow DigitalOcean and Wafer unlock order-of-magnitude inference speedups on AMD GPUs for Kimi 2.5, DeepSeek V3.2, and GLM-5 through deep kernel and systems engineering.2026年5月19日 Ian YeAchieving Heterogeneous Compute One Kernel at a TimeHow custom kernels pushed our AMD MI355X deployment from a tuned baseline to leading Qwen3.5 397B throughput.