MasterLee's Tech Blog

无损以太网的"无损"，你凭什么信？——聊聊 SONiC Scale-Up 测试标准

从 LLR、CBFC 的机制与实测结果出发，解释 SONiC Scale-Up 测试标准如何验证无损以太网的可部署性。

17 分钟阅读 马斯特李

封面图

（这篇文章是我在 2026 AI 网络技术应用创新大会听完一场演讲、又和几个做网络的朋友吵了一架之后写的，观点可能有点直接😁）

争论的起因很简单。会上，阿里云牵头的 SONiC Scale-Up 测试标准更新了 LLR/CBFC 的最新测试策略和实测进展1。散场后一个朋友撇撇嘴：“以太网做 Scale-Up？‘无损’俩字先打个问号吧。协议写得再漂亮，跑起来该丢还是丢。“另一个朋友反驳：“UEC 规范都出了，LLR、CBFC 硬件都实现了，还有什么好怀疑的？”

我的看法是：他们俩都错了，而且错在同一个地方——他们都在讨论”协议”，但真正的问题是”验证”。 第一个朋友错在把”没验证过”当成”做不到”；第二个朋友错在把”规范发布了”当成”落地了”。这中间隔着的东西，恰恰就是这次大会上发布的那份测试标准要解决的。

这篇文章我想把这件事讲透：LLR 和 CBFC 到底在干什么，为什么”协议规范 ≠ 可部署”，以及一份测试标准为什么值得你认真看一眼。

1.1. 先问一个问题：协议说”零丢包”，你信吗？

先问一个问题：一份协议规范白纸黑字写着”硬件级零丢包”，你敢直接拿去搭生产集群吗？

你不敢。因为规范描述的是正常路径，而生产环境杀死你的永远是边界情况。

规范会告诉你 NACK 触发重传，但不会告诉你 Poison CRC 帧在 Store-and-Forward 和 Cut-Through 两种转发模式下行为不一样；

规范会告诉你 Credit 耗尽就暂停发送，甚至定义了信令丢失后的自动恢复机制，但不会告诉你在你的链路距离和缓存配置下，恢复要多久、恢复期间缓冲区会不会被击穿；

规范会告诉你流控保证无损，但不会告诉你 3:1 Incast 打进来的时候，三个发送端谁先饿死。

“能不能”是协议规范回答的问题，“确定能”是测试标准回答的问题。这两个问题之间的距离，就是实验室和生产网的距离。

说白了，这就是分布式系统的老规律换了个马甲：你写了一个共识算法，证明了 Safety 和 Liveness，不代表你的实现在网络分区、时钟漂移、磁盘满这些脏场景下不出事。Jepsen 为什么有价值？因为它不看你论文写了什么，只看你的系统在注错之下的真实行为。链路层协议同样需要它的”Jepsen”。

1.2. 为什么 Scale-Up 网络对丢包零容忍

要理解这份标准为什么较真到纳秒级，得先回到第一性原理：AI Scale-Up 网络到底特殊在哪。

Scale-Up 是把一台”超级服务器”内部的加速卡互联起来的那张网（注意和 Scale-Out 区分开，后者是服务器之间的集群网络，两张网的设计约束完全不同）。在这张网上跑的是集合通信——AllReduce、AllGather 这类操作。集合通信有个残酷的性质：它是同步屏障，全体成员必须等最慢的那一个。 一千个端口里有一个端口丢了一个包，触发上层重传，其他九百九十九个端口就得陪着等。丢包率再低，乘上端口数和迭代次数，就是持续放大的尾部延迟。你平均延迟再漂亮，训练任务感受到的永远是最差的那条链路。

那丢包从哪来？在链路层，主要就两个来源：

  1. 误码丢包。高速 SerDes 上跑 400G/800G，物理层靠 FEC 纠错。FEC 能纠掉大部分错误，但纠不动的残余错误帧就变成丢帧。链路越多、速率越高，撞上残余错误的概率就越大。
  2. 拥塞丢包。多打一的 Incast 流量把交换机缓存打爆，溢出即丢。

传统以太网对这两件事的态度是”丢了让上层重传”。这个态度在 Scale-Up 场景下不可接受——上层重传的代价是微秒到毫秒级，而 Scale-Up 网络的单跳延迟预算是几百纳秒。用毫秒级的手段去修纳秒级网络的错，等于没修。

UEC（Ultra Ethernet Consortium）给出的答案是两个互补机制2：

  • LLR（Link Level Retry，链路层重传） 对付误码丢包：每帧携带序列号，接收端按序检测，发现错帧通过 CtlOS 带外信令回 NACK，发送端从 Replay Buffer 硬件重传。整个过程不经过主机，对上层透明。
  • CBFC（Credit-Based Flow Control，基于信用的流控） 对付拥塞丢包：接收端按自己的缓存余量给发送端发信用，发送端发一帧扣一份信用，信用耗尽就停。缓存永远不会被打爆，因为发送端根本没资格发出会溢出的那个包。它支持最多 32 个 Virtual Channel 独立流控，无损流量和尽力而为流量可以分道走。

这里你可能要问：以太网不是早就有 PFC 了吗，为什么还要搞一个 CBFC？这个问题问到了点子上。PFC 的机制是”事后刹车”：接收端缓存水位越过阈值才发 Pause 帧，Pause 帧在链路上飞的这段时间里，发送端还在继续灌数据，所以你必须预留一段 Headroom 缓存来兜住这些”在途”流量。这个设计有两个天生的软肋：一是粒度粗，暂停以端口乘优先级为单位，最多 8 个流量类，一停就是一整类流量陪葬；二是 Pause 逐跳反压，在环形依赖的拓扑里可能酿成 PFC 死锁和风暴——这是运维过大规模 RoCE 网络的人都交过的学费（谁没在半夜处理过 PFC 风暴，谁就没资格说无损以太网简单）。CBFC 把逻辑整个反过来：不是”缓存快满了求你别发”，而是”我先告诉你有多少额度，你没额度就发不出来”。从被动刹车到主动记账，从阈值触发到逐帧核销，这是流控范式的换代，不是参数调优。 再配上 32 个 VC 的细粒度隔离，无损流量被背压时，尽力而为流量该跑还跑。

一个管”已经发生的错误”，一个管”即将发生的拥塞”。机制上讲，这两个东西凑齐了，以太网在链路层确实具备了零丢包的硬件基础。到这里，我那位乐观的朋友是对的。

但接下来的问题，他就答不上来了。

1.3. 从规范到落地，隔着四类坑

SONiC 社区的 Scale-Up 工作组在 UEC 规范和 ESUN 产业共识之上，已经输出了多厂商互通的集群参考架构3。也就是说，“用什么协议”和”搭什么架构”都有了答案。剩下的问题是：你怎么知道手里这台设备、这颗芯片、这个 IP，真的把规范做对了？

把大会上分享的部署挑战归纳一下，坑可以分成四类模式，每一类的性质都不一样1：

模式一：行为未定义。 规范没写的地方，各家实现各凭理解。Poison CRC 帧转不转发？LLR 流和非 LLR 流混跑时 FEC 错误怎么交互？Incast 恢复之后调度还公不公平？这类坑的特点是：单看任何一家都”没毛病”，两家一对接就出事。

模式二：参数深度耦合。 LLR 的 Replay Timer、Outstanding Data Max，CBFC 的 Credit Size、Credit Limit，这些参数彼此咬合，而且和物理世界直接挂钩——链路距离决定 RTT，RTT 决定你需要多深的 Replay Buffer 和多大的信用池。配小了，链路跑不满线速；配错了，重传风暴。这类坑没有万能默认值，只有按场景推导。

模式三：判据模糊。 过去验收一台设备，标准是”流量跑通了""看起来正常”。跑通了不等于对——计数器和理论值差了 20% 也叫跑通，重传默默兜了底也叫跑通。没有量化判据，Pass/Fail 就是玄学。

模式四：观测缺失。 传统网络监控看的是端口计数和流表，但 LLR/CBFC 的状态机、CtlOS 控制信令都在 PCS 层以下跑，你的运维系统根本看不见。设备出了问题，你连”它现在处于什么状态”都回答不了。

这四类坑有个共同点：没有一类能靠单一厂商自己解决。 行为未定义需要多方对齐，参数耦合需要跨设备联调，判据需要各方认账，观测需要接口标准化。这就是为什么答案必须是一份社区标准，而不是某家的内部测试手册。

1.4. 这份测试标准到底干了什么

现在来看这份标准（SONiC Scale-Up Test Standard，当前 Draft v0.4，由 SONiC Scale-Up 工作组测试子组维护，成员包括阿里云、博通、是德科技、合见、字节跳动，文档维护人来自阿里云4）交出的答卷。

先看方法论。整套验证体系是一个四层闭环：流量注入 → 控制验证 → 硅级观测 → 合规报告1。流量注入层用支持 LLR/CBFC 协议的硬件测试仪，做亚微秒级时间戳打点和精确的 CRC/FEC 错误注入——这是”攻击面”；控制验证层基于 SONiC 的测试框架，通过 SAI 标准接口下发配置、查询能力、编排用例矩阵；硅级观测层直接读芯片内部的 LLR 收发/NACK/Replay 计数器和 CBFC 信用计数器，盯着协议状态机的真实流转；合规报告层按统一格式记录数据，输出互操作矩阵和配置基线建议。这个架构的关键在”双通道”：测试仪从外面看到的行为，和 SAI 接口从芯片里读出的状态，必须相互印证。 只看外部表现，你分不清”没丢包”是协议做对了还是重传默默兜了底；只看内部计数器，你不知道线上真实流量到底经历了什么。两边对上了，结论才算数。

在这个框架之上，标准干了四件事，恰好对着上面四类坑。

第一件事：让每条协议要求都有验证方法。 标准从协议规范反向推导出 22 个测试用例——LLR 10 个、CBFC 12 个——覆盖异常注入、极值压力、混合流量、拥塞公平、故障恢复五个维度4。你去看用例设计就知道它有多”不怀好意”：LLR-05 专门注入 Poison CRC 验证不该触发重传的场景；LLR-09 用 64±1 到 9216±1 字节的边界包长做遍历；CBFC-03 故意掐断 Credit 信令再恢复，看信用账本会不会算错；CBFC-12 模拟 500 米线缆的 RTT 打满线速，验证信用池深度够不够。好的测试标准不是证明系统能工作，而是穷尽让它不工作的方法。

第二件事：把”正常”变成数字。 标准给出了精确的量化判据：无损流量必须零丢包；硬件计数器和理论公式的偏差必须小于 5%；Credit Recovery 时间有明确上界4。在阿里云的实测环境里，端到端延迟落在 650~710ns、Jitter 小于 43ns（4×400GE、20 米线缆、无链路错误条件下的实测值1）。你注意这个精度——判据压到几十纳秒的抖动，是因为 Scale-Up 场景的性能预算就在这个量级，判据比预算粗，测了等于白测。

第三件事：让互通有据可依。 标准定义了 Pairwise 互操作矩阵，四种组合：交换机对测试仪验证行为基线，交换机对端侧 IP 验证跨厂商协议栈，测试仪对端侧 IP 验证直连互操作，多源 Incast 验证流控公平性4。以前多厂商互通测试是”各说各话”——A 说自己合规，B 说自己合规，插在一起不通，谁的锅说不清。现在是同一套用例、同一把尺子，谁不合规，计数器直接告诉你。

第四件事：倒逼接口标准补课。 是我认为最能体现测试价值的一条。测试过程中发现，要按标准验证 LLR/CBFC，现行 SAI（交换机抽象接口）不够用：v0.4 第 9 节列出了 19 项缺失或未完全覆盖的属性与计数器——比如 LLR Replay Buffer Size 的配置项、CBFC 收发两端的信用计数器4。你想读的状态读不到，说明接口层从一开始就没为”可观测”设计。这份清单已提交芯片供应商确认，目标是在下一版 SDK 补齐。测试标准倒逼接口标准，接口标准反过来喂养可观测性——这是标准化最大的杠杆效应。（顺带解决了上面说的模式四：运维系统看不见状态机，本质是接口没暴露，而不是技术做不到。）

1.5. 实测数据怎么读

大会上同步发布了两组实测结果，我建议你带着”边界条件”的眼光去读，而不是只看结论。

第一组，网侧。在阿里云的以太网 Scale-Up 交换机上，用是德 INPT 800GE 测试仪、4×400GE 环境跑完全量 22 个用例，全部通过：LLR 场景零丢包线速吞吐，CBFC 在 3:1 Incast 下无损流量零丢包且发送端之间公平性达标1。22 个用例全过意味着什么？意味着这台设备不只在正常路径上工作，而是在错帧注入、信令丢失、缓冲极限、混合流量这些故意刁难的场景下也守住了”零丢包”的承诺。

其中有两个混合流量的结果，我觉得比”全部通过”这四个字更有信息量。一个是 LLR 的混跑用例：无损流和尽力而为流同时注入并叠加 FEC 错误，结果无损流靠 LLR 重传完整恢复、零丢包，而没有 LLR 保护的尽力而为流出现丢包1。另一个是 CBFC 的 Incast 用例：一个无损 VC 加一个尽力而为 VC 一起打 3:1 Incast，无损 VC 零丢包，尽力而为 VC 正常降级1。这两个结果放在一起说明一件事：保护是选择性的，代价也是选择性的——需要确定性的流量拿到确定性，不需要的流量不用陪着付出缓存和信用的开销。 这才是生产网想要的形态。真让所有流量都无损，缓存和信用池的成本会把你压垮，而且绝大多数流量根本不需要。

第二组，端侧。合见 IP 的验证结果是 LLR 全部通过，CBFC 大部分通过，有 4 个用例未完成——一个等 IPv6 支持的版本迭代，一个等双 VC 并发的版本更新，两个等多方联合测试排期1。

我特别想说说第二组。有人可能觉得”没全过”不好看，我的看法恰恰相反：敢把没通过的用例连同原因一起公开，比一张全绿的表格可信一百倍。 一份测试标准的公信力，恰恰建立在它能测出问题、并且大家愿意承认问题上。全员满分的考试，只能说明考卷有问题。

还有几条测试洞察值得记下来，因为它们是规范里读不到的一手工程经验1：CtlOS 控制信令的带宽开销实测约 0.38%（典型 spacing 配置下），不大，但要纳入容量规划；端口级信用共享做不到 VC 间隔离，只适合单一流量类型的快速部署，多租户场景必须上 Per-VC Credit；链路层测试高度依赖具备注错能力的硬件测试仪，你想复现这套验证，软件打流是不够的。

1.6. 标准是慢功夫，但它是杠杆

最后说点技术之外的看法。

在大厂做工程的人都知道，写标准、做测试规范是典型的”吃力不讨好”的活：产出是文档不是功能，周期以季度计，成果还要跟一堆友商共享。为什么值得做？因为基础设施行业里，谁定义了”怎么衡量好坏”，谁就定义了这个方向的演进节奏。 你去看以太网自己的历史就明白：以太网能活到今天、吃掉一个又一个私有互联，靠的从来不是单点性能最强，而是开放生态下”任何两家的设备插在一起就能通”的确定性。而这个确定性，从来都是测试和认证体系给的，不是协议文本给的。

这份标准的做法我认为是对的路子：阿里云牵头把自己生产验证的方法论拿出来，但从第一天起就放在 SONiC 社区里，和博通、是德科技、合见、字节跳动一起打磨，测试标准文档、SAI 接口定义、参考架构全部公开43。根据大会上联合发布材料，在此之前 SONiC 社区还没有 Scale-Up 层面的标准化测试规范，这份文档补上了这一环4。后续路线也已经公开：计划 2026 年三季度联合发布完整测试数据集与性能基线，核心测试用例基于 SONiC Ranking Test 框架开源，标准从 v0.4 向 v1.0 演进时纳入 ESUN、SRv6、AI Telemetry 等场景1。

一家公司定不了产业标准，这是常识。但产业标准也从来不会凭空出现——总得有人先把第一版可用的东西做出来、测出来、开源出来，别人才有东西可以反对、修正和共建。前者是姿态，后者是工程，两者缺一不可。

回到开头那场争论。以太网 Scale-Up 的”无损”到底能不能信？我的答案是：别信任何人的口头承诺，去看测试报告——现在，终于有一份大家公认的考卷可以看了。 协议文本里的承诺和生产环境里的事实之间，隔着一整套可测量、可复现、可交叉验证的体系。这套体系有了 v0.4，还在往 v1.0 走。你要是做 Scale-Up 相关的芯片、设备或者集群，我建议你现在就去把那份标准文档读一遍4，然后用它考一考你手里的设备。

考不过不丢人，不敢考才丢人。

（全文完）

参考资料

Footnotes

  1. 《以太网 Scale-Up 标准化测试：LLR/CBFC 测试策略与最新进展》，阿里云、是德科技、博通、合见、字节跳动联合演讲材料，2026 AI 网络技术应用创新大会，2026 年 8 月。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  2. UE Specification v1.0.2 §5.1（LLR）、§5.2（CBFC），Ultra Ethernet Consortium，https://ultraethernet.org（访问时间：截至 2026 年 8 月）。 ↩

  3. Ethernet Scale-Up AI Cluster Architecture，SONiC 社区，https://github.com/sonic-net/SONiC/blob/master/doc/scale_up/Ethernet_Scale_Up_AI_Cluster_Architecture.md（访问时间：截至 2026 年 8 月）。 ↩ ↩2

  4. SONiC Scale-Up Test Standard Draft v0.4，SONiC Scale-Up WG Test Subgroup（Alibaba、Broadcom、ByteDance、Keysight、Univista），https://github.com/sonic-net/SONiC/pull/2389（访问时间：截至 2026 年 8 月）。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8