当所有人都在讨论 GPU 数量和模型规模时，真正卡住 AI 集群的可能是那条跑了四十年的传输层协议。

发生了什么

Hacker News 上出现一场题为《Homa: The End of TCP for AI Clusters》的分享，讨论用 Homa 协议替代 TCP 作为 AI 集群内部的数据中心传输协议。Homa 并非新概念，它来自学术界对数据中心网络的长期研究，核心思路是重新设计传输层，使其适配现代数据中心「低延迟、多对一、短消息密集」的流量特征，而不是继续沿用为广域网和互联网拥塞场景设计的 TCP。这场分享的价值不在于发布某个新产品，而在于把「AI 集群的网络栈需要换血」这一议题重新推到工程社区的视野里。

为什么重要

TCP 诞生于一个完全不同的假设世界：链路不可靠、带宽稀缺、端到端路径漫长、丢包意味着拥塞。它用慢启动、拥塞窗口、重传超时等机制换取鲁棒性，代价是延迟和 CPU 开销。而 AI 集群的典型场景恰恰相反——网络拓扑可预测、链路质量高、通信模式高度规律。

更关键的是 AI 负载的流量形态变了。分布式训练中的 AllReduce、参数同步、梯度交换，以及推理场景下的 KV Cache 传输和专家路由，都会产生大量「多对一」的突发小消息。这类流量在 TCP 下容易触发 incast 问题，队列堆积、尾延迟飙升，最终表现为 GPU 利用率上不去——算力在等网络。

RDMA 和 InfiniBand 是业界已有的应对方案，但它们成本高、生态封闭、运维复杂。Homa 代表的是另一条路径：在通用以太网和普通网卡上，通过更贴合数据中心语义的传输层设计，逼近专用网络的性能。这对希望用开放生态构建大规模集群的团队尤其有吸引力。

影响与看点

对基础设施团队而言，这意味着网络栈重新成为一个值得投入的优化维度。过去几年算力优化的注意力集中在算子、并行策略、显存管理上，网络层常被当作既定条件接受。如果传输层协议本身可以重构，那么集群的有效算力上限、训练任务的扩展效率、以及单位算力的成本曲线都会被重新定义。

对开发者的直接影响相对间接但真实：如果底层协议演进成熟，上层框架的通信原语、集合通信库、甚至并行策略的设计空间都会变化。今天很多工程妥协——比如梯度压缩、通信与计算重叠的复杂调度——本质上是在为传输层的低效买单。

值得关注的几个点：一是 Homa 这类协议从论文走向生产部署的成熟度，包括与现有网卡、交换机、容器网络的兼容性；二是主流云厂商和 AI 芯片厂商是否会跟进支持，生态决定成败；三是它和 RDMA over Ethernet 等既有路线是竞争还是互补。

一个克制的判断：TCP 不会真的「终结」，但在 AI 集群这个特定场景里，它作为默认选择的合理性正在被系统性地质疑。这场讨论的意义，是提醒行业——当算力投资达到数十亿美元量级时，那条被默认继承的软件栈，可能才是最便宜的优化机会。