
マーク・ハリス著
2025年7月30日発行
よりインテリジェントなAIモデル、特に大規模言語モデル(LLM)とディープラーニングアルゴリズムの飽くなき追求は、計算能力に対する前例のない需要を牽引してきました。この革命の核心はグラフィックス・プロセッシング・ユニット(GPU)です。その並列処理能力は、AIトレーニングを特徴付ける集中的な反復計算に最適です。しかし、データセンター環境で相互接続された数千台のGPUの潜在能力を最大限に引き出すには、単にそれらをプラグインするだけでは不十分です。膨大なデータフローを最小限の遅延で、そして何よりもパケットロスゼロで処理できる高度なネットワーク基盤が必要です。これが、 データセンターブリッジング(DCB)高度なフロー制御メカニズムと組み合わせると、 優先度ベースフロー制御(PFC) そして 明示的輻輳通知(ECN)は絶対に必要になります。
大規模GPUクラスタにおけるネットワーク輻輳の概要
AIの学習ジョブが数百、あるいは数千ものGPUにまたがっていると想像してみてください。これらのGPUは膨大な量のデータ(パラメータ、勾配、活性化値など)を、しばしば高度に同期したバーストで絶えず交換しています。この「全対一」または「多対一」の通信パターンは、 インキャストは、一般的にイーサネットと呼ばれる従来のネットワークをすぐに圧倒する可能性があります。 スループットの崩壊適切なメカニズムがなければ、ネットワークバッファがオーバーフローし、パケットドロップが発生します。AIの文脈において、パケットロスは単なる不便さではなく、学習効率を著しく低下させ、学習時間を増加させ、さらにはモデルの収束に問題を引き起こす可能性があります。パケットロスによる再送信は大きな遅延を引き起こし、GPUの高速処理能力を事実上無効にしてしまう可能性があります。
ネットワーク接続、輻輳、GPU 使用率
したがって、ネットワークの成功は、トレーニングと推論の両方において、資本集約型の GPU を高利用するための鍵となります。
- LLM 推論 (モデルの並列処理とバッチ処理): モデルの並列処理を必要とする非常に大規模な LLM (モデルの異なるレイヤーまたは部分が異なる GPU、場合によっては異なるサーバー上に存在する) の場合、各推論リクエストでは、プロンプトがモデルのレイヤーを通過する際に GPU 間で順次データ転送が行われます。これらの GPU 間のネットワーク パスで少しでも輻輳が発生すると、推論パイプライン全体が停止します。同様に、バッチ処理を使用して GPU 使用率を最大化する場合、バッチの一部の輻輳によるわずかなパケット損失や遅延によってバッチ全体の完了が遅れ、後続のバッチに波及効果が生じる可能性があります。これは、エンドユーザーにとっての推論レイテンシの増加と、システム全体の推論スループット (1 秒あたりのクエリ数) の大幅な低下に直接つながります。DCB のロスレス機能により、これらの重要な GPU 間転送が中断されることがなくなり、スムーズで高スループットの推論パイプラインが維持され、GPU 投資の ROI が最大化されます。
- LLM の微調整 (分散トレーニング): 数百のGPUにまたがる分散型の微調整ジョブでは、勾配更新とモデルパラメータ(All-Reduce操作など)の頻繁かつ大規模な交換が行われます。ネットワークが輻輳すると、これらの集合的な通信操作の速度が大幅に低下します。並列プロセッサであるGPUはアイドル状態になり、他のGPUからのデータが現在の反復処理を完了するまで次の反復処理を開始できません。100%の計算使用率を示すGPUは、ネットワークI/Oのためにストールしている可能性があります。これは、実際に行われる作業量が大幅に減少することを意味し、数時間、あるいは数日もの無駄な計算時間とクラウド/電気料金の増加につながります。PFCは、これらの重要なAll-Reduceパケットが決してドロップされないことを保証し、壊滅的な速度低下を防ぎます。一方、ECNはフローをプロアクティブに管理し、これらのアイドル待機を最小限に抑えます。
データセンターブリッジング:ロスレスAIネットワークの構築
データセンターブリッジング(DCB)は、データセンター環境のイーサネットを強化するために設計されたIEEE標準規格(802.1Qxx)のセットであり、特に、さまざまなトラフィックタイプ(ストレージ、管理、高性能コンピューティング)が共存する統合ネットワークをサポートします。AIにおけるDCBの役割の鍵は、 低遅延でロスレスなイーサネットファブリック重要なAIトラフィックでパケットロスが発生しないことを保証します。これを可能にするDCBの2つの重要なコンポーネントは、優先度ベースのフロー制御(PFC) および明示的輻輳通知 (ECN).
優先度ベースフロー制御(PFC):リンクレベルでのパケット損失の防止
PFC(IEEE 802.1Qbb)は、従来のイーサネットPAUSEフレームを拡張したリンクレベルのフロー制御メカニズムです。リンク上のすべてのトラフィックを停止する標準的なPAUSEフレームとは異なり、PFCでは サービスクラス(CoS)の優先度に基づいてトラフィックを選択的に一時停止する.
GPU 密度の高い環境で PFC がどのように機能するかを簡単に説明します。
- トラフィック分類: AIトレーニングトラフィックは、多くの場合、Remote Direct Memory Access (RDMA) over Converged Ethernet (RoCEv2) を利用し、特定の高優先度CoSが割り当てられます。これにより、ネットワークによって重要なデータとして扱われることが保証されます。
- 輻輳検出: 特定の CoS キュー (RoCEv2 トラフィック専用のキューなど) のスイッチの出力バッファが事前定義されたしきい値に達すると、輻輳が差し迫っていることを示します。
- PFC 一時停止フレーム: 輻輳したスイッチは、上流の送信デバイス(別のスイッチまたはGPUのネットワークインターフェースカード(NIC))にPFCポーズフレームを送り返します。このポーズフレームは、輻輳したCoS優先度に固有のものです。
- 選択的停止: PFCポーズフレームを受信すると、上流デバイスは特定のCoS優先度のトラフィックの送信を一時的に停止します。同じリンク上の他のトラフィッククラスには影響しません。
- バッファ回復と再開: 輻輳したバッファが空になり、その占有率が再開しきい値を下回ると、スイッチは PFC 再開フレームを送信し、上流デバイスにその優先度の送信を再開するように通知します。
GPU における PFC の利点:
- パケット損失ゼロ: PFC は、バッファがオーバーフローする前にトラフィックを一時停止することで、分散 GPU 計算の整合性と効率にとって最も重要である重要な AI データのロスレス配信を保証します。
- トラフィックの分離: これにより、高優先度の AI トラフィックのバーストが、同じリンク上の他の時間的制約がそれほど厳しくないトラフィック タイプに影響を与えるのを防ぎ、ネットワーク全体の安定性を維持します。
- 予測可能なパフォーマンス: PFC はパケット損失を排除することで、GPU 通信の予測可能で一貫したパフォーマンスに貢献し、ジッターを削減し、ジョブの完了時間を改善します。
ただし、PFCには限界があります。慎重に設計・設定しないと、「PFCストーム」が発生する可能性があります。これは、ポーズフレームが広範囲に伝播し、特にマルチホップ環境ではネットワーク全体の速度低下やデッドロックにつながる可能性があります。 このため、PFCを補完するために別の技術であるECNが追加されます。.
明示的輻輳通知(ECN):プロアクティブな輻輳回避
ECN(RFC 3168)は、ネットワークデバイスがエンドポイントに初期の輻輳を通知できるようにするメカニズムです。 前に パケットロスが発生した場合、ECN対応デバイスはパケットをドロップする代わりに、IPヘッダーにパケットをマークして輻輳を通知します。これにより、GPU間トラフィックの信頼性向上に必要なレベルのアクティブキュー管理が実現します。
ECN トラフィック管理プロセスは通常、次のように展開されます。
- ECN対応ネゴシエーション: 接続の確立中(TCP ハンドシェイクなど)、送信者と受信者は ECN 機能をネゴシエートします。
- 渋滞マーク: ネットワーク デバイスのキュー使用率が ECN しきい値 (PFC をトリガーするしきい値よりも低いしきい値) に達すると、デバイスは着信 ECN 対応パケットを「輻輳発生」(CE) としてマークします。
- 受信者通知: マークされたパケットは ECN 対応の受信者に到達します。
- 送信者フィードバック: 次に、受信側は、この輻輳通知を送信側にエコーバックします (たとえば、TCP ヘッダーに ECN-Echo (ECE) ビットを設定するか、RoCEv2 で輻輳通知パケット (CNP) を送信します)。
- 料金引き下げ: 輻輳のフィードバックを受信すると、送信者は事前に送信速度を下げ、バッファオーバーフローやパケットドロップが発生する前に輻輳を緩和します。
大規模 GPU 展開における PFC と ECN の相乗効果:
数百または数千の高価な GPU で構成される大規模な AI クラスターでは、PFC と ECN が連携して堅牢で効率的なロスレス ネットワークを提供し、GPU 自体の提供価値を高めます。
- 第一防衛線としてのECN: ECNは、輻輳の早期警告を提供するプロアクティブなメカニズムとして機能します。送信側が事前にレートを下げることで、PFCしきい値に達する可能性を最小限に抑え、トラフィックを一時停止するというより極端な措置を回避します。この「ソフト」なレート調整は、継続的なデータフローを維持するために不可欠です。
- 最後の手段としてのPFC: ECN のプロアクティブな対策では輻輳を十分に防げない場合、または突然大量のトラフィックが急増した場合、PFC がリアクティブでハードストップなメカニズムとして介入し、最も重要な AI トラフィックのパケット損失を一切防止します。
- RoCEv2 パフォーマンスの最適化: GPU相互接続に広く採用されているRoCEv2は、これらのメカニズムに大きく依存しています。ECN信号は、NIC内で輻輳制御アルゴリズム(データセンター量子化輻輳通知(DCQCN)など)をトリガーし、送信速度を動的に調整します。PFCは、極度の負荷下でもRoCEv2パケットがドロップされないことを保証し、RDMA操作の整合性を維持します。
- レイテンシとスループットのバランス: ECN のプロアクティブなレート制限と PFC のロスレス保証を組み合わせることで、ネットワーク アーキテクトは、遅延の影響を受けやすい「マウス フロー」(小規模なインタラクティブ メッセージ)の低レイテンシと、大規模な「エレファント フロー」(トレーニング中のバルク データ転送)の高スループットのバランスをとるようにネットワークを微調整できます。
実際の企業の例: 多様な QoS と SLA 要件を持つマルチテナント AI ワークロード
大規模企業では、AIクラスターが単一のタスク専用になることはほとんどありません。同じGPUクラスターが複数の異なるAIワークロードをサポートするマルチテナント環境を考えてみましょう。
- 研究開発(R&D)チーム: 新製品機能のための実験的なLLM微調整ジョブを実行しています。これらのジョブは多くの場合、大規模で長時間実行され、初期レイテンシが多少高くても許容されますが、特定の時間枠(例えば、夜間に実行し、翌朝までに完了するというSLA)内に完了するためには帯域幅の保証が必要です。これらのジョブでは、たとえ他の低優先度トラフィックの速度が一時的に低下するとしても、トレーニングの遅延を回避するための一貫したスループットが最優先事項となります。
- 製造品質管理(QC)部門: 組立ラインでのリアルタイムの欠陥検出が求められており、生産ラインの停止を防ぐために、非常に低いレイテンシ(<10ms)とほぼゼロのパケット損失(例:99.999%の成功推論のSLA)が求められています。
- 財務リスク分析チーム: 不正検出や市場予測のためのバッチ推論ジョブの実行。これらは重要ですが、インタラクティブ性は低く、特定のコンプライアンス期間(例えば、1日の終わりまで)内に大規模なデータセットを処理するには高いスループットが必要です。
DCBはPFCとECNと連携し、ネットワーク管理者が多様なトラフィックタイプを分類し、優先順位付けすることを可能にします。レイテンシの影響を受けやすい推論クエリのRoCEv2トラフィックには、積極的なECNしきい値を備えた最高優先度のCoSを割り当て、プロアクティブなレート削減を実現します。一方、トレーニングトラフィックにはロスレス配信を実現する高優先度CoSが割り当てられ、その他のバックグラウンドトラフィックには標準クラスが使用されます。この高度なトラフィック管理により、高優先度の推論クエリが大規模なトレーニングジョブによって処理能力が不足することがなくなり、共有GPUインフラストラクチャにおいて各テナントのSLA要件が確実に満たされます。
結論
AIモデルの複雑さと規模が拡大するにつれ、基盤となるスケールアウト型ネットワークインフラストラクチャは、システム全体のパフォーマンスにおいてますます重要な要素となっています。優先度ベースフロー制御(PFC)と明示的輻輳通知(ECN)という基盤機能を備えたデータセンターブリッジングは、単なる最適化やあれば便利な機能ではありません。GPUへの多額の投資を伴う、効率的で信頼性が高く、スケーラブルなAIコンピューティングソリューションを構築するための極めて重要かつ基本的な要素です。ロスレス通信を保証し、輻輳をプロアクティブに管理し、トラフィックをきめ細かく制御できるネットワーク接続ソリューションを選択することで、これらのDCBテクノロジーに基づくスケーラブルなソリューションは、企業とそのAI戦略を強化し、業界標準テクノロジーを使用して可能性の限界を押し広げ、人工知能時代のイノベーションを加速させます。
当社の製品やサービスに関してご意見、お問い合わせ、ご質問がございましたら、以下のフォームにご記入ください。
最近のブログ
2025 年 7 月 30 日
2025 年 7 月 11 日
2025年4月28日