AI时代的数据中心，正在被网络“卡脖子”丨ToB产业观察

过去几年，人们习惯用单颗GPU的算力指标来衡量AI基础设施的先进程度。但在2026年，算力竞赛的底层逻辑已经被改写。当大模型训练集群从千卡迈向万卡甚至十万卡，真正的瓶颈早已不是芯片算力，而是网络。就像一条高速公路，车道修得再宽，如果收费站堵死了，车还是跑不起来。AI集群正在遭遇的，正是这样一场拥堵。 GPU在等数据 先看一组数据。 是德科技 网络与数据中心副总裁Joachim Peerlings在Keysight World大会上展示了一组令人深思的数字：在计算机视觉模型训练中，GPU有超过60%的时间花费在数据移动和通信上，真正用于计算的时间仅占20%左右。换句话说，一块昂贵的GPU，大部分时间不是在“算”，而是在“等”，等数据从隔壁的GPU传过来。 这还不是最糟糕的。在资源最密集的大语言模型训练任务中，因网络问题导致的训练失败率高达21%。每五次训练就有一次因为网络问题而中断，而一次中断可能意味着数小时甚至数天的计算成果付诸东流。 中科曙光 高级副总裁李斌算过一笔账：传统CPU计算节点，一台机器配一张网卡就够了；但如今以GPU为中心的计算节点，一台机器需要配置八张甚至更多网卡。“相比原来的数据中心高速网络用量，基本提升了10到20倍。” 更棘手的问题在于，上万张卡需要在同一时间高度协同工作，任何一个节点的网络抖动、拥塞或丢包，都可能导致成百上千张卡进入等待状态。 今天的AI大模型训练集群，单端口流量已经逼近400G。但传统网络的负载均衡算法依然停留在“逐流ECMP”的时代，这种模式将每一条数据流通过哈希算法分配到某一条链路上。问题是，AI训练的流量模式需要成千上万个GPU同时发起通信，流量像潮水一样涌来，哈希算法根本来不及反应。结果就是部分端口满载，部分端口闲置的资源错配。 相比传统ECMP方案，新的端到端负载均衡方法可将网络带宽利用率提升最高38%，模型训练任务时长缩短超过3%。38%的带宽提升和3%的训练加速，听起来不算惊人，但在十万卡集群里，3%可能意味着节省数百万美元的电力成本和数周的研发周期。 而这些困境的底层原因是因为，芯片算力的增长速度，已经远远超过了数据在芯片之间搬运的速度。这也就造成了网络已成为制约AI集群发展的核心因素。 重新思考AI需要的网络 面对这样的矛盾，一个最本能的反应是堆硬件，堆更高速的光模块，堆更大端口的交换机，堆更粗的铜缆。从400G到800G再到1.6T，接口速率每隔一两年就翻一倍。但这条看似最直接的路，正越走越窄。 对此，是德科技网络应用安全部门技术经理杨益锋表示，当前带宽翻倍的速度，远远追不上模型规模翻倍的速度。一个典型的大语言模型，参数量从千亿级到万亿级只用了不到两年，而光模块从400G迭代到800G再迭代到1.6T，每一次跃进背后都是漫长的产业链协同。更关键的是，带宽翻倍带来的成本、功耗和散热压力是指数级增长的，到了某个临界点之后，每提升1G带宽所付出的代价会让任何财务总监都皱眉头。 与此同时堆硬件也带来了ROI的问题。杨益锋告诉我们，不少企业在落地AI网络时，都踩过同一个坑：为了提带宽买了一批最先进的高速交换机和高性能光模块，兴致勃勃地上架，结果一跑大模型训练，算力利用率远没达标。一位互联网大厂的基础设施负责人曾对我们表示，设备采购花了几个亿，实际跑起来发现，三分之一的算力都损耗在网络等待上，相当于每三台GPU就有一台在空转。 造成这种情况主要是因为：AI网络的性能瓶颈，往往不在设备本身的标称规格上，而在于流量调度机制的精细度。你可以把带宽修到400G、800G，但如果流量调度依然靠“蛮力”，大部分带宽依旧是被浪费的。 也正是在这个背景下，行业开始从堆硬件转向了，如何通过协议、软件等方式，让数据流跑得更顺畅。 传统的TCP/IP网络，是为人与人通信设计的，比如网页请求、邮件发送、文件下载，这些场景中流量随机且不着急，丢几个包大不了重传。 但AI网络完全不同，GPU集群内部通信是“机器与机器”的对话，周期性极强、同步要求极高。在大规模模型训练中，所有GPU必须在一个同步周期内完成全部梯度交换，任何一个慢节点都会拖垮整个集群。这就形成了“木桶效应”，在AI网络里，一个微小的网络抖动，就是那块最短的板。 在此背景下，LLR与CBFC这两个原本并不受关注的技术开始被AIDC运营方关注。 其中，LLR把重传机制下沉到链路层，让交换机自己发现丢包、自己重传，不等上层发号施令，把恢复时间从毫秒压到微秒级，解决了传统IDC网络中，因一个数据包丢失引发的重传延迟。 CBFC则可以理解为是一个“网络红绿灯”系统。发送端在发数据之前，先确认接收端有足够的缓存空间再发，避免数据发过去了对方装不下、只能丢弃。听起来很基础，但在大规模AI集群里，成百上千个发送端同时向一个接收端汇聚流量时，这套红绿灯系统的协调精度直接决定了网络的通畅程度。 今年3月，是德科技与Broadcom在OFC 2026上完成了业界首个基于超以太网联盟规范、在800GE线速下实现LLR和CBFC的公开互操作性演示。这标志着这两项技术正式从实验室协议走向了真实的互联互通。 但从协议到大规模现网部署，还有很多路要走。不同厂商的设备、不同的网络拓扑、不同的工作负载，都需要精细化的参数调优才能让LLR和CBFC真正发挥威力。协议写好了，标准通过了，但到了真实的生产环境，每一个参数设置都可能影响网络性能的成败。 更关键的是，调参的前提是得先知道网络到底哪里出了问题。而这则引出了AI网络验证这个最容易被忽视的命题。 测通非真通 网络环境搭建好了，如何确认它真的能跑顺了？很多企业在服务器买回来了，交换机上架了，线也插好了，标准测试跑了一遍，显示带宽达标、延迟正常，一切看起来完美。但一跑大模型训练，问题就来了：要么频繁掉线，要么速度上不去，要么莫名其妙地卡住。 对此，杨益锋表示，这个问题主要出在了验证环节。他从Scale-Up、Scale-Out和Scale-Across三个维度，分享了是德科技对AI网络验证的些许看法。 杨益锋认为，这三个环节中，最容易被企业忽视的就是Scale-Up环节，“Scale-Up发生在机柜内部，距离短、看起来技术含量不高，很多企业采购完服务器，插上线就认为Scale-Up网络已经Ready了，”杨益锋进一步指出，“但恰恰是这些短距离的连接，承载着最密集、最频繁的数据交换。GPU之间每一次参数同步、每一次梯度聚合，都要通过Scale-Up网络完成。一旦这里出了问题，整个集群的性能都会打折扣。”更麻烦的是，Scale-Up涉及的技术正在快速迭代，LLR和CBFC的关键应用场景就在这个维度。 与此同时，Scale-Out和Scale-Across方面企业依旧面临着不少的挑战。Scale-Out涉及大量交换机之间的互联，拓扑复杂、路径繁多，传统验证方式，验证不了真实负载下的性能；Scale-Across则面对长距离传输的延迟和可靠性问题，在跨数据中心协同训练的场景下，光速本身都成了限制因素。 是德科技的一项调查显示，95%的运营商认为真实工作负载测试对AI网络验证至关重要。但现实是，很多企业在部署AI网络时，依然在用传统数据中心的测试方法，比如跑几个标准benchmark，测一下带宽和延