テクノロジー · シミュレーション、部分的に肯定的

AIイーサネットの輻輳制御：シミュレーションで改善した修正と、なお性能が低下する条件

大規模AIモデルの学習では、数千のチップ間で同時に巨大なデータバーストが飛び交う。ネットワークが詰まると、最も遅い転送がジョブ全体の速度を決める。ネットワークベンダーはこのための新しい輻輳制御を設計している。我々は公開されているUltra Ethernet設計のシミュレータ(uet-htsim)で、既発表のMNSCCという手法を出発点に取り組んだ。Ciscoを含むどのベンダーとも関係はない。

Conceptual illustration generated with AI. Not experimental data or a depiction of the actual equipment.

1行の変更で、5つのシミュレーショントラフィック設定で典型的な完了時間が3〜37%短縮され、incastではわずかに悪化した。シミュレーション上の結果であり、新規性は未検証である。

試したこと

測定の前に、仮説と合格基準を書き留めた。最初のアイデア - コントローラが遅延信号をどれだけ平滑化するかを適応させる - は2つの設計で失敗した。多くの送信者が1つの受信者に集中するincastパターンではどちらも機能しなかった。これは否定的結果として記録した。

3ラウンド目では、1つの設計がある単一シードで大きく負ける理由を調べた。あるケースでは、最も遅いフローの遅延が目標未満なのに、パケットの72%が輻輳ありとマークされていた。マーク閾値(キュー40 KB)は目標キュー(約100 KB)より低いため、マークはキューが40 KBを超えたことしか示さない。コントローラは往復ごとにウィンドウを約36%削減した。これはトレースからこのケースを説明するものであり、すべてのケースの証明ではない。

新しいシードでのテスト前に凍結した修正:遅延の中央値も目標以上の場合にのみウィンドウを削減する。それ以外は変更なし。

新しいシードでの結果

出典:REPORT3.md、設計に使わなかったシードでの検証。ラベルはシミュレータ固有のシナリオ名(ele = 16/8パスの交差トラフィック設定、failed8 = リンク障害あり)で、完全な定義は元のレポートにある。合計20のペアシード:設定ごとに5、5、3、3、2。これらの交差トラフィック設定では負けたシードは1つもない。これはこの20シードに限った話である。

Incast(3シード): 平均完了時間は、ローカル配置で適応ベースラインの2455に対し2530(+3.1%)、スプレッド配置で2450に対し2507(+2.3%)。最大完了時間はほぼ同等(+0.3%、+0.4%)。単純なNSCC手法はincast平均で依然最良(2382と2444)。凍結した合格基準は±2%だったため、これは不合格。
incastでの最悪の単一シード: +11.8%、修正前は+18%。

限界

シミュレーションのみ:128または1024ノードの理想化されたファットツリーで、設定あたり2〜5シード。
MNSCCは公開済みの手法であり、我々のものではない。我々の変種が新しいかどうかは未検証。見つけた最も近い公開アイデアはAPSCCとSTrack。
incastでの残りの損失は、削減幅の大きさに由来する可能性がある。これはトレースからの仮説である。
ブレイクスルーではない。ハードウェアもベンダーの関与もない。