John Ousterhout：TCP 和 RDMA 正拖慢 AI 推理，他想用 Homa 换掉它们

John Ousterhout 开场就说这场演讲对他很不寻常——会场里第一次摆了造雾机。真正不寻常的其实是话题:这天主舞台前后几场讲的都是 agent 怎么用工具、怎么管上下文,他却一路扎进数据中心网络协议层,说服台下的人 TCP 和 RDMA 正在拖慢 AI 推理的吞吐。他是斯坦福教授,写过 Tcl/Tk 脚本语言,也参与设计过 Raft 共识协议,这次带来的是他正全职投入的新项目 Homa。

原视频:https://www.youtube.com/watch?v=I2cbIws9j10(约 00:36:00 开始)

训练是搬家,推理是发短信

过去 AI 训练把网络用成了搬家公司:动辄几个 GB 的权重梯度在机器之间来回搬,连接建立慢一点也无所谓,反正传输本身要跑很久,能撑起吞吐才是唯一指标。TCP 和 RDMA 在这种场景里表现得相当不错。

Ousterhout 说这两年情况变了。推理和 agent 工作负载里,机器之间交换的东西变小了:检查一个分布式 KV cache 里有没有某条记录、在一轮计算结束后做屏障同步,都是几十到几百字节的小消息。这种场景下,决定体验的不是吞吐,是往返时延——把一小段数据发出去、算一下、结果传回来要多久。更精确地说,真正决定体验的是尾延迟:P99 延迟,也就是一百次请求里最慢那一次要多久。计算阶段是 5 秒、同步只花几毫秒的时候,没人会在乎。但 agent 工作负载要求以毫秒级节奏吐出 token,计算阶段本身已经压到了毫秒级,这时候同步哪怕多花几毫秒,GPU 就只能干等,浪费的是实打实的算力。他在现场做了个举手调查,问是否有人观察到小消息延迟拖累了应用吞吐,举手的人比他预期的多。

拥塞控制这道题,TCP 和 RDMA 从设计上就没打算做好

尾延迟差的根源通常是拥塞,具体表现叫 incast:好几台机器同时把数据发向同一个目的节点,链路带宽是对称的,三个节点同时发送就是接收端处理能力的三倍,包会在最后一跳交换机的出口队列里堆积。这时如果有个短消息也要发去同一个目的地,它会堵在长消息后面排队,运气不好还会撞上交换机缓冲区溢出丢包,触发超时重传,情况更糟。

解决思路是让发送端知道该收着点发。TCP 和 RDMA(Ousterhout 说的 RDMA 其实特指 RoCE,也就是跑在以太网上的 RDMA)走的都是发送端做拥塞控制这条老路:早年靠丢包间接判断有没有拥塞,现在靠交换机在队列快满时给经过的包打上 ECN 标记,标记随确认包传回发送端,发送端才知道该减速了。问题是发送端离拥塞真正发生的地方很远,只能拿到”有没有拥塞”这一个比特的信息,场上还有好几个发送端同时在猜该怎么调,等它们摸清楚该降多少、什么时候能再升回去,网络里的情况早就变了。这套机制天生带着控制延迟,很难稳定下来,大多数时候都在发送过多和发送过少之间来回震荡。

TCP 和 RDMA 还有一个结构性问题:它们的数据模型是字节流,没有消息边界。TCP socket 会把一串消息打包成一条连续的字节流,两个大消息后面跟一个小消息,小消息会卡在同一条流里排在大消息后面,这就是队头阻塞——协议压根不知道消息在哪里断开,想优先处理短消息都做不到。

Homa 把发送端和接收端的角色倒过来

Homa 是一次彻底的白纸重来,几乎每个关键设计都跟 TCP、RDMA 反着来。它最初是 Ousterhout 学生 Behnam Montazeri 的博士课题,结果好到他决定亲自下场,把它变成自己现在的主业——他形容自己已经”半退休”离开斯坦福教职,就是为了能把 100% 时间投进 Homa。目前 Homa 已经做成了 Linux 内核模块,代码在 GitHub 上开放,他本人正在推动把它并入内核主线。

第一处不同:Homa 是消息级协议,不是字节流协议。它的基本单元是一次 RPC,一个请求消息加一个响应消息,协议从头到尾都知道消息有多长。接收端收到第一个包就知道后面还有多少数据要来,这个信息拿来做拥塞控制比 TCP 精确得多。Homa 还用了 SRPT 调度(最短剩余处理时间优先,说白了就是谁剩的活少谁先走)给短消息让路,各个消息互相独立,短消息可以直接绕过排在前面的长消息,不会卡住。

更关键的一处,是 Homa 把拥塞控制这件事搬到了接收端来做。这个思路其实很直觉——拥塞真正发生的地方是最后一跳到接收端的链路,接收端天然掌握更完整的信息。Homa 的做法是发送端先只发前几个”非受控包”,后面的”受控包”要等接收端主动发”许可包”才能发出去。接收端可以压着许可包不马上发,借此直接控住队列长度,也可以优先给短消息发许可,相当于用许可机制把 SRPT 落到了实处。

最后一点,Homa 还用上了现代交换机自带的多级优先队列(一般有 8 级),把短消息塞进高优先级队列。回到前面 incast 的场景,一堆大消息挤在最低优先级队列里排队,短消息走高优先级队列,直接插队冲到接收端,不用排在大消息后面等。

13 倍和将近 2 倍

Ousterhout 展示了一组自己做调优用的基准测试:一堆机器互相交换从 50 字节到 1MB 不等的消息,横轴是消息长度,纵轴是往返时间,同时画出 P50(中位数延迟)和 P99(尾延迟)两条曲线,TCP 是绿色,Homa 是蓝色。

第一个结果:短消息的 P99 尾延迟,TCP 超过 1 毫秒,Homa 不到 100 微秒,快了大约 13 倍。换算到实际场景里——如果一次分布式推理里有成百上千次这样的小同步,TCP 路径上总会有几次撞上那条超过 1 毫秒的尾巴,GPU 就得等在那里,Homa 几乎不会遇到这种情况。第二个结果更反直觉:Homa 明摆着偏袒短消息,按理说长消息应该吃亏,但实测下来即便是最长的消息,Homa 也比 TCP 快了将近一倍。原因跟 Homa 用的是”跑到完成”的调度策略、而不是 TCP 那种”公平调度”有关,他没有细讲,但结论很直接:给短消息让路不等于牺牲长消息。

这场分享在当天议程里的位置

这场排在当天(官方 Day 4,收尾日)主舞台 9:20 到 9:40 这个二十分钟档期,前一场是 Barr Yaron 主持的年度问卷开场,后一场是 DSPy 团队讲怎么把任务和模型分开优化,两边都挂在 Harness Engineering 这条线上,讲的是 agent 怎么用工具、怎么管上下文、怎么控制权限。Ousterhout 这场单独挂在 Software Factories track,往下扎进了数据中心网络协议层,跟前后两场几乎不在同一个抽象层次上说话。

这个位置本身就是个信号。当天大部分分享都在往上堆 harness 这层的能力,agent 怎么规划、怎么记忆、怎么接受审计,但推理和 agent 工作负载的新流量模式,同样在推着支撑这些能力的网络层变。KV cache 查询、屏障同步这类小消息交换,就是”多机协作”在网络层的投影——这层跟不上,上层设计得再精巧,也只能卡在几毫秒的同步延迟里干等。

我的判断

Homa 本身还只是 GitHub 上的一个 Linux 内核模块,没有进内核主线,早期采用有风险。这场分享真正该记住的,是他给出的诊断路径:先别急着换协议,先去测一下自己的推理或 agent 流水线里,短消息的尾延迟是不是真的在拖累吞吐。这个问题此前多半当成”小事”被忽略,现在随着 agent 工作负载把计算阶段压到毫秒级,一次几毫秒的同步延迟就可能吃掉相当比例的 GPU 时间。测出来真卡在这,Homa 是现成能试的方案;没卡在这,TCP 和 RDMA 目前也还够用。