本文初稿主要由 ChatGPT 生成；已于 2026 年 10 月 10 日按公开资料核查和更新。文中的产品状态以厂商公开披露为准，不能直接等同于跨厂商互操作或大规模部署。

现在的光通信技术发展的怎么样？在数据中心中 RoCEv2 还是事实标准吗？RoCEv2 被替代的时间表有预期吗？

截至 2026 年 10 月 10 日，可以把数据中心光通信和高性能网络的状态概括成一句话：

高速端口正从 800G 向 1.6T 扩展，CPO 与可插拔光模块并行发展；AI 以太网的 RDMA 传输也出现 UET、MRC 等多路径方案，但 RoCEv2 仍在使用。

光通信：现在处在 800G → 1.6T 的换挡期

在高端 AI 网络中，400G 已很成熟，800G 广泛用于新建高速链路，1.6T 的器件已经进入出货和互操作展示阶段。Marvell 称其 1.6T Ara 光 DSP 已批量出货；Ethernet Alliance 公布的 2026 年 9 月 ECOC 多厂商展示方案涵盖 1.6T OSFP 和 224G SerDes。这些进展不等于所有 1.6T 链路都已完成标准化和大规模部署。截至 10 月 10 日，包含 1.6TbE 的 IEEE P802.3dj D3.3 正处于第 3 次 Standards Association 复审投票，截止日期为 10 月 10 日 AOE，尚不能称为正式发布的 IEEE 标准。Marvell · Ethernet Alliance · IEEE 802.3 投票公告

当前常见的 1.6T 光模块方案之一是：

8 × 200G/lane → 1.6T

也有不同的电接口与复用方式，不能把 8 × 200G 当作唯一实现。Marvell 已推出 200G/lane 的 1.6T PAM4 DSP，并在 2026 年扩充产品线。Marvell · Ethernet Alliance 2026 路线图

但我觉得比单纯“800G → 1.6T”更重要的变化其实是光器件正在越来越靠近交换 ASIC / XPU。

传统路径大致是：

ASIC → 板级高速电连接 → 模块内 DSP → 前面板光模块 → 光纤

到了 200G/lane，这段高速电连接越来越耗电，也越来越难做。所以现在出现了几条并行路线：

技术	2026 年状态	核心想法
Retimed pluggable	仍是主流	光模块里放 DSP，信号质量最好，但功耗高
LRO / LPO	快速发展	减少甚至去掉模块 DSP，降低功耗
TRO 等中间路线	开始产品化	只在部分方向 retime，折中功耗与信号完整性
CPO	已有产品送样和生产公告，部署规模仍需区分	光引擎集成在交换 ASIC 附近
Optical I/O	更前沿	将光学 I/O 集成到 XPU 等芯片封装附近
光学 scale-up	规范与产品探索中	用光链路扩展 XPU 之间的 scale-up 网络

可插拔光模块仍是重要方案，LPO/LRO、TRO 和 CPO 则针对不同距离、功耗及维护需求并行发展。Broadcom 已公布 TH6-Davisson CPO 交换芯片并向早期客户送样；NVIDIA 称 Spectrum-X Ethernet Photonics 已进入生产，官网标注 2026 年下半年可用。这些厂商公告说明 CPO 已走出纯研究阶段，但不能据此推断其已成为市场主流。Broadcom · NVIDIA · Ethernet Alliance

所以未来几年的主线其实不是单纯：

400G → 800G → 1.6T

而是：

电互连距离不断缩短 + 光不断向计算芯片靠近。

scale-up 网络也在探索光互连。2026 年 AMD、Broadcom、Meta、Microsoft、NVIDIA、OpenAI 等成立了 Optical Compute Interconnect（OCI）MSA，目标是制定开放的光学 scale-up 互连规范；这仍是标准制定和生态建设，不能理解为统一产品已经部署。Broadcom

那 RoCEv2 现在是不是事实标准？

如果把范围限定为：

Ethernet-based AI/HPC scale-out 网络

答案是：RoCEv2 仍是成熟且广泛采用的选项，但不能据此断言所有新建集群都默认选择它。

但不能扩展成“整个数据中心的标准协议”。

普通数据中心业务流量还是 TCP/IP 为主；NVIDIA AI/HPC 还有相当大的 InfiniBand 市场；GPU 机内或 rack-scale 的 scale-up 又是 NVLink、UALink 等另一套协议。

如果现在建设 Ethernet GPU 集群，RoCEv2 仍是可以采购和部署的 RDMA 方案。NVIDIA 的 ConnectX-9 文档继续列出 RoCE 支持，Broadcom 的 400G AI NIC 也列出 RoCEv2。与此同时，NVIDIA 公开提供 MRC，Broadcom 的 Thor Ultra 800G NIC 则声明支持 UEC 特性；产品选择正在分化。NVIDIA ConnectX-9 文档 · Broadcom 400G NIC · Broadcom Thor Ultra

UEC 的规范在介绍传统网络时，也描述了以下常见组合：

RoCEv2 + ECMP + ECN/DCQCN（网络中也可能同时承载 TCP 流量）

这一套模式。它是传统方案的概括，并不是说每套 RoCE 网络都必须启用 PFC 或采用 DCQCN。UEC 规范 · NVIDIA 的 RoCE 网络配置示例

所以如果问：

“2026 年建一个 AI Ethernet cluster，还会不会用 RoCEv2？”

答案是：会，RoCEv2 仍是可行且常见的选择；具体采用率没有可核实的统一统计。

为什么大家又都在想办法替代 RoCEv2？

因为传统 RoCEv2 部署面临的主要挑战并不是协议规定的“带宽上限”，而是负载均衡、拥塞与丢包恢复在超大规模 AI 网络中的效率。

采用静态 ECMP 的经典 RoCE 网络可以近似为：

RDMA connection
      ↓
single path / ECMP hash
      ↓
DCQCN
      ↓
PFC / near-lossless Ethernet（常见部署方式之一）

三个问题越来越突出。

第一是 ECMP 的 flow collision。

静态 ECMP 通常把同一条流哈希到某一条路径：

Flow A ───────── Path 1
Flow B ───────── Path 1  ← collision
Flow C ───────── Path 3
Path 2 ───────── idle

网络可能总带宽很多，但某些链路拥塞，某些链路空闲。

第二是 RoCE 对丢包和乱序处理并不优雅。

传统 RoCE Reliable Connection 在丢包时可能触发较大范围的重传；乱序也会增加实现复杂度。因此不少部署使用 PFC、ECN、DCQCN 等机制来减少拥塞与丢包，但 RoCEv2 不等于必须配置无损网络：厂商也提供有损 RoCE 的配置方案。UEC · NVIDIA

PFC
ECN
DCQCN
buffer tuning
queue tuning

这些机制需要按拓扑、缓冲和流量模式设计与调优。

UEC 对传统方案的批评集中在这里：大型近无损 RoCE fabric 可以做好，但需要大量调优、监控和工程经验。Ultra Ethernet Consortium

第三，也是 AI 最关键的一点，是流量模式已经变了。

传统数据中心很像：

A → B
C → D
E → F

AI collective 更像：

GPU0 ─┐
GPU1 ─┼── 多对多或多对一通信
GPU2 ─┤   AllReduce / All-to-All 等
GPU N ─┘

成千上万个 accelerator 同时爆发通信。

这使得 tail latency、incast、路径利用率远比以前重要。

UET：为 AI/HPC 重新设计的以太网传输

Ultra Ethernet Consortium 的 UET（Ultra Ethernet Transport） 是 RoCEv2 之外一个重要的新传输方案。

UEC 1.0 于 2025 年 6 月 11 日发布；截至 2026 年 10 月 10 日，规范历史页列出的最新公开版本是 1.0.3（2026 年 7 月 16 日）。1.0.3 的发布说明列出新增 200 Gb/s 每通道信号支持，以及若干协议修正。UEC 规范历史 · 1.0.3 发布说明

它不是简单的：

RoCEv3

实际上它把不少核心假设都换掉了。

最重要的是 packet-level multipathing / packet spraying：

               ┌── Path 1 ──┐
GPU A ─ NIC ───┼── Path 2 ──┼── NIC ─ GPU B
               ├── Path 3 ──┤
               └── Path 4 ──┘

在启用 packet spraying 的模式下，同一通信的报文可以利用多条路径；规范也保留单路径模式，并非所有 UET 流量都必须逐包分散。

UET 支持根据拥塞反馈调整路径选择，并设计了：

packet spraying、灵活的顺序语义、发送端拥塞控制和遥测。接收端信用控制与交换机 packet trimming 是可选机制，不能把它们写成所有 UET 实现的必备功能。UEC 技术说明 · UEC 规范

而且一个非常重要的变化是：

UET 的拥塞控制以 best-effort（允许丢包）的以太网为设计目标。

这降低了对全网近无损配置的依赖，但仍需拥塞控制和可靠性机制。RoCEv2 本身也可以部署在有损网络上，所以区别在于对丢包、乱序和多路径的处理方式，而非“能否丢包”这个二选一问题。UEC 规范 · NVIDIA RoCE 配置示例

这是我认为 UET 比“800G → 1.6T”更深层的变化。

但现在还不能说 UET 已经取代 RoCE

因为目前实际上正处在：

RoCE 成熟部署期 → UET 产品化初期

这个交界点。

Broadcom 已发布宣称符合 UEC 规范的 Thor Ultra 800G AI NIC；Marvell 展示了交换芯片上的 packet trimming、自动负载均衡与 UET 相关验证；VIAVI 于 2026 年 6 月推出 UET 验证方案。UEC 也已公开合规测试资料。这些是产品和测试生态推进的证据，尚不足以证明 UET 已大规模替代 RoCEv2，或不同厂商产品均已完成互操作验证。Broadcom · Marvell · VIAVI · UEC 合规资料

UEC 在 2025 年底描述 2026 年工作重点时，强调帮助行业实施规范、提供教育材料和编写应用指南。

结合目前公开的产品和验证资料，更稳妥的判断是：UET 仍在标准落地和产品导入阶段。Ultra Ethernet Consortium

而且现在又出现了一个很有意思的变量：MRC

2026 年 NVIDIA 又公开了 MRC — Multipath Reliable Connection。

它也是一个 RDMA transport，核心同样是：

one RDMA connection
        ↓
multiple paths

而不是传统 RoCE/ECMP 的单路径思路。

NVIDIA 表示 MRC 已在 Spectrum-X 上用于生产环境；Open Compute Project 也发布了 MRC 规范，贡献方包括 AMD、Broadcom、Intel、Microsoft、NVIDIA 和 OpenAI。开放规范与单一平台的生产使用，不等于跨厂商互操作已普遍实现。NVIDIA · OCP MRC 规范

所以现在真正的局面实际上变成了：

                 Ethernet AI fabric
                        │
           ┌────────────┼────────────┐
           │            │            │
        RoCEv2         UET          MRC
           │            │            │
      成熟/广泛       UEC规范/导入中  OCP规范/已有生产案例

而不是一个很简单的：

RoCEv2
   ↓
 UET

NVIDIA 表示 Spectrum-X 可运行 Adaptive RDMA、MRC 和其他定制传输。这也说明，多路径与自适应路由能力不能简单归结为“RoCE 全无、UET/MRC 才有”。NVIDIA

因此，“RoCEv2 什么时候被替代？”目前没有官方时间表

没有类似：

2028 年 RoCEv2 EOL

这样的行业路线图。

公开资料不足以支持把 2027–2030 年划成具体替代阶段。更有用的是观察以下可验证的节点：

节点	目前能确认的状态
规范	UEC 1.0.3 与 OCP MRC 规范已公开
设备	已有支持新传输的 NIC、交换机公告和验证方案
互操作	需继续看跨厂商一致性测试及公开结果
部署	需看可复核的规模部署、运维经验和软件生态支持

因此，无法给出 RoCEv2 被 UET 或 MRC 替代的可信年份。新建集群可能采用不同传输，既有集群也可能长期继续使用 RoCEv2；这是依据现有产品与部署信息作出的判断，而非公布的行业路线图。UEC 规范历史 · UEC 合规资料 · OCP MRC 规范

原因很简单：网络协议的存量效应非常强。

RoCEv2 已经有成熟的实现与运维生态，例如：

NIC firmware
Linux RDMA stack
verbs API
NCCL / MPI 中的 RoCE 后端或部署
NVMe-oF 的 RoCE 部署
Kubernetes RDMA 设备与网络配置
cloud infrastructure
monitoring / debugging tools

但 verbs、NCCL、MPI、NVMe-oF 等接口或框架本身并不与 RoCEv2 绑定；它们的存在不能单独证明 RoCEv2 的未来份额。

可能出现的并存格局是：

既有集群：RoCEv2
新建集群：RoCEv2 / UET / MRC（取决于设备和软件生态）

新传输能占多大比例，还取决于互操作、软件适配、性能和运维成本。

真正值得关注的是网络设计的变化

这个区分很重要。

RoCEv2 仍会被使用多久，目前无法准确预测。

但下面这种设计：

one flow → one path
lossless fabric
PFC
ECMP
DCQCN
careful tuning

正受到多路径、改进的拥塞控制与恢复机制挑战。这只是对传统部署模型的概括，不代表所有 RoCEv2 网络都严格采用这一组配置。

一些新一代 AI Ethernet 方案正在探索或采用以下能力：

multi-path
packet spraying
loss tolerant
adaptive congestion control
telemetry
selective / efficient retransmission

换句话说，未来不一定是：

Ethernet 打败 InfiniBand

或者：

UET 打败 RoCE。

更准确的技术趋势是：

Ethernet 正在吸收很多以前专用 HPC fabric 才有的能力，同时重新设计 RDMA transport。

从当前公开进展看，未来几年值得持续观察的变化包括 800G → 1.6T、CPO/硅光、多路径 RDMA，以及 NVLink、UALink 和光学 scale-up。它们处于不同成熟阶段，不能合并成一条确定的替代时间线。

如果你是从网络/系统方向的职业或技术学习角度问这个问题，那么我会特别建议把注意力从“记住 RoCEv2 配置方法”稍微上移一层，重点理解 ECMP、PFC、DCQCN、packet spraying、incast、tail latency、UET congestion control 和 scale-up/scale-out 的区别。这些概念在接下来几年比某一个具体协议名更不容易过时。