Meta 8 月 24 日公开了 MetaRoCE 的设计细节。这是它自己做的一套 RDMA 传输协议，用来替掉标准 RoCE。10 月的 OCP 全球峰会上，完整协议规范、一个叫 libsoftmetaroce 的参考实现和一套生产合规测试集会一起放出来。
标准 RoCE 在十万卡规模上撑不住
RoCE 的设计前提是网络把每一帧按顺序送到，靠交换机上的 PFC（优先级流控）保证不丢包。这套假设在几百张卡的集群里跑得挺好，到了 Meta 现在的规模就开始漏。
Meta 的原话是，标准 RoCE 期望网络按序交付每一帧、依赖 PFC，并且不鼓励包喷洒——而包喷洒恰恰是多平面大规模网络里提升性能的手段。冲突就在这儿：把一条流的包同时打到多条路径上，跟”按序交付”直接对立。PFC 又是逐跳背压，一处拥塞会一路顶回去，超大规模下容易连锁。而 all-reduce 这类集合通信要同步上千个加速器，最慢的那条传输决定整个作业的节奏。
Meta 提到的目标场景是”分布在多个数据中心和地域的几十万张 GPU”。这个量级下，靠交换机维持无损网络已经是在跟概率对赌。
智能挪到网卡
MetaRoCE 的设计原则被浓缩成一句话：
“The fabric sees packets, but the NIC sees intent.” 交换网只看得见包，网卡才知道意图。
落地成六条：原生乱序交付，包故意喷洒到多条路径，数据直接写进目标内存地址，不设重排序缓冲；原生多路径，每条连接维护多条逻辑路径，各自跟踪往返时延和 ECN 状态；容忍丢包，把丢包当常态，用选择性确认位图补齐，不需要 PFC；双重拥塞控制，发送端 AIMD 加接收端的公平份额速率提示；拓扑无关，只要求 ECN 标记和 ECMP，胖树、多平面、浅缓存交换机都能跑；统一连接，单个队列对承载多条有序消息流和多条路径，共用一个拥塞控制器。
64 节点上的数字
实测跑在一个 64 节点的 AMD GPU 集群上。吞吐持续高于 RoCEv2；1% 丢包率下保住约 86% 的吞吐，10% 丢包下仍可工作；4 平面和 8 平面拓扑下吞吐线性扩展，最多测到 4000 条并发连接；单个平面失效时流量自主重新分配，应用层不用介入。
64 节点跟”几十万张卡”之间还有很长的路，Meta 自己把后续工作分成三块：机架内的 scale-up 要优化短内存操作的快速信令，去掉重排序缓冲和 PFC 带来的延迟；上千公里级的 scale-across 要在毫秒级往返的长途链路上做逐路径自适应和公平性；存储与 KV 缓存场景则打算用接收端速率提示对付一次读取扇出到多台服务器的 incast。
开源这一步是给网卡厂看的
网卡侧目前只有 AMD Pensando 是已验证的实现，其他几家在做。这一条决定了 MetaRoCE 能走多远——协议再漂亮，落不进主流网卡的固件里，它就只是 Meta 的内部方案。
放到 OCP 开源、并且明确对齐 ESUN（以太网可扩展统一网络）倡议，意图很清楚：让网卡厂按这个规格出货，Meta 自己的采购面才会宽。这条路以太网阵营走过一次——当年 RoCE 能从 InfiniBand 手里啃下份额，靠的就是以太网生态便宜、供应商多。现在 RoCE 自己成了瓶颈，Meta 想用同一个套路再来一轮：先把规范摊到桌面上，让所有人跟着做。
对国内做智算中心的团队，10 月那份规范出来之后可以对着看看，尤其是”不需要 PFC”这一条。省掉 PFC 调优，运维上就少了一个最难缠的问题源。
参考来源：Meta 工程博客、CocoLoop、OCP ESUN 相关材料；1% 丢包下约 86% 吞吐、10% 丢包仍可工作、64 节点 AMD GPU 集群与 4000 条并发连接等测试口径均按 Meta 公开的实测描述核对。