title: "AI 集群网络为何告别 TCP？Ousterhout 的架构判断"
source_url: "https://www.youtube.com/watch?v=eZ8WWZzoaR0"
author: "AI Engineer"
excerpt: "公共早报 John Ousterhout 指出，AI 推理与智能体负载让小消息往返延迟成为关键瓶颈，揭示 TCP 与 RDMA 在 incast 与队头阻塞下为何失效，并介绍基于消息、接收端驱动的传输协议 Homa，可将短消息 P99 延迟降低约 13 倍。"
简要描述
斯坦福大学名誉教授 John Ousterhout 认为， evolving AI 工作负载——特别是推理和智能体架构——正在从纯吞吐量受限的批量数据传输转向对延迟敏感的小型协调和元数据消息交换。像 TCP 和 RDMA 这样的传统传输协议在混合小型和大型消息时会出现严重的尾延迟，因为它们采用发送端驱动的拥塞控制和 unstructured 字节流中的队头阻塞。为了解决这些瓶颈，Ousterhout 介绍了 Homa，这是一种从零开始设计的用于数据中心传输的协议，它用基于消息的远程过程调用替代字节流，通过调度的 grants 将拥塞管理委托给数据包接收端，并利用现代数据中心交换机中的硬件优先级队列将尾延迟降低一个数量级以上。
目录
- 变化的 AI 工作负载和延迟敏感性的兴起
- 为什么传统协议失败：Incast、发送端拥塞和字节流
- 介绍 Homa：数据中心清洁 slate 传输
- Homa 的核心架构机制
- 性能基准：与 TCP 的尾延迟比较
- 结论和协作机会
变化的 AI 工作负载和延迟敏感性的兴起
请欢迎斯坦福大学名誉教授 John Ousterhout。
很高兴来到这里谈论 AI 应用程序的网络方面，并提出延迟很重要而且未来会更重要的论点。AI 工作负载严重依赖网络性能来实现其计算潜力，因为这些大型模型必须分布在多台持续通信的机器上。
然而，这些底层工作负载正在经历根本性的变化。AI 网络历来以海量数据传输为主，原始吞吐量是主要指标。在接下来的十五到二十分钟里，我想表明，我们看到越来越多的对延迟至关重要的小型传输，传统协议如 TCP 和 RDMA 非常不适合这种环境，并且一种名为 Homa 的清洁 slate 协议可以将尾延迟降低一个数量级或更多。
从历史上看，AI 工作负载由节点之间的巨大传输组成，推动数 GB 的数据用于权重梯度。在这种情况下，你关心的只是以千兆位每秒衡量的吞吐量。这些对于网络基础设施来说是相对简单的工作负载。长期设置时间无关紧要，因为传输会运行很长时间，在这些条件下，像 TCP 和 RDMA 这样的传统协议表现良好。这里的 RDMA 主要指 RoCE，即融合以太网上的 RDMA。
工作负载变得更加精细，以更小的计算块和更小的数据交换为特征。这种模式在推理和智能体工作负载中尤为突出，而不是模型训练，后者仍然以海量传输为主。系统越来越多地交换用于元数据和协调的小型消息，例如验证分布式 KV 缓存中是否存在条目或在计算阶段之间执行 barrier 同步。
对于这些操作，重要的是往返延迟：跨网络发送小请求、执行小计算并接收响应所需的时间。平均延迟不是瓶颈；尾延迟才是。在分布式系统中，高 P99 尾延迟严重限制整体应用程序吞吐量。
考虑一个常见工作流，其中密集计算 split 跨多个 GPU 节点。一旦每个节点完成其计算 pass，节点在进入下一轮之前交换同步元数据。当那个 exchange 发生时，GPU 完全空闲。如果即使单个传输经历延迟，整个过程也会 stall，因为所有 exchanges 必须在计算恢复之前完成。
当计算阶段需要五秒钟而交换需要几毫秒时，开销可以忽略不计。在设计为以快速、一致的间隔流式传输 token 的智能体工作流中，计算阶段缩小到毫秒级。如果网络同步也需要毫秒级，则相当一部分 GPU 计算能力浪费在等待网络 barrier 上。
为什么传统协议失败：Incast、发送端拥塞和字节流
数据中心中高尾延迟通常源于 incast 引起的缓冲区拥塞。当多个节点同时向同一目标节点传输数据时，就会发生 incast。因为网络链路共享统一带宽，三个发送节点传输数据的速度可以是单个目标接收速度的三倍。数据包 rapid 积累 在到接收器的最后一跳的 top-of-rack 交换机的出口缓冲区中。
当一个独立节点尝试向同一目标发送短消息、延迟关键消息时，短消息在大量批量数据数据包后面排队。在严重情况下，incoming 流量耗尽交换机缓冲区空间，强制数据包丢弃，触发超时和重传。为了保持低尾延迟，协议必须防止交换机队列无控制地增长。
在 Homa 之前，历史上的网络协议——包括 TCP 和 RDMA——将拥塞控制完全放在发送端。发送端必须检测下游拥塞并相应地限制其传输速率。因为拥塞发生在数据中心网络的远端，发送端必须依赖延迟的反馈。在旧设计中，发送端只有在缓冲区溢出且未确认的数据包丢弃后才能检测到拥塞。
现代数据中心网络通过让交换机在队列占用率跨越配置阈值时应用显式拥塞通知（ECN）标记来减轻丢弃。当数据包到达接收端时，接收端将 ECN 标记复制到返回的确认中，这样发送端意识到拥塞存在并减慢速度。
然而，发送端驱动的拥塞控制存在严重的控制滞后。发送端只收到一位指示路径某处存在拥塞，而多个发送端尝试同时调整速率。发送端需要多次往返才能收敛到可用容量。当发送端速率调整时，早期的流已经完成或新的流已经开始，导致网络在过度订阅和利用不足之间振荡，而从不稳定。
此外，TCP 和 RDMA 采用非结构化字节流模型。通过 TCP 套接字发送的消息被序列化成一个 undifferentiated 流。传输协议无法辨别消息边界，无法预测 incoming 消息量，也无法优先处理小型消息而不是大型传输。这直接导致队头阻塞，小型消息被 trapped 在同一流中兆字节的批量数据后面。
介绍 Homa：数据中心清洁 slate 传输
为了克服这些结构性限制，我们在斯坦福大学开发了 Homa，通过从零开始重新设计数据中心网络传输。当从零开始专门为现代数据中心架构设计传输时，几乎每个基础决策都与 TCP 和 RDMA 不同。Homa 管理并发的大型和小型消息，为短传输提供一致的低尾延迟。
Homa 起源于 Behnam Montazeri 的博士论文。实验结果足够引人注目，以至于我在过渡到斯坦福大学名誉教授后将 Homa 作为我的主要重点。我为 Homa 开发了一个开源的 Linux 内核模块，在 GitHub 上提供，并目前正在努力将其实现 upstream 到主线 Linux 内核。
Homa 的核心架构机制
Homa 的架构基于三个核心设计选择。首先，Homa 是基于消息的而不是基于流的。它的基本操作单元是从客户端到服务器的请求消息，然后是从服务器返回客户端的响应消息的远程过程调用。
因为消息长度直接嵌入在传输 header 中，Homa 获得了对 traffic 需求的预测可见性。接收端在收到第一个数据包时就知道整个传输的确切字节长度。这种明确的 message boundary 允许 Homa 实现最短剩余处理时间（SRPT）调度，优先处理短消息而不是大型传输。因为消息完全独立而不是在流中序列化，短消息绕过长传输而不经历队头阻塞。
其次，Homa 将拥塞控制从发送端转移到接收端。因为数据中心拥塞主要发生在到接收端的最后下行链路上，接收主机拥有对网络压力的直接可见性。当发送端传输消息时，它只发送前几个数据包 unprompted；这些被指定为未调度的数据包。
所有后续数据包都是已调度的数据包，仅在接收端通过 grant 数据包明确请求时传输。接收端随时间动态调整这些 grant 的节奏。如果接收端同时有十个 incoming 传输，它会扣留来自较低优先级传输的 grant 以防止 top-of-rack 缓冲区积累。通过优先向剩余数据最少的流授予数据包，接收端强制执行严格的 SRPT 调度。
第三，Homa 利用现代网络交换机中存在的硬件优先级队列。现代数据中心交换机在每个出口端口提供多个优先级队列——通常是八个——严格按优先级顺序处理数据包。Homa 根据剩余消息长度动态地将数据包 header 分配给交换机优先级级别。在 incast 事件期间，大型消息数据包收集在较低优先级队列中，而来自短消息的数据包进入较高优先级队列，绕过 bulk 队列而不延迟。
性能基准：与 TCP 的尾延迟比较
为了评估 Homa 与传统协议，我们测量了一个在广泛大小范围内交换消息的集群工作负载，从 50 字节到 1 兆字节。基准测试记录匹配请求和响应对的往返完成时间，跟踪中位数延迟（P50）和尾延迟（P99）。
在 P99 处，对于短消息，TCP 的尾延迟超过一毫秒。在相同工作负载下，Homa 将尾延迟保持在 100 微秒以下，代表了 13 倍的延迟改进。
优先处理短消息并不会降低大型传输的性能。即使对于最大长度的消息，Homa 也实现了大约两倍于 TCP 的吞吐量性能。这种效率优势来自于 Homa 的 run-to-completion 方法避免了 TCP 公平共享机制中固有的吞吐量降解调度抖动。
结论和协作机会
随着分布式 AI 应用程序和智能体系统的成熟，短消息交换将发挥越来越重要的作用。 experiencing 应用程序吞吐量因尾延迟瓶颈而降解的系统设计者应该评估现代传输替代方案。Homa 在混合工作负载下提供数量级的尾延迟降低。
我正投入全部时间开发和改进 Homa。欢迎工程团队进行协作、提问和部署反馈，这些团队有兴趣在其集群内测试该协议。