AI 集群的瓶颈正在从吞吐转向尾延迟｜AI Engineer × John Ousterhout

先说结论

AI 集群的网络问题，正在从“能不能把大量数据搬得足够快”，转向“能不能让关键的小消息及时抵达”。训练仍然大量依赖吞吐，但推理和 Agent 工作负载会反复交换 KV cache 元数据、同步信号和小型请求；只要其中一个消息拖慢，整组 GPU 就可能等待。John Ousterhout 的主张是：TCP 和 RoCE 以字节流、发送端拥塞控制为中心，难以识别并优先处理这些短消息；Homa 则把消息作为基本单位，让接收端控制后续发送，并用交换机优先级让短消息绕过大传输。中文深度整理，非逐字翻译。

原始来源：Homa: The End of TCP for AI Clusters。节目：AI Engineer。嘉宾：John Ousterhout。原始日期：2026-09-16。时长：约 19 分钟。内容类型：技术演讲 / AI 基础设施。

这期内容在讨论什么

演讲并不是简单宣布 TCP 已经失效，而是先区分两类工作负载。传统训练常常在机器之间搬运大块梯度，连接建立和短暂等待相对于长时间传输并不重要，吞吐自然是主要指标。推理和 Agent 系统则更像许多轮短计算与短通信交替进行：一次缓存查询、一次屏障同步、一次小型 RPC，都可能处在整个计算循环的关键路径上。

当多个节点完成计算后等待彼此的同步消息，最慢的那个交换决定下一轮何时开始。计算阶段越短，网络尾延迟占比越大。平均延迟看起来不错，并不能说明系统稳定，因为真正决定吞吐的往往是 P99 一类的慢尾部。

核心观点

第一，短消息的问题常常发生在最后一跳。多个发送节点同时把大消息发往同一接收节点时，数据会在顶层交换机通往接收端的出口队列里堆积。此时一个只有几百字节的同步消息，也会排在大消息的分片之后。它本身传输很快，却可能在队列里等待很久；缓冲区耗尽后，丢包、超时和重传还会进一步放大延迟。

第二，传统拥塞控制的反馈路径太长。TCP 或 RoCE 通常由发送端决定速率，交换机发生拥塞后才通过丢包或 ECN 标记把信号传回发送端。多个发送者同时调速时，每个发送者只看到不完整的局部信息，不知道应该减多少、何时恢复。于是系统可能在过量发送和过度退让之间摆动，而队列已经制造了延迟。

第三，字节流隐藏了调度真正需要的信息。应用层明明知道自己发的是多个独立消息，但 TCP 只看到一串字节。如果短消息排在大消息之后，传输层没有办法把它单独提到前面，于是形成队头阻塞。要优化短消息，网络必须知道消息边界、消息剩余大小和不同消息之间的优先级。

推理链与关键例子

Homa 的设计从这三个缺口出发。它把独立 RPC 消息作为基本单位，并在消息开始时暴露长度。发送端先发出少量无需授权的分片，让接收端知道有哪些消息正在到来；剩余分片则等待接收端发放 grant。接收端靠近拥塞发生的最后一跳，能够同时看到竞争同一出口的消息，因此可以决定哪些消息先继续发送、每次允许发送多少。

这套机制同时承担流控和调度两个任务。假设十条消息都在等待同一个接收端，如果一次性放行所有消息，交换机队列仍会爆满。接收端可以优先授权剩余长度较短的消息，让短任务更快完成，再继续安排长任务。交换机的多个优先级队列则把短消息放进高优先级队列，使它们在出口处绕过低优先级的大消息积压。

演讲展示的基准测试用不同长度的请求和响应比较 TCP 与 Homa。讲者报告称，Homa 在短消息的 P99 延迟上约有 13 倍改善，最长消息的延迟也接近改善一倍。这个结果说明消息边界、接收端授权和优先级调度可以同时改变短消息尾部与大消息完成时间，但它首先是传输层基准，不等于任何 AI 应用都会得到相同幅度的加速。

边界、保留意见与争议

第一，演讲没有证明“换成 Homa 就能让 AI 应用整体快 13 倍”。如果一次计算持续数秒，而同步只占很小比例，网络改进对总吞吐的影响就有限；只有当短消息等待处于关键路径时，应用才会明显受益。

第二，展示的直接比较是 Homa 与 TCP。讲者提到的 RDMA 主要指 RoCE，但现场并没有给出同等细节的 Homa 与 RoCE 对照，因此不能把结果直接解读成相对于所有 RDMA 部署的优势。

第三，项目的工程成熟度仍需单独验证。讲者提供了 Linux 内核模块和 GitHub 实现，但实现说明中对大规模 incast 优化仍有明确限制。对真实集群来说，API、内核集成、故障恢复和运维工具都和论文中的机制同样重要。

整理后的观察

这期演讲真正改变的是排查顺序。很多团队看到 GPU 利用率不高，会先检查模型、批处理和显存，却未必检查同步消息的尾延迟。对于推理和 Agent 集群，应该把“最慢的那条必要消息是否让所有 GPU 等待”作为单独的诊断问题。

更广泛地看，Homa 代表一种基础设施趋势：当工作负载从大块离线计算变成细粒度、频繁协调的在线系统，网络协议的基本抽象也要变化。吞吐仍然重要，但它不再足以描述系统性能；消息边界、关键路径、尾延迟和调度公平性，会成为模型服务成本的一部分。先测出短消息是否真的限制了应用，再决定是否引入新的传输协议，这比把协议名称当成架构答案更稳妥。