AI Ethernet：UEC、ESUN、SUE-T 与端到端 Fabric 的完整分层

1. 问题定义：AI 流量为什么逼迫 Ethernet 分层演进

传统数据中心网络经常承载相对独立的 RPC、存储和前端流量。AI 训练与推理新增了高度同步的 collective、MoE all-to-all、长上下文 KV 转移以及加速器间的高频小消息。它们一旦在局部形成 incast，就会让最慢 rank 或最慢请求决定整体进度。

AI fabric 要同时控制 goodput、P99、拥塞传播、错误恢复和可观测性。端口速率只给出链路上限；一个可部署的通信方案还要说明端点如何发包、交换网络如何处理拥塞，以及应用如何观察完成与失败。

2. 分层地图：不要把标准名称当成一个协议栈

UEC、ESUN、SUE-T、UALink 等名称分布在不同层或不同互联路线。最常见的误解是把它们都当成“又一种网卡”。实际上一个端到端系统需要同时回答：端点提供什么可靠性/排序服务，网络转发什么帧和拥塞信号，运行时怎么根据拓扑选择路径与算法。

3. 数据面与控制面：AI Ethernet 不能只看 packet

数据面搬运 activation、token、KV、gradient、权重或存储块；控制面维护 membership、地址/密钥、队列、credit、topology epoch、路由策略和健康状态。小的控制消息往往决定大数据能否正确发出：没有 buffer advertisement 或 credit，发送方应等待；模型版本发生变化后，旧数据不应再被提交给新 worker。

这也是为什么“交换机没有 drop”并不能证明服务正确：目标端的 KV page 可能已经被回收，或者 runtime 的 communicator 已经因 rank 故障重建。反过来，控制面极其严格但每次传输都走 host 同步，也会把 token 关键路径拖慢。

4. UEC：面向 AI/HPC 的端到端传输服务框架

Ultra Ethernet Consortium 的公开规范历史将 AI/HPC 场景中的传输服务、拥塞控制、路由与可靠性作为系统接口。它的价值在于将“可靠但无序”“可靠且有序”“无序 best-effort”等语义显式化：不同工作负载不必强迫使用同一种最重的服务，也不能把需要顺序的元数据误放到不提供该保证的路径。

UEC 一类规范要求软件公开自己的传输假设：操作是否幂等、重传是否安全、目标 buffer 何时可见、拥塞反馈如何影响发包速率，以及 ECMP/多路径怎样维持可接受的顺序与公平性。runtime 可以据此将 TP、EP、KV 和后台 I/O 分配给不同服务等级。

5. ESUN：交换网络侧的 scale-up Ethernet 职责

OCP 对 ESUN 的公开说明将其聚焦在标准化 Ethernet switching 和 framing：网络如何转发、处理错误、提供无损/低延迟传输，并在单跳或多跳 scale-up 拓扑中控制拥塞。它刻意不把 host-side stack、应用协议和非 Ethernet 互联都包进自己的范围。

2026 年公开的 ESUN 1.0 资料强调可靠无损 Ethernet、链路级 retry、拥塞管理、紧凑报头和多跳 scale-up。对部署者而言，这意味着交换网络会更理解 AI 流量的需求，但它不会替 runtime 选择 TP group、解决 MoE expert 热点或为 KV 定义提交事务。网络能力与软件调度必须同时到位。

6. SUE-T：端点/XPU 与网络之间的 transport 契约

OCP 的 SUE-T 工作流将 scale-up Ethernet 的端点部分与 ESUN 的网络部分区分开。端点侧关心的是 workload partition、memory ordering、负载均衡、NIC/XPU interface 和 transport 语义；网络侧关心的是 switching、framing 与错误/拥塞处理。这个拆分符合实际系统：同一网络可承载不同端点实现，而端点也可能面对不同的拓扑。

对系统软件而言，SUE-T 风格的接口提醒我们不要把“硬件能直连”误等同于“应用自然正确”。一次 remote write 需要明确目标地址、访问权限、完成事件与 buffer 生命周期；一次多路径发送需要定义重排/重复处理；一次端点故障需要让 communicator 和路由器看到可操作的健康状态。

7. UALink 与 Ethernet 路线：比较边界，而不是制造替代关系

UALink 是面向 accelerator scale-up 的开放互联生态；OCP 与 UALink 的公开协作公告强调其服务 AI/HPC 高带宽、低延迟、低功耗互联的目标。它和 Ethernet-based 方案在使用场景上可能相交，但协议层、端点实现、可用硬件和部署生命周期不必相同。

比较这些路线时，应考察紧耦合内存/通信域的规模、端点与软件栈的可移植性、拓扑和故障域的表达、collective 的有效带宽与 P99，以及它们同现有 scale-out、存储和控制网络的协作方式。“开放对专有”或“Ethernet 对非 Ethernet”的二分法会漏掉实际选型中的运行时和运维成本。

8. 拥塞与可靠性：端点、交换机和应用各自的闭环

端点需要基于 credit、拥塞反馈、deadline 和队列深度调节注入速率；交换机需要处理队列、标记、流控、路径和链路错误；应用需要定义什么可以降级、重传或迁移。若只使用 PFC 一类机制而没有流量分类、缓冲预算和端点节流，短 burst 可能扩大为 pause storm。若只让端点盲目重传，恢复流量也可能淹没网络。

发送资格 =
  receiver_credit > 0
  AND route_healthy
  AND congestion_window / rate_budget allows
  AND request_deadline has remaining budget

失败后：
retry only if operation is idempotent and epoch still matches;
otherwise abort, release, and re-route.

TP/EP 的同步路径常需要快速失败和 group 重建；KV 预取可容忍丢弃并重新取数；checkpoint 更关心持久化和吞吐。把这三类流量放在一个无区分的可靠服务中，既浪费性能也难以提供正确的恢复语义。

9. 拓扑与消息形状：AI Ethernet 不会消除物理限制

每个 GPU/NIC 的亲和性、每个 rail 的上/下行、leaf-spine 的收敛比、ECMP 哈希和光链路质量，都会决定实际 effective bandwidth。TP 的小且频繁的 collective 更看重最短路径与低启动延迟；EP 的 all-to-all 更看重双向 bisection、均衡的 expert placement 和避免 incast；KV/存储流更看重背压、队列隔离和可观测 P99。

多平面或多 rail 能提高容错与容量，但前提是软件知道每个 rank 对应哪张 NIC、每条 communicator 选哪条 rail、故障后如何避免集中到剩余路径。网络设备配置与 runtime placement 若独立演化，最终会得到“布线对称、流量不对称”的集群。

10. 性能模型：从端口线速到应用 goodput

端口速率是理论上限。端到端 goodput 还会被 header/packetization、DMA、NIC queue、交换 buffer、拥塞反馈、collective 算法、GPU pack/unpack 和最慢 rank 的同步扣减。一个设计若在大块单流传输上很好，也可能在 decode 的小消息或 MoE 的不均匀 all-to-all 上表现很差。

评估必须画出 message size × concurrency × topology 的曲面，而不是一个单点数字。还要把网络测试嵌入真实模型：如果 comm 与 GEMM 争抢 SM 或 HBM，网络带宽增加不一定转化为更低 token latency。

11. 部署例子：64 GPU MoE 服务怎样使用 Ethernet fabric

假设 8 个 8-GPU 节点组成 64 GPU 服务。每个节点先保留 TP8 在强互联域内，EP 跨节点形成 group。部署时先生成 GPU-NIC-rail 映射，使每个 rank 的跨节点 token 流量有可预测的出口；为 EP all-to-all、KV transfer、checkpoint 配置独立的队列/速率预算；router 把 KV transfer 目的地与 NIC 健康、credit 和模型 epoch 一起考虑。

当一个 rail 出现错误时，健康控制面将其从新请求映射中移除；已有 communicator 根据库与部署策略重建或降级；KV 的未提交 block 被 abort；后台 checkpoint 降速，让 decode 保留预算。这个 64-GPU 例子用来检查每条快速路径的性能和故障行为，并不规定必须采用哪一种标准。

12. 观测与故障：网络可见性必须进入模型运行时

最小观测集应包括每个 collective/transfer 的 bytes、发起与完成时间、route/rail、NIC queue 与重试、交换端口水位与标记、GPU stream wait、模型 TBT/TTFT。若只有设备层的平均 utilization，就无法判断一个异常究竟来自 expert hotspot、坏光模块、ECMP 偏载、端点 CQ 堵塞还是路由器把大量 KV 发向同一 decode pool。

故障演练也应跨层：拔掉一条 uplink、使一个 NIC 降速、让目标 worker 拒绝 credit、注入模型 epoch 切换、制造 KV burst。验收标准是请求能否在定义的 SLO 内降级或重路由，buffer 是否被正确回收，控制面是否能阻止旧版本数据重新可见。

13. 2026 公开状态：标准在收敛，部署仍需逐层验证

OCP ESUN 1.0 已公开发布；OCP 网络项目将 ESUN 和 SUE-T 作为独立工作流展示；UEC 公开 1.0.2 版本历史；OCP 也在 2026 年发布面向 AI inference fabric 的参考架构。它们为开放 AI networking 提供了共同语言：端点、网络、拓扑、可靠性和运维不再由单一设备文档各自定义。

但“公开标准存在”不等于“所有硬件、NIC firmware、通信库和应用 runtime 已完全互操作”。生产团队应将标准作为 design review 的检查表，并在目标硬件、目标模型和目标流量上做 microbenchmark、混合负载、故障注入与滚动升级验证。

14. 实施检查表：把抽象标准落到可运行的集群

1. 画出每种 AI 流量的消息大小、频率、语义和 deadline。
2. 从硬件发现生成 GPU-NIC-switch 拓扑，不依赖手工假设。
3. 明确每类流量所需的排序、可靠性、重试和幂等语义。
4. 为 EP、KV、存储建立队列/credit/QoS 边界，避免后台流量抢占 decode。
5. 把 rail 选择、拥塞、错误、模型 epoch 和 request trace 关联起来。
6. 在扩容前运行同机架、跨机架、故障与混合流量测试。

15. 与 Mainline 和相关文章索引的连接

16. 来源与版本边界