TCPに代わる通信プロトコル「Homa」をスタンフォード大学名誉教授が提唱、AI時代は1ミリ秒の遅延でもGPUが待たされる

ウェブやクラウドを支える通信プロトコル「TCP」はAI向けデータセンターの通信には適していないとして、スタンフォード大学のジョン・オースターハウト名誉教授がトランスポートプロトコル「Homa」への移行を訴えています。Homaは短いメッセージを優先的に処理することで通信遅延を抑える仕組みを備えており、既存のTCPと並行して導入できるとのことです。

The Homa network protocol [LWN.net]
https://lwn.net/Articles/1003059/

Homa: The End of TCP for AI Clusters — John Ousterhout, Stanford - YouTube

A Linux Kernel Implementation of the Homa Transport Protocol
(PDFファイル)https://www.usenix.org/system/files/atc21-ousterhout.pdf

Stanford prof is beating the drum for a new protocol to replace TCP
https://www.theregister.com/networks/2026/10/01/stanford-prof-is-beating-the-drum-for-a-new-protocol-to-replace-tcp/5300629

TCPは送ったデータが相手に届いたことを確認しながら通信を進める仕組みで、ウェブをはじめとする幅広い用途で使われています。信頼性の高い通信を実現する一方で、接続ごとに状態を管理し、データを送信順に並べた「バイトストリーム」として扱うという特徴があります。

一般的なインターネット通信では長年にわたって活躍してきたTCPですが、データセンターでは物理的に近い多数のコンピューターが細かなリクエストを大量にやりとりするため、接続の管理や送信順序の保証に伴う処理が通信時間に占める割合が大きくなります。

さらに、AI向けの大規模クラスターではモデルの重みや勾配などの大規模なデータ転送と、KVキャッシュの検索やメタデータの調整などの短い通信が同じネットワーク上を流れます。こうした大小のデータの通信をそれぞれ管理して遅延を最小にすることが大切です。オースターハウト氏は「重要なのはレイテンシーだ」と指摘しており、わずか1ミリ秒の遅延でも高価なGPUが処理を待つ時間につながると述べています。

TCPでは送信側がネットワークの混雑具合を推測しながら送信量を調整しますが、受信側から届く応答などを手掛かりに速度を下げるため、個々の送信側からは別の送信元を含めて受信側にどれほど通信が集中しているのかを把握しにくく、混雑への対応が遅れがちです。また、TCPはデータを一続きのストリームとして扱うため、短いメッセージと長いメッセージを区別して短い方だけを先に届ける仕組みも備えていません。

同様の問題はウェブでも以前から指摘されており、TCP上で動作するHTTP/2ではパケットが失われると後続データが待たされる「Head-of-Line Blocking」が発生します。ウェブ向けにはTCPの代わりにQUICを利用するHTTP/3が登場しており、GIGAZINEでも過去に以下の記事で詳しく解説しています。

ウェブを支えるHTTP通信はどのように進化しているのか - GIGAZINE

Homaはデータセンター向けの通信そのものを改めて設計することで、TCPで生じる問題を解決しようとしています。Homaの研究は2018年に発表された論文までさかのぼり、ベーナム・モンタゼリ氏やオースターハウト氏らは「短いメッセージの低遅延」と「高いネットワーク使用率」を両立するプロトコルとしてHomaを提案しました。

Homaの大きな特徴はTCPのようなストリーム型ではなく「メッセージ型」で通信する点です。HomaはRPC(Remote Procedure Call)という別のコンピューター上の処理を呼び出す仕組みを想定しており、送信するメッセージの長さが最初から分かります。受信側は残りのデータ量を把握できるため、短時間で受信し終えられるメッセージを優先して処理できます。

さらにHomaでは混雑制御の主導権を受信側に持たせています。受信側は到着予定のメッセージ量を確認し、どの送信者がどれだけデータを送っていいのかを「GRANT」と呼ばれる通知で指定します。大量の通信が1台のサーバーに押し寄せた場合でも、受信側が到着順を調整しやすくなるというわけ。

短いメッセージを渋滞に巻き込ませないため、Homaはネットワーク機器の優先度付きキューも活用します。研究チームが2018年に公開したHomaでは、受信完了までに残っているデータ量が少ない通信ほど優先度を高くする方式を採用。大きなデータ転送の後ろに小さなリクエストが並んで待たされる時間を減らすことが狙いです。

オースターハウト氏がThe Registerに示した100Gbps・ネットワーク使用率80％という条件での比較では、短いメッセージの99パーセンタイル遅延がTCPでは1.2ミリ秒だったのに対し、Homaでは92マイクロ秒でTCPの約13分の1だったとのこと。長いメッセージでもHomaはTCPの約2倍の性能だったとオースターハウト氏は主張しています。

2021年に公開されたLinuxカーネル向けHoma実装の論文でも、40台のマシンを使ったテストでHomaはすべてのメッセージサイズにおいてTCPとDCTCPより低い遅延を記録し、短いメッセージの99パーセンタイル遅延はTCPの19分の1～72分の1、DCTCPの7分の1～83分の1だったと報告されています。

Homaへの移行は段階的に行うことが可能で、既存のTCP通信を一斉に廃止する必要はないとのこと。公開されているLinuxカーネルモジュールをクライアントとサーバーに導入すればHomaとTCPを並行して利用できるため、アプリケーションを順番にHomaへ移行できます。オースターハウト氏はHomaとTCPを同時に利用した際の性能改善にも取り組んでおり、GitHubでは2026年1月に両者を共存させる際の通信制御を改善する「homa_qdisc」が追加されています。

Homaは研究だけにとどまらず標準化やLinuxへの導入も進められています。IANA(Internet Assigned Numbers Authority)はHomaにIPプロトコル番号「146」を割り当て済みで、オースターハウト氏はHomaをLinux本体に取り込むためのパッチを継続的に提出しています。

GitHubの実装にも開発が続いており、2026年3月にはRed Hat Enterprise Linux 8および9.5へのバックポートが実施され、同年9月にはデータ送信許可の仕組みに変更が加えられています。

GitHub - PlatformLab/HomaModule: A Linux kernel module that implements the Homa transport protocol. · GitHub
https://github.com/PlatformLab/HomaModule

ウェブの世界ではTCPの問題を回避するためQUICが普及しましたが、Homaが狙っているのはデータセンター内部のRPCです。オースターハウト氏はIETFでの標準化に向けた文書の作成やLinuxへの統合作業を進めるとともに、大手金融サービス企業ともHomaを使った試作に取り組んでいるとのこと。半世紀近くネットワークの主役を務めてきたTCPをすぐに追い出すわけではなく、まずはAIクラスターなど遅延への要求が厳しい場所からHomaを広げていく考えを示しています。

なお、データセンター向けにはRDMAなど別の低遅延通信技術も利用されています。

Metaが100万GPU規模を想定した新通信プロトコル「MetaRoCE」を発表、パケットロスを前提にEthernetでAIクラスタを高速接続 - GIGAZINE