# インネットワーク集約 ## 定義 インネットワーク集約(In-Network Aggregation、In-Network Computing とも)とは、AllReduce・Barrier のような集団操作(collective operation)の縮約(reduce)処理を、ホスト CPU ではなくネットワークスイッチやネットワークアダプタといった経路上のデバイスに担わせることで、データがネットワークを通過する過程そのもので計算を完了させる設計思想である。[[@2016__COM-HPC__Scalable Hierarchical Aggregation Protocol (SHArP) - A Hardware Architecture for Efficient Data Reduction]](COM-HPC '16)が提案する Scalable Hierarchical Aggregation Protocol(SHArP)は、この思想を [[Mellanox]] の SwitchIB-2 ASIC 上に集約ノード(Aggregation Node, AN)として実装し、InfiniBand ネットワーク上で商用製品として実証した代表例である。 ## 横断的知見 (このconceptは本ソースが初出のため、横断的知見は2ソース目以降の突き合わせで積み増す。以下は本ソース単体からの体系整理であり、将来的な複数ソース照合の起点として記録する。) - **論理木と物理トポロジの分離が、集約ハードウェアの再利用性を生む**: SHArP は集約木(aggregation tree)を物理ネットワークトポロジから独立した論理構造として定義する。物理的には fat-tree・DragonFly+・hypercube のいずれの上にも同じ論理木を重畳でき、集約ノード(AN)はスイッチにもホストにも実装できる。この抽象化により、ハードウェア実装(SwitchIB-2 の TCA)は特定のトポロジに縛られず、トポロジ最適化の問題(木のトポロジへの割り当て)をプロトコル本体から明示的に切り離している(out of scope として論文が宣言)。(Source: [[@2016__COM-HPC__Scalable Hierarchical Aggregation Protocol (SHArP) - A Hardware Architecture for Efficient Data Reduction]]) - **end-point 管理から switching infrastructure 管理への権限移譲が、CPU オフロードの新しい形になる**: SHArP 以前の Mellanox CORE-Direct や Portals 4.0 triggered operations は、end-point(HCA)側が集約操作の進行管理を担う設計だった。SHArP はこれを転換し、end-point を操作の開始・完了のみに関与させ、進行管理そのものをスイッチングインフラ(AN)に委ねる。CPU オフロードの単位が「1回の通信操作」から「集団操作全体の管理責任」へ広がっている。(Source: [[@2016__COM-HPC__Scalable Hierarchical Aggregation Protocol (SHArP) - A Hardware Architecture for Efficient Data Reduction]]) - **高 radix スイッチが浅い縮約木を可能にし、レイテンシとスケーラビリティを同時に満たす**: SHArP は 36 ポートの SwitchIB-2 の高 radix を活かし、木の各レベルでデータ量を最大 18 倍削減する浅い(shallow)縮約木を構成する。IBM Blue Gene 系(トーラス、深い木)や Cray Aries(radix 最大 32)との比較で、SHArP は木のノード radix の広さによって、オペランド数への依存が弱い小データ縮約レイテンシを実現している。「radix を広げて木を浅くする」という設計選択が、ネットワークレベル並列性の活用とスケーラビリティ確保の両方の鍵になっている。(Source: [[@2016__COM-HPC__Scalable Hierarchical Aggregation Protocol (SHArP) - A Hardware Architecture for Efficient Data Reduction]]) - **決定的な演算順序の保証が、ハードウェア縮約の正しさの前提条件になる**: 浮動小数点の加算・乗算は可換だが結合則を満たさないため、集約要求の到着順序(非決定的)のままで縮約すると再現不能な結果を生みうる。SwitchIB-2 は全オペランドが TCA に揃うまで待ってから固定順序で縮約することで、この問題を回避する。ハードウェアオフロードによる集約が実用に足るためには、単なる演算のオフロードだけでなく、順序保証という正しさの設計が不可欠であることを示す。(Source: [[@2016__COM-HPC__Scalable Hierarchical Aggregation Protocol (SHArP) - A Hardware Architecture for Efficient Data Reduction]]) - **ハードウェア最大ペイロードの制約を、既存の多重化能力(多数の未完了操作を並行実行する能力)で乗り越える**: SwitchIB-2 の SHArP はペイロード最大 256 byte までしかハードウェア縮約できないが、これを超えるサイズはソフトウェアレベルでメッセージを断片化し、複数の SHArP 縮約操作を同時にパイプライン投入することで対応する。ハードウェア制約そのものを取り除くのではなく、ハードウェアが既に持つ別の能力(多重ジョブ・多重集約操作のサポート)を転用して制約を回避する設計は、ハードウェアオフロード全般に見られる典型的なパターンである。4096 byte まで 3.24 倍のレイテンシ改善を達成した。(Source: [[@2016__COM-HPC__Scalable Hierarchical Aggregation Protocol (SHArP) - A Hardware Architecture for Efficient Data Reduction]]) ## 未解決の問い - SHArP のようなハードウェア集約オフロードは 2016 年時点で InfiniBand SwitchIB-2 に実装されたが、2020 年代の NVIDIA NVLink/NVSwitch 世代の GPU 間集合通信(NVSHARP・Multimem)にどのように系譜として引き継がれ、どこが再設計されたか。ネットワーク越しの縮約(SHArP)とノード内 NVLink 越しの縮約(NVSHARP)で、決定的演算順序の保証やペイロード上限といった設計上の制約はどう変化したか。([[@2016__COM-HPC__Scalable Hierarchical Aggregation Protocol (SHArP) - A Hardware Architecture for Efficient Data Reduction]]、[[集合通信]] concept が集める NVSHARP/Multimem 言及と突き合わせる余地がある) - SHArP の木トポロジ割り当て最適化・分散グループ生成アルゴリズムの詳細は論文の対象外とされている。これらは後続研究・製品でどのように解決されたか。 - SHArP は最大 64 木/集約ノードをサポートするが、数万 GPU 規模の現代 AI 訓練クラスタでマルチテナント環境における木の割り当て・リソース競合はどう管理されているか。 - デッドロック回避のための end-to-end リソース可用性の保証(論文が「実装される必要がある」とのみ述べ詳細を示さない部分)は、実際の SHArPd・Aggregation Manager 実装でどう解決されているか。 ## 関連 - ソース: [[@2016__COM-HPC__Scalable Hierarchical Aggregation Protocol (SHArP) - A Hardware Architecture for Efficient Data Reduction]] - 概念: [[集合通信]] / [[InfiniBand]] / [[RDMA]] - エンティティ: [[Mellanox]] / [[Richard L. Graham]] / [[Gilad Shainer]] / [[Eitan Zahavi]] / [[Alexander Shpiner]] ## 出典 - [[@2016__COM-HPC__Scalable Hierarchical Aggregation Protocol (SHArP) - A Hardware Architecture for Efficient Data Reduction]](SHArP プロトコル定義・SwitchIB-2 TCA 実装・128 ホストで 8 byte MPI Allreduce() 2.1 倍・4096 byte パイプライン化 3.24 倍・OpenFOAM 実測)