关注星融元

A-Lab 是星融元服务于新一代网络运维工程师的资讯专栏，你可以在这里找到各类基于开放网络技术架构的配置指导和技术分享。访问地址：https://asterfusion.com/alab-for-netdevops/

十年弹指一挥，当年的爆款热词“云计算”已然能搭上“传统” 二字当前缀；

十年弹指一挥，机房滚滚轰鸣声中，网工小王不知不觉熬成了老王；

老王不解啊，十年弹指一挥，咱亲手上架的服务器不说上千也有大几百，不就多了几张网卡，配个智算服务器怎会卡了壳？！

客官别笑，通用云计算中心与智算中心在主机侧网络架构层面的确存在显著差异，老网工偶尔走点弯路也是在所难免的啦。今天就让我们快速捋一捋其中缘由。

为啥出错？

传统CPU服务器多采用单网卡出口设计，通过OS内核协议栈实现网络报文转发，其网络拓扑相对简单，主要满足虚拟化资源的弹性调度需求。

源于AI训练任务对网络带宽的严苛要求，智算中心的GPU服务器普遍采用多网卡出口架构，用于接入参数网、存储网、业务网和带外管理网，其中通常会有8张网卡用于接入参数网，或称计算后端网络。而跨服务器的通信大多发生在同轨（Rail）的网卡/GPU之间。（请参考：关于智算的“多轨道网络架构”）

老王遇到的机间通信失败问题主要发生在以下两种场景：

场景1：

智算业务报文从管理网段发出。两台GPU服务器A和B的8张网卡都接入到一张参数网，对应的网卡A1到A8、B1到B8，它们都分配到不同的网段，同轨网卡之间有互通需求（A1-B1，A2-B2…）

如果没有进行路由规划，通常在GPU服务器A的系统上会看到默认路由是业务网的，8个子网A1～8会产生8条对应的网段路由，报文会命中A的默认路由从管理网段发出，此时A1和B1是无法直接通信的。

场景2：

回程通信失败。如果网卡A1到A8、B1到 B8 都分配到同一个网段下的不同IP，在这种情况下在服务器B上通过B1尝试与A1通信，会发现报文可以到达A1，但是回包会命中默认路由之外的代价最低的路由，很可能会从其他7张网卡中的一张出去，导致通信失败。

通信失败情况下可能的系统路由配置：

应对思路

当传统路由设置方法在智算环境下失效，一个可行的应对方式是提前规划GPU服务器内的路由，借助Linux的多路由表和策略机制实现更加灵活、精细的流量控制和路由管理功能。

具体而言：在Linux内增加一个自定义路由表，并通过策略路由告知系统，特定源地址的报文根据这张自定义路由表转发，并在该表中增加一条指定目的网段的表项（例如前往10.0.5.0/24的报文从指定网卡发出）。

• 多路由表（Multiple Routing Tables）：Linux支持多张路由表，这些路由表可以通过不同的标识符来区分，每张路由表中可以包含一组路由规则。Linux系统默认会存在一个主路由表，当不特别指定的时候路由规则会写入默认路由表。
• 策略路由机制（Policy Routing）：根据数据包的源目的IP、网卡等条件来选择合适的路由表进行转发。

更高效的实现方式

更高效的办法，当然是用脚本工具批量自动配置啊！

星融元（Asterfusion）AI智算网络解决方案中包含的EasyRoCE Toolkit – IRM工具（In-Node Route Map，GPU服务器内部路由规划）正是用于解决多网卡路由问题——根据已有的IP地址规划表，自动生成并对集群内所有GPU服务器下发内部路由规划和配置。

IRM工具运行过程中需要通过SSH和集群中的所有GPU服务器进行交互，一般运行在管理节点上。

网工老王仅需完成三步微操：

1、将IRM工具上传到管理节点；

2、指定需要解析的路由规划信息文件。该文件可在EasyRoCE-AID （AI Infrastructure Descriptor，AI基础设施蓝图规划）工具引导下手动填写，形式为下图所示的excel表格，主要包含IP和接口地址规划、Rail平面划分等构造智算网络的必备信息；

3、运行IRM工具脚本。等待上述规划信息完成转换重组后，IRM工具会生成包含路由配置的JSON文件并下发到集群，随后网络运维人员即可查验到所有GPU服务器内部的策略路由都已成功生效，同一个Rail平面内的网段按照预期正常互通。此外，该阶段生成的JSON文件亦可复用于其他客户自定义/第三方工具。

关注星融元

DeepSeek的优化，精细但门槛极高

作为开源周的“彩蛋”，DeepSeek于上周六展示了采用混合专家模型（MoE）DeepSeek-V3 / R1 所使用的推理架构的整体方法——从增大吞吐和降低时延的目标出发，再次优化了PD分离架构，不过暂时没有开源代码。

与Llama等采用张量并行（TP）的Dense（稠密）模型不同，混合专家（MoE）模型通过组合多个专家模型来处理复杂任务，每个专家模型专注于输入数据的不同部分，每次计算任务只需激活特定专家（而非整个神经网络）。

DeepSeek-V3 / R1 的推理系统架构一方面引入了更复杂的跨节点和多节点的传输提升计算效率和改善内存墙，同时也通过异步通信和流水线调度设计，确保由此增加的通信开销被计算任务掩盖。

值得注意的是，根据官方公布的信息，若要充分发挥DeepSeek MoE 模型的能力，起步资源是320卡，且不论在未开源的情况下面临的技术挑战。

综合成本和需求考量，上述面向专家并行的推理系统优化仅在部分toC云计算场景具备一定研究意义。现阶段toB行业大模型以及边缘计算场景仍以Dense模型为主，需要高并发的大集群平台部署可延续现有主流的算力网络设计思路，面向本地低并发需求则可采用大内存单机部署方案。

回顾：AI推理集群的PD分离和流量特征

大模型的推理任务一般分为两个阶段，一是Prefill，处理所有输入的 Token，生成第一个输出 token 和 KV cache，是算力密集型；二是Decode，利用 KV Cache 进行多轮迭代，每轮生成一个 token，需要反复读取前面所有token的 Key 和 Value，瓶颈在于内存访问。

从用户实际体验层面看，推理过程中最关键的指标是 “第一个Token的延迟” （Time To First Token, TTFT） 和后续token输出的延迟（Time Per output Token, TPOT）。

如果 Prefill 和 Decode 两个阶段在同一张GPU卡上运行，则容易发生资源争抢影响到 TTFT 和 TPOT 表现，尤其是当用户输入一段长 prompt 时，不光需要较多算力来支撑prefill运算, 也需要大内存来存储 KV Cache。

因此，业界通常采用 Prefill-Decode 分离的架构：用高算力卡做 Prefill（prefill server）, 低算力卡做 Decode（decode server）, Prefill节点在完成计算传输 KV cache 后即可释放本地显存。

参阅：一文揭秘AI智算中心网络流量 —AI推理

AI推理系统的 Scale-out 组网设计

推理集群的工程部署方面，由于 Prefill 和 Decode 采用的GPU并行方式不一样，Prefill和Decode集群是相互独立的，但两个集群间需要互联以同步KV cache。从两个阶段的输入输出来看，Prefill 流量的特征是低频大流量，要求大带宽；Decode 阶段流量的特征是高频小流量，要求低时延。

1、分离网络架构

• 分为Prefill网络和Decode网络，分别负责本集群内流量，两个集群之间的流量通过互联网络实现
• 两个网络分别运维管理，但Prefill和Decode GPU之间的流量至少需要3跳

2、统一网络架构

• 单个网络同时负责集群内和集群间流量
• 网络统一运维管理，Prefill和Decode GPU之间流量可一跳直达

我们推荐采用统一网络架构，借助 QoS、自适应路由技术对 Prefill 和 Decode 流量分别处理。

Rail-only 拓扑

• GPU服务器内部：每四个GPU作为一组，共享一个并行推理网卡，连接到同一个PCI Switch,两组GPU之间的通信通过两个PCI Switch之间的直连通道完成；
• GPU服务器之间：同一组号的GPU之间的通信通过交换机直接完成；不同组号的GPU之间的通信，先通过PCI Swtitch将流量路由到另一组的网卡，然后通过交换机完成

小规模并行推理网络拓扑

• 每台推理服务器有8张GPU，2张400G网卡，双归连接到两台CX732Q-N
• 16个推理服务器（128张GPU）和2个CX732Q-N组成一个PoD。Prefill和Decode服务器可能属于不同PoD
• 可横向扩展至64个PoD

中大规模并行推理网络拓扑

• 每台推理服务器有8张GPU，2张400G网卡，双归连接到两台CX864E-N
• 64个推理服务器（512张GPU）和2个CX864E-N组成一个PoD，Prefill和Decode服务器在同一个PoD，服务器间一跳可达
• 可横向扩展至64个PoD

拓扑设计仅供预览参考，方案均采用星融元（Asterfusion）提供的CX-N系列 AI智算网络产品：基于SONiC的开放NOS（AsterNOS）+ 100G/200G/400G/800G 超低时延以太网交换机硬件，全端口支持 RoCEv2 & EasyRoCE Toolkit。了解产品详情或项目定制方案请与我们联系。

关注星融元

当你尝试在私有集群上部署各类LLM应用，除了关注作为成本中心的算力资源，也一定不要忽视网络侧的配置！未经优化的网络连接，会给你的集群通信性能带来将近80%的损耗，哪怕仅有双机8卡规模。

参考：分析NCCL-Tests运行日志优化Scale-Out网络拓扑

一言以蔽之，上述性能瓶颈来自于网络连接方式与集合通信模式的不匹配。当前智算集群内采用的组网是“轨道优化”或“多轨道网络架构”，连接方式与一般云计算场景差别巨大。

以适用性最高的 Fat-tree CLOS 组网架构为例（这也是各大智算公有云的首选方法，具有非阻塞的 all-to-all 连接，不依赖于正在训练的模型），下方拓扑中的Leaf/TOR交换机被称为轨道交换机（Rail Switches），它们与所有集群单元内的GPU节点都建立了直接连接。

为什么要有轨道优化？

这个问题可能需要从通信库说起。当我们要利用分布式的GPU集群实现并行计算，集合通信库是关键环节之一。集合通信库向上提供API供训练框架调用，向下连接GPU卡（机内和机间）以完成模型参数的高效传输。目前业界应用最为广泛的是NVIDIA 提供的 NCCL 开源通信库，各个大厂基本都基于 NCCL 或 NCCL 的改造版本作为底座。

NCCL自2.12版本起引入了 PXN 功能，即 PCI × NVLink。PXN 利用节点内 GPU 之间的 NVIDIA NVSwitch 连接，首先将数据移动到与目的地位于同一轨道上的 GPU 上，然后将其发送到目的地而无需跨轨道传输，从而实现消息聚合和网络流量优化。

轨道优化拓扑即是适应这一通信特征，将不同服务器上位于相同位置（轨道）的NIC连接到同一台交换机上。

由于每个服务器有8张连接计算平面的网卡，整个计算网络被从物理上划分为8个独立并行的轨道（Rail）。由此，智算业务产生的并行通信需求（All Reduce、All-to-All 等）可以用多个轨道并行地传输，并且其中大部分流量都聚合在轨道内（只经过一跳），只有小部分流量才会跨轨道（经过两跳），大幅减轻了大规模集合网络通信压力。

轨道优化聚合了同一对 NIC 之间传递的消息，得以最大限度地提高有效消息速率和网络带宽。反观NCCL 2.12 之前，同样的端到端通信将经过三跳交换机（上图的L0、S1 和 L3），这可能会导致链路争用并被其他流量拖慢。

如何配置多轨架构的智算网络？

首先是需要明确GPU卡的连接方式。如果是N卡，你可以使用nvidia-smi topo -m的命令直接查看。但综合考虑成本因素，要想在更为通用的智算环境下达到GPU通信最优，最好的办法还是在采购和建设初期就根据业务模型特点和通信方式预先规划好机内互联（GPU-GPU、GPU-NIC）和机间互联（GPU-NIC-GPU），避免过早出现通信瓶颈，导致昂贵算力资源的浪费。

下面我们以星融元智算网络方案具体举例，使用CX-N系列RoCE交换机组网。 

100G/200G/400G/800G RoCE 端口，运行企业级SONiC/AsterNOS，转发时延约450~560ns，全面支持 EasyRoCE Toolkit

主机侧的路由配置

智算环境下以GPU卡（而非服务器）为单位的通信模式形成了服务器多网卡多出口环境的路由策略，通常会有8张网卡用于接入参数/计算网，每张网卡位于各自的轨道平面上。为避免回包通信失败，服务器上的网卡配置需要利用Linux多路由表和策略路由机制进行路由规划，这与传统云网的配置方式完全不同。

第一步是按照组网规划和网段规划，进行IP地址规划和Rail平面划分。在我们的EasyRoCE Toolkit 下的AID工具（AI Infrastructure Descriptor，AI基础设施蓝图规划）中，Notes字段用于标注Rail编号，即0代表Rail平面0、1代表Rail平面1，以此类推。 

交换机侧的主动路径规划

CLos架构下，各交换节点分布式运行和自我决策转发路径容易导致无法完全感知全局信息，在多层组网下流量若发生Hash极化（经过2次或2次以上Hash后出现的负载分担不均）将拖慢集群性能。

为解决满足AI集群规模化部署的通信需求，一般来说我们会通过规范流量路径来解决性能和规模方面的痛点（例如负载均衡、租户隔离等），按照如下转发逻辑去配置RoCE交换机：

1. 跨 Spine上行流量进入Leaf后根据源IP和是否为跨Spine远端流量，执行策略路由转发给Spine，每网卡对应一个接口：

• 在上下行流量1：1无收敛的情况下，Leaf的每个下行端口绑定一个上行端口；
• 在n：1的情况下，上下行端口以倍数关系(向上取整)形成n:1映射。

2. 跨Spine上行流量在Spine上按照标准L3逻辑转发，在轨道组网中多数流量仅在轨道内传输，跨轨道传输流量较小，网络方案暂不考虑Spine上拥塞的情况（由GPU Server集合通信处理）。
3. 跨 Spine下行流量进入Leaf后根据 default 路由表指导转发。

当然，这里也可以使用EasyRoCE Toolkit 下的PPD工具（主动路径规划，Proactive Path Definer）自动生成以上配置。以下为PPD工具运行过程。

正在生成配置文件
100%[#########################]
Configuring leaf1's port 
leaf1的端口配置完成 
Generating leaf1's ai network config
The ai network config finished.
 
正在生成配置文件
100%[#########################]
Configuring leaf2's port 
leaf2的端口配置完成 
Generating leaf2's ai network config
The ai network config finished.
 
正在生成配置文件
100%[#########################]
Configuring leaf3's port 
leaf3的端口配置完成 
Generating leaf3's ai network config
The ai network config finished.
 
正在生成配置文件
100%[#########################]
Configuring leaf4's port 
leaf4的端口配置完成 
Generating leaf4's ai network config
The ai network config finished.
 
正在生成配置文件
100%[#########################]
show running config
是否需要查看生成的配置(Y|N):

PPD可以独立运行在服务器上，也可以代码形式被集成到第三方管理软件中，利用AID工具来生成最终配置脚本，将配置呈现在统一监控面板（例如Prometheus+Grafana）进行浏览和核对。