OCP2026｜Tahan与ESUN
以太网Scale-up产品先行，开放互通仍待验证
2026年OCP大会上，开放Scale-up有三项不同性质的进展：Tahan正在出货，服务Meta MTIA 300系统；下一代72加速器机架进入公开预览；ESUN在年内发布1.0基础规范之后，继续推进后续版本。它们让以太网进入加速器紧耦合互联的路线更加具体，但还没有合并为一套已经采用ESUN、可任意混搭加速器的产品。[1]
这一区别决定了本届发布应该怎样读。Tahan回答以太网今天能怎样进入一个具体加速器系统；72加速器方案回答下一代交换芯片怎样扩大机架规模；ESUN回答不同实现能够共同依照什么网络要求建设。对规划超节点的CTO，值得关注的是三者开始接近，而不是把最先进的规范、最大的机架和当前产品的交付状态拼成一张不存在的规格表。
Tahan以现有传输服务Meta MTIA
Tahan使用Broadcom Tomahawk 5交换芯片，四台交换机连接16个MTIA 300加速器，形成非阻塞互联。Meta将其状态表述为“shipping today”，本文据此使用“正在出货”，并限定在其服务Meta加速器的产品语境中。这个表述说明产品已经进入出货阶段，不代表某项交付全部完成，也不证明它已经面向所有客户普遍商售。芯片容量与接口配置的详细口径见文末技术说明。[1]
Tahan没有先等待一套全新的端到端协议栈。它复用现有RoCE传输及配套的路由、流控和流量管理机制，并由FBOSS管理。这是把已有以太网工程基础延伸进Scale-up的路线：先围绕自有加速器建立确定的系统边界，再逐步优化协议开销和网络行为。它可以复用已有技术资产，却不意味着把一台普通数据中心交换机插进GPU机架，就能获得同样的结果。
对于自研加速器团队，这条路线有现实吸引力。交换芯片、网络操作系统和运维工具不必全部从零建立，硬件团队可以把更多工程资源放在端点、背板与通信软件上。对于采购第三方加速器的企业，则必须看到另一面：Tahan与MTIA的配合证明了一套具体实现成立，尚不能替任意两家加速器的互操作背书。网络开放与计算平台可替换，是两个需要分别完成的产品目标。
这也是Tahan相对过去“以太网能否进入Scale-up”讨论的变化。争论不再只有交换时延是否足够低，而开始涉及一个产品实际采用什么传输、如何接入加速器、哪些管理能力可沿用。相比抽象地宣称开放互联会降低成本，当前更扎实的证据是：专用计算端点能够围绕通用交换技术建立可交付系统。它能降低哪部分依赖、增加哪部分集成工作，仍要按系统边界拆开计算。
72加速器预览展示的是下一步密度而非当前配置
Meta同时预览下一代Scale-up刀片：采用102.4T Tomahawk6C芯片，八个刀片连接一柜72个加速器。这里值得先关注的是机架尺度的改变。芯片容量提高，为扩大本地通信域提供了硬件条件；能否把这些条件变成模型收益，还取决于端点能力和通信方式。具体端口组合不等同于芯片全部容量，计算口径另列于技术说明。[1]
从16个加速器系统到72个加速器机架，变化不只是规模数字。更多设备可以被放入低时延通信域，模型切分与集合通信因而拥有不同的选择空间；与此同时，背板、线缆、供电和散热需要支持更密集的连接。一柜放得下，不代表每种模型都适合把全部设备放进同一个高频同步组。通信域扩大带来的收益，取决于模型中哪些通信能够从外部网络迁入本地，以及新增并行度是否抵得上同步开销。
最容易被忽略的时态也在这里。Meta正文明确说，未来一代Scale-up刀片计划采用ESUN数据平面。虽然同页图注把新刀片与ESUN联系得很紧，报道仍应以正文对代际的限定为准。当前Tahan、下一代72加速器方案与未来ESUN实现，是一条演进路径，不是同一产品已经同时具备的能力。公开材料尚不足以给出所有环节的量产时间、客户可采购配置及软件适配清单。
这一代际顺序透露出一种产品方法：硬件扩容可以先进行，协议与开放接口随后在产品代际中收敛。这样做有利于不被规范进度锁住，但也会增加版本管理要求。系统商必须说清当前接口支持哪些模式，未来能力需要换芯片、换板还是只更新软件。采购方若把路线图当成免费升级承诺，开放生态反而可能留下新的锁定成本。
ESUN把网络必须交付的能力写成共同要求
ESUN 1.0并非2026年10月大会才诞生。OCP在3月10日发布公告，规范生效日期为2月9日。它提供的是面向运营者需求的基础规范，重点围绕Fabric，即加速器报文穿越的网络。Meta在大会期间称ESUN 1.1接近完成，方向包括交换机配置档和帧间隙缩减；截至本文资料时间，不能将它写成已经正式发布。[2][3]
基础规范的意义，是把“适合Scale-up的以太网”拆成可以实现和测试的要求，包括减小报文固定开销，以及让拥塞控制和局部恢复具有明确规则。大消息容易摊薄固定开销，细粒度消息却会把每一次处理和等待放大为计算依赖。因此，优化小消息是在减少分布式计算中反复出现的停顿，而不仅是提高链路利用率。具体报头与流控机制见技术说明。[3]
更紧凑的报头不能直接换算为模型加速比。完整报文仍有其他字段、公共链路开销和物理传输成本，端点还要完成提交、地址访问与通知。一个模型若主要受计算或显存带宽限制，减小网络报头未必改变整体瓶颈；另一个模型可能只在少量同步阶段对它敏感。规范给出了降低成本的机制，产品必须证明这些成本在自己的真实负载中占多大比例。
这些网络要求还帮助供应商说明责任边界：什么由交换Fabric保证，什么需要端点配合，什么必须交给作业恢复。若把所有能力压缩成一句“无损网络”，产品之间的差异反而会被遮住。
过去用一句“支持无损以太网”描述互联能力，往往不足以比较不同产品。现在需要进一步问：哪些能力是必选，哪些可选；两端能力不同时如何工作；可选机制关闭后性能和恢复怎样变化。标准化的价值，首先是让这些问题拥有共同的描述方式，而不是保证所有厂商在相同负载下得到相同结果。
Fabric开放之后端点和软件仍决定系统边界
ESUN没有试图统一所有加速器的执行模型。报文到达端口，与计算核可以安全使用远端数据之间，还隔着内存访问、DMA、完成通知和执行流约定。远端写入在什么时候算完成，通知与数据如何排序，原子操作支持什么范围，异常发生后由谁重试，都是端点与软件必须明确的接口。网络可以为这些操作提供通路，却不能替加速器规定全部语义。
这一区分对异构产品尤其重要。两块加速器都能接入同一种交换Fabric，只能证明物理与网络连接拥有共同基础。若它们对完成、排序、地址保护或错误处理的理解不同，上层作业仍不能直接把它们看成一个统一执行域。因此，开放Scale-up短期内更可能先降低网络供应选择的障碍，再逐步扩大端点与软件的互操作范围。后一个判断是对产业路径的分析，不能被表述为任何组织已经承诺的产品结果。
UEC在10月12日发布的UE Specification 1.1，是相关但不同的工作。它增加了面向Scale-up的优化，并与OCP协调后续ESUN及端点工作；它不是ESUN 1.1的另一种称呼。把UE 1.1已发布写成ESUN 1.1已完成，会把两个标准组织、不同工作范围和不同进度混在一起。本文关注ESUN的Fabric边界，UE传输、拥塞信号与可编程接口的具体变化放在网络系统专题讨论。[4]
软件还决定新增硬件规模是否真正有用。集合通信库需要把通信组、消息尺寸和并行策略映射到拓扑上。小消息可能主要受通信阶段数影响，大消息则更依赖有效带宽；专家交换还会面对目的端不均衡。硬件接口相同，并不保证一个只针对旧系统优化的集合算法会自然适合72加速器机架。网络拓扑、rank放置与模型切分，需要作为同一份产品配置验证。
这种协同不应只靠给应用堆积大量人工参数。更可持续的方式，是让运行时知道带宽层级、共享瓶颈和可用路径，在硬件变化后调整通信映射，同时维持稳定的应用语义。NCCL等集合库本身仍有严格的参与条件，例如rank之间的数据数量和类型必须匹配；网络更开放并不会消除这些要求。[5] 供应选择增多，必须伴随可维护的软件适配，才可能成为长期收益。
下一轮竞争在于谁能交出完整的开放系统
Tahan与ESUN共同推动的趋势，是把Scale-up从一项通常随加速器整体采购的能力，逐步拆成端点、交换Fabric和软件可以分别审视的工程对象。这有机会扩大交换芯片与系统供应商的参与空间，也让自研加速器拥有更多系统设计选择。但拆开接口并不减少全部工作量，其中一部分集成、验证和生命周期责任会转移到平台建设者手中。
系统选型因此需要先固定当前可交付版本。对正在出货的产品，关注真实端点、软件和拓扑组合；对预览，关注接口冻结、样机验证与升级条件；对规范，关注实现覆盖和互操作证据。三者分别建立证据之后，再比较目标负载的有效吞吐、尾延迟、功耗及故障恢复，才能避免用未来的最高能力替当前产品估值。
验证也要从链路进入作业。点到点测试能说明基本路径，集合通信能揭示并发和拓扑影响，真实模型才能说明计算与通信能否重叠。测试时还应加入路径降速、端点退出和混合版本，以观察开放接口在不完全健康的环境中是否仍然可用。这里需要的不是无止境增加测试项，而是找到每个产品承诺对应的证据，尤其是扩大通信域后新增的风险。
Scale-up域越大，维护和故障对作业的影响也可能越大。一次链路退化可能只是降低带宽，一次端点重置却可能迫使整个通信组恢复；它们不能共用“恢复连通用了多久”这一指标。平台要比较的是在相同工作负载和可靠性目标下，扩大本地域节省了多少通信成本，又增加了多少恢复、冗余和升级成本。
OCP 2026给出的结论已经比“以太网也能做Scale-up”更具体：当前有Tahan这样基于成熟传输的产品，有面向更大机架的硬件预览，也有开始定义共同Fabric要求的ESUN。下一步值得追踪的是这些线索何时在同一套可交付系统中汇合，以及端点与软件是否提供足够的可移植性。开放Scale-up的竞争力，最终要由产品代际之间持续可用的接口和可重复的应用收益来证明。
技术说明
Tahan的芯片与端口口径
Tahan采用51.2 Tbps Tomahawk 5芯片。Meta正文给出64×800G总容量，其中一半通过背板服务加速器；官方图注中的32×800G不能被解释为芯片只有一半容量。四台交换机连接16个MTIA 300，是特定系统配置，不能据此推断任意加速器都能直接接入。[1]
当前传输组合为RoCE、路由式IPv6、PFC以及针对AI调整的QoS，由FBOSS管理。它没有被官方正文描述为已经采用ESUN数据平面的生产系统。“shipping today”在本文中只记为正在出货，不扩写成普遍商售或全部交付完成。[1]
下一代刀片的接口配置
预览刀片采用102.4T Tomahawk6C芯片，接口方案为216×400G，八个刀片连接一柜72个加速器。216×400G为86.4 Tbps，并不是102.4T芯片的全部容量。芯片容量、接口带宽之和、单加速器注入能力与作业可用带宽是不同指标，不能互相替代。[1]
Meta正文将采用ESUN数据平面的方案放在未来代际；同页图注的简写不能覆盖这个时态限定。公开材料没有给出全部环节的量产时间、客户可采购配置或软件升级条件。[1]
报头 流控与恢复机制
ESUN 1.0的EH报头为4字节，保留拥塞反馈、流量区分、负载分担及逐跳生存期等所需信息。这个长度不包括完整报文的全部公共开销，也不能直接换算成应用加速比。[3]
流控要求同样具有具体边界。规范以PFC作为基线，并区分端点与交换机对基于信用的流控CBFC、链路级重试LLR的支持要求。三种机制解决的问题不同：暂停控制缓冲接近边界时的发送，信用机制按接收能力安排注入，链路重试缩短局部误码的恢复路径。它们并不创造额外带宽，也不会自动消除长期拥塞，更不能替代设备故障之后的端到端恢复。[3]
“支持无损以太网”不足以完成互操作判断。还应记录必选与可选能力、端点和交换机的支持差异、协商与回退路径，以及关闭可选机制之后的性能和恢复行为。链路恢复与设备重置后的作业恢复分别测试，才能确认每项机制实际承担的责任。
来源与口径
资料截至2026年10月17日。产品代际、标准版本与交付状态按官方正文区分；机制影响、供应链判断和验证建议为作者分析，不是厂商性能承诺。未把预览、规范发布或开放接口等同于跨厂商整机互操作完成。
[1] Meta，OCP Summit 2026 Powering AI with Open Innovations in Scale-Up Scale-Out and Scale-Across Networks，2026年10月12日
https://engineering.fb.com/2026/10/12/open-source/ocp-summit-2026-powering-ai-with-open-innovations-in-scale-up-scale-out-and-scale-across-networks/
[2] OCP，The OCP ESUN 1.0 Specification Has Been Released，2026年3月10日
https://www.opencompute.org/index.php/blog/the-ocp-esun-10-specification-has-been-released
[3] OCP，ESUN Network Operator Requirements Base Specification Rev 1.0，2026年2月9日生效，第5—7节
https://www.opencompute.org/documents/ocp-esun-network-operator-requirements-base-specification-rev-1-0-final-pdf
[4] Ultra Ethernet Consortium，Ultra Ethernet Consortium Releases Specification 1.1 Advancing AI and HPC Networking，2026年10月12日
https://ultraethernet.org/ultra-ethernet-consortium-releases-specification-1-1-advancing-ai-and-hpc-networking/
[5] NVIDIA，NCCL Collective Operations，官方软件文档，2026年10月17日查阅
https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/usage/collectives.html