尝试私有化部署DeepSeek？至少九成工程师会忽略这一点

当你尝试在私有集群上部署各类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）进行浏览和核对。