HN4612
AIクラスターの常識を覆す：TCPの時代は終わったのか？「Homa」の衝撃
Homa: The end of TCP for AI clusters [video]
signa11・1日前
議論
9件AIクラスターにおけるネットワーク通信の新たな選択肢として注目を集めるプロトコル「Homa」についての論文と関連資料です。現代のデータセンターやAIインフラにおいて、なぜ従来のTCPがボトルネックとなるのか、次世代のプロトコルがどのような解決策を提示しているのかを深く掘り下げています。詳細な論文はこちらからご覧ください: https://www.usenix.org/system/files/atc21-ousterhout.pdf 。また、本トピックに関する議論や解説記事についても併せて確認してみてください。関連リンク: https://lwn.net/Articles/1003059/ および https://www.theregister.com/networks/2026/10/01/stanford-prof-is-beating-the-drum-for-a-new-protocol-to-replace-tcp/5300629
数ヶ月前にJane StreetのRon Minskyがポッドキャストで、AIクラスターにおいてTCPがボトルネックになっているという話をしていたのを思い出した。電気エンジニアの視点から言うと、サーキットスイッチング（回線交換）がパケットスイッチングに取って代わられたのは、ネットワークを使う主体が多いと利用状況が非常にまばらになるからだった。効率は良くないが、トラフィックの種類が多様すぎるとフローパターンが動的すぎて最適化が難しいんだよね。車の交通に例えると、ダウンタウンは多種多様な場所へ向かう車で溢れているから、非効率であっても信号機を置くのが少なくとも「それなりに機能する」解決策になるわけ。
一方で、トラフィックが非常に予測可能なパターンに従うなら、専用の実装の方がずっと効率的になれる。特に最近は、機械学習が強化学習を通じてはるかに優れた解決策を見つけ出せるし、AIクラスターのデータフローはインターネット全体のトラフィックより遥かに予測しやすいからね。
メインのリンクに動画を使うのはやめてくれないか。
記事にあるような「勾配の重み、モデルの重み、KVキャッシュのエントリ、チェックポイントといった作業」のためにLLMがHomaや他の最適化プロトコルを使うようになると、その多くの理由から、学習後のインタラクションにおいてもTCPがボトルネックになり始めるんじゃないかと思ってる。
Homaについては何年も前から聞いているけど、何が新しいのか気になっていた。gitリポジトリのREADMEにチェンジログを見つけたよ: https://github.com/PlatformLab/HomaModule (https://github.com/PlatformLab/HomaModule)
Homaはもうしばらく前からあるね。これが2018年の論文だ。[1]
核心となるアイデアはこうだ：送信側のトランスポートモジュールにメッセージが届くと、Homaはそれを2つに分ける。最初は未スケジュールの部分（最初のRTTbytes分）で、その後にスケジュールの部分が続く。送信側は未スケジュール分をDATAパケットで即座に送信する。スケジュール分は、受信側からGRANTパケットで明示的に要求されるまで送信されない。
つまり、短いリクエストなら盲目的に送るけど、その後は受信側からの許可が必要ってわけ。主な用途がリモートプロシージャコール（RPC）なら理にかなってる。QNXのネットワークプロトコルを思い出すよ。あれも単一パケットのメッセージ要求/応答だけど、任意に長いメッセージも扱えたしね。
今の時代にこれが機能するのは、ハードウェアスイッチにおけるパケット単位の処理オーバーヘッドが、バイト単位のオーバーヘッドに比べて小さいからだ。初期のソフトウェア駆動スイッチではパケット単位のオーバーヘッドが支配的で、小さなパケットを送るのは非常に非効率だった。FPGAが処理を行う現代のハードウェアスイッチなら、パケット単位のオーバーヘッドは十分小さいから、小さなパケットでも効率は悪くない。
面白いのは、今のウェブ界隈は肥大化しすぎていて、1MB以下のトランザクションが「小さい」と見なされることだよ。だから、これはオープンなウェブ用途には向かないプロトコルだね。
[1] https://people.csail.mit.edu/alizadeh/papers/homa-sigcomm18.... (https://people.csail.mit.edu/alizadeh/papers/homa-sigcomm18.pdf)
(~6:01) の「輻輳制御は送信側の責任である」「何らかの方法で送信ノードが速く送りすぎるのを止めさせなければならない」という点について。それってEthernetやRoCEには存在しないのか？
リンクレベルフロー制御: InfiniBandはクレジットベースのアルゴリズムを使用して、HCA間のロスレスな通信を保証する。RoCEはEthernet上で動作する。実装によっては、InfiniBandに近い性能特性を得るためにロスレスEthernetネットワークが必要になる場合がある。ロスレスEthernetは通常、Ethernetフロー制御や優先度フロー制御（PFC）で構成される。データセンターブリッジング（DCB）Ethernetネットワークの構成は、InfiniBandネットワークの構成より複雑になる可能性がある。[19]
- https://en.wikipedia.org/wiki/RDMA_over_Converged_Ethernet (https://en.wikipedia.org/wiki/RDMA_over_Converged_Ethernet)
送信局（コンピュータやネットワークスイッチ）は、リンクの受信側が受け取れる速度よりも速くデータを送信してしまう場合がある。フロー制御を使うことで、受信局は送信側に対して受信が追いつくまで送信を中断するようにシグナルを送ることができる。Ethernetのフロー制御はデータリンク層で実装可能だ。
Homaは良い設計じゃないね。[1]
-
RPC全体の欠落を検知する方法がない。外部のコネクション状態を持たないため、RPCの送信側でパケットがすべて失われると、サーバー側は再送を要求すべきかどうか検知する術がない。RPCはそのままエーテルの中に消える。これはパケット数が少ない小さなメッセージ（1パケットに収まるようなもの）で特に影響が出る。
-
上記に関連して、組み込みの暗号化サポートがない。だから暗号化が必要なら、その上か下にレイヤーを追加しないといけない。
-
ベンチマーク性能がひどい。[2]の表4にある60kBの平均メッセージのケースで、20Gbit/sを出すのにハイパースレッドを5つも消費してる。1スレッドあたりたったの4Gbit/sだ。極めて単純なシステムコールごとに1パケットを送るネットワークプロトコルでも、1スレッドあたり8Gbit/s近くは出るはず。パフォーマンスに少し集中すれば、1スレッドあたり30Gbit/sは簡単に出せる。
-
QUICは（Homaよりは速いけど）設計上の問題が山ほどあるにもかかわらず、Homaが解決しようとしているあらゆる問題を、より洗練された方法ですでに解決している。ストリームIDはRPC IDに対応し、ストリームMaxはGrantに対応している。単一のクライアント下での複数ストリームは優先順位付けも可能だ。
メッセージ全体がランダムに失われるようなことはないし、小さなメッセージをパケットに詰め込むこともできる。より正確なRTTが取れるから、より精密なペーシングや輻輳計算が可能だし、組み込みの暗号化もある。ミドルボックスの問題もクリアできるし、複数のackフレームやパケットでackオーバーヘッドも減らせる。
唯一の大きな違いは、Homaが暗黙的な送信側再送の代わりに明示的な受信側再送を使っていること。だけど実際には、特に再送パケットが単一の再送スパンしかサポートしていないせいで、損失が起きるような非自明なシナリオでは受信側のリソースを大幅に消費する。それにレイテンシも高くなるし、失いたくない余分なデータが通信経路を通過するため、損失の多いネットワーク全体に対する要求も高くなる。
RFCを読み直してパッと思いつく深刻な問題はこれくらい。必要ならもっと挙げられるよ。
[1] https://github.com/johnousterhout/homa-rfc/blob/main/draft-o... (https://github.com/johnousterhout/homa-rfc/blob/main/draft-ousterhout-tsvwg-homa-00.md)
[2] https://www.usenix.org/system/files/atc21-ousterhout.pdf (https://www.usenix.org/system/files/atc21-ousterhout.pdf)