企业官网建设流程全解析

1. 从"卡脖子"到"自己造"：scaleFabric到底在解决什么问题

第一次看到"全自研、真无损、可量产"这三个词摆在一起的时候，我的直觉是：这不像是一句宣传口号，更像是一份技术验收清单。因为做高速网络这一行的人都清楚，这三个词里任何一个单独拿出来都不算稀奇，难的是同时成立。全自研意味着从芯片到协议栈不依赖外部授权，真无损意味着在拥塞场景下能做到零丢包，可量产意味着它不是实验室里的演示样机，而是能上架、能交付、能规模部署的成熟产品。中科曙光把scaleFabric拿出来首发，本质上是在回答一个被问了很久的问题：高端互联网络这块，我们能不能不靠别人。

先把背景说清楚。在集群和超算领域，节点之间的通信网络一直是决定整体性能的关键瓶颈之一。你CPU再强、GPU再多，如果节点之间传数据要靠传统的以太网TCP/IP栈，那延迟和CPU占用率会直接把并行效率拖垮。这就是RDMA（Remote 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）的目标是在链路层就保证不丢包，靠的不是事后重传，而是事前预防。它的核心手段是基于优先级的流控（PFC，Priority-based Flow Control）加上拥塞控制。PFC的原理有点像交通管制：当下游交换机的某个优先级队列快满了，它就向上游发一个"暂停"帧，让上游先别发了，等队列腾出空间再恢复。这样数据包在缓冲区里排队而不是被丢弃，从链路层实现了零丢包。

但PFC本身是个双刃剑。它容易引发"队头阻塞"和"PFC风暴"——一个端口的暂停可能沿着链路一路传导，最后把整个网络拖慢，甚至形成死锁。所以真正成熟的无损网络方案，不能只靠PFC，必须配合精细的拥塞控制算法，在拥塞刚冒头的时候就主动降速，而不是等队列满了才踩刹车。scaleFabric号称"真无损"，我判断它在PFC之上一定做了自己的拥塞控制机制，否则在大规模集群里根本撑不住。

2.2 无损不是单一技术，而是一整套协同设计

很多人以为无损就是网卡支持PFC就行了，这是典型的误解。无损是一套从网卡、交换机到协议栈、再到上层通信库的系统工程。我把它拆成几个层次来看：

这张表说明一个道理：任何一层掉链子，整条链路都谈不上"真无损"。中科曙光敢说"全自研"，意味着这几层它都得自己啃下来，尤其是网卡芯片和交换机芯片这两个最硬的骨头。这也是为什么高速网络的门槛这么高——它不是买几个现成部件拼起来就行，而是需要芯片、硬件、固件、软件全栈的深度协同。

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 性能验证：拿数据说话

任何高速网络方案，最终都要用数据证明自己。我列几个关键的验证维度，也是你在选型时应该重点考察的：

这些测试做下来，才能真正判断一套网络是不是"真无损"。宣传材料上的峰值数字意义有限，关键是看它在真实负载、真实规模下的表现。

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这类新方案，我建议你也用同样的标准去验证它，别被漂亮的峰值数字冲昏头脑，真实负载下的稳定性才是硬道理。