AI Engineer onepage/ Homa networking
John Ousterhout, Stanford · 約 17:27
這支影片在講：AI 叢集不該再把 TCP 當成預設答案
AI 推論與 agent 工作流帶來大量小型協調訊息。它們一旦被巨量資料卡在同一條佇列，99th percentile latency 就會讓昂貴 GPU 等資料。Homa 以「訊息」而非位元組串流為單位，改由接收端主動排程。
Published: 2026-09-17Video ID: eZ8WWZzoaR0
01 / 問題
流量型態已反轉
過去的重點是 GB 級 gradient 傳輸與吞吐量；現在 inference、KV cache lookup、barrier sync 都依賴頻繁而短小的協調訊息。
02 / 卡點
小包被困在大流量後面
incast 讓短訊息在交換器佇列中排隊。只要一個同步回覆慢，整批 GPU 就可能閒置等待。
03 / 解法
讓接收端掌握節奏
Homa 先辨識完整訊息，再由接收端發 grant 控制誰能送、送多少，並以 SRPT 優先處理剩餘量最小的工作。
Signals
影片中最重要的四個訊號
AI traffic
小而頻繁
推論與 agent coordination 使 latency 成為一級指標。
Queueing cost
P99
短訊息一旦卡在 queue，尾端延遲會直接轉成 GPU idle。
Protocol model
Message
知道訊息邊界，才能依剩餘工作量排序，而非盲送 bytes。
Benchmark
10×+
短訊息 tail latency 相較 TCP 可降低超過十倍，同時不犧牲大訊息表現。
Core story
TCP 與 RDMA 在 AI 流量下的三個結構性限制
限制 1
壅塞控制放在發送端，看到問題時已太晚
TCP 與 RDMA 大多靠 sender 偵測 drop 或交換器延遲後再收斂。這是反應式迴路，容易振盪；真正擁有佇列資訊的接收端卻沒有主控權。
限制 2
byte stream 看不到工作的重要性
傳統協定把資料視為不透明的位元組串流，無法知道哪些是即將完成同步的短訊息，因而不能優先讓關鍵工作穿越佇列。
限制 3
平均吞吐量掩蓋了尾端停頓
即使平均表現好，單一慢交換仍足以讓分散式工作停住。對 GPU 叢集，最慢那個同步點往往才是每秒成本最高的位置。
Architecture pivot
Homa 把傳輸協定翻成三個可排程的決策
以訊息為原生單位Homa 不只看到 bytes；它知道一段傳輸是哪個 message、還剩多少，得以用 Shortest Remaining Processing Time 優先完成短工作。
由 receiver 發 grants接收端根據自己將收到的訊息與可用頻寬發放許可，讓壅塞在進入交換器佇列前就被協調，而非等遺失封包後補救。
使用現有的硬體 priority queues不必等待新交換器：Homa 將短、急的訊息送入較高優先權佇列，讓它們繞過已排隊的大量傳輸。
短與長不必互相犧牲影片的 benchmark 重點不是只讓短訊息更快；它同時改善大訊息，表示排序與流控降低了整體隊列混亂。
Apply this
對 AI infra 團隊的實務檢查表
先量 P99/P999，而非只看平均 throughput對每個 inference 或 training pipeline，標出 KV lookup、barrier、metadata RPC 等同步點，確認 tail latency 是否正在造成 GPU idle。
把資料面依「訊息目的」拆開觀察將長 payload 與短控制／協調訊息分開統計；如果兩者混在同一個 queue，平均值很可能掩蓋關鍵阻塞。
檢視誰真正知道壅塞狀態若 receiver 最清楚哪些 RPC 即將抵達、哪些工作最急，卻只能被動接收，流控設計可能放錯了決策點。
善用既有交換器的優先權能力導入新 transport 前先確認硬體 queue 與排程策略；Homa 的設計價值之一是能利用已存在的多條 priority queues。
Source video