职贝云数AI新零售门户

标题: 从 DeepSeek 的 Dualpath 看推理如何高功效好网络 [打印本页]

作者: 5UzkOc 时间: 3 天前
标题: 从 DeepSeek 的 Dualpath 看推理如何高功效好网络
主页：http://qingkeai.online/

作者：老七
https://zhuanlan.zhihu.com/p/2010791643062747157

昨天第一工夫就看了这篇论文，和一些冤家也讨论了一下，以及明天很多同事在问，就在内网写了一篇分析，然后做了一些删减和脱敏，大家可以一同交流讨论下。
Dualpath方案的背景和动机

这篇论文的背景是Agentic LLM Inference场景下特点是Multi-turn, Short-append，这会带来两个成绩：

1、KV-Cache 命中率极高，由于高缓存命中率，KV-Cache 加载效率而非纯计算成为功能瓶颈，工作负载从"计算密集型"转变为"I/O 密集型"。

2、由于Multi-turn的上下文特别长，DRAM无法包容全部 KV-Cache，必须依赖外部 SSD 存储，这使得存储 I/O 带宽成为关键瓶颈。

基于下面这两个背景，以及deepseek他们的3fs的kv cache存储方式，他们就发现了一个关键成绩：只要prefill节点会去kvstore读kv cache，并且网卡带宽成为了瓶颈，而decode节点的网卡完全是闲暇。然后Dualpath的核心就是怎样把decode节点上的网卡也用起来。

(, 下载次数: 2)

在往下讲方案由于触及到很多网络知识，所以先得做一个背景知识科普，目前AI数据中心有三张网络：

Frontend Network：在deepseek文中他们称为Storage Network，这张网次要承载的流量是存储业务，比如训练中的dataload/ckpt，推理中的kv store的访问等。

在deepseek文中将Storage Network对应网卡称为SNIC，由于deepseek线下自建的机房，所以SNIC是一个裸的物理网卡。而云厂商往往这张网卡是DPU的外形，由于需求承载vpc、ebs、cpfs等云产品的服务。

Backend Network：也被称为Scale out Network，在deepseek文中他们称为Compute Network，这张网次要承载了计算过程中通讯，比如训练和推理过程中跨机并行的集合通讯，以及推理中PD分离的流量，还有一些采用DRAM构建分布式kv store的流量也会走到Backend Network上。

在deepseek文中将Compute Network对应网卡称为CNIC，也是物理网卡外形。

Scale up Network：这部分次要是就是相似nvlink，这部分和本文关系不大，我这里就不展开赘述了。

这三张网络目前物理上都是互相独立的，核心的差异是功能和规模的差异：

功能方面：以NVIDIA的H100机型为例，Frontend网络1张400Gbps网卡，也就是8张GPU公用400Gbps的带宽，平均每个GPU只要50Gbps的带宽。scale out一共3.2T网络带宽，每个GPU有400Gbps的带宽。

scale up网络每个GPU有3600Gbps的带宽（当然nvlink的有效载荷比较低，这里需求打个折，实践大概3040Gbps），所以从GPU视角看三者的功能比为：1：8：60.8。

另外由于Frontend Network的DPU功能比较复杂，要思索很多云厂商虚拟化的特性，因此演进的速度比较慢，在最新的NVIDIA B300机型上，这个比例曾经达到了1：16：121.6。

规模方面：Scale up Network规模是最小的，目前次要在一个rack内，比如NVIDIA的NVL72，当然目前海外大厂也有一些更大规模scale up网络的方案，这里就不展开了，还是以nv的方案来讲。

Backend Network早期大家都是在一个集群内，但是目前全体趋向也是往跨集群方向去演进，比如目前阿里云曾经逐渐放开了同AZ跨集群的访问，并且后续在HPN8.0会做到全地域互通。最后Frontend Network从网络可达性角度是全域互通的。
Dualpath方案简述

Dualpath其实原理上并不复杂。下面说了只要P节点的SNIC从存储节点读kv cache，D节点的SNIC是完全闲暇的，所以Dualpath核心就让D的节点SNIC也去存储节点读kv cache，然后在经过Backend Network（CNIC）传给P节点。如下图所示，就是两个path，一个是PE read path，一个是DE read path。

(, 下载次数: 2)

Dualpath的核心完成：CNIC-CENTRIC TRAFFIC MANAGER

Dualpath方案虽然看上去比较简单，但是会引入一个新的成绩：CNIC上kv cache流量和并行通讯流量（比如EP）冲突成绩。由于并行通讯的流量对功能愈加敏感，因此不能让kv cache流量影响到了并行通讯的流量。

这其实并不是一个新成绩，原来PD分离流量和EP的流量就会有这个冲突成绩。由于计算的流量是间歇性突发的特点，因此kv cache的流量是可以应用计算流量通讯间隙的去通讯的。

另外Backend Network带宽比Frontend Network大很多倍，因此kv cache应用这些间隙去通讯是可以完全满足功能需求的，所以这里本质就变成了一个网络Qos成绩了。

在这个qos方案中CNIC、交换机的qos都比较好做的，deepseek由于是IB网络，所以他们是基于IB网络做的，实践上基于以太网比如RoCEv2也是比较容易完成的。

但是这里还是有一个难点，由于这里引入了H2D/D2H的流量，所以这里的流量冲突不只仅发生在CNIC和交换机上，也发生在pice sw上，而pice上的qos并没有特别成熟的方案。

所以这里deepseek有一个比较巧妙的设计：CNIC-Assisted KV-Cache Copy，提交 RDMA Write 央求给CNIC，目的地址是本地GPU的显存地址，它本质上是应用网卡的 DMA 引擎作为一个高功能、可调度 PCIe 主控器，直接向 GPU 发起 PCIe Write 事务。

数据途径是：Host DRAM → CNIC → GPU HBM。这样H2D的流量就会经过CNIC，然后就可以应用CNIC来完成qos才能。这个方案数据面相当于去CNIC上绕了一圈，按照直觉功能应该会变差，只是添加了qos才能。

但是deepseek他们测试发现，在处理大量细粒度数据块时，CNIC 辅助的 H2D/D2H 功能优于 CUDA Copy Engine，这个也是比较反直觉，后面我会去测试一下。

(, 下载次数: 2)

此外，除了CNIC-CENTRIC TRAFFIC MANAGER外，Dualpath还有一个核心完成是ADAPTIVE REQUEST SCHEDULER，这一部分处理了 DualPath 系统在引入双途径加载后，如何在线动态决议每条央求的加载途径，并同时平衡存储网卡（NIC）流量与 GPU 计算负载的关键应战。这部分由于和通讯关系不大，大家可以直接看下面的详细引见。
DualPath方案总结

DualPath方案的动机在于deepseek是经过Frontend Network去读取的集中式存储的kv store的数据，由于Frontend Network带宽比较小，这就形成了瓶颈，所以才想办法把D节点的Frontend Network也用起来构成DualPath来缓解这个瓶颈。

这个过程中由于P和D之间kv cache通讯都是走Backend Network，并经过网络的qos来处理kv cache和ep通讯互相关扰的成绩。

所以对于目前曾经运用Backend Network来构建kv store的方案，本身网络带宽是非常充足的，这个方案本身是没有太大参考意义，但是qos的一些设计还是可以参考的，不管什么方案，kv cache和跨机并行的通讯流量qos还是必须。
推理业务如何高功效好几张网

Dualpath方案的核心是推理如何高效应用好网络带宽资源，说到这个话题不断都有一些争议，就是这几种推理业务到底怎样用这几张网。下面我就结合这些流量pattern特点以及将来的发展趋向，谈一下本人的一些观点。

首先我们总结了一下当前推理上最常见的一些流量类型，这里RL rollout也是相似的（但是推理Rollout中能够还存在，训推间传weight的流量，这里暂时不思索），我们下面来逐一分析这些流量：

1、各种并行通讯（TP/EP）：对功能非常敏感，尽量放到scale up域，也可扩展到Backend Network，这个应该是没有什么争议的。将来随着Agent业务对tpot的要求越来越高，走scale out的EP方案很难卡住tpot的要求，所以在scale up域内做大EP是大势所趋。

2、PD分离/kv store（内存池）：这两种流量放一同讲吧，比较相似，也是目前争议最大的。所以目前就有两个流派：

所以核心的争议点在于到底Frontend Network能不能满足将来PD分离和内存kv store的需求。

我们可以看到的一个趋向是将来agent场景会对这个kv cache通讯带宽要求越来越高，一方面是超长的上下文，另一方面是超高的cache命中率都会加剧对网络带宽的需求。所以将来Frontend Network的功能很能够是满足不了需求。

另外Frontend Network发展速度分明慢于Backend Network，Backend Network和GPU是一个迭代速度，Frontend Network的DPU相比要慢一个版本（比如如今Backend Network都曾经是800G网卡，Frontend Network还是400G网卡，这样使得带宽比例进一步放大到了1:16）。

另外还有一个成绩假如这个流量走到了Frontend Network，能够有会和走集中化存储的那部分流量冲突了。

最后Backend Network还是有两个常常被诟病的地方，一个kv cache流量和并行流量冲突的成绩，这个下面曾经做了很详细的分析，技术上不是成绩，目前大部分客户也都没遇到过这个成绩。还有一个是Backend Network能否跨集群的成绩，由于如今能够有需求跨集群的PD分离或者kv store的部署，这个目前也不是成绩，目前阿里云新的架构的趋向也都是支持Backend Network的全域互通。

3、kv store（集中式存储）：一旦内存池不够用，能够需求集中式存储，目前由于存储服务器都是没有Backend Network，所以目前也只能走Frontend Network，这时分就会遇到Frontend Network的带宽瓶颈成绩，这时分是可以参考Dualpath的方案。

另外就是可以不用集中式的存储，就用本地盘搭一个分布式的持久化存储，这样的话就可以直接用Backend Network来构建，功能就不是成绩。

最后，基于以上的分析在结合目前业内了解到的一些状况，全体的梳理了一个推理业务运用网络的最佳实际方案。

(, 下载次数: 1)
相关工作部分的关键启示

成绩定位精准：DualPath 没有反复优化"单途径效率"，而是辨认出"多途径带宽不平衡"这一被忽视的系统级成绩。

技术正交性强：与 DRAM 缓存、KV-Cache 紧缩、留意力优化等工作构成互补，可组合运用以获得叠加收益。

架构通用性好：不依赖特定留意力机制或模型结构，在 MoE/Dense、不同 KV-Cache 大小的模型上均有效。

工程落地务虚：基于 PD 分离这一行业理想标准架构停止改进，降低了部署门槛和迁移成本。

往期引荐

(, 下载次数: 2)

超越精度！为什么训练-推理不分歧是一个优化成绩，又如何修复？

从PD分离到AF分离！聊聊 LLM 推理架构演进中的几个关键技术节点

深度！当速度扼杀波动性：字节揭秘训练-推理不婚配导致的RL崩溃

入坑必备基础知识！关于推理模型的一些科普

加入青稞AI技术交流群

加入青稞AI技术交流群，不只能与来自MIT、港中文、CMU、UCLA、斯坦福、清华、阿里、腾讯等名校名企AI研讨员/开发者一同停止技术交流，同时还有一线青年AI研讨员/开发者的Talk分享、青稞Tea、论文精读、招聘内推、国内外硕/博央求、大模型技术报告解读等。备注：姓名+学校/公司+方向，暗号"AI"优先审核经过!

都看到这了，点个关注再走吧🧐～

欢迎光临职贝云数AI新零售门户 (https://www.taojin168.com/cloud/)