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，测一下带宽和延迟，就认为没问题了。等到真正跑大模型训练时，才发现问题层出不穷。
这是因为传统数据中心的网络，承载的是可预测的流量，比如网页浏览、视频播放、文件下载等流量模式相对稳定。但 AI 网络的流量模式突发性强、东西向流量巨大、对丢包和延迟极度敏感。在 AI 训练中，哪怕一个数据包的丢失，都可能引发连锁反应，最终导致整轮训练失败。杨益锋坦言，未来五年 AI 集群的东西向流量将增长 10 倍或更多，等 GPU 到位再测试网络的旧模式根本无法扩展。企业如果不能及早建立系统级的网络验证能力，堆再多的硬件也只是摆设。
值得注意的是，这种现象在推理场景中尤为明显。过去的大模型推理，用户提交一个任务，系统批量处理，等个十几秒甚至几十秒出结果，大家都能接受。但现在，AI 正在嵌入对话系统、实时翻译、自动驾驶、金融高频交易等场景都要求 AI 做出毫秒级响应。
在推理场景中，有两个关键时延指标：首 Token 时延（用户发出请求到收到第一个输出 Token 的时间）和 Token 间时延（后续 Token 之间的间隔）。" 首 Token 时延决定了用户有没有反应的感知，而 Token 间时延决定了整个交互过程的流畅度。如果 Token 间时延不稳定，对话就不会流畅，用户体验瞬间崩塌。" 杨益锋指出。
这也就意味着网络不仅要快，还要稳。传统网络可以容忍偶尔的抖动（视频卡一下，文件下载慢几秒，不会太影响体验）。但在实时推理场景下，每一次抖动都会直接转化为用户感知到的 " 卡顿 "。而网络验证的目标，也从能不能跑到标称速率，变成了在最恶劣的流量冲击下，时延和抖动能不能稳定在承诺范围内。
当十万卡集群成为标配，实时推理渗透进每一个日常应用，网络就不再只是传输流量的管道，而是决定 AI 算力能否真正释放的 " 命门 "。网络也不再只是简单的堆硬件，只有搭建起真正可靠的系统，才能让网络不再是卡住 AI 发展的阻碍。
（文｜Leo 张 ToB 杂谈，作者｜张申宇，编辑丨杨林）
