スタンフォード大学名誉教授のJohn Ousterhout氏が、データセンター向け通信プロトコル「Homa」を、AIクラスタの通信遅延を減らすための選択肢として改めて提案している。
AI Engineerが2026年9月17日に公開した講演動画では、大量のデータを高速に転送することだけでなく、小さな通信を大容量転送の後ろで待たせないことの重要性を取り上げた。
2018年から研究されてきたHomaは、RPCのメッセージ単位で優先順位を付け、受信側が送信量を制御する設計を採る。2026年には、TCPとの共存時の干渉を抑える仕組みや、長いメッセージの送信開始方法にも変更が加えられた。
ただし、AIクラスタでHomaを実際に利用するには、通信性能だけでなく、既存アプリケーションへの組み込みや暗号化、運用環境の整備といった課題も残る。
小さなRPCの遅れがGPU全体を待たせる
Ousterhout氏が今回の講演で強調したのは、AIクラスタの通信が大容量転送だけではなくなっていることだ。
大規模学習では、勾配などの巨大なデータをノード間で転送する処理が重要になる。一方、推論やエージェント型の処理では、KVキャッシュへの問い合わせや同期処理など、小さなメッセージを頻繁にやり取りする場面も増える。
大量のデータを効率よく送り続けられることと、小さな要求へすぐ応答できることは、同じ性能指標では測れない。
複数のGPUや計算ノードが通信の完了を待って次の処理へ進む場合、最も遅い応答が全体の進行を決めることがある。
ほとんどの通信がすぐ終わっても、一部だけが長く待たされれば、その間は高価なGPUが次の処理へ進めない。
そこで重要になるのが「テールレイテンシ」である。
P99は、測定した処理の99％がその時間以内に完了する境界を示す。平均値が小さくても、P99が大きければ、一部の遅い通信が分散処理全体を止める可能性がある。
こうした遅延を生む典型例の一つが「インキャスト」だ。
複数の送信元から一つの受信先へ同時にデータが集中し、合計の送信速度が受信先へ向かうリンク容量を超えると、受信先直前のスイッチでパケットの待ち行列が伸びる。
そこへ小さな要求が届いても、先に送られている大容量データの後ろで待たされることがある。
TCPとHomaを比較した2021年の論文では、同じTCP接続上に長いメッセージと短いメッセージが混在した場合に起こる「Head-of-Line Blocking」も問題として挙げている。
TCPは一つの接続をバイト列として扱い、順番どおりアプリケーションへ渡す。そのため、先に送られた大きなデータが詰まれば、後から来た小さなデータだけを先に処理することは難しい。
複数のTCP接続を使うなど、アプリケーション側で回避する方法はある。
Homaはこうした優先順位付けをアプリ側ではなく、トランスポートプロトコル側で扱うことを目指している。
残りデータ量が少ないメッセージを優先する
Homaは、要求を送り、応答を受け取るRPC（Remote Procedure Call）を基本単位として扱う。
各メッセージの全体サイズが分かるため、まだ送る必要があるデータ量が少ないRPCを優先できる。
考え方の基礎となっているのが「SRPT（Shortest Remaining Processing Time）」に近いスケジューリングだ。
残りの処理量が少ない仕事を先に終わらせることで、小さなRPCが大容量転送の後ろで長時間待つことを防ぐ。
受信側はGRANTパケットを使い、送信側へ「どこまで送信してよいか」と、そのデータに割り当てる優先度を通知する。
複数の送信元から一つの受信先へデータが流れ込む場合でも、受信側が到着予定のメッセージを見ながら、どの通信を先に進めるかを調整できる。
ただし、受信側が優先順位を決めても、すでにスイッチ内に大量のパケットが並んでいれば、それらを簡単に追い越せるわけではない。
そこでHomaは、データセンタースイッチが備える複数の優先キューも利用する。
短いメッセージには高い優先度を与え、大容量転送とは異なるキューで処理する。
送信側でも、複数のメッセージを送れる状態にある場合には、残りデータ量の少ないものを優先する。
さらに、NIC内部へ大量のパケットを先送りしてしまうと、後から発生した短いメッセージがNICの待ち行列に閉じ込められる。
これを防ぐため、HomaにはNICへ送り込むデータ量を調整する「pacer」と呼ばれる仕組みもある。
こうした受信側のスケジューリング、送信側の制御、スイッチの優先キューを組み合わせることで、短いRPCをできるだけ早く完了させる。
Homaは信頼性を捨てたプロトコルでもない。
プロトコルの説明には、欠落したデータを受信側が検出し、再送を要求する仕組みが記されている。
一方、複数のRPCが開始された順番と同じ順番で完了することは保証されない。
例えば「書き込みが終わった後に読み出す」といった順序関係が重要なアプリケーションでは、その依存関係をアプリ側で管理する必要がある。
また、短いメッセージを優先し続けると長いメッセージがいつまでも送れない可能性があるため、古い通信にも一定の帯域を割り当てる仕組みを備えている。
2021年の性能差を、そのままAIクラスタへ当てはめることはできない
Ousterhout氏がUSENIX ATC 2021で発表した査読済み論文では、40台の実機を使ってLinux版Homaを評価している。
各ノードは25Gbpsのネットワークで一つのスイッチへ接続され、Linux 5.4.80を使用した。
GoogleやFacebookなどで観測されたメッセージサイズ分布を使い、各ノードがランダムに選んだ相手へ要求を送り、同じサイズの応答を受け取る試験を行っている。
論文の第5.2節では、高負荷時の短いメッセージについて、HomaのP99レイテンシがTCPの19〜72分の1、DCTCPの7〜83分の1だったと報告している。
ただし、この比較には条件がある。
ネットワーク負荷は各プロトコルが維持できる最大速度の80〜90％程度になるよう設定されており、すべての方式へ同じ絶対トラフィック量を与えた比較ではない。
また、短いメッセージが多いワークロードでは、ネットワーク帯域ではなくLinux側のソフトウェア処理が先に限界へ達する場合もあった。
したがって、「HomaならどんなネットワークでもTCPより数十倍速い」と解釈することはできない。
低負荷に近い単純な試験では、違いはさらに小さくなる。
論文のTable 2では、100バイトの要求と100バイトの応答を1組ずつ連続して送った場合、往復時間はHomaが15.1マイクロ秒、TCPが23.4マイクロ秒だった。
一方、500KBの要求と応答を順番に処理した場合のスループットは、Homaが10.0Gbps、TCPが20.3Gbpsと、TCPの方が高かった。
| 試験 | Homa | TCP |
|---|---|---|
| 100B要求＋応答の往復時間 | 15.1µs | 23.4µs |
| 500KB要求＋応答の逐次転送 | 10.0Gbps | 20.3Gbps |
これらは単一のクライアントスレッドを使い、5秒間の試験を5回実行した中から最も良い平均値を採用した結果である。
Homaの強みは、単純な大容量転送そのものを常に高速化することではない。
サイズの異なる多数のRPCが同時に存在する高負荷環境で、小さな通信が大きな通信の後ろに取り残されることを減らす点にある。
複数のRPCを同時に動かした試験では、Homaの大容量転送のスループットはTCPと同程度まで伸びている。
比較方法を巡る議論もある
Homaの性能評価については、比較方法を巡る議論も続いてきた。
ネットワーク技術者のIvan Pepelnjak氏は2023年の批判で、複数のRPCを同じTCP接続へ流す試験ではHead-of-Line Blockingが発生しやすく、TCPに不利な条件ではないかと指摘した。
既存のRDMAやRoCEなどとの比較が不足している点にも疑問を示している。
これに対しOusterhout氏は公開した反論で、複数のTCP接続を使った2018年の実験でもHomaが高い性能を示したと説明している。
その比較結果はSIGCOMM 2018論文のFigure 8にも掲載されている。
一方、Ousterhout氏自身も、実際のデータセンターで通信相手がどのように分布しているかを示す十分なデータを得られなかったため、送信先を一様ランダムに選んで評価したという限界を認めている。
また、2021年の主な性能比較はTCPとDCTCPを対象としたものであり、現在のAIクラスタで使われるRDMA系通信と同じ条件で直接比較した結果ではない。
Homaの設計上の利点を示す実測結果はあるが、特定のAIサービスでGPU利用率や推論性能がどれだけ改善するかは、そのサービスの通信パターンを使って確認する必要がある。
P99レイテンシが10倍改善したからといって、AI処理全体が10倍速くなるわけではない。
2026年にはTCPとの共存とGRANT方式を改良
Homaの開発は2021年の論文発表後も続いている。
HomaModuleの変更履歴を見ると、2026年にはTCPとの共存や対応OS、メッセージの送信開始方法に関する変更が加えられた。
| 時期 | 主な変更 | 導入時に関係する点 |
|---|---|---|
| 2026年1月 | homa_qdiscを導入 |
同じホストでTCPとHomaを使った場合の干渉を抑える |
| 2026年3月 | RHEL 8、RHEL 9.5へバックポート | 対応環境を広げる |
| 2026年9月 | GRANTが必要なメッセージを完全にスケジュールし、START_MSGを追加 |
長いメッセージも、実データ送信前から受信側が制御できる |
この表はHomaプロジェクト自身の変更履歴を整理したもので、商用製品への採用や標準化を意味するものではない。
RHEL向けブランチが用意されたことも、Red HatがHomaを正式な製品機能としてサポートしているという意味ではない。
特に9月の変更は、従来のHomaの説明を読む際に注意が必要になる。
2021年の論文や現在公開されているprotocol.mdでは、長いメッセージでも最初の一部を受信側の許可なしで送信し、その後をGRANTで制御する仕組みが説明されている。
しかし2026年9月の変更履歴では、GRANTが必要なメッセージについては、最初から実データを送らず、まずSTART_MSGで受信側へ存在を知らせる方式へ変更されたとしている。
つまり、長いメッセージについては、受信側がデータ送信の開始段階からスケジュールへ関与するようになった。
古い論文やprotocol.mdだけを読んで現在の実装を説明すると、この変更を見落とす可能性がある。
TCPと同時に使うなら専用のキュー制御が必要
既存のデータセンターを段階的にHomaへ移行する場合、TCPとの共存は避けにくい。
しかし、HomaとTCPを同じホストで動かせることと、特別な設定なしで双方が高い性能を出せることは別である。
Homa開発者の2026年1月の記録によると、100GbpsのCloudLab c6620環境でhoma_qdiscを使わずにTCPとHomaを同時実行した場合、Homaの短いメッセージのP99は約4倍に増えた。
homa_qdiscを有効にすると、TCPと併用した状態でもHoma単独時に近い性能へ戻ったという。
導入手順では、homa_qdiscには二つの役割があると説明している。
一つは、NIC内部に長い送信キューができることを防ぎ、小さなHomaメッセージがその後ろで待たされないようにすること。
もう一つは、TCPなど他のプロトコルとの間で送信キューを調整し、互いの通信が過度に干渉しないようにすることだ。
実際の導入を評価するのであれば、Homaだけを流したベンチマークだけでなく、既存のTCP通信が同じホストやネットワークで動いている状態でも測定する必要がある。
Homaを使うには、カーネル以外の対応も必要
HomaはLinuxカーネルモジュールとして公開されている。
現在の導入手順では、mainブランチについてLinux 6.17.8で動作確認済みとしている。
ただし、カーネルモジュールを読み込めば、それだけで論文と同じ性能が得られるわけではない。
Homaの性能を引き出すには、NICの割り込み設定、Receive Packet Steering（RPS）、NICの送信キュー、ジャンボフレームなどを調整する必要がある。
Top-of-Rackスイッチ側でも、DSCPなどに基づいて複数の優先キューを使えるよう設定する。
大きなメッセージを効率よく送るためには、TSOやGSOといったセグメンテーションオフロードも重要になる。
つまり、「Homaをインストールすること」と「低いテールレイテンシを維持した状態で運用すること」は別の作業である。
標準化の状況にも注意したい。
HomaにはIANAのIPプロトコル番号146が割り当てられている。
ただし、IPプロトコル番号を取得したことは、HomaがIETF標準として成立したことを意味しない。
GitHubで公開されているRFCドラフトも、往復時間が数十マイクロ秒以下のデータセンター環境を主な対象としており、WAN向けのプロトコルとして設計されているわけではない。
「インターネット全体でTCPを置き換える技術」と理解すると対象を広げすぎる。
gRPC統合と暗号化は現在の大きな導入課題
アプリケーション側では、RPCフレームワークが通信方式の違いを吸収できれば、Homaへの移行は容易になる。
しかし、公開されているgRPC向け統合実装grpc_homaは、2023年後半に活発な開発を停止したとREADMEに記されている。
開発停止時点ではC++版が動作し、Java対応は一部にとどまっていた。
さらに、対応するのは暗号化されていないチャネルだけである。
HomaのLinuxカーネル実装そのものは2026年にも更新されているが、既存のgRPCサービスへ安全に組み込み、そのまま本番環境で利用できるところまで周辺ソフトウェアが整っているわけではない。
AIクラスタでHomaを評価するのであれば、通信プロトコル単体のベンチマークだけでは足りない。
実際に利用するアプリケーションで、
- 小さなRPCのP99レイテンシ
- ネットワーク処理が消費するCPU時間
- GPUが通信完了を待って停止する時間
- TCPと同時に利用した際の性能
- 暗号化を含む本番環境での実装方法
を合わせて確認する必要がある。
そこで優位性が維持され、利用するRPCフレームワークも継続的に保守できるのであれば、Homaは大容量転送に小さなRPCが埋もれ、GPUが通信待ちになる時間を減らす選択肢になり得る。
