1. 从卡脖子到自己造scaleFabric到底在解决什么问题第一次看到全自研、真无损、可量产这三个词摆在一起的时候我的直觉是这不像是一句宣传口号更像是一份技术验收清单。因为做高速网络这一行的人都清楚这三个词里任何一个单独拿出来都不算稀奇难的是同时成立。全自研意味着从芯片到协议栈不依赖外部授权真无损意味着在拥塞场景下能做到零丢包可量产意味着它不是实验室里的演示样机而是能上架、能交付、能规模部署的成熟产品。中科曙光把scaleFabric拿出来首发本质上是在回答一个被问了很久的问题高端互联网络这块我们能不能不靠别人。先把背景说清楚。在集群和超算领域节点之间的通信网络一直是决定整体性能的关键瓶颈之一。你CPU再强、GPU再多如果节点之间传数据要靠传统的以太网TCP/IP栈那延迟和CPU占用率会直接把并行效率拖垮。这就是RDMARemote Direct Memory Access远程直接内存访问存在的意义——它让一台机器可以直接读写另一台机器的内存绕过操作系统内核把CPU从数据搬运的苦力活里解放出来。而承载RDMA的主流高速网络技术长期以来就是InfiniBand这个市场基本被一家海外厂商牢牢握在手里。所以scaleFabric的定位就很清晰了它是一套面向高性能计算和AI集群的高速互联解决方案核心能力是RDMA对标的就是InfiniBand那一套东西。它要解决的不是有没有网卡这种低层次问题而是能不能在无损、低延迟、高带宽的前提下把大规模集群的通信效率做到国际一线水平同时供应链完全自主可控。适合关注这个话题的人其实很广做超算和智算中心架构的工程师、搞分布式训练的平台开发者、负责数据中心网络选型的运维负责人甚至只是想知道国产高速网络到底走到哪一步的技术爱好者都能从这套东西里找到自己关心的点。我下面会从几个角度把它拆开讲无损网络到底难在哪、RDMA和go-back-n重传是什么关系、scaleFabric这类方案在工程上要迈过哪些坎、以及如果你真要在项目里用它该注意些什么。这些内容一部分来自公开的技术资料一部分是我基于多年做集群网络的经验做的合理推演凡是推演的部分我都会说明。2. 无损网络这四个字为什么比听起来难得多2.1 丢包在普通网络里是常态在RDMA里是灾难普通以太网的设计哲学是尽力而为丢包了就重传TCP协议栈会帮你兜底用户顶多感觉卡一下。但这套逻辑放到RDMA场景里就完全行不通了。RDMA的卖点是低延迟和低CPU占用它的实现方式是把网络协议栈卸载到网卡硬件上让网卡直接和远端内存打交道。问题在于一旦发生丢包硬件协议栈的重传机制远没有软件TCP那么灵活而且RDMA的很多操作是基于可靠连接假设的丢一个包可能触发整条链路的重传甚至连接重置延迟瞬间从微秒级飙到毫秒级性能断崖式下跌。这就是无损两个字的重量所在。无损网络Lossless Network的目标是在链路层就保证不丢包靠的不是事后重传而是事前预防。它的核心手段是基于优先级的流控PFCPriority-based Flow Control加上拥塞控制。PFC的原理有点像交通管制当下游交换机的某个优先级队列快满了它就向上游发一个暂停帧让上游先别发了等队列腾出空间再恢复。这样数据包在缓冲区里排队而不是被丢弃从链路层实现了零丢包。但PFC本身是个双刃剑。它容易引发队头阻塞和PFC风暴——一个端口的暂停可能沿着链路一路传导最后把整个网络拖慢甚至形成死锁。所以真正成熟的无损网络方案不能只靠PFC必须配合精细的拥塞控制算法在拥塞刚冒头的时候就主动降速而不是等队列满了才踩刹车。scaleFabric号称真无损我判断它在PFC之上一定做了自己的拥塞控制机制否则在大规模集群里根本撑不住。2.2 无损不是单一技术而是一整套协同设计很多人以为无损就是网卡支持PFC就行了这是典型的误解。无损是一套从网卡、交换机到协议栈、再到上层通信库的系统工程。我把它拆成几个层次来看层次关键能力缺失后的后果物理层/链路层低误码率、PFC流控基础丢包重传频繁网络层自适应路由、拥塞感知热点链路拥塞全局性能下降传输层可靠RDMA、重传机制连接不稳定长尾延迟高通信库层集合通信优化AllReduce等操作效率低管理面拓扑发现、故障隔离大规模部署运维困难这张表说明一个道理任何一层掉链子整条链路都谈不上真无损。中科曙光敢说全自研意味着这几层它都得自己啃下来尤其是网卡芯片和交换机芯片这两个最硬的骨头。这也是为什么高速网络的门槛这么高——它不是买几个现成部件拼起来就行而是需要芯片、硬件、固件、软件全栈的深度协同。2.3 可量产才是最难的那道坎实验室里跑通一个无损网络demo和把它做成能批量交付的产品中间隔着十万八千里。可量产意味着几件事芯片良率要过关、固件要稳定、要和主流服务器和操作系统兼容、要有完整的运维工具链、要能通过长时间稳定性测试。我见过太多技术指标很漂亮但一上规模就各种诡异问题的网络方案问题往往不出在核心算法而出在工程细节——比如某个温度下网卡降频、某个固件版本和特定交换机不兼容、大规模组网时路由收敛慢等等。所以全自研、真无损、可量产这三个词连在一起其实是在说我们不仅掌握了核心技术还把它做成了能真正落地的东西。这个组合的分量比单独强调任何一个指标都要重。3. RDMA和go-back-n重传一对绕不开的搭档3.1 RDMA为什么对重传机制如此敏感要理解scaleFabric这类方案的技术难点必须搞懂RDMA和重传的关系。RDMA的可靠传输通常基于两种语义可靠连接RC和不可靠数据报UD。高性能场景基本都用RC因为它保证消息按序、可靠送达。但可靠这两个字是要付出代价的——它需要一套重传机制来兜底。RDMA网卡为了追求极致低延迟通常把协议处理放在硬件里硬件资源有限不可能像软件TCP那样维护复杂的滑动窗口和选择性重传。于是很多实现采用的是go-back-n重传一旦某个包丢了或者超时没收到确认发送方就从那个包开始把它之后的所有包全部重发一遍。这种机制实现简单、硬件开销小但效率不高——如果窗口里有100个包第1个丢了后面99个即使已经成功到达也要重发。这就是为什么无损网络对RDMA如此重要。如果链路层能保证不丢包go-back-n重传就几乎不会被触发RDMA的低延迟优势才能充分发挥。反过来说一旦无损没做好频繁触发go-back-n性能就会雪崩。所以真无损和高效RDMA是一体两面的关系scaleFabric把这两点绑在一起讲逻辑上是自洽的。3.2 go-back-n的优化空间在哪里虽然go-back-n实现简单但工程上还是有不少优化余地。我基于常见实践梳理几个方向减小重传窗口窗口越小一次go-back-n需要重发的包越少但窗口太小又会影响带宽利用率需要权衡。快速重传触发不等到超时才重传而是通过重复ACK或NACK提前感知丢包缩短恢复时间。选择性确认的硬件化在硬件里实现类似SACK的机制只重传真正丢失的包避免go-back-n的放大效应。和无损机制联动把PFC和拥塞控制做到极致从源头减少触发重传的概率。提示如果你在做RDMA性能调优发现长尾延迟异常高第一件事就是去查重传统计。很多时候问题不在带宽而在某个隐蔽的丢包点反复触发go-back-n。3.3 从热词看技术关注点这次的相关热词里出现了rdma go-back-n 重传说明关注这套方案的人很多是真正在做底层调优的工程师。他们关心的不是有没有RDMA这种入门问题而是重传机制怎么设计、无损怎么保证、大规模下性能怎么稳住这些硬核问题。这也侧面印证了scaleFabric的受众是专业群体它的价值要在真实的集群负载下才能体现出来。4. scaleFabric这类自研方案工程上要迈过哪些坎4.1 芯片自研最难但最值钱的一步高速网络的核心是网卡芯片HCA和交换机芯片。这两块芯片的设计难度极高涉及高速SerDes、协议硬件加速、缓存管理、功耗控制等一系列硬核技术。自研芯片的好处是显而易见的协议可以按自己的需求定制不受外部授权限制供应链安全成本可控。但代价是研发周期长、投入大、风险高。我判断scaleFabric在芯片层面做了深度定制特别是在RDMA引擎和拥塞控制逻辑上。因为通用芯片很难同时满足无损和低延迟这两个有点矛盾的需求只有自己设计才能做针对性优化。比如把PFC的响应逻辑做进硬件、把拥塞检测的采样频率提高、把重传窗口的管理做得更精细这些都是自研芯片才能玩的花样。4.2 协议栈与生态兼容不能只自己玩自研方案最大的风险之一是生态孤立。如果scaleFabric只能跑自己的通信库、只兼容自己的交换机那它的应用范围就会非常受限。真正能打的方案必须在协议层面兼容主流的RDMA编程接口比如verbs让现有的MPI、NCCL、分布式训练框架能直接跑上去不需要大改代码。这一点对AI集群尤其重要。现在主流的分布式训练框架都深度依赖NCCL做集合通信如果scaleFabric能提供兼容NCCL的通信库那迁移成本就大大降低。我推测曙光在这方面做了不少适配工作否则可量产就无从谈起——客户不会为了换一套网络把整个软件栈重写一遍。4.3 大规模组网的稳定性魔鬼在细节里小规模测试和大规模部署完全是两回事。几十个节点的集群随便怎么连都能跑但上千个节点、多层交换的拓扑路由收敛、拥塞传播、故障隔离这些问题就会集中爆发。我列几个大规模组网常见的坑路由震荡链路状态变化时如果路由收敛太慢会出现短暂的环路或黑洞导致大量丢包。PFC死锁环形依赖的流控可能导致整个网络卡死需要精心设计拓扑和流控策略。慢节点拖累一个性能异常的节点可能拖慢整个集合通信需要快速检测和隔离。固件一致性大规模部署时几千张网卡的固件版本管理是个大工程。这些问题的解决靠的不是某个单点技术而是整套运维体系。scaleFabric要真正做到可量产必须在这些工程细节上有成熟的方案。4.4 性能验证拿数据说话任何高速网络方案最终都要用数据证明自己。我列几个关键的验证维度也是你在选型时应该重点考察的验证维度关注指标典型测试方法点对点带宽单链路Gbps大消息带宽测试点对点延迟微秒级小消息往返延迟集合通信效率AllReduce带宽不同规模下的扩展性拥塞场景表现丢包率、延迟抖动多打一拥塞测试长时间稳定性误码、重传率72小时以上压测故障恢复切换时间链路/节点故障注入这些测试做下来才能真正判断一套网络是不是真无损。宣传材料上的峰值数字意义有限关键是看它在真实负载、真实规模下的表现。5. 如果你要在项目里用scaleFabric这些经验值得参考5.1 选型阶段先想清楚你的负载特征不是所有场景都需要无损RDMA网络。如果你的应用是大量小消息、对延迟极度敏感比如高频交易、实时推理那无损网络的价值巨大如果你的应用是大块数据传输、对延迟不敏感比如离线训练、数据备份那普通高速以太网可能就够了。选型前先做负载画像别为了先进而过度投入。具体来说我会从这几个问题入手通信模式是点对点还是集合通信为主消息大小分布如何对尾延迟的容忍度是多少集群规模会扩展到多大把这些想清楚再去看scaleFabric的能力是否匹配。5.2 部署阶段拓扑和流控策略要提前规划无损网络的部署拓扑设计是重中之重。我建议遵循几个原则避免环形依赖PFC流控最怕环路拓扑设计时要确保流控依赖关系无环。拥塞点分散不要让所有流量都挤在少数几条上行链路上合理规划收敛比。预留管理通道带内管理和带外管理要分开避免管理流量和业务流量互相干扰。固件版本统一部署前把所有网卡和交换机固件刷到统一版本避免兼容性玄学问题。注意PFC配置不当是导致大规模网络故障的头号原因。上线前一定要在测试环境做完整的拥塞和故障注入测试别直接上生产。5.3 调优阶段从重传统计入手网络跑起来之后调优的第一步是看统计。重点关注的指标包括PFC暂停帧的发送频率、RDMA重传次数、拥塞控制触发次数、各链路的带宽利用率。如果发现某个链路PFC暂停帧频繁说明那里是拥塞热点需要调整路由或增加带宽。如果重传次数高说明无损没做好要回头查PFC和拥塞控制配置。我个人的经验是很多性能问题不是出在网络本身而是出在应用侧的通信模式。比如某个进程发送节奏太激进瞬间打满缓冲区触发大量PFC。这种情况下调整应用侧的发送窗口比调网络参数更有效。5.4 运维阶段建立可观测性体系大规模网络的运维靠人肉巡检是不现实的。必须建立一套可观测性体系实时采集网卡、交换机、链路的各项指标设置合理的告警阈值做到问题早发现、早定位。我建议至少覆盖这几个层面物理层误码、链路层流控、传输层重传、应用层通信效率。这样一旦性能下降能快速定位是哪一层的问题。另外故障演练要常态化。定期注入链路故障、节点故障验证网络的收敛和恢复能力。真正可靠的网络不是不出故障而是出了故障能快速自愈。6. 国产高速网络的这一步意味着什么6.1 从能用到好用的跨越国产高速网络这些年进步很快但早期很多方案停留在能用的阶段——功能有了性能和稳定性还差口气。scaleFabric打出的全自研、真无损、可量产如果真能兑现意味着国产方案开始向好用甚至好用且可靠迈进。这个跨越的意义比单纯多一个产品要大得多。因为它证明了一件事高端互联网络这块我们不仅能做出来还能做成产品、做成产业。6.2 对AI集群的直接影响当前AI大模型训练对集群网络的要求越来越高。万卡甚至十万卡级别的集群网络稍微有点抖动整个训练任务就可能被拖慢几倍。这种场景下无损RDMA网络不是锦上添花而是刚需。scaleFabric这类自研方案的出现给国内的智算中心提供了一个不依赖海外的选择这对保障AI基础设施的供应链安全有实际价值。6.3 生态建设才是长期战役不过我也要泼一点冷水单有好的硬件不够生态才是长期胜负手。InfiniBand之所以强势不只是因为技术好更因为它有庞大的生态——所有主流的通信库、框架、工具都优先适配它。scaleFabric要真正站稳必须在生态建设上持续投入让更多软件原生支持它、让更多开发者熟悉它、让更多运维工具兼容它。这是一场持久战不是发一个产品就能解决的。我在实际做集群项目时的体会是网络选型从来不是纯技术决策还要考虑团队的技术储备、供应商的支持能力、长期的演进路线。scaleFabric迈出了重要一步但后面的路还长。对使用者来说保持关注、在合适的场景小范围试点、积累自己的使用经验是比较稳妥的做法。等技术成熟度、生态完善度都到位了再大规模铺开也不迟。最后分享一个我踩过的坑早年做RDMA集群图省事用了默认的PFC配置结果在一次大规模AllReduce时触发了PFC风暴整个训练任务卡死了半小时。后来才发现是拓扑里有环形依赖加上流控阈值设得太激进。从那以后我养成了一个习惯——任何无损网络上线前必做三件事拓扑无环检查、PFC阈值压测、故障注入演练。这三件事做完心里才踏实。scaleFabric这类新方案我建议你也用同样的标准去验证它别被漂亮的峰值数字冲昏头脑真实负载下的稳定性才是硬道理。