全栈智算系列直播回顾 | 智算中心对网络的需求与应对策略（下）

在上一篇中，分享了“智算中心对网络的要求与传统的计算中心有什么区别？”以及“异构/多元算力会对网络带来更多的挑战，智算中心应该如何应对？”等内容。本篇作为此次直播的下半部分，将继续分享相关的精彩内容。
本次直播由益企研究院联合创始人王海峰主持，参与专家包括吉利智算网络技术专家宋中伟、中国移动通信集团设计院研究总监、正高级工程师封铎、安捷诺亚太区产品总监王君原、益企研究院创始人张广彬、新华三集团交换机产品线产品管理部总监陈伯超。

话题四：如何应对大规模网络对性能的高要求？

宋中伟：根据我的一些统计，2025 年上半年，至少有393个智算中心相关项目招标，数量相比去年翻倍。这些项目中，中标金额达到千万级别的有 96 个；亿元以上的大单有 43 个。最大的一单是新疆的一个算力中心，中标金额是 72 亿元，计划算力达到20000P。

这其中体现的趋势是单个数据中心的投资额在不断地上升。算力设备的成本提高是原因之一，更大的原因是对算力基础的需求变得更大了。比如像24年上半年的29个亿元的大单里，只有3个是超过10亿元的，但是25年上半年至少有10个项目超过 10亿元。但是投入运营的项目数量有所减少，今年上半年投运的智算中心只有30个，而去年同期投运了60个。整体来说，超大规模的需求存在一定收敛，训练的需求可能在集中到一些头部厂商。中小企业可能大多数只是做微调。

封铎：随着参数量的增长，我们对算力的需求肯定也是随之增长的。增长曲线可能会变，指数曲线可能稍微放缓，但整体的趋势应该不会有什么大的变化。现在智算发展的形势都是争分夺秒的，用更高的算力、用更短的时间完成训练是最重要的事情。

陈伯超：所谓超大规模就是万卡以上。首先把这个网络架构搭出来，其实这就对设备有要求了。用多少台32口的设备都搭不出来这个规模的网络，最少要用64口的设备才能支撑起这样的端口密。规模大了，布线距离长了，要用一些长距离光模块。这都是硬件基础设施层面要考虑的。

第二个层面就是服务于算力的调度。规模大了之后，算力调度平台上的规则会非常复杂，会非常灵活。设计算力调度的人是不会考虑网络的，他认为GPU发出去的东西，网络就应该给我传过去。但实际上网络是有自己的转发规则和规律的，如果不做一些优化，主动与算力匹配，是满足不了算力调度平台的要求的。对于算力租赁，随着租户的变化，网络就得跟着调整，要把客户的数据隔离。

第三个层面是运维。在运维层面，可以顺着刚才配线架和ODF的话题说一下，ODF对于大规模的算力连接的正确性是一个非常大的挑战，没有一定经验的人去连这个光纤很容易连错的。1万张卡对应的就是4万个光模块，那这么多光纤一个都不错还是有一定的挑战的。另外，网络得保证训练的执行，很多客户在每次跑训练之前都得先测试一遍，包括集合通信库是不是能负载均衡？IP ECMP是不是都工作正常？网络吞吐是不是都正常？网络确定正常了，才能开始训练，毕竟算力资源很贵。

最后是安全的层面。随着业务和数据越来越丰富，可能也会涉及到一些敏感的、关键的数据。数据的安全防护包括一些加密规则，数据通道的可信程度，包括一些备份存储的手段。

王海峰：伯超老师，我顺便也问一下，现在以新华三举例来看的话，我们的交换机目前能够匹配到多少卡的规模？

陈伯超：如果是400G的话，我们现在是128 口，理论上三层架构是可以支持到50万张卡的。

王君原：网络规模大了以后，复杂性确实明显增加。布线是标准化程度极高的领域，你能想到的各种东西都有一个标准化。但是因为布线应用的场景比较多、比较广，所以在每个场景下的适用性可能不太一样。我们这两年在密切关注智算中心布线的问题，封老师在组织的一个标准中也有专门的章节在聊智算场景下布线的实施。大家如果对于基础设施的管理有兴趣的话，可以重点关注，这几年应该会有相应的布线标准和落地的。

封铎：通算的流量特点是流量很多，但每个流的数据量并不大。智算的特点是流量数少，但是每个流的量都很大。现在很多网络厂商都在做的一个工作是把原来的逐流路由，改为逐包路由。我想请教伯超老师，咱们现在是不是也有这方面的工作在做？

陈伯超：逐包交换机是可以做，但是它需要依赖网卡能够重组，因为逐包发之后，不一定按照发的顺序到，毕竟逐包就是为了走不同路径，会带来不同时延，到达可能就乱序，需要搭配支持乱序重排的网卡。其实对于大规模智算中心来讲，这个成本提升还是蛮多的。

我们今年发布了信元转发DDC（Diversified Dynamic-Connectivity，多元动态联接）架构，可以从交换机侧实现信元级切片转发，切碎了再重组都在网络内部进行，不依赖于网卡也可以实现负载均衡的最终效果。

封铎：IB 网络不存在这个问题，因为IB是用信令方式，先把通道打开，或者叫通道预留。但是RoCE是利用以太网，然后用哈希来去做均衡，有可能会造成“多打一”这种网络阻塞。有的场景把逐包叫做喷洒，就是切小，切小之后更容易分配得更均匀一些。

陈伯超：对，现在有几种技术路线。逐流需要解决哈希不均这个根本问题。哈希出来的结果不可控，所以要改输入，譬如改网卡的UDP 端口号，把端口号和交换机的哈希算法关联起来，哈希到不同的路径。我们的路线是要跟网卡协同，毕竟输入是来自网卡的，解决了输入问题才能解决哈希的极化问题。

王海峰：伯超老师，您刚才说的DDC架构，是不是前段时间发布的大规模集群交换机H3C S12500AI？

陈伯超：是的。DDC就是把数据切得很碎，然后就可以喷洒得足够均匀。然后这些喷洒的东西在交换机出口的时候又重新组装，变成跟原来一样。所以它会有几大好处：一个是性能足够高，二是不挑网卡、不挑GPU，什么流量来也不用做调优。其实对于网络运维来讲，最重要的就是针对算力调优，但DDC不用调优。

话题五：从成本角度考虑，智算网络如何选择更合适的方案？

张广彬：我先来抛砖引玉吧。Tomahawk 6的总带宽比Tomahawk 5提升了一倍。但就像前面都多次提过的，我们不要只看纯硬件的指标。之后出了Tomahawk Ultra，从表面上来看，它的总带宽、针脚兼容性方面都是跟着Tomahawk 5的。Tomahawk Ultra的硬件规格没有Tomahawk 6那么强大，但是它支持SUE，不仅用于Scale Out网络，也可以用在Scale Up。然后它还具有更短的延迟，支持包括链路重传等纠错机制，包括也把UEC的一些东西放到了里面。这也体现网络是个系统工程，在硬件上大力出奇迹是好的，但是也要有软件、协议等巧力。大力和巧力是不冲突的。

封铎：从整个组网上来说，假如延续现在的400G，从Tomahawk 6出来是102.4T的吞吐量，意味着256个400G的端口。用两层网络可能组网规模是256 × 128，大概是3.2万张卡。但假如我们单端口的带宽，用 800G 做，那么它的组网规模与上一代（51.2T、400G端口）齐平。所以，设备和芯片的性能提升提供了更大的组网规模的选择。

陈伯超：我谈一下我对博通这两颗芯片的看法，它的路标还是比较明确的，Tomahawk 6就是做

Scale Out 的，可以像刚才封老师说的两层做3万卡，节省了大量的设备和光模块数量，这对客户来讲价值很高。尤其是对万卡左右的，原来51.2T 两层够不着，得上三层的。另外说说大力出奇迹，Tomahawk 6有100G SerDes和 200G

SerDes两个版本， 200G就可以支持1.6T光模块了,

这是一个非常长生命周期、具有前瞻性的产品。

然后讲一下Tomahawk Ultra的SUE。这其实是试图满足Scale Up要求的以太网方案，它并不能达到真的利用 NVLink或者某公司私有总线来实现Scale Up的效果。它做了哪些工作呢？刚才广彬老师也说了，它降低了时延、减少了包头，然后做了一些转发纠错，包括一些链路预留的能力。它所做的其实就是让以太网的设备无限贴近于 NVLink的那一套系统，学习它们的精华，做了一个规模上超越NVLink，性能上稍弱的一个版本。

马斯克那20万卡，其实交换机是51.2T的，算是一个标准方案，是某企业的无损以太网。为什么能建得那么密呢？是因为它用了液冷，单机柜里放了 8 台服务器。一般的机柜放两台都算是非常胆大的了，一般就放一台。所以他的占地面积也不是很大，我估计他的网络中最长的一条光纤的距离可以控制在2公里以内。

张广彬：那也已经是单模光纤了。

陈伯超：两公里目前性价比较高的应该是单模。

王君原：没错。是从传输来说的话，50米之内的是多模，柜内可以是铜缆，然后50 米以上的话就是单模。但是单模也分并行，那是 500 米之内的；500 米以上到两公里之内的话，基本上就是双芯的单模。从目前的状态来看，800G 以上的传输，50米以上基本都是单模。

宋中伟：智算的需求推动了网络设备的迅速发展。之前交换机容量没有这么大，端口400G，那时候就有客户提出要超出256台的极限，希望1024台的组网。当时我们给客户建议是，成本远大于组网一个收益。然而现在也就过去了一年，交换机发展很快，400G的端口数量增加，还量产了800G。也就是说，随着模型参数量的增加，网络也会跟着有一定的提升。另外，组网框架也有更新，比如从RoCE V1，到现在的 RoCE V2。

在超大规模的集群里，训练的故障有34%是网络引起的，其中光模块的问题会比较突出。刚才有提到1.6T端口，虽然说已经发布了，但还没有普及。投入102.4T的交换机还需要一定的时间，可能还需要谨慎。

封铎：现在的训练方式，或者说集合通讯库这一块，已经对网络有影响。网络已经按照训练的模式进行优化和改造。现在整个组网的架构其实也在朝着这个方向来去调整，就是Scale Up这个趋势。

在直播过程中，观众积极与嘉宾进行了互动，如下是精选出来的几个问题以及回答：

观众问题1：数据中心在垂直方向布置是否可以减少布线距离和延迟？

张广彬：其实国内的一些大厂也提过上下楼的布局，上下左右是机房，把网络布置在中间。但是刚才我也提了，至少马斯克做到 20 万卡也还是用的平层。

封铎：关于垂直布缆有一个问题需要注意。垂直布缆都是用扎带绑在竖井里的梯架上。但是光纤只能用软绑带，不能扎得很紧，否则可能会造成光纤的损伤。那么问题就来了，假如楼上楼下只用光纤直布的话，重量只能靠光纤自身的护套来拉住，时间长了之后，护套可能会产生松弛现象，会影响到纤芯。如果纤芯承受拉力了，就会造成损伤。真正需要上下垂直布缆的话，我们通常是要考虑两端用光缆，然后光缆成端在ODF 上，但是这会造成潜在故障点的增加，增加施工复杂度。

王君原：对于垂直场景，需要选好抗拉、抗压符合垂直敷设需求的光缆。尽量不用跳线，因为跳线本身一根弱保护的光纤。但一旦采用光缆，肯定需要用到布线以及两端的配线设施，节点增加后，运维难度实际上是会增大。

观众问题2：某用户计划将GPU服务器和大模型知识库数据分别部署在同城两个不同的机房里，即算力和模型数据分离部署，确保数据不出域。请问这个方式可行吗？机房之间采用的是裸纤连接方式。

封铎：关键问题是两个节点距离是多远？他所说的裸纤，假如是不经过传输设备，那么我觉得距离应该是有限的。核心问题在于管道资源，怎么把裸纤给布过去。

宋中伟：我们是有实际案例去应用的。客户跟我们租赁算力设备组了一个推理的场景。他之前打算是知识库放在GPU服务器内，后来因为传输的问题，最终把知识库落在他本地。他并没有通过专线，而是通过1G互联网，直接调用DeepSeek 70B模型。

封铎：他有一个前提是数据不出域，也就是说都是在他这两个中心之间的连接，肯定不会放到公网上，所以需要自己布线。

观众问题3：CPO在智算网络中落地了吗？

陈伯超：光电共封装目前还没有规模落地，只有小的试运行。但我觉得这个东西目前来讲比较完美的方案。但是因为它是把光路都封装在芯片里了，这也导致它的对外输出的光信号模式都已经定了。国内用户目前还是希望能够自由选择，譬如说短距离就用多模的，能省点成本，长距离的够不着了，才买单模的。CPO的设计没有办法去兼顾所有的需求，只能统一都做单模的，对于客户的成本不是很友好。

观众问题4：长期的垂直主干抗疲劳度对损耗的影响有实测数据吗？

王君原：在机房场景下，其实垂直敷设的距离是很短，基本上是 10 米以内，光缆的自重其实是很小，即使在整个计算中心生命周期内，垂直敷设没有任何的影响。

封铎：我觉得他这个问的应该是只是光纤。如果是光缆的话，实际施工的时候会把它紧紧地绑扎在竖井里的梯架上，光缆护套也不承受重量的，重量都卸载在梯架上。而且本身光缆护套就会考虑保护，甚至还有一些铠装光缆都可以选择。但是对于光纤来说这个就是另外一个情况了，用软绑扎并不会加一个很大的力，而且它是成捆的，在没有结实捆扎的情况下，个别的光纤有可能会承受全部光纤的重量。这个是在工程上必须要考虑的问题，因为在真正布线的时候，做不到特别均匀，每根光纤先承受自己的重量这种理想状态是做不到的。假如长期疲劳之后，护套松懈了，那么故障可能会是批量出现，就像爆豆一样，开头可能是短暂的一个两个，后面可能是连串的故障就很可怕了。

王君原：如果用光纤跳线的风险的确是很大，是毋庸置疑的。因为跳线本身应用场景就不是垂直的。在垂直应用场景里面应该避免使用跳线，尽量是用光缆。

观众问题5：结构化布线和设备之间的直连布线，哪个会成为主流？

王君原：这个一直有争论，其实也没有定论，还是要根据组网的规模来选择。比如说一个小型的组网形式，几个机柜之间的互联，或者说单个机柜TOR、多个机柜TOR这样的互联结构，选择直连就可以了。在智算中心里面，组网结构特别复杂，然后又遇到了单对多的需求，甚至还提到有跨楼层的情形，从工程的角度、从稳定性的角度、从维护的角度来说，结构化布线肯定是更好的选择。

但是用户通常会关注两点，第一个前期的布线投入，第二是对布线做有效的维护。在智算中心里，光模块的损耗实际上是蛮大的，它是潜在故障节点。一旦光模块出问题，就会需要去做一些布线上的跳接。跳接和维护的过程相对于直连来说在效率上肯定是会有很大的提升。需要从整体的智算中心运维生命周期去看，哪种方案更适合。

封铎：这个问题大致可以从不同的网络平面来区分处理。比如传统的业务面、管理面、存储面，保持结构化布线是没有什么问题的。但是对于参数面、数据面，我们现在还是比较推荐直连这种方式。主要是因为直连可以有效减少故障点。只要经过跳接，每一个跳接点都是我们的故障点，而且它会引起光的衰耗。光的衰耗会影响传输距离，尤其是高带宽真的对衰耗

比较敏感。

要观看此次直播的更多细节，请关注益企研究院视频号，搜索7月24日主题为“智算中心的网络应该如何选择”，或者点击阅读原文，观看直播回放。