‹ Back to Blog

Technical Report

クロスベンダー Disaggregated 推論:NVIDIA H100 と AMD MI300X GPU による GPT-OSS-120B

March 18, 2026

この文書はAIによって自動翻訳されたものです。不自然な表現や不正確な内容が含まれる場合がありますので、必要に応じて英語の原文をご参照ください。 英語の原文を見る

Full technical report in PDF

単一GPUがすべてを担う時代の終焉

AIデータセンターは従来、単一のGPUモデルを中心に構築されてきました——予算の許す限り最新のNVIDIA GPUをできるだけ多く購入し、同一構成でデプロイし、ロードバランサーでリクエストを均等に分散させるというものです。このアプローチはシンプルですが、大規模AI推論の経済的現実とますます乖離しています。すべてのワークロードに最適な単一のアクセラレータアーキテクチャは存在せず、1種類のみをデプロイすることは、常に一部のハードウェアが過剰にプロビジョニングされるか、活用されないことを意味します。

業界は、異なるアクセラレータタイプを組み合わせ、それぞれを最も得意とするワークロードに割り当てるヘテロジニアスシステムへと移行しています。NVIDIAはGTC 2026でこの方向性を明確にし、Vera Rubin GPUとNVIDIA Groq 3 LPX——256基のLPUアクセラレータ(チップあたり500 MB SRAM、アクセラレータあたり150 TB/s帯域幅)を搭載したラック——を組み合わせて共同で推論を行うシステムを発表しました。NVIDIAは、従来の推論アーキテクチャではインタラクティブ性とスループットの間でトレードオフを強いられ——“3つすべてを同時に実現することはできなかった”(インタラクティブ性、インテリジェンス、スループット)と述べています。LPXは、GPUの計算密度とLPUの超高速SRAMアクセスを単一システム内で組み合わせることでこの課題を解決し、1兆パラメータモデルにおいてメガワットあたり最大35×のスループット向上を実現すると主張しています。

Figure 1. NVIDIA Groq 3 LPX rack containing 256 LPU accelerators, designed to work alongside Rubin GPU racks for heterogeneous inference.
図1. NVIDIA Groq 3 LPXラック(256基のLPUアクセラレータ)。Vera Rubinシステムでは、このラックがRubin GPUラックと連携し、GPUとLPUがそれぞれのアーキテクチャ上の強みを活かして共同で推論を実行します。(出典:NVIDIA)

同じ論理は単一ベンダーの製品ライン以外にも適用されます。現実のデータセンターでは、すでに異なる世代のGPU(B300とH200の併用)、異なるGPUベンダー(NVIDIAとAMD)、さらにはまったく異なるアクセラレータクラス(GPUとTenstorrentプロセッサなどのAIアクセラレータ)を混在させています。それぞれの組み合わせが、ワークロードに応じて異なる効率フロンティアを切り開きます。

Prefill-Decode Disaggregation

ヘテロジニアスアクセラレータを活用するさまざまな技術の中で、最も代表的なのがprefill-decode disaggregation(PD disaggregation)です。LLM推論は、計算特性が根本的に異なる2つのフェーズで構成されます。Prefillフェーズは、密行列乗算により入力プロンプト全体を並列処理し、計算律速となります。Decodeフェーズは、自己回帰的に出力tokenを1つずつ生成し、各ステップでGPUメモリからモデルパラメータとKV cacheを読み出すため、メモリ帯域幅律速となります。これら2つのフェーズは、根本的に異なるハードウェア要件を持っています。

Figure 2. Traditional serving vs. disaggregated serving: in traditional serving, prefill and decode share the same GPUs; in disaggregated serving, they run on dedicated GPU groups.
図2. 従来型サービング(左)とdisaggregatedサービング(右)。計算律速のprefillとメモリ律速のdecodeを専用GPUに分離することで、2つのフェーズ間の干渉を排除します。(出典:NVIDIA)

PD disaggregationは、これらのフェーズを専用サーバーノードに分離し、各GPUをそのハードウェア特性に最も適した役割に割り当てます。Prefillノードは入力プロンプトを高スループットで処理し、生成されたKV cacheを高速・低レイテンシネットワーク経由でdecodeノードに転送します。Decodeノードはtoken生成のみを処理し、低く予測可能なtoken間レイテンシを維持します。この分離がなければ、クラスター内で異なるGPUを混在させても効果は限定的です——各ノードは依然として両方のフェーズを実行し、弱い方のフェーズがボトルネックとなります。

クロスベンダーDisaggregationの課題

単一ベンダーエコシステム内のPD disaggregationは、vLLM、SGLang、NVIDIA Dynamoなどのフレームワークですでにサポートされています。しかし、これをベンダーの境界を越えて拡張すること——例えば、NVIDIA GPUでprefillを実行し、AMD GPUでdecodeを実行すること——は、既存のオープンソースフレームワークでは解決されていない独自のエンジニアリング課題をもたらします。

最も根本的な障壁は、統一されたクロスベンダー通信レイヤーの不在です。NVIDIA GPUはNCCL、AMD GPUはRCCLに依存しており、これらのライブラリは相互運用できません。異なるベンダーのprefillノードとdecodeノード間のKV cache転送は、GPUDirect RDMAによる直接GPU間メモリアクセスを使用できず、データはホストCPUメモリを経由する必要があり、クリティカルパスにレイテンシが追加されます。さらに、2つのベンダーエコシステムはまったく異なるソフトウェアスタック(CUDA vs. ROCm)を使用しており、個別のkernel実装、個別のモデルコンパイル、およびアーキテクチャ間の互換性を確保するためのKV cacheメモリフォーマットの慎重な管理が必要です。最後に、異なるGPUアーキテクチャは異なる計算対帯域幅比を持つため、フレームワークは各アーキテクチャの性能特性を理解し、クラスター全体でprefillとdecodeのワークロードを最適にバランスさせる必要があります。

MoAI Inference Framework:クロスベンダーDisaggregation

MoAI Inference Frameworkは、クロスベンダーPD disaggregationをサポートする唯一のプロダクショングレード推論フレームワークであり、単一のサービングクラスター内で異なるベンダーのGPUにprefillとdecodeをルーティングします。NVIDIA Dynamo、vLLM、SGLangはそれぞれのプラットフォーム上でPD disaggregationをサポートしていますが、この機能をベンダーの境界を越えて拡張するものはありません。

MoAIは、ソフトウェアスタックの違いとアーキテクチャ固有の性能特性を処理するベンダーニュートラルな抽象化レイヤーと、異なるベンダーのGPU間でRDMAベースのKV cache転送を可能にする通信ライブラリにより、クロスベンダーの課題を解決します。データセンター運用者は、単一ベンダーロックインから解放され、複数のサプライヤー間でハードウェア予算を配分し、各ベンダーのGPUを最も高い性能を発揮するワークロードフェーズに割り当てることができます。

本レポートでは、特定のクロスベンダーの組み合わせをベンチマークしました:prefillにNVIDIA H100、decodeにAMD Instinct MI300Xを使用し、GPT-OSS-120Bモデルをサービングします。4つのISL/OSLシナリオにおいて、クロスベンダー構成は単一ベンダーMI300Xクラスターと比較して、幾何平均端対端レイテンシとスループットで8–9%の改善を達成し、最も負荷の高いワークロードではレイテンシで最大43%、スループットで最大67%の向上を実現しました。

システムアーキテクチャ

NVIDIA H100とAMD Instinct MI300Xは根本的に異なるハードウェアプロファイルを持ち、推論の異なるフェーズに適しています。

NVIDIA H100 SXMAMD Instinct MI300XMI300X / H100
HBM Capacity80 GB (HBM3)192 GB (HBM3)2.4×
Memory Bandwidth3.35 TB/s5.3 TB/s1.58×
FP8 TFLOPS1,9792,6151.32×
L1 + Scratchpad256 KB per SM32 KB L1D + 64 KB LDS per CU0.38×

MI300Xは、H100の2.4×のHBM容量と1.58×のメモリ帯域幅を提供し、メモリ帯域幅律速のdecodeフェーズにおいて構造的な優位性を持ちます。一方、prefillフェーズは大規模GEMM演算が主体であり、H100のより大きなL1およびscratchpadメモリ(SMあたり256 KB vs. CUあたり96 KB)により、ピークTFLOPSが低いにもかかわらず、より高い計算利用率を維持できます。これらの特性に基づき、H100をprefillに、MI300Xをdecodeに割り当てました。

それぞれ1つの専用prefillノードと1つの専用decodeノードで構成される2つの構成をテストしました:

  • クロスベンダー(ヘテロジニアス):H100ノードがprefill、MI300Xノードがdecodeを担当。Morehは、RDMA経由でKV cacheを転送するカスタムクロスベンダー通信レイヤーを実装しました。現在の実装はホストメモリ経由でデータをステージングします。将来のリリースでは、ベンダー境界を越えた直接GPU間転送を実現するGPUDirect RDMAサポートが追加されます。
  • 単一ベンダー(ホモジニアス):MI300Xノードがprefill、MI300Xノードがdecodeを担当。KV cache転送は、GPUDirect RDMAを有効にしたNIXL connectorを使用し、CPUステージングなしにNIC経由で直接GPU間メモリ転送を実現します。

バックエンド推論エンジンは、AMD MI300Xノード上ではMoreh vLLM、NVIDIA H100ノード上ではvLLMです。クロスベンダー構成がハードウェアアクセラレーションされたGPUDirect RDMAではなくホストステージング転送パスを使用しているにもかかわらず、計算・通信オーバーラップ技術が転送レイテンシを効果的に隠蔽しており、特に高負荷ワークロードで顕著です。

実験セットアップ

3台の独立したサーバーノードを使用しました:1台のNVIDIA H100ノード(prefill用)に8× H100 80 GB SXM GPU、2台のAMD MI300Xノード(1台はdecode用、1台は単一ベンダーテストでのprefill用)にそれぞれ8× MI300X 192 GB OAM GPU。すべてのノードは200 Gbps ConnectX-6 NICで接続されました。

CategoryH100 NodeMI300X Node
CPU2× AMD EPYC 9654 (96-core, 2.4 GHz)2× AMD EPYC 9474F (48-core, 3.6 GHz)
Memory1,536 GB2,304 GB
GPU8× NVIDIA H100 80 GB SXM8× AMD Instinct MI300X 192 GB OAM
NICConnectX-6 (200 Gbps)ConnectX-6 (200 Gbps)
OSUbuntu 22.04.3 LTSUbuntu 22.04.4 LTS
ModelGPT-OSS-120BGPT-OSS-120B
PrecisionMXFP4MXFP4
ParallelismTensor Parallelism (TP=8)Tensor Parallelism (TP=8)
Backend EnginevLLM 0.15.0Moreh vLLM

対象モデルはOpenAIのGPT-OSS-120Bで、総パラメータ数約1,168億、tokenあたりのアクティブパラメータ数約51億の疎なMixture-of-Experts (MoE)モデルです。推論はMXFP4量子化とtensor parallelism TP=8で実行され、各ノードの8基のGPUが単一のモデルpipelineを構成します。Prefix cachingは無効化し、各ハードウェア構成の素の計算効率を分離しました。

4つのISL/OSL(入力シーケンス長/出力シーケンス長)シナリオをテストしました:1K/1K、1K/8K、8K/1K、および8K/8K。ほとんどのシナリオで並行度は1から32の範囲とし、8K/1Kシナリオでは高負荷時の挙動を観察するため最大256まで拡張しました。すべての実験でリクエストレートをREQ_RATE=8に固定しました。メモリアロケーション、GPU kernel初期化、KV cache connectorハンドシェイクによるコールドスタート効果を排除するため、各測定前に2回のウォームアップイテレーションを実施しました。

結果

以下の表は、クロスベンダー(H100 prefill + MI300X decode)と単一ベンダー(MI300X prefill + MI300X decode)の性能を比較しています。E2ELは端対端レイテンシの中央値(秒)、TPSは総スループット(token/秒)です。E2EL RatioとTPS Ratioはクロスベンダー/単一ベンダーであり、E2EL ratioが1.0未満、TPS ratioが1.0超でクロスベンダーの優位性を示します。

ハイライト:高負荷ワークロードでのクロスベンダー優位性

長いシーケンスと高並行度の高負荷ワークロードにおいて、クロスベンダーdisaggregationは単一ベンダーのベースラインに対して大幅な改善をもたらします。

ISL/OSLCONCross E2EL (s)Single E2EL (s)E2EL RatioCross TPSSingle TPSTPS Ratio
8K/1K256190.52256.620.74×12,1079,0301.34×
8K/8K16119.24207.670.57×2,1901,3121.67×
8K/8K32214.75324.800.66×2,4171,5401.57×
Geomean0.65×1.52×

ISL 8K / OSL 8Kにおいて、クロスベンダー構成は並行度16–32でE2ELを34–43%削減し、スループットを57–67%向上させました。これらの向上は、各GPUをそのハードウェア特性に最も適した推論フェーズに割り当て、ベンダー境界を越えたKV cache転送を管理する通信レイヤーの組み合わせによるものです。以下のセクションでは、4つのISL/OSLシナリオとさまざまな並行度レベルの完全な結果を示し、クロスベンダーdisaggregationがいつ、なぜ優位性を発揮するかを説明します。

ISL 1024 / OSL 1024

入力・出力ともに1,024 token——最も軽量なワークロード——では、2つの構成はすべての並行度レベルでほぼ同一の性能を示します。

CONCross E2EL (s)Single E2EL (s)E2EL RatioCross TPSSingle TPSTPS Ratio
15.325.321.00×3813781.01×
46.426.391.00×1,1651,2340.94×
87.287.301.00×2,1392,1750.98×
169.099.240.98×3,4023,3331.02×
3211.6611.391.02×5,1985,0861.02×
Geomean1.00×1.00×

入力tokenが1,024のみの場合、prefillはどちらのGPUでも迅速に完了し、リクエストあたりのKV cacheは数十MBにすぎません。prefill計算もKV cache転送もボトルネックにならないため、性能はほぼ完全にdecode速度で決まります——そしてdecode速度は構成間で同一です。これにより、クロスベンダー運用が固有のペナルティをもたらさないことが確認されました。

ISL 1024 / OSL 8192

短い入力と長い出力(8,192 token)では、decodeフェーズが実行時間の大部分を占めます。クロスベンダーの優位性は並行度4から出現し、着実に拡大して、並行度32ではE2ELが29%削減、スループットが46%向上します。8Kの長い出力シーケンスがdecode側の輻輳効果を増幅します:単一ベンダー構成では、NIXL connector経由の制御されていないKV cacheバースト転送が、出力生成全体のtoken間レイテンシを増大させます。

CONCross E2EL (s)Single E2EL (s)E2EL RatioCross TPSSingle TPSTPS Ratio
145.0544.131.02×2042080.98×
453.6758.510.92×6866261.10×
867.0674.490.90×1,0939861.11×
1693.8292.411.02×1,6391,4891.10×
32108.74152.610.71×2,5081,7221.46×
Geomean0.91×1.14×

ISL 8192 / OSL 1024

長い入力(8,192 token)と短い出力では、prefillが総レイテンシに占める割合が大きくなります。低並行度(1–16)では、prefillはよりメモリ帯域幅律速であり、MI300Xの5.3 TB/s帯域幅が単一ベンダー構成に有利に働きます。並行度32で明確なクロスオーバーが発生します:prefillが計算律速に移行すると、H100の優位性が効果を発揮し、クロスベンダー構成は並行度256まで優位を維持します(E2ELが26%改善、スループットが12,000 tok/s以上を維持 vs. 単一ベンダーの10,000 tok/s未満)。

CONCross E2EL (s)Single E2EL (s)E2EL RatioCross TPSSingle TPSTPS Ratio
16.526.021.08×1,4091,5090.93×
49.007.601.18×3,8544,7270.82×
811.729.651.21×6,0777,0950.86×
1617.3314.621.19×8,7949,5970.92×
3224.9336.540.68×11,4868,1051.42×
6447.7657.000.84×11,8709,9781.19×
128101.58119.450.85×11,2249,5981.17×
256190.52256.620.74×12,1079,0301.34×
Geomean0.95×1.06×

ISL 8192 / OSL 8192

最も負荷の高いワークロードは、前述の2つのシナリオの影響を組み合わせたものです。並行度1では、低並行度でのMI300Xの帯域幅優位性により、単一ベンダー構成がわずかに高速です。並行度8以降、クロスベンダー構成が決定的にリードします——並行度16–32では、E2ELが34–43%高速で、スループットが57–67%向上します。長い入力と長い出力の二重の圧力が、H100の計算律速prefillでの優位性とdecode側の輻輳効果の両方を増幅します。

CONCross E2EL (s)Single E2EL (s)E2EL RatioCross TPSSingle TPSTPS Ratio
152.6747.881.10×3113420.91×
473.4774.770.98×8909270.96×
887.13110.400.79×1,5951,1831.35×
16119.24207.670.57×2,1901,3121.67×
32214.75324.800.66×2,4171,5401.57×
Geomean0.80×1.25×

主要な発見

4つのISL/OSLシナリオすべてにおいて、クロスベンダー構成(H100 prefill + MI300X decode)は、単一ベンダーMI300Xクラスターに対して、幾何平均E2EL ratio 0.92×、幾何平均TPS ratio 1.10×を達成しました(E2EL ratioが1.0未満、TPS ratioが1.0超はクロスベンダーの優位性を示す)。主な知見は以下のとおりです:

  • 実現可能性を確認:NVIDIAとAMD GPU間のクロスベンダーPD disaggregationは、テストしたすべてのワークロードで信頼性をもって動作しました。MoAI Inference Frameworkがハードウェアの違いを抽象化し、運用者は互換性の制約なく単一のサービングクラスター内でGPUベンダーを混在させることができます。
  • 低負荷時の性能同等性:軽量ワークロード(1K/1K)および低並行度では、2つの構成はほぼ同一の性能を提供し、クロスベンダー運用が固有のペナルティをもたらさないことを確認しました。
  • 高並行度でのクロスベンダー優位性:長い出力シーケンスのワークロード(1K/8K、8K/8K)や高並行度(8K/1K、CON ≥ 32)では、クロスベンダー構成がレイテンシで最大43%、スループットで最大67%、単一ベンダー構成を上回ります。2つの要因が寄与しています:(1) 並行度が上がるとprefillは計算律速になり、H100のより大きなオンチップメモリ(L1 + shared memory)が密なGEMM演算をより効率的に処理します。(2) クロスベンダー通信レイヤーのソフトウェアベースの転送バッファリングが、NIXL connectorの直接GPUメモリパスで発生するdecodeノードのキュー飽和を防ぎます。
  • 相補的なハードウェア特性:低並行度では、prefillはよりメモリ帯域幅律速であり、MI300Xの5.3 TB/s帯域幅が優位に働きます。より高い並行度では、prefillは計算律速に移行し、H100の計算密度が優位になります。MI300Xの192 GB HBM3と高帯域幅は、メモリ帯域幅律速のdecodeフェーズに一貫して適しています。
  • ワークロードに応じた最適化が不可欠:性能特性はシーケンス長と並行度レベルによって劇的に変化します——低並行度で劣る構成が、高並行度では43–67%もリードすることがあります。ヘテロジニアスハードウェアの効果を最大限に引き出すには、リアルタイムのワークロードパターンに基づいてprefill/decode割り当て、KV cache転送戦略、リクエストルーティングを動的に調整する必要があります。MoAI Inference Frameworkは、この最適化の自動化を目指しており、各GPUアーキテクチャとワークロードの相互作用に関する深い知識を必要とする手動チューニングから運用者を解放します。

結論

本研究は、ヘテロジニアスGPUクラスターが単一ベンダー構成と同等に——多くのシナリオではより効果的に——LLMをサービングできることを実証しました。NVIDIA H100 GPUを計算集約型のprefillフェーズに、AMD MI300X GPUをメモリ帯域幅集約型のdecodeフェーズに割り当てることで、MoAI Inference Frameworkはデータセンター運用者が単一ベンダーロックインを超え、ベンダーの制約ではなくワークロードの特性に基づいてGPUインフラストラクチャを設計することを可能にします。

最も負荷の高いワークロードでは、クロスベンダー構成が単一ベンダーMI300Xクラスターと比較して、端対端レイテンシを最大43%削減し、スループットを最大67%向上させました。同時に、結果はシーケンス長と並行度に応じて性能特性が大幅に変化することを示しています——軽負荷で最適な構成が重負荷では最適でない場合があり、その逆も同様です。スケールでこの複雑性を手動で管理することは実用的ではありません。MoAI Inference Frameworkは、ヘテロジニアスクラスター全体でのワークロード対応GPU資源割り当て、KV cache転送戦略、リクエストルーティングを自動化することでこの課題に対処し、継続的な手動チューニングの運用負担なくクロスベンダーdisaggregationの性能利点を享受できるようにします。