围绕AI加速芯片构建数据中心网络仿真环境:实现网络感知级验证(2026 OCP APAC Summit)

一、单芯片指标无法外推集群表现

针对在封闭实验室测试单芯片峰值并据此推演集群表现的做法，Ashutosh Kumar指出：“单芯片在孤立环境下的静态测试数据，无法反映其在集群环境中的真实表现。”

芯片在实验室通常侧重峰值TFLOPS与Memory带宽等微架构参数。但在分布式训练中，单芯片离线测试达标，接入集群后仍需承受通信依赖链级联、微秒级拥塞蔓延与连接状态激增的系统级压力。决定系统整体MFU的关键瓶颈，从来不在单芯片本身，而在互联网络架构与交互逻辑。

二、发送数据流过于激进易导致吞吐崩溃

针对集合通信启动时是否应尽快打满线速的疑问，在对比芯片实测FCT分布时，Suranjan Saha指出：“DUT A在启动阶段几乎瞬间并发下发全部Flow，导致Fabric内部发生严重拥塞，FCT大幅恶化；测试中出现的性能断崖式下降，并非由于硬件算力达到物理上限或网络承载力不足，而是源于芯片自身的Egress Flow调度逻辑缺陷。”

测试表明，在微秒级窗口内交错发送数据流的芯片（DUT B）为Buffer预留了吸收空间，全程稳定维持在400Gbps Line Rate；而激进抢占带宽的芯片（DUT A）在扩展到128个Rank时触发严重Incast，总线有效带宽直接出现断崖式下跌。单纯堆砌物理带宽无法规避网络阻塞，具备网络感知能力的数据流调度算法才是核心要素。

三、平均吞吐指标掩盖长尾瓶颈

针对习惯以平均带宽利用率评估网络健康的运维方式，在剖析集合通信损耗时，Ashutosh Kumar强调：“平均值与极值指标无法体现系统真实状态；在集合通信的同步机制下，系统整体吞吐与执行效率受制于尾部延迟。”

在BSP同步机制下，集群的计算节奏完全受限于传输耗时最长的数据流。在万卡集群中，即便99.9%的数据流实现低延迟传输，只要极少数Flow因微秒级排队产生长尾延迟，也会导致所有计算节点在Barrier前被迫等待。平均吞吐数据掩盖了局部的队列阻塞，聚焦尾部FCT分布才是评估互联效能的标准尺度。

围绕AI加速芯片构建数据中心网络仿真环境：实现网络感知级验证

目录：

• 芯片验证与前置集群构建困境
• 规模效应带来的三类核心影响：集合通信、网络拥塞与连接状态
• 基于MLCommons Chakra DAG模拟流量行为
• 测试平台架构与双仿真模式
• 案例剖析：流调度与尾部延迟分析
• 核心结论与技术演进方向：面向AI Fabric的测试左移

芯片验证与前置集群构建困境

Ashutosh Kumar： 大家好，希望大家都能听清我的声音。欢迎参加我们的技术演讲，感谢各位到场。我是Ashutosh，旁边是我的同事Suranjan，我们都来自Keysight。在开始前，我想向Keysight团队以及与我们合作的其他机构致谢，正是这些优秀成员的付出促成了本次分享。我们今天重点探讨所有AI芯片团队都会遇到的痛点：芯片从晶圆厂回片之后，团队需要在集群环境中做验证，但此时物理集群根本还没有建好。面对这种情况，我们该怎么做？

我们先看受测设备，也就是DUT。这里的DUT指的是AI/ML芯片，内部包含计算单元和HBM，同时配备一个或多个RDMA NIC。这些网卡可以做在Die内，可以封装在同个Package内，也可以是独立的适配卡。在实际测试中，DUT代表参与集合通信的单Rank。从定义上看，集合通信操作必须有多个Peer节点共同参与。既然如此，为什么不直接搭建集群在真实系统里测？现实情况是，芯片交付的时间点通常远早于集群搭建完成的时间。

集群建设涉及机柜、Switch、液冷、光模块等各个环节，还需要打通CCL集合通信库与上层框架的集成。如果一直干等到集群完全就绪，这期间宝贵的几个月时间就已经彻底浪费了。在小规模节点的Bring-up实验室里，如果发现问题，还能通过固件修复解决；但如果是等到第一批大规模集群搭建完成才发现问题，这时候往往无法直接修改固件，只能靠打补丁绕过，继续勉强推进。用少数几个节点做测试固然很有价值，但这根本无法暴露只有在大规模集群下才会显现的问题。

规模效应带来的三类核心影响：集合通信、网络拥塞与连接状态

Ashutosh Kumar： 在大规模集群下，主要会出现哪三类效应？第一是集合通信行为的变化。从4个Rank、8个Rank一路增加到1000个Rank，集合通信的行为模式完全不同。以AllReduce环形算法为例，8个Rank对应的是14步依赖链，而1024个Rank会拉长到2046步依赖链。许多CCL通信库还会根据Rank数量动态优化算法，在树状算法和环形算法之间切换。

第二是拥塞响应机制。当芯片检测到拥塞信号时，必须做出响应：主动降速，随后逐步恢复。整个闭环控制必须具备极高的可预测性，才能达到预期的吞吐性能。而随着参与集合通信的Rank数量增多，这种确定性会大幅降低。

第三是芯片本身的连接状态开销。芯片通常需要在片上SRAM中缓存每个Peer节点的信息。在集合通信执行期间，如果只有7个或8个Rank，所有状态都能完整放进SRAM缓存，不会产生任何性能惩罚；但当规模扩展超过1000个Rank时，片上缓存根本装不下这么多连接状态，这会导致缓存缺失，必须频繁访问片外内存，造成严重的延迟与吞吐损失。这类问题只有在真正的大规模扩展时才会暴露出来。

基于MLCommons Chakra DAG模拟流量行为

Ashutosh Kumar： 显而易见，我们的核心目标是在单颗DUT周围仿真出大量的Rank节点。但首先要搞清楚，从DUT的视角看，物理链路上的流量行为特征是怎样的。每个Rank在执行时都有预设的集合通信缓冲区大小，通信组内所有Rank的缓冲区大小相同。在执行集合通信操作时，往往会通过多个独立的通道并行传输，总缓冲区容量会被切分到这些通道中。每个通道分担的数据再拆解成一系列RDMA消息，每条RDMA消息由一个或多个数据包构成，通常与4KB的IB MTU对齐。

如果把整个集合通信执行过程投射到时间轴上，会看到非常明显的模式：瞬时突发传输后伴随一段空闲等待。我们仿真的节点必须在物理链路上精准复现这种突发流量模式。突发模式本身取决于具体的AI工作负载特征。从宏观维度看，AI工作负载由一系列计算操作与通信操作组合而成，这可以直接用有向无环图（DAG）来建模，其中节点代表具体操作，边代表依赖关系。例如，AllReduce通信节点必须在左侧的计算节点执行完成后才能触发。

MLCommons的Chakra项目正是针对这种场景制定的开放可交换DAG格式。开源社区提供了成熟的工具链，可以直接从PyTorch等框架中提取真实的执行Trace，转换为Chakra Trace，再展开为每个Rank的专属DAG并分发给对应Rank执行。仿真Rank在执行到计算节点时，无需执行真实算力消耗，只需模拟对应的计算耗时窗口；而执行到通信节点时，则会根据AllReduce、ReduceScatter或点对点Send/Receive等不同算子，在物理链路上真实收发RDMA流量。

测试平台架构与双仿真模式

Ashutosh Kumar： 这就是我们测试平台的实现思路。系统以DUT为中心，发出的流量标记为DUT TX，接收的流量标记为DUT RX。DUT通过高速接口连接到一个或多个硬件测试端口，每个硬件测试端口都具备线速仿真RDMA流量的能力，兼容RoCEv2或各类自定义私有协议。在硬件测试端口后方，我们通过纯软件方式仿真整套Scale-Up或Scale-Out网络Fabric架构，并能在网络链路的任意位置注入故障与网络损伤。在这套软件仿真的Fabric后端，各个端点连接的就是执行Chakra DAG的仿真Rank，从而完整复现真实AI工作负载的通信流量。

测试平台支持两种基础测试模式。第一种模式是将DUT连接到多个独立的物理硬件测试端口，每个物理端口仿真一个RDMA NIC和一个Rank。这种模式具备高保真线速带宽，能真实复现多对一Incast等拥塞场景。第二种模式是将DUT连接到单物理硬件端口，该硬件端口仿真Switch角色，并在后方通过软件虚拟化出多个仿真Rank及对应的仿真网卡。这种模式主要用于验证海量Peer节点场景下的网卡连接状态扩展性，虽然单Rank无法占满物理线速，但能精准测试芯片面对数千个连接时的状态维护能力。

对于All-to-All这种对称型集合通信算子，第二种模式不仅扩展能力极高，而且能完整体现网络动力学特征。接下来我们将展示如何利用这一模式定位并排查芯片的性能瓶颈。下面请Suranjan为大家介绍具体评测数据。

案例剖析：流调度与尾部延迟分析

Suranjan Saha： 正如Ashutosh前面介绍的，图上展示的是16个Rank在不同集合通信缓冲区大小下执行All-to-All算子测得的总线带宽曲线。我们对比了两种仿真模式：蓝色曲线代表每个物理测试端口仿真1个Rank，总计使用15个物理硬件端口；橙色曲线代表单个物理测试端口后方仿真15个Rank；绿色横线是400Gbps物理链路理论带宽。

因为All-to-All操作将带宽均匀分配给16个Rank，每个Rank获得可用带宽的十六分之一。从图上可以看到，两种仿真模式的数据曲线高度重合，这充分证明通过单物理端口仿真多Rank的方案完全能够提供极高的置信度，可直接用于后续的大规模扩展评测。在小缓冲区配置下，实测总线带宽大约在100Gbps左右，随着传输数据量增大，带宽逐步拉平并接近物理线速。小数据包阶段的性能爬坡主要受协议栈开销影响，并非网络拥塞导致，否则在数据包数量更多的大数据块阶段，性能反而应该出现下滑。

随后我们使用相同的测试平台对比了来自两家不同供应商的DUT。图中橙色代表的DUT B表现极佳，测得的总线带宽非常接近400Gbps物理线速；而DUT A的总线带宽最高仅达到310Gbps左右。为了深入探究背后的根因，我们将单次测试的集合通信缓冲区固定为1GB，确保传输的总数据量保持恒定，随后将Rank数量从16持续扩展到128。

测试结果显示，DUT B全程保持稳定的水平输出，紧贴物理链路极限，这完全符合恒定数据传输下的预期表现；但DUT A在小规模Rank下虽然能维持在300Gbps左右，一旦Rank数量从64增加到128，性能便出现了断崖式下跌。这表明该现象并非固定的硬件开销所致，更大概率源于DUT A内部的数据流调度策略缺陷。

为了进一步查明问题，我们将DUT A的网络流量拆分为接收方向（DUT A RX）与发送方向（DUT A TX）分别进行观测。图上清晰显示，DUT A的RX带宽全程稳定在350Gbps左右，没有任何跌落现象；然而TX发送路径则完全复现了此前的断崖式暴跌。这一对比明确证实，瓶颈既不在DUT的接收链路上，也不在外部网络Fabric上，问题完全出在DUT自身的出向流调度算法上。

这张图绘制了两组累积分布函数（CDF）：左图是数据流起始发送时间的CDF分布，右图是流完成时间（FCT）的CDF分布。此前性能表现较差的是DUT A。从左图可以明显看出，DUT B将所有数据流的发起时间做了平滑交错调度，整个启动过程持续约1.66毫秒，避免了流量瞬间集中下发造成网络缓冲区溢出；反观DUT A，几乎在同一瞬时将所有数据流并发打出。瞬时冲击直接导致Fabric内部发生剧烈拥塞，大幅抬高了队列排队延迟，导致最终的长尾流完成时间显著恶化。右侧FCT分布图中，DUT B的整体完成时间显著优于DUT A。此前观察到的性能断崖和平台期瓶颈，根本不是物理硬件或Fabric架构缺陷，而是芯片内部的流调度逻辑在起作用。如果只看总线吞吐平均值，根本无法察觉这种问题，必须借助感知网络的深度验证方案，结合流启动时序和尾部FCT分布才能精确定位。接下来请Ashutosh做最后总结。

核心结论与技术演进方向：面向AI Fabric的测试左移

Ashutosh Kumar： 我们总结出的第一条核心结论是：单芯片在孤立环境下的静态测试指标无法预测其在集群环境中的真实表现。团队必须在物理集群搭建就绪之前，就将大规模网络环境引入验证流程。通过仿真周边Fabric架构，无需动用数千张物理板卡或堆叠庞大的物理Switch网络，即可精准复现芯片在真实集群下的工作状态。

第二，验证必须重点关注长尾分布与恶劣工况。平均值和最大最小值指标往往会掩盖单条数据流的阻塞细节，而在集合通信的同步屏障机制下，尾部流完成时间直接决定了上层业务的整体执行效率。这种测试左移的方法，通常采用单臂测试形态（即一端连接真实的DUT芯片，另一端对接仿真网络测试设备），能帮助芯片团队在流片回片后、集群交付前，提早发现并修复固件与协议引擎中的深层缺陷。

从后续推进方向来看，首先是建立标准化的自动化基准评估方案，实现测试完成后自动生成诊断报告定位故障；其次是进一步深化硬件端口后方的拓扑感知能力，在仿真Fabric中支持精细化构建拥塞树与网络损伤注入；最后是推动测试算子从基础的AllReduce、All-to-All扩展到完整的Chakra DAG工作负载回放，直接运行Llama 3或Mixture-of-Experts等真实模型的通信Trace。

以上是今天分享的全部内容，大家如果有问题我们可以现场交流，也可以到场外继续讨论。非常感谢大家。

Suranjan Saha： 谢谢大家。