下一代LLM推理网络：ZCube如何缓解网络瓶颈？

LLM推理正在重塑AI基础设施。网络曾经是推理集群中最不引人注意的部分，但如今已不再如此。随着长上下文推理和Prefill-Decode分离架构成为主流，网络已处于吞吐量、尾延迟和每token服务成本的关键路径上。

为了应对Prefill-Decode分离部署中日益严重的拓扑拥塞问题，Z.ai、Harnets.AI和清华大学联合开发并在线上生产环境中部署了ZCube网络架构。部署结果表明，在网络架构层的系统级创新可以以一种极具成本效益的方式释放硬件潜力。

在GLM-5.1编码工作负载的生产基准测试中，ZCube仅通过架构优化就带来了显著收益：

• 成本优化：GPU、软件栈和应用程序保持不变，而交换机和光模块的资本支出减少了33%。

• 吞吐量提升：平均GPU推理吞吐量提高了15%。

• 延迟改善：TTFT P99降低了40.6%。

拥塞的根本原因在于推理流量模式的变化。随着PD分离成为主流，跨节点KV Cache传输使推理流量高度不对称，源、目的地和流量大小动态变化。在传统的ROFT（Rail优化胖树）架构中，静态拓扑和端口映射很容易将流量集中到有限的交换机和链路上，导致局部热点、队列积压和PFC反压。这就造成了一个结构性问题：总带宽看起来足够，但局部拥塞却频繁发生。

ZCube通过使用完全扁平化的网络拓扑以及混合单轨/多轨接入设计来解决这个问题。在网络架构层，它将PD流量解耦并分布到更宽的路径空间中，从源头上降低了拓扑引起的拥塞概率。这为下一代超大规模推理集群提供了更高效的网络基础。

图1：与ROFT相比，ZCube有效避免了拓扑引起的网络拥塞

图1：与ROFT相比，ZCube有效避免了拓扑引起的网络拥塞

网络成为高效推理的瓶颈

当数千个GPU同时服务在线推理请求时，每一次KV Cache传输和每一次数据同步操作都要经过GPU间网络。随着长上下文推理和Prefill-Decode分离推理逐渐成为主流，Prefill与Decode节点之间的数据交换持续增长。网络带宽，以及更重要的——如何有效利用它，已经开始直接影响集群级别的吞吐量和延迟。

为了量化网络对推理性能的影响，我们首先在512-GPU集群上进行了一项消融实验。我们保持GPU计算、软件栈、模型和应用逻辑不变，仅调整可用的NIC带宽上限，然后测量整体集群吞吐量和首Token延迟（TTFT）的变化。

图2：不同网络带宽设置下的整体集群吞吐量和TTFT

图2：不同网络带宽设置下的整体集群吞吐量和TTFT

例如，当网络带宽从100Gbps增加到200Gbps时，整体推理吞吐量提高了约19%，而首Token延迟（TTFT）降低了约22%。这表明，在LLM推理中，网络带宽已成为制约服务性能的关键因素之一。

1. 推理中的网络拥塞

如今，AI集群普遍采用Clos或胖树架构。基本思想是通过堆叠多层交换机来扩展网络。然而，Clos网络的性能在很大程度上依赖于交换机之间的理想负载均衡，而在实际中，由于路由策略和真实流量模式的影响，这一点很难实现。

例如，在许多两层Fat-Tree部署（由Spine和Leaf层组成）中，不同Spine交换机之间的流量可能严重失衡。结果，上层应用往往无法获得预期的网络性能。

为了减少跨层转发的开销，业界经常采用ROFT（Rail优化胖树）架构[1]。如图3所示，ROFT按索引（“rail”）对GPU进行分组，并将相同索引的GPU连接到同一个Leaf交换机上，从而降低了跨Spine交换机的通信开销。

图3：在ROFT中，Leaf交换机之间的流量容易失衡

图3：在ROFT中，Leaf交换机之间的流量容易失衡

ROFT对某些训练流量模式效果良好。然而，在Prefill-Decode分离推理中，我们观察到一个更突出的问题：KV Cache传输表现出强烈的源-目的不对称性。不同的GPU和不同的NIC承载着高度不均的通信负载，如图4所示。结果，ROFT的rail映射不再自然地转化为负载均衡。相反，流量可能会集中到少数Leaf交换机和链路上，导致链路拥塞和传输性能下降。

这表现在以下几个方面：

• 一些Leaf交换机成为持续的负载热点，增加了多个KV Cache传输流在同一链路上竞争的概率。结果，实际传输吞吐量可能远低于NIC带宽容量。

• 某些Leaf交换机上的出口队列长时间保持高深度，并频繁触发PFC反压，如图5所示。

• 链路拥塞进一步放大了尾延迟，同时影响TTFT和整体吞吐量。

图4：同一台机器上不同NIC之间的KV Cache传输负载不均衡

图4：同一台机器上不同NIC之间的KV Cache传输负载不均衡

图5：某些Leaf交换机端口上频繁的PFC暂停事件

图5：某些Leaf交换机端口上频繁的PFC暂停事件

有必要区分两种类型的网络拥塞，如图6所示：

• 不可避免的拥塞：例如，当多个GPU同时向同一目的地发送数据时，最后一跳链路上的争用是不可避免的。

• 可避免的拥塞：由拓扑设计、流量映射或多路径利用率不均衡引起。从根本上说，这是一个架构层面的设计问题。

图6：两种网络拥塞的示意图

图6：两种网络拥塞的示意图

对于第一种拥塞，我们通常依靠拥塞控制、流量整形等机制来缓解其影响。对于第二种拥塞，新的网络传输机制如自适应路由[2]、包喷洒[3,4]和MRC[5]可以提供帮助。然而，更有效的方法是通过网络架构层的创新，从源头上防止本不应发生的网络冲突。

Prefill-Decode分离推理就是一个典型的例子。如果网络拓扑无法匹配流量模式，系统将反复产生负载热点和链路冲突。解决这个问题需要重新思考推理网络架构本身。

2. ZCube网络架构

为了解决上述问题，我们部署了一种新的ZCube网络架构[6]。ZCube打破了传统的Clos分层交换机堆叠设计理念，引入了完全扁平化的GPU服务器互连。

针对ZCube架构专门设计的ZCube路由策略充分利用了扁平拓扑的结构特性。它可以在网络中的所有交换机上实现接近理想的负载均衡，从而显著提升整体集群网络带宽。

与Clos相比，ZCube在负载均衡方面具有天然优势。这一优势对训练集群和推理集群都有好处。重要的是，ZCube在实现这些性能提升的同时，与Clos相比还降低了约三分之一的交换机和光模块成本。基于当前主流的交换机和NIC配置，ZCube可以支持数万甚至数十万个GPU的扁平化组网。

2.1 ZCube核心架构

如图7所示，ZCube的核心思想是：

• 移除Spine交换机层。

• 将Leaf交换机分为两组，大小相等，通常为奇数编号交换机和偶数编号交换机。

• 在两个交换机组之间建立完全二分互连。

• 使用单轨和多轨接入模式，将每个GPU NIC的两个端口分别连接到两个组中对应的交换机。

图7：ZCube架构概览

图7：ZCube架构概览

假设每个GPU对应一个双端口的NIC，即p=2。总共有n个GPU，GPU和NIC共享相同的索引：1,2,…,n。令k表示每个交换机连接的GPU数量。交换机总数为2n/k，编号为1,2,…,2n/k。对于GPU i，其中1≤i≤n：

• 第一个端口连接到奇数编号交换机：

((i−1)mod(n/k))×2+1

• 第二个端口连接到偶数编号交换机：

⌈i/k⌉×2

两个交换机组之间以完全二分图方式连接：每个奇数编号交换机与每个偶数编号交换机相连。

在双端口NIC配置下，p=2,n=32,k=8的ZCube拓扑如图7所示。

2.2 ZCube的关键特性

网络直径

ZCube的网络直径为两跳交换机，即任意一对GPU可以通过两台交换机互相到达。这介于单层交换机网络（一跳，但规模有限）和传统两层交换机网络（支持更大规模，但通常需要三跳，延迟更高）之间。

负载均衡

首先，ZCube路由策略确保每对GPU之间有一条唯一的最优路径，避免了多路径路由选择导致的流量冲突。

其次，ZCube使用了两种互补的GPU到交换机连接模式。一个交换机组以单轨模式连接GPU，每个交换机连接一段连续的GPU ID。另一个交换机组以多轨模式连接GPU，每个交换机连接各组中具有相同相对索引的GPU。

这种设计使得ZCube能够在典型的AI训练流量模式（如AllReduce和All-to-All）以及典型的AI推理流量模式（源-目的关系不确定，NIC负载可能高度不均衡）下，在整个交换矩阵上实现高度有效的负载均衡。

因此，ZCube可以从架构层避免前面描述的第二种网络拥塞。如图8所示，在ROFT下会冲突的流量流在ZCube下可以获得专用的网络路径，从而避免拥塞。

图8：ZCube架构下的负载均衡

图8：ZCube架构下的负载均衡

可扩展性

ZCube在保持其优越性能特性的同时提供了强大的可扩展性。例如，使用一层51.2T交换机，每台交换机具有128个400Gbps端口，ZCube可以构建连接16384个400Gbps NIC的网络。如果使用更高容量的交换机，或者将ZCube网络划分为更多平面，该架构可以进一步扩展到支持数万甚至数十万个GPU的互连。

成本

在相同的集群规模下，与传统的Clos/ROFT架构相比，ZCube可以降低约三分之一的交换机和光模块成本。例如，在一个10000-GPU的AI集群中，ZCube可在网络硬件投资上节省约2.1亿至6.4亿元人民币。这些特性表明ZCube可以在降低网络硬件成本的同时实现更好的负载均衡和性能。

2.3 实际集群测试：提升推理性能的同时降低网络成本

我们将一个运行GLM-5.1编码推理服务的千卡集群的网络架构从原有的ROFT升级为ZCube架构。由于ZCube架构取消了传统Clos架构中的Spine层交换机，原有Clos框架下建立的布线路由、IP寻址方案、路由策略和交换机配置方法无法直接复用，需要针对ZCube进行全新设计。

为了应对这些挑战，Harnets.AI网络团队设计了一套以ZCube架构为核心的综合网络解决方案。他们开发了一系列自动化工具，包括ZCube Controller、数据中心布局设计工具和布线正确性验证程序。这实现了数据中心部署规划、布线验证、自动配置生成和批量部署等功能，有效解决了ZCube部署中的诸多难题。这一套工具是在极短的时间内成功完成大型生产集群架构迁移的关键因素。

在无缝完成网络架构迁移后，我们在该集群上运行GLM-5.1编码推理服务，对ZCube架构进行了实际测试。通过对比集群升级前后的推理性能，我们发现，与ROFT架构相比，ZCube将平均GPU推理吞吐量提高了15%以上（如图9所示），同时将TTFT的P99尾延迟降低了40.6%。

图9：同一集群中ZCube与ROFT架构的吞吐量和TTFT对比

图9：同一集群中ZCube与ROFT架构的吞吐量和TTFT对比

总之，对于相同规模和配置的GPU和服务器硬件，在不修改任何应用程序的情况下，将网络架构升级到ZCube不仅节省了1/3的光模块和交换机硬件，还使集群每秒服务的推理请求数增加了15%。在当前推理工作负载爆炸式增长、计算资源严重短缺的背景下，这种方法极具实用价值。目前，这个ZCube集群已稳定运行超过两周，在为GLM-5.1编码推理服务提供强大动力方面发挥着关键作用。

3. 结论

LLM推理正在从点式优化走向系统级协同设计。网络与推理引擎之间的耦合日益紧密，使网络成为推理系统的关键组成部分。ZCube的生产部署表明，网络架构创新可以直接释放推理系统的有效容量。通过更好地使网络架构与KV Cache传输和PD流量模式对齐，ZCube从源头上降低了拓扑引起拥塞的概率，在提高吞吐量和延迟的同时提升了集群成本效率。

展望下一代LLM基础设施，网络设计将从通用互连演变为模型流量驱动的系统协同设计。长上下文推理、PD分离、MoE以及训练-推理一体化工作负载正在重塑集群内通信模式，要求网络拓扑、通信库和调度策略围绕实际模型流量进行联合优化。未来，我们将继续为更大规模的推理和训练集群开创新颖的AI网络架构——将网络从GPU基础