NVIDIA DGX Sparkについて話すとき、まず話題になるのは2つの点だ。1つ目は、その目玉となるスペック。約4,000ドルのデスクトップ筐体に128GBの統合メモリを搭載している。これは、わずか2年前でさえ、エンジニアのデスクに置くには考えられないようなスペックだ。2つ目は、本体背面に搭載された200GBのネットワークだ。デスクトップ機器に本格的なデータセンタークラスのファブリックが搭載されていることが、人々の注目を集める理由である。なぜなら、それは単に高速なシングルボックスワークステーション以上のものを意味しているからだ。Sparkを接続して物理的に複製できる、かつてはラックにしか設置できなかったようなマルチノード構成が可能になることを意味するのだ。
本レビューでは、その機能を検証します。手元にある3つのOEM Spark実装すべてについて分散推論のベンチマークを行い、200Gbファブリックで接続された2ノードクラスタにペアリングし、モデルバリアントと3つのワークロード形状にわたってテストを実施しました。また、NVIDIAのデフォルト推奨とは異なる、モデルを2つのマシン間で分割する方法について、意図的に方法論的な選択を行い、データに基づいてその妥当性を検証します。ただし、その前に、クラスタリングを可能にするネットワークと、ユーザーがクラスタリングを使用する理由、あるいは使用しない理由という2つの背景情報が、以降のすべての内容を左右します。
200GBファブリック
ネットワークの実装については、以前の DGX Spark レビューで詳しく解説しましたが、このレビューのすべてが基本事項に基づいているため、基本事項を改めて述べておきます。すべての Spark の背面には、統合された NVIDIA ConnectX-7 SmartNIC によって駆動される 2 つの QSFP56 ケージが搭載されています。理論上は、2 つのケージで合計 400 GB の接続が可能とされていますが、実際の上限は PCIe です。ConnectX-7 は 2 つの Gen5 x4 リンクの背後にあり、ケージの配線方法に関係なく、プラットフォームの使用可能な帯域幅は最大 200 GB です。1 つの QSFP56 ケージに部品を組み込むだけで、ボックスがサポートする 200 Gb の帯域幅がすでに確保されているため、2 番目のポートは追加のスループットではなく、トポロジーの柔軟性のために存在します。
その柔軟性は、3つの一般的な構成に表れています。最もシンプルなのは、200 GBのポートを1つ使用してSpark同士を直接リンクさせる構成です。これはNVIDIAが検証済みの2ノード構成で指定されているもので、今回のレビューでも使用しました。2つ目は、100 Gbのポートを2つ使用して、スイッチなしでクラスタリングを行うためにSpark間にリング状のトポロジーを構築する構成です。3つ目は、役割を分割する構成で、一方のケージをクラスタリング用のピアSparkに接続し、もう一方をNVMe-oF経由の高速ストレージに接続する構成です。これは、作業データセットがSparkの内部NVMeに収まらない場合に便利です。
NVIDIAは、ネットワークの利用方法に応じて、Sparkを3つの構成で販売しています。個々のデスクトップ作業向けのシングルSpark、拡張モデル向けに200Gbファブリックで直接接続された検証済みの2つのSparkクラスタ、そして今年のGTCでNVIDIAが2ノード制限を超えるユーザーからの要望に応えて公開した4ユニット構成です。NVIDIAが積極的に販売しているのはデュアルSpark構成であり、読者の多くが実際に導入するであろう構成でもあります。また、このハードウェア上で本番環境レベルの推論を行う際の妥当な上限を表していると考えるのもこの構成です。今回のレビューでも、この構成をエンドツーエンドでベンチマークテストしています。
そもそもクラスタースパークとは？
Sparkをクラスタ化する明白な理由は、他のクラスタと同様、128GBの単一のマシンでは重要なモデルすべてを格納できないためです。120Bパラメータのモデルを2台のマシンに分割することで、通常では収まらないようなワークロードも処理できるようになります。これが最も注目されるユースケースであり、最も頻繁にデモが行われるものです。
あまり知られていない理由、そしておそらくこのプラットフォームにおけるNVIDIAの実際の顧客にとってより重要な理由は、学習です。NVIDIAはSparkを入門機として位置付けています。公式ドキュメント、サンプルノートブック、パートナープレイブックでは、Sparkを教育用機器として扱っています。ローカルチャットインターフェースの背後で事前に構築されたモデルを起動することから、ホストされたエンドポイントに対してコーディングアシスタントを実行すること、小規模モデルの微調整、PyTorchとJAXでエンドツーエンドのアプリケーションを構築することまで、あらゆることに関する一流のガイドが含まれています。その売り文句は、CUDAカーネルを一度も書いたことがない人でも、週末にデスクでゼロから動作するAIワークフローを構築できるということです。これは、完全に制御できる自己完結型のサンドボックスを求める非機械学習分野のエンジニアにも当てはまります。2つのSparkクラスタは、この教育環境をマルチノード領域に拡張します。同じ人が、実際のボトルネックを明らかにするのに十分なほど現実的なネットワークを使用して、テンソル並列処理、パイプライン並列処理、集合通信ライブラリが実際にどのように動作するかを学ぶことができます。
しかし、NVIDIA自身のポジショニングにおいて、Sparkが本番環境の推論処理向けであるという主張が明らかに欠けている。ジェンセン氏はここ数年、ほぼすべての基調講演でハードウェアとソフトウェアの協調設計について語っており、その原則はここにも当てはまる。NVIDIAのプラットフォームはそれぞれ特定のワークロード形状に最適化されており、Sparkはトラフィック処理ではなく、個々の探索と学習に最適化されている。以前のSparkレビューですでに示されているように、このプラットフォームはほとんどの推論タスクでメモリ帯域幅に大きく依存しており、クラスタリングするとネットワークによってその制約がさらに厳しくなる。デスクトップとしては印象的な200Gbリンク1本でも、単一シャーシ内のPCIe Gen5 x16接続よりは明らかに遅く、NVLinkブリッジで接続されたデータセンターGPUペア間でスムーズに動作する集合通信パターンは、実際のレイテンシのペナルティなしには200Gbファブリックに移植することはできない。
これが、NVIDIAが公式にサポートする構成を長らく2つのSparkに限定していた本当の理由であり、GTCでの4ユニットのデモが製品の自然な拡張ではなく、ユーザーの要望に応えたものであった理由です。ソフトウェアスタックは4ノードまたは8ノードで実行できますし、複数のユーザーやメディアがより大規模なクラスタでの結果を公表しています。これらの実験から得られたパフォーマンス数値は概して芳しくありません。ノード間のファブリックが主要なコストとなり、全体のパフォーマンスは急激に低下します。さらに、これらの構成の末端では、クラスタを正当化するのに十分な規模のモデルであっても、ユーザーあたりのスループットが1秒あたり1桁のトークンの範囲まで低下する可能性があります。その時点では、このセットアップは機能的にはサービスプラットフォームではなく、学習ラボとなっています。
これは決して否定的な意味ではありません。Sparkクラスタリングは、数十万ドルもするデータセンターのハードウェアに阻まれて得られない分散推論とトレーニングの直感を養うための実に優れた方法であり、パイプラインのバブル、オールリデュースのボトルネック、並列処理のトレードオフを実際に自分のシステム上で確認できることの教育的価値は非常に大きいものです。私たちの次の計画は、この取り組みをさらに進め、実際の分散事前トレーニング実行の条件をできる限り忠実に再現するように選択したデュアルSparkクラスタ上で、1億パラメータまたは1億パラメータ未満の小規模モデルをゼロからトレーニングし、この種のクラスタが有効な場合とそうでない場合を正確に示すことでした。現在、このプロジェクトは、既にご覧いただいた他の記事の執筆作業と、新しい800Gbラボコアスイッチの光学系の到着を待っている間、保留状態となっています。ラボ環境が安定したら、このプロジェクトを再開する予定です。
以下では、デュアルSpark構成が最も有効となるユースケース、すなわち、両方のSparkボックスを必要とするほど大規模なモデルの分散推論に焦点を当て、手元にある3つのOEM実装すべてでベンチマークテストを実施します。モデルごとの数値に入る前に、次のセクションでは、NVIDIAの公式ドキュメントでデフォルトとして使用されているテンソル並列構成ではなく、パイプライン並列構成でこれらの数値を報告する理由を説明します。
性能試験
パイプライン並列ではなくテンソル並列を報告する理由
NVIDIA が公開しているDGX Spark ガイドやほとんどのリファレンス資料では、2 つの Spark ボックス間でモデルをスケーリングする方法を説明するために、テンソル並列処理 (TP) を使用しています。TP では、すべての行列乗算を両方の GPU に分割するため、各レイヤーは両方のデバイスで同時に実行され、部分的な結果は、すべてのアテンションと MLP ブロックの後に all-reduce によって結合されます。パイプライン並列処理 (PP) は異なるアプローチを採用しています。モデルをレイヤーごとに半分に分割し、前半を一方のボックスに、後半をもう一方のボックスに配置し、アクティベーションをそれらの間でストリーミングします。各リクエストは引き続き完全なモデルを流れますが、任意の時点では、一方のボックスのみが特定のトークンの計算を実行し、もう一方のボックスは次のマイクロバッチを処理します。
トレードオフは、ネットワークを介して何が伝送されるかに尽きます。デュアル Spark スタックは、ConnectX-7 200 GbE リンクを介して 2 つのシステムを接続します。これはネットワーク リンクとしては高速ですが、単一の Spark 内のメモリ帯域幅と比較すると低速です。TP の all-reduce はトランスフォーマー レイヤーごとに 2 回実行されるため、TP=2 で実行される 80 レイヤー モデルでは、出力トークンごとに 160 回のクロス ボックス交換が発生し、その交換の 1 回ごとに次の計算がブロックされます。PP=2 では、モデルの 2 つの半分の間の境界で、トークンごとに 1 回だけアクティベーションを渡します。レイテンシが無視できない 200 GbE リンクでは、この違いが他のすべてを凌駕します。
GPT-OSS-120B の測定結果は、これを明確に裏付けています。バッチ サイズ 1 ではワークロードが薄すぎてどちらの戦略のオーバーヘッドも隠せないため、PP=2 がリードし、並列度が増加するにつれてそのリードを維持します。Equal ISL/OSL ワークロードでは、バッチ サイズ 128 で TP=2 が 252.01 tok/s に達するのに対し、PP=2 は同じハードウェアで 554.69 tok/s まで上昇し、2.20 倍の優位性があります。Prefill Heavy も同様の傾向を示し、PP=2 は 310.63 tok/s で終了し、TP=2 は 164.99 tok/s です。Decode Heavy シナリオは 3 つの中で最も拮抗していますが、PP=2 はバッチ サイズ 8 からバッチ サイズ 64 までリードしており、長い 8K 出力がパイプライン バブル コストを増幅するバッチ サイズ 128 でわずかにリードを譲るだけです。
TP=2 が優位に立つのは、ごく限られた範囲に限られます。バッチサイズ 1 の場合、どのシナリオでも TP はわずかですが確実に優位に立っています。Equal では 39.55 tok/s 対 28.79 tok/s、Prefill Heavy では 37.97 対 29.60、Decode Heavy では 39.42 対 30.28 です。処理中のリクエストが 1 つしかない場合、アイドル状態のパイプライン ステージをビジーに保つための 2 番目のマイクロ バッチは存在しないため、PP はステップごとに空きスロットの料金を支払うことになりますが、TP は存在する唯一のトークンで両方の GPU を使用できます。これは、NVIDIA の TP ガイダンスが想定している環境です。つまり、最初の唯一のリクエストのレイテンシが総スループットよりも重要となる、インタラクティブなシングル ストリーム サービスです。デプロイメントが本当にチャット スタイルで、1 つのボックスにつき 1 人のユーザーとタイトな TTFT ターゲットがある場合、TP=2 が適切な選択であり、これは NVIDIA が Spark をどのように捉えているかとも一致します。
バッチ推論と多数の同時リクエストを伴う大規模なインフラストラクチャを提供するワークロードの場合、特にエキスパート並列処理などの戦略が使用されていない場合は、複数のマシンにまたがってスケーリングする際にはパイプライン並列処理の方が適しています。200 GbE ファブリックは、コンピューティングをアイドル状態にすることなく TP のトークンごとの all-reduce トラフィックを維持することはできず、バッチサイズが 4 または 8 になると、PP のバブルコストは定常状態のストリームに消えてしまいます。そのため、この記事の残りの部分では、モデルごとの数値はすべて TP=1、PP=2 で報告されています。これは、デュアル Spark デプロイメントが実際の作業を実行する際に実際に提供できるものを表している構成です。
TPとPPの比較グラフの見出しとしてGPT-OSS-120Bを選んだのは、このグラフが最も大きな差を示しているためです。しかし、これはすべてのモデルに当てはまるわけではなく、これらのパラメータはモデルのパラメータに依存することも示したいと考えています。BF16のLlama-3.1-8B-Instructは、はるかに控えめな結果を示しています。このモデルは十分に小さいため、各レイヤーの計算が高速で、TPのall-reduceトラフィックもそれに応じて控えめです。対照的に、PPのステップごとの調整コストはモデルのサイズに関係なく固定されています。その結果、TP=2はバッチスイープのほぼ全体にわたってリードを維持しています。 Equal ISL/OSL では、TP=2 はバッチ サイズ 1 (23.2 対 13.4 tok/s) からバッチ サイズ 32 (388.7 対 349.3 tok/s) までリードし、バッチ サイズ 64 (524.8 対 638.2 tok/s) とバッチ サイズ 128 (679.2 対 1,047.1 tok/s) でのみトップの座を失います。Prefill Heavy も同様のパターンで、TP=2 がバッチ サイズ 32 までリードした後、PP=2 が 64 と 128 でリードします。Decode Heavy は最も決定的な結果で、TP=2 はすべてのバッチ サイズで勝利し、バッチ サイズ 128 では 366.7 tok/s で PP=2 の 330.5 tok/s を上回ります。
この反例は、根本的なメカニズムを否定するのではなく、むしろ強化するものです。PP=2 が勝つのは、バッチサイズがパイプラインを満たし、バブルコストを完全に償却できるほど十分に大きく、かつモデル自体が TP のレイヤーごとの全削減が安価になるほど小さい場合のみです。このクロスオーバーポイントはさらに先に進みます。デコードヘビーの結果も一貫しています。出力シーケンスが長くなると、デコードステップが増え、パイプラインバブルが連続して支払われる回数が増え、PP が差を埋めるための時間が短くなります。言い換えれば、バッチサイズ 128 で GPT-OSS-120B に対して 2.20 倍の勝利をもたらすのと同じ物理法則が、8B モデルで上位 2 つのバッチサイズでのみ勝利し、デコードヘビーのスイープでは決して勝利しない理由も説明しています。
GPT-OSS-120B
ISL/OSL が等しい場合、Dell は 67.06 tok/s から始まり、バッチサイズ 64 で 927.93 tok/s までスケールアップします。GIGABYTE は 65.77 tok/s とやや低いスタートですが、最終的には 994.53 tok/s まで向上し、HP は 1,009.75 tok/s でグループをリードしています。ほとんどのテストで差は小さく、バッチサイズ 32 以降は HP がリードしています。
プリフィルヘビーでは、スループットが全体的に大幅に向上します。Dellは164.42 tok/sから2,097.80 tok/sに、GIGABYTEは162.96 tok/sから2,086.72 tok/sに、そしてHPは165.95 tok/sから2,208.16 tok/sに上昇し、最も優れた結果を示しました。HPはほぼすべてのバッチサイズでリードしており、DellとGIGABYTEは特にバッチサイズ32と64で非常に近い値となっています。
デコード負荷が高い場合、デコード処理の負荷が高いため、全体的なパフォーマンスは予想通り低下します。Dellは41.20 tok/sから563.98 tok/s、GIGABYTEは40.83 tok/sから617.96 tok/s、HPは41.63 tok/sから593.56 tok/sの範囲で推移します。バッチサイズ64ではGIGABYTEが最も優れた結果を示し、中程度の処理ではHPがリード、Dellは高い同時実行数ではわずかに劣るものの、僅差で追随しています。
GPT-OSS-20B
ISL/OSLの均等比較では、Dellがほとんどの項目でリードしており、バッチサイズ1で88.73 tok/sからバッチサイズ64で1,953.55 tok/sまでスケーリングしています。GIGABYTEはそれに僅差で続き、88.42 tok/sから1,904.62 tok/sまで増加し、HPは83.49 tok/sから1,831.45 tok/sの範囲となっています。Dellは全体的に最も強力なハイエンドスケーリングを維持しており、特にバッチサイズ16以降でその傾向が顕著です。
Prefill Heavy では、3 つのシステムすべてでスループットが急激に上昇します。このテストでは Dell が最高値を記録し、バッチサイズ 64 で 216.05 tok/s から 4,261.96 tok/s にスケールアップします。GIGABYTE は 4,011.86 tok/s で続き、HP は 3,785.25 tok/s に達します。3 つのシステムは、より小さなバッチサイズでは密接にまとまっていますが、バッチサイズ 16 で Dell が他社との差を広げ始め、残りのテストでそのリードをさらに広げます。
Decode Heavyでは、スケーリングはより緩やかですが、すべてのプラットフォームで高いパフォーマンスを維持しています。Dellは54.88 tok/sから1,173.31 tok/s、GIGABYTEは55.24 tok/sから1,181.94 tok/s、HPは53.20 tok/sから1,082.23 tok/sにそれぞれスケーリングしています。バッチサイズが最大の場合、GIGABYTEがDellをわずかに上回りますが、同時実行レベルが高い場合はHPが両システムに劣ります。
ラマ3.1 8B インストラクションベース
Equal ISL/OSL では、バッチサイズ 64 で Dell は 27.69 tok/s から 1,376.38 tok/s までスケーリングし、27.23 tok/s から 1,372.27 tok/s の範囲の GIGABYTE をわずかに上回ります。HP は全体を通してわずかに遅れ、26.89 tok/s から 1,235.32 tok/s までスケーリングします。バッチサイズ 16 までは 3 つのシステムすべてが非常に近い値を示しますが、より高い同時実行レベルで Dell がわずかにリードし始めます。
プリフィルヘビーでは、バッチサイズが大きくなるにつれてスループットが急激に向上します。Dellは68.60 tok/sから2,575.25 tok/sに増加し、GIGABYTEは最終的に最も優れた結果を記録し、バッチサイズ64で67.49 tok/sから2,694.25 tok/sに拡大しました。HPは2,315.15 tok/sに達し、競争力を維持していますが、バッチサイズが大きいほどDellとGIGABYTEに常に劣ります。GIGABYTEは、特にバッチサイズが64以上の場合、上位でリードしています。
Decode Heavyでは、スケーリングは全体を通して安定しています。Dellは17.19 tok/sから726.22 tok/s、GIGABYTEは16.96 tok/sから720.57 tok/s、HPは16.79 tok/sから663.31 tok/sの範囲でスケーリングしています。DellとGIGABYTEはテストの大部分でほぼ同じですが、同時実行数が最も高いレベルではDellがわずかに優位に立っています。同時に、バッチサイズが大きい場合はHPがわずかに劣ります。
ラマ3.1 8B命令FP4
ISL/OSL が等しい場合、Dell はバッチサイズ 64 で 69.71 tok/s から 2,849.20 tok/s までスケーリングし、GIGABYTE はわずかに上回り、70.92 tok/s から 2,912.03 tok/s まで成長します。HP も競争力を維持し、69.52 tok/s から 2,821.50 tok/s の範囲となっています。3 つのシステムはワークロード全体にわたって密接にグループ化されており、同時実行レベルが高くなるとわずかな差が見られるだけです。
Prefill Heavy では、特にバッチサイズが大きい場合にスケーリングがはるかに積極的になります。Dell は 170.09 tok/s から 4,417.65 tok/s に増加し、GIGABYTE はグループの中で最も優れた結果を記録し、バッチサイズ 64 で 173.55 tok/s から 4,767.43 tok/s に上昇します。HP は 170.12 tok/s から 4,214.57 tok/s にスケーリングします。GIGABYTE はバッチサイズ 32 以降で他社との差が開き始め、このワークロードで最も高いスループットを実現しています。
Decode Heavyでは、3つのシステムすべてが、ほとんどのスキャンにおいて再びほぼ同等の性能を維持しています。Dellは43.19 tok/sから1,260.24 tok/s、GIGABYTEは43.53 tok/sから1,258.05 tok/s、HPは42.54 tok/sから1,178.74 tok/sにそれぞれ対応しています。DellとGIGABYTEはバッチサイズに応じて事実上リードを入れ替えていますが、HPは最大の同時実行レベルでは両システムにわずかに劣っています。
ラマ3.1 8B命令FP8
Equal ISL/OSLでは、Dellはバッチサイズ64で46.93 tok/sから2,206.52 tok/sまでスケーリングし、GIGABYTEは46.16 tok/sから2,175.44 tok/sまでスケーリングします。HPはそれに僅差で続き、46.40 tok/sから2,149.15 tok/sまで増加します。テスト全体を通して全体的なばらつきは小さく、3つのシステムすべてがバッチサイズ32までほぼ同じスケーリング動作を維持しています。
Prefill Heavy では、同時実行数の増加に伴いスループットがより積極的に上昇します。Dell は 115.85 tok/s から 3,794.52 tok/s に増加し、GIGABYTE はバッチサイズ 64 で 113.34 tok/s から 4,133.76 tok/s に拡大し、全体的に最も優れた結果を示しました。HP は 3,624.73 tok/s に達します。GIGABYTE は、特にバッチサイズ 32 以降、より高いバッチサイズでより顕著なリードを確立し始めます。
Decode Heavyでは、3つのシステムは低同時実行レベルではほぼ同程度の性能を維持しますが、高同時実行レベルではわずかな差が生じます。Dellは29.11 tok/sから1,077.07 tok/s、GIGABYTEは28.64 tok/sから1,068.92 tok/s、HPは28.68 tok/sから1,000.20 tok/sにそれぞれ上昇します。ワークロードの大部分においてDellがわずかにリードを保ち、GIGABYTEがそれに非常に近い位置に追随する一方、HPはバッチサイズが大きくなるとわずかに後れを取ります。
ミストラル スモール 3.1 24V
ISL/OSL が等しい場合、Dell はバッチサイズ 64 で 10.41 tok/s から 498.56 tok/s までスケーリングし、GIGABYTE は上限でわずかにリードし、9.76 tok/s から 509.18 tok/s まで増加します。HP は両システムにわずかに劣り、9.25 tok/s から 477.25 tok/s の範囲です。ワークロード全体を通して、特に低～中程度の同時実行レベルでは、システム間の差は比較的小さいままです。
Prefill Heavyでは、3つのシステムすべてでスケーリングが大幅に改善されています。Dellは25.91 tok/sから1,079.19 tok/sに増加し、GIGABYTEは24.25 tok/sから1,071.07 tok/sにスケーリングしています。HPはバッチサイズ64で988.82 tok/sに達しています。DellとGIGABYTEはスイープの大部分でほぼ同じですが、最も高い同時実行レベルではDellがわずかに優位に立っています。
Decode Heavy では、予想通り、より大きなモデルでのデコード重視のワークロードでは、スループットは全体的に大幅に低いままです。Dell は 6.49 tok/s から 297.82 tok/s まで、GIGABYTE は 6.10 tok/s から 297.23 tok/s まで、HP は 5.77 tok/s から 276.55 tok/s まで増加します。Dell と GIGABYTE はテスト全体を通してほぼ互角ですが、HP はバッチサイズが大きい場合、一貫して両システムにわずかに劣ります。
Qwen3 コーダー 30B A3B ベース
Equal ISL/OSLでは、Dellはバッチサイズ64で59.05 tok/sから817.82 tok/sまでスケーリングし、GIGABYTEは59.81 tok/sから809.88 tok/sまでスケーリングします。HPは両システムにわずかに劣り、56.51 tok/sから780.21 tok/sまで増加します。DellとGIGABYTEのパフォーマンスは、ほとんどの範囲でほぼ同じで、バッチサイズが大きい場合にのみわずかな差異が見られます。
Prefill Heavy では、同時実行数の増加に伴いスループットが大幅に向上します。Dell は 144.81 tok/s から 1,756.99 tok/s に増加し、GIGABYTE はバッチサイズ 64 で 147.55 tok/s から 1,862.40 tok/s に増加し、全体的に最も高いスケーリング性能を示します。HP は 1,751.17 tok/s に達し、競争力を維持していますが、上位の 2 つのシステムにわずかに劣ります。GIGABYTE はバッチサイズ 32 付近からわずかにリードを確立し、テストの最終段階までそのリードを維持します。
Decode Heavy では、3 つのシステムはワークロードの大部分において再びほぼ同等の性能を維持しています。Dell は 36.69 tok/s から 427.48 tok/s の範囲、GIGABYTE は 36.92 tok/s から 417.42 tok/s の範囲、HP は 35.30 tok/s から 403.32 tok/s の範囲となっています。Dell は最大のバッチサイズでわずかに優位性を維持していますが、デコードに特化したワークロードでは HP は Dell と GIGABYTE の両方にわずかに劣っています。
Qwen3 コーダー 30B A3B FB8
ISL/OSLが等しい場合、Dellはバッチサイズ64で98.65 tok/sから1,379.26 tok/sまでスケーリングし、GIGABYTEは100.20 tok/sから1,308.79 tok/sまで変化します。HPは全体を通して競争力を維持し、97.06 tok/sから1,354.23 tok/sまで増加します。HPはいくつかの低～中程度のバッチサイズで一時的にリードしますが、Dellは全体的に最も高いスループットで終了します。
Prefill Heavy では、3 つのシステムすべてでスループットが急激に向上します。Dell は 240.43 tok/s から 3,041.72 tok/s に増加し、GIGABYTE はバッチサイズ 64 で 245.92 tok/s から 3,088.62 tok/s に向上し、全体的に最も優れた結果を示しました。HP は 2,857.80 tok/s に達しました。GIGABYTE はバッチサイズ 4 から顕著なリードを確立し、スイープの残りの部分でそれを維持します。
Decode Heavy では、Dell が全体的に最も高い上位スケーリング性能を発揮します。Dell は 60.91 tok/s から 705.77 tok/s の範囲でスケーリングし、GIGABYTE は 61.53 tok/s から 639.80 tok/s まで、HP は 59.85 tok/s から 635.25 tok/s までスケーリングします。HP はバッチサイズが小さい場合は一時的にリードしますが、同時実行レベルが大きい場合は Dell がリードし、グループ内で最も高いデコードスループットを実現しています。
デュアルスパークシステムの最大出力概要
以下の表は、Dell、GIGABYTE、およびHPのデュアルSparkシステムにおける分散PP=2テスト中に観測されたピークトークン出力スループットをまとめたものです。各値は、テスト対象のバッチサイズにおける当該ワークロードシナリオで達成された最高出力スループット（tok/s）を表しています。太字で示されている数値は、当該ワークロードシナリオにおいて最も優れたパフォーマンスを発揮したシステムを示しています。
| モデル | シナリオ（BS – 64） | Dellのピーク出力 | GIGABYTE ピーク出力 | HP ピーク出力 |
|---|---|---|---|---|
| GPT-OSSモデル | ||||
| GPT-OSS-120B | ISL/OSLは同等 | 463.97 トーク/秒 | 497.26 トーク/秒 | 504.88 トーク/秒 |
| GPT-OSS-120B | プレフィルヘビー | 419.56 トーク/秒 | 417.34 トーク/秒 | 441.63 トーク/秒 |
| GPT-OSS-120B | デコードヘビー | 451.18 トーク/秒 | 494.37 トーク/秒 | 474.85 トーク/秒 |
| GPT-OSS-20B | ISL/OSLは同等 | 976.77 トーク/秒 | 952.31 トーク/秒 | 915.72 トーク/秒 |
| GPT-OSS-20B | プレフィルヘビー | 852.39 トーク/秒 | 802.37 トーク/秒 | 757.05 トーク/秒 |
| GPT-OSS-20B | デコードヘビー | 938.65 トーク/秒 | 945.55 トーク/秒 | 865.78 トーク/秒 |
| ラマモデル | ||||
| ラマ-3.1-8B-指示 | ISL/OSLは同等 | 689.53 トーク/秒 | 687.48 トーク/秒 | 618.87 トーク/秒 |
| ラマ-3.1-8B-指示 | プレフィルヘビー | 515.45 トーク/秒 | 539.27 トーク/秒 | 463.39 トーク/秒 |
| ラマ-3.1-8B-指示 | デコードヘビー | 581.43 トーク/秒 | 576.91 トーク/秒 | 531.07 トーク/秒 |
| ラマ-3.1-8B-FP4 | ISL/OSLは同等 | 1427.39 トーク/秒 | 1458.86 トーク/秒 | 1413.51 トーク/秒 |
| ラマ-3.1-8B-FP4 | プレフィルヘビー | 884.22 トーク/秒 | 954.23 トーク/秒 | 843.57 トーク/秒 |
| ラマ-3.1-8B-FP4 | デコードヘビー | 1008.98 トーク/秒 | 1007.23 トーク/秒 | 943.73 トーク/秒 |
| ラマ-3.1-8B-FP8 | ISL/OSLは同等 | 1105.42 トーク/秒 | 1089.85 トーク/秒 | 1076.68 トーク/秒 |
| ラマ-3.1-8B-FP8 | プレフィルヘビー | 759.50 トーク/秒 | 827.40 トーク/秒 | 725.51 トーク/秒 |
| ラマ-3.1-8B-FP8 | デコードヘビー | 862.33 トーク/秒 | 855.81 トーク/秒 | 800.78 トーク/秒 |
| ミストラルとクウェンのモデル | ||||
| ミストラル-スモール-3.1-24B | ISL/OSLは同等 | 249.77 トーク/秒 | 255.09 トーク/秒 | 239.09 トーク/秒 |
| ミストラル-スモール-3.1-24B | プレフィルヘビー | 216.01 トーク/秒 | 214.38 トーク/秒 | 197.92 トーク/秒 |
| ミストラル-スモール-3.1-24B | デコードヘビー | 238.44 トーク/秒 | 237.97 トーク/秒 | 221.41 トーク/秒 |
結論
今回のテストで最も有益な発見は、どのOEMがどのワークロードで優位に立ったかという点とはほとんど関係がない。テストしたすべてのモデルとワークロードにおいて、Dell、GIGABYTE、HPの3つのSpark実装は、いずれも狭い範囲内で性能を発揮した。特定のバッチサイズではわずかな差が見られたものの、どのプラットフォームも圧倒的な勝利を収めることはなく、またどのプラットフォームも常に劣勢に立たされることもなかった。3つのプラットフォームから選択する際は、ベンチマークの差ではなく、筐体設計、熱特性、保証条件、サポート体制に基づいて判断すべきである。ベンチマークの差は、デスクトップクラスのシステムが持続的な負荷を受けた際に発生する、実行ごとのばらつきに近いものだからだ。
より興味深い結果は方法論的なものです。2 つの Spark を接続する 200 GbE ファブリックでは、テンソル並列処理とパイプライン並列処理の選択が、3 つの OEM 間の違いよりも重要であり、妥当な並列度でのバッチ推論にはパイプライン並列処理の方が適しています。TP=2 のレイヤーごとの all-reduce トラフィックは、コンピューティングをアイドル状態にすることなく ConnectX-7 リンクを通過するには不十分であり、PP=2 のパイプライン バブル コストは、バッチがパイプラインを満たすとすぐに定常状態のストリームに償却されます。NVIDIA のドキュメントでは、正当な理由からデフォルトで TP が推奨されています。Spark の主な位置付けは、TTFT がタイトなインタラクティブなシングル ストリーム サービスであり、これは TP=2 が完全に優位に立つ唯一の領域です。ワークロードがチャット インターフェイスではなくサービス インフラストラクチャのように見える瞬間、計算は逆転します。
この逆転現象は、Sparkが何であり、何でないのかを明確に示しています。2ノードのSparkクラスタは、開発および学習プラットフォームであり、1人のエンジニアが、実際のデータセンターのファブリックを模倣するのに十分な速度のネットワーク上で分散推論の動作を直接確認できると同時に、大規模な本番環境での展開で回避されるボトルネックを明らかにするのに十分な制約も設けています。
より大規模な Spark 構成については、その規模に適したワークロードと並列処理戦略を用いて個別に検討する価値があり、そのための作業はロードマップに含まれています。また、今回の実験に続いて予定されている次の実験では、推論から学習へと移行します。これは、より大規模なシステムの分散型事前学習条件を模倣するように構成されたデュアル Spark クラスタ上で、1億パラメータ未満のモデルをゼロから学習させるものです。この作業は、新しい 800 Gb ラボ コア スイッチ用の光学系が届くまで一時停止しており、新しいコアがオンラインになり次第、公開する予定です。
Amazon