一、一个让人心情复杂的故事
看完 DualPath 论文,心情有点复杂。
一方面佩服咱中国人的工程能力,另一方面又心疼——咱面对的硬件资源有限问题,给逼的在螺蛳壳里做道场。
这不是什么"弯道超车"的爽文故事。这是一个"没卡用了,只能想办法"的现实故事。
二、PD 分离:美好的设计,现实的瓶颈
要理解 DualPath,得先理解现在主流的推理架构:PD 分离。
大模型推理分为两个阶段:
Prefill(预填充): 把输入文本转化为模型内部表示(KV Vectors)。
Decode(解码): 循环产生下一个 token。
举个例子:
用户:What's your model?
Prefill:处理 "What's your model?" → 生成 KV Cache
Decode:第一次输出 "DeepSeek" → 第二次输出 "v4"
最终输出:DeepSeek v4
这个设计很聪明,还有一个好处:KV Cache 复用。
如果用户继续问:
用户:What can you do?
Prefill 不需要重新处理前两句,直接从 KV Cache 读取之前的对话状态,继续处理新输入。
省算力,省时间。
三、按了葫芦起了瓢
但计算机行业就是这样——按了葫芦起了瓢。
KV Cache 减少了 GPU 计算浪费,但负担转移到了读取 KV Cache 上。
如果 KV Cache 存在 GPU 之外(比如远程存储),存储网卡带宽就成为瓶颈。
尤其在 Agent 模式下:
- 数据量大
- Prefill 忙不迭地从 KV Cache 读入
- Decode 啥也干不了,只能摸鱼
Prefill 的带宽忙死了,Decode 没活干。昂贵的 GPU 在等数据,而不是在计算。
四、美国同行怎么解决的?
他们可能根本没把这当成问题。
因为他们不缺卡。
10000 片卡不够?那就 20000 片。20000 片不够?那就 40000 片......
简单粗暴,但有效。
但我国 GPU 资源有限,逼得只能想办法解决。
这就是 DualPath 诞生的背景。
五、DualPath 的核心思路:兄弟我来帮忙了
DualPath 的思路很简单:打虎亲兄弟,谁也别闲着。
既然 Prefill 侧忙着搬运数据,Decode 侧闲着,那就让 Decode 也帮忙搬呗。
都是 GPU,都有网卡,干就是了。
具体做法:
让 Decode 也从外部读取 KV Cache,然后通过 GPU 之间的高速计算网络(CDMA 有 3.2T 带宽,比存储网卡快 8 倍)传给 Prefill。
这样,瓶颈消除了。
六、很巧妙,但也很......Hack
说实话,看到 DualPath,觉得这方法挺巧妙,但是也很.......Hack。
就像写软件代码:
- 最开始模块定义很清晰,各司其职
- 后来发现性能不行
- 不得不 hack 原有设计,把模块边界破坏了
- 感觉很脏,但能用
本来 Prefill 和 Decode 的功能定义很清晰:
- Prefill:处理输入,生成 KV
- Decode:生成输出
七、新问题,新解决方案
按了葫芦起了瓢,问题很快就出现了。
GPU 之间的计算网络本来是跑模型推理通信的,如果把 KV-Cache 搬运塞进去,可能把网络堵了,推理性能反而更差。
DualPath 的解决办法也很聪明:
利用 InfiniBand 的虚拟通道做流量隔离。
- 推理通信走 VIP 通道,独占 99% 带宽保障
- KV-Cache 搬运排队坐经济舱,只捡空闲带宽用
八、效果怎么样?
说了这么多,效果怎么样?
根据 DualPath 论文:
- 离线推理吞吐:最高提升 1.87 倍
- 在线服务吞吐:平均提升 1.96 倍
那还啰嗦个啥?看在钱的份上,方法 Hack 一点也显得真香了!
九、写在最后:工程创新 vs 理论创新
虽然 DualPath 非常巧妙,但这是一个纯粹的工程创新,并不是 AI 的理论创新。
在 AI 领域:
- 理论创新开新地图,做到 0-1
- 工程创新扩展地图,做到 1-100
很自然,我们也会想 DualPath 和 DeepSeek V4 的关系。
我想 DualPath 的架构创新肯定会被应用在 V4 中,但它绝不是 V4 的全部。V4 中会包含真正的理论创新。
如果 DeepSeek V4 是一道满汉全席,那 DualPath 顶多算是上热菜之前的开胃鲜果——好吃,但只是一个前菜。
到底 DeepSeek V4 这道大席有什么硬菜,我们拭目以待吧。
---
参考
- DualPath 论文:https://arxiv.org/abs/2502.14991
- 作者:DeepSeek-AI 团队
*你怎么看 DualPath 这种"螺蛳壳里做道场"的工程创新?是无奈之举还是中国 AI 的独特优势?欢迎在评论区分享你的看法。*