标签： 技术实现

关注星融元

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）进行浏览和核对。