はじめに
この記事は、シスコシステムズ合同会社の有志による Cisco Systems Japan Advent Calendar 2025 の 21 日目として投稿しています。
2019年から参加しており今年で7年目になります。去年に引き続き読み物の投稿をしてみようと思います。
いろいろなご意見があると思いますが、年末の軽い読み物としてお楽しみいただけましたら幸いです。
@ktsutsum です。
本記事は、私が2022年から続けている「計算と通信と」シリーズの第4弾となります。
過去の投稿はこちら
Tellusによる初めての衛星データ解析
はじめての Intel Open VINO
flightrader24フィードで最上位プランをゲット
計算と通信と#1
計算と通信と#2
計算と通信と#3
これまでは、クラウドネイティブ時代のネットワーク、セキュリティとの融合、そしてAI活用について触れてきました。
シリーズ4年目となる2025年、改めて原点に立ち返り、一つの根本的な問いを投げかけたいと思います。
1. 問い：「どこまでが通信で、どこまでが計算か？」
皆さんは、この問いに即答できるでしょうか？
かつて、その答えは明確でした。
「LANケーブルとルーターまでが通信（土管）、サーバーのCPUから先が計算（処理）」。
インフラエンジニアとアプリエンジニアの職域も、この物理的な境界線によって綺麗に分かれていました。
しかし、今、その境界線は急速に消失しつつあります。
2. 歴史： The Era of Separation
なぜ今まで、私たちは「計算」と「通信」を別物として扱ってきたのでしょうか？
それは、複雑性を管理するため でした。
OSI参照モデル vs ノイマン型アーキテクチャ
通信の世界では「OSI参照モデル」が、計算の世界では「ノイマン型アーキテクチャ」が、それぞれの秩序を保ってきました。
ネットワークエンジニアは「パケットの中身（計算）」に関知せず、サーバーエンジニアは「パケットの運び方（通信）」に関知しない。
この 「関心の分離（Separation of Concerns）」 こそが、ITインフラをここまでスケーラブルに発展させた原動力でした。
しかし、AIの登場がその前提を破壊しました。
計算があまりにも膨大かつ高速になりすぎたため、「通信のオーバーヘッド」を無視できなくなったのです。
もはや、お互いに無関心ではいられない時代が到来しました。
3. 融合： The Convergence
エネルギーの壁とIOWN
境界が消えるもう一つの理由は 「エネルギー」 です。
AIモデルのパラメータ数は指数関数的に増大しており、それに伴い消費電力も爆発しています。
従来の電気信号による通信では、距離が伸びるほど抵抗により信号が減衰し、熱としてエネルギーが失われます。
「電気で計算して、電気で通信する」ことの限界。
これを超えるのが、NTT、Intel、Ciscoなどが推進する IOWN（光電融合） です。
チップの直近、あるいはチップ内部まで「光」を引き込むことで、圧倒的な低消費電力と低遅延を実現します。
物理レイヤーにおいても、計算（シリコン）と通信（フォトニクス）は融合しつつあるのです。
「通信待ち」という無駄：AllReduceの現実
AIの分散学習では、AllReduce という集団通信パターンが頻繁に発生します。
各GPUがそれぞれ計算した「勾配（Gradient）」を全GPUで共有・合算し、その平均値で全員がパラメータを更新する——これが分散学習の基本サイクルです。
問題は、この「全員で足し算」のコストです。
例えば1024台のGPUで学習する場合、各GPUは自分の勾配を他の1023台に送り、同時に1023台からの勾配を受け取らなければなりません。
ナイーブに実装すれば、通信量は O(N²) に爆発します。
Ring AllReduceなどのアルゴリズムで O(N) に抑えられますが、それでもGPUは「足し算」という単純作業のために計算サイクルを費やし、ネットワークは膨大なトラフィックで飽和します。
なぜAllReduceはこれほど重いのか？
これは単なる「通信量」の問題ではありません。本質は 「同期待ち」 にあります。
分散学習では、全GPUが同じステップで足並みを揃える必要があります。つまり、最も遅いGPUがボトルネックとなり、全体の速度を決定します。
たった1つのパケットロスや遅延が、システム全体を停止（Stall）させるのです。
上図のように、GPU 2の計算が遅れると、GPU 1と3は何もできずに待機（Idle）することになります。これが積み重なると、巨大なリソースの無駄になります。
さらに、GPU自身も「足し算」という単純な演算に時間を取られます。
最新のH100/H200 GPUは、行列演算では1000 TFLOPS以上の性能を発揮しますが、AllReduceのような 「通信bound」 な処理では、その能力を十分に発揮できません。
GPU間の通信帯域（NVLink: 900GB/s）と比較しても、ネットワーク帯域（InfiniBand: 400Gbps = 50GB/s）は約18倍も遅いのです。
この問題を解決する糸口が、次に紹介する In-Network Aggregation です。
In-Network Aggregation: スイッチが計算する必然
ここで登場するのが、In-Network Aggregation です。
これまでサーバー（GPU）が行っていた「勾配の加算（足し算）」を、通り道のスイッチが肩代わりします。
スイッチはパケットを転送しながら、通過する数値データを足し合わせ、合計値だけを次のノードに送ります。
これにより、通信量は劇的に削減され、GPUは「足し算」という単純作業から解放されます。
これは単なるオフロードではありません。「計算」と「通信」の境界線を物理的に消滅させるアプローチなのです。
推論 (Inference)： レイテンシとの戦い
学習だけでなく、推論（Inference） においても境界線は消えつつあります。
巨大なLLMは1枚のGPUには収まりきらないため、複数のGPUに分割して載せます（Tensor Parallelism）。
この時、1つの単語（トークン）を生成するたびに、GPU間で同期通信が発生します。
つまり、「通信速度」がそのまま「生成速度（ChatGPTのレスポンス速度）」に直結する のです。
また、RAG (検索拡張生成) のアーキテクチャでは、外部データベースへの「検索（通信）」と、LLMによる「生成（計算）」がセットになって初めて一つの回答が生まれます。
ここでも、通信と計算は不可分なプロセスとして統合されています。
4. Simulation: 勾配集約（Gradient Aggregation）の可視化
この「スイッチが足し算をする」ことのインパクトを、シミュレーションで見てみましょう。
これは、分散学習における Gradient Aggregation（勾配集約） の簡易モデルです。
概念図：何が変わるのか？
シナリオ
- Leaf (GPU): 学習データを処理し、勾配（Gradient）を生成。
-
Switch:
- パターンA（従来）: パケットをそのままRoot（Parameter Server）へ転送。
- パターンB（In-Network）: 複数のLeafからの勾配を「足し合わせて」から転送。
実行結果（インタラクティブ・デモ）
このシミュレーションの効果を直感的に理解していただくために、ブラウザ上で動くデモを用意しました。
ノード数や深さを変更して、どれくらいトラフィックが削減されるか試してみてください。
See the Pen Untitled by necoha (@necoha) on CodePen.
考察と実践的洞察
シミュレーション結果を見ると、In-Network Aggregation（パターンB）では、トラフィックが 50〜80%削減 されています。
これは単なる理論値ではありません。実際のAI Fabricにおいても、この技術により以下のような効果が報告されています：
- 学習時間の短縮: 27〜47%（NVIDIA、Meta AI の実測データより）
- GPU利用率の向上: 60% → 85%以上
- スイッチ輻輳の緩和: ピーク時のバッファオーバーフローがほぼゼロに
なぜこれほど効果があるのか？
-
トラフィックの非対称性の解消
従来のAllReduceでは、リーフスイッチから上位（Spine）へのトラフィックが集中し、アップリンクが飽和します。
In-Network Aggregationでは、各段階で集約が行われるため、上位に行くほどトラフィックが減り、帯域を効率的に使えます。 -
GPUオフロード
足し算処理をスイッチに任せることで、GPUは純粋な計算（行列演算）に専念できます。
特にfp16やbf16といった低精度演算では、足し算のオーバーヘッドは無視できません。 -
レイテンシの短縮
パケット数が減ることで、スイッチのバッファでの待ち時間が劇的に減少します。
これは「Tail Latency」（最悪ケースの遅延）の改善に直結し、システム全体の同期待ち時間を短縮します。
実装上の落とし穴
しかし、In-Network Aggregationは「銀の弾丸」ではありません。以下の課題があります：
- 専用ハードウェアが必要: 通常のスイッチASICでは実装できず、プログラマブルスイッチ（P4対応ASIC、SmartNICなど）が必要
- 数値精度: スイッチでの浮動小数点演算は精度が限られる（多くは整数演算のみ）。量子化誤差が学習に影響する可能性
- 故障時の複雑性: スイッチが計算を担うため、ネットワーク障害が即座に学習ジョブの失敗につながる
設計指針：いつIn-Network Aggregationを使うべきか？
- モデルサイズ: 100B+パラメータ、勾配サイズが10GB超の場合
- ノード数: 256台以上のGPUクラスタ
- ネットワーク帯域: 400Gbps以上のファブリック
- トポロジー: Fat-Tree、Dragonfly+など、多段スイッチ構成
これらの条件を満たす場合、投資対効果は十分に高いと言えます。
5. The Reality: 見えない「ストール」との戦い
AI Fabricを実際に運用して初めて見えてくる問題があります。それは 「ストール（Stall）」 です。
分散学習において、全てのGPUは同期して動きます。誰か一つでも遅れれば、全員が待たされます。
これは「最も遅いGPU」がシステム全体のペースを決める、という残酷な現実です。
ストールの主な原因（Major Causes）：
- Incast（インキャスト）: 複数のノードから同時に1つのノードへパケットが殺到し、スイッチバッファが溢れる
- Head-of-Line Blocking: 1つの遅いフローが、同じキューを使う他のフローをブロック
- PFC Pause Storm: RDMA over Converged Ethernet (RoCE) で、輻輳時のPFC（Priority Flow Control）が連鎖的に伝播し、ファブリック全体が停止
これらは、従来の「ベストエフォート」なネットワーク設計では防ぎきれません。
なぜなら、AIワークロードは 「確率的に99.9%届けばいい」ではなく「100%確実に、決まった時間内に届く」 ことを要求するからです。
6. The Insight: 確率的（Probabilistic）から決定的（Deterministic）へ
AI Fabricの本質的な課題は、「不確実性の排除」 にあります。
従来のイーサネットは「ベストエフォート」であり、パケットがいつ届くか、あるいは届くかどうかさえも「確率的（Probabilistic）」でした。
しかし、AIの分散学習において、これは許されません。
数千台のGPUが同期して動くため、たった一つのパケットロス、たった一つの遅延が、システム全体の停止（Stall）を招くからです。
AI Fabricに求められるのは、「決定的（Deterministic）」 なパフォーマンスです。
ロスはゼロでなければならず、レイテンシは予測可能でなければなりません。
私たちは今、確率的なネットワーク技術を使って、決定的なシステムを構築するという矛盾に挑んでいるのです。
7. The Solution: 「制御（Control）」による決定性の担保
この「決定性」を担保するための技術こそが、「制御（Control）」 です。
輻輳制御：DCQCNからSwift/HPCC へ
AI Fabricにおける輻輳制御は、従来のTCP/IPとは異なるアプローチを取ります。
- DCQCN (Data Center Quantized Congestion Notification): ECN（Explicit Congestion Notification）とPFCを組み合わせ、送信レートを動的に調整。RoCEv2の標準プロトコル。
- Swift: Googleが開発した次世代プロトコル。遅延とスループットの両方を最適化し、Incast耐性を大幅に向上。
- HPCC (High Precision Congestion Control): Alibabaが提案。INT（In-band Network Telemetry）を活用し、パケットごとにリアルタイムでキュー長を取得、μs単位でレート調整。
これらの技術により、パケットロスを 10^-12 レベル（実質ゼロ）まで抑え込むことが可能になっています。
Scheduled Fabric：予測可能なレイテンシ
Cisco Silicon Oneが提供する Scheduled Fabric は、さらに一歩進んだアプローチです。
従来のスイッチは「到着したパケットを順次処理」しますが、これでは衝突や待ち時間が不可避です。
Scheduled Fabricでは、Ingress（入口）とEgress（出口）が事前に調整を行い、「通れることが確定してから送る」 という制御を行います。
具体的な仕組みは以下の通りです：
- Ingress時点でスケジューリング: パケットを受信した瞬間、スイッチファブリック全体の状態を考慮し、衝突しないタイムスロットを割り当て
- VOQ (Virtual Output Queue): 出力ポートごとに仮想キューを持ち、Head-of-Line Blockingを回避
- Credit-based Flow Control: PFCに頼らず、送信側と受信側でクレジット（送信許可）をやり取りし、バッファオーバーフローを防ぐ
この仕組みにより、レイテンシは ±10ns 以内 の精度で予測可能になります。
これは、確率的なネットワークを決定論的なシステムに変える、本質的なブレークスルーです。
Ciscoの戦略 「Connect, Secure, Observe」 は、この文脈では極めて実利的な意味を持ちます。
それは、AIワークロードが必要とする「予測可能なパフォーマンス」を、インフラ側で保証するための機能群なのです。
8. The Evolution: ネットワークエンジニアから「AIインフラエンジニア」へ
私たちの役割は、単にパケットを運ぶことではありません。
AIシステムのパフォーマンスを最大化することです。
JCT (Job Completion Time) へのコミット
これからのエンジニアに求められるのは、「AIインフラエンジニア」 としての視座です。
ネットワークの帯域や遅延は、あくまで中間指標に過ぎません。
最終的なゴールは、「ジョブ完了時間（JCT）」の短縮 です。
必要なスキルセット（2025年版）
-
フルスタックの理解
- GPU: CUDA、Tensor Core、NVLink、GPU Directの仕組み
- 通信ライブラリ: NCCL、MPI、Gloo の内部動作とチューニングパラメータ
- ネットワーク: RoCEv2、InfiniBand、ECN、PFC、DCQCN
- ストレージ: 分散ファイルシステム（Lustre、GPFS）、チェックポイント戦略
-
パフォーマンス・エンジニアリング
- プロファイリングツール: NVIDIA Nsight、PyTorch Profiler、Netdata
- ボトルネック特定: 計算バウンド vs メモリバウンド vs 通信バウンド の切り分け
- 最適化手法: Gradient Accumulation、Mixed Precision、ZeRO Optimizer
-
障害対応力
- 障害検知: GPU故障、ネットワーク輻輳、ストール の早期発見
- 自動復旧: チェックポイント＆リスタート、Elastic Training
JCT短縮のためのチューニング例
実際の現場では、以下のようなパラメータ調整が劇的な効果を生むことがあります。これらは「ネットワークの設定」ですが、その効果はGPUの追加投資に匹敵します。
- ネットワークトポロジーの最適化: Rail-Optimized Placementで、GPU配置をネットワークトポロジーに合わせて調整（通信時間 -20%〜）
※ 同じランク（番号）のGPU同士を同じスイッチ（Rail）に収容することで、AllReduce時の通信効率を最大化します。
-
NCCL_ALGOの選択: ノード数やメッセージサイズに応じて
RINGかTREEかを明示的に指定（AllReduce時間 -10%〜） - ECNしきい値のチューニング: デフォルト値よりもアグレッシブに設定し、輻輳を早期検知してパケットロスを未然に防ぐ（Tail Latencyの大幅改善）
「ネットワークがつながっている」ことはゴールではありません。
「計算が最速で終わる」ことこそが、私たちが提供すべき価値なのです。
9. The Future: 2030年、境界の「再定義」
最後に、5年後の未来を予測してみます。
かつて「計算」と「通信」を隔てていた物理的な壁は消え去りますが、それは無秩序になることを意味しません。
「AIインフラ（AI Infrastructure）」 という、計算と通信が不可分に融合した新たな社会基盤として、その境界線が 「再定義」 されるのです。
予測1: Optical AI Fabric の実用化
IOWNが本格展開し、チップ間・ラック間通信が全て光に置き換わります。
電気-光変換のオーバーヘッドが消え、レイテンシは 10ns 以下 に。
エネルギー効率は現在の 1/10 になり、AI学習コストは劇的に低下します。
予測2: In-Network Computingの標準化
専用ASICではなく、汎用スイッチチップに「計算機能」が標準搭載されます。
OpenComputeやSONiCといったオープンスタンダードに組み込まれ、誰でも使える技術に。
AllReduceだけでなく、Attention計算 や Activation関数 まで、ネットワークがオフロードする時代が来るでしょう。
予測3: AI-Driven Network Optimization
ネットワーク自体がAIで最適化されます。
トラフィックパターンを学習し、リアルタイムでルーティングやQoS設定を調整。
人間が手動でチューニングする時代は終わり、「ネットワークがネットワークを制御する」 完全自律型ファブリックが主流に。
予測4: Compute-as-a-Service の進化
クラウドで「計算リソース」を借りるのではなく、「JCT（ジョブ完了時間）」を購入 する時代へ。
「このモデルを24時間以内に学習完了させてください」という SLA（Service Level Agreement）が標準になります。
インフラプロバイダーは、GPU・ネットワーク・ストレージを統合最適化し、JCT保証を実現する責任を負います。
私たちの役割：「システム・アーキテクト」へ
境界が再定義された世界では、専門領域に閉じこもることはできません。
私たちは、GPU、ネットワーク、ストレージ、ソフトウェアの全てを統合的に設計する 「システム・アーキテクト」 へと進化する必要があります。
おわりに
計算と通信の境界が溶け合った今、私たちエンジニアに求められるのは、システム全体を俯瞰する視座です。
「つながればいい」という確率的な世界から、「必ず届ける」という決定的な世界へ。
「計算」と「通信」を繋ぎ、システム全体を「制御」して、パフォーマンスを最大化する。
それが、これからの時代のネットワークエンジニア、すなわち 「AIインフラエンジニア」 の役割なのです。
来年の「計算と通信と #5」では、この「制御」がどのように自律化（Autonomous）していくのか、そして光電融合が実際にどこまで進んだのかについて、実例とともに語れることを楽しみにしています。
参考文献
本記事の執筆にあたり、以下の文献・資料を参考にしました。
- HPCC: Li, Yuliang, et al. "HPCC: high precision congestion control." SIGCOMM 2019.
- Swift: Kumar, Gautam, et al. "Swift: Delay is Simple and Effective for Congestion Control in the Datacenter." SIGCOMM 2020.
- DCQCN: Zhu, Y., et al. "Congestion Control for Large-Scale RDMA Deployments." SIGCOMM 2015.
- SwitchML: Sapio, A., et al. "Scaling Distributed Machine Learning with In-Network Aggregation." NSDI 2021.
- ZeRO: Rajbhandari, S., et al. "ZeRO: Memory Optimizations Toward Training Trillion Parameter Models." SC 2020.
- In-Network Computing: NVIDIA Technical Blog. "Scaling Deep Learning Training with In-Network Computing."
- Cisco Silicon One: Cisco Systems. "Cisco Silicon One Architecture White Paper."
- IOWN: NTT IOWN Global Forum. "IOWN All-Photonics Network (APN)."
本記事は、Cisco Systems Japan Advent Calendar 2025 の一部です。
免責事項
本サイトおよび対応するコメントにおいて表明される意見は、投稿者本人の個人的意見であり、シスコの意見ではありません。本サイトの内容は、情報の提供のみを目的として掲載されており、シスコや他の関係者による推奨や表明を目的としたものではありません。各利用者は、本 Web サイトへの掲載により、投稿、リンクその他の方法でアップロードした全ての情報の内容に対して全責任を負い、本 Web サイトの利用に関するあらゆる責任からシスコを免責することに同意したものとします。