Wise：DeepSeek 新论文剧透 V4 新框架！发现推理资源错配，用闲置资源增强AI性能

Wise：DeepSeek 新论文剧透 V4 新框架！发现推理资源错配，用闲置资源增强AI性能 Wise：DeepSeek 新论文剧透 V4 新框架！发现推理资源错配，用闲置资源增强AI性能 Modified March 5 于是，一个奇怪的瓶颈出现了：95% 的Token都是旧的上下文，它们不需要重新被计算，却都要被加载和搬运。 这个现象在Agent智能体场景尤其明显。 我们对Agent的诉求是它能够连续工作、记住上下文、帮助我们完成复杂的任务，但所有的更懂你，其实都是更多更有效的上下文。 对话长、记忆多、任务复杂，数据搬运反而成为了瓶颈。 资源错配：旱的旱死，涝的涝死。 现在主流的 AI 推理系统，把工作分给两类员工： 这个分工听起来很合理，专业的人做专业的事。 但问题来了： 所有的旧记忆，都要通过预填充引擎的存储网卡搬运。 想象一下前台既要招呼新客人，又要负责去仓库取所有的旧档案。忙到焦头烂额。 与此同时，后厨的厨师们闲着，他们也有自己的通道，但几乎没有档案要走。 这就是 DeepSeek 发现的资源错配：一边的通道堵死，另一边的通道闲置。 DualPath：换条路走，反而更快 既然预填充引擎的通道堵了，为什么不换条路？ 论文的想法很简单：旧记忆不一定非要走前台，走后厨的通道也行。 这就是论文的核心思想： 等等，走后厨再转到前台，不是绕远了吗？ 恰恰相反。 其实和我们开车时很像的，只要不堵车，绕远点其实可能更快。 这里有个技术细节：后厨到前台之间有一条内部高速通道，叫RDMA（远程直接内存访问）。 它的速度非常快，传档案几乎不花时间，所以绕路的代价很小，收益却很大。 这个论文还设计了两套机制确保在绕路的时候不出问题。 第一，给正事让路。 后厨的通道（计算网络）本来是用来传递菜品的，也就是模型计算过程中需要交换的数据。 现在也要用来传档案，会不会耽误正事？ 论文的方案是设置优先级：做菜的流量是最高优先级，预留 99% 的带宽，搬档案的流量只能蹭剩下的带宽。 这样，搬档案永远不会耽误做菜。 第二，智能调度。 系统会实时监控每个通道的拥堵情况，自动选择最优路径。前台通道是空的，就走前台，堵了，就走后厨绕行。 调度员盯着两个指标：通道里排了多少档案（磁盘队列长度），有多少新客人要接待（Token 数量）。 然后做出最优决策。 论文在自研推理系统上，用真实感更强的 agentic 工作负载做了离线/在线评测，场景覆盖离线推理和在线服务。 结果相当惊人： 最关键的是：这一切不需要增加额外的GPU算力。 只是换了一种搬运数据的方式，性能就翻了近一倍。 最后 对于AI应用来说，DualPath的结果意味着：在长上下文、高KV复用的智能体推理负载下，成本会大幅下降。 对于我们来说，在长上下文、多Agent的时候，还能保障AI响应的速度能更快，体验能变得更好。 DualPath的启发是I/O 瓶颈不是不可突破的。 与其堆硬件，不如重新思考数据该怎么流动，存储到计算的路该怎么走。 当然，DualPath 不是万能的，它需要RDMA的网络支持，比较适合长对话场景，如果是短的对话，双路径的优势并不明显。 而且降低了GPU的显存占用，但却会增加DRAM 与 CNIC 的带宽压力 随着上下文窗口的暴涨，如何高效地搬运旧记忆，可能比如何快速地计算新内容更重要。 参考资料：https://arxiv.org/pdf/2602.21548 于是，一个奇怪的瓶颈出现了：95% 的Token都是旧的上下文，它们不需要重新被计算，却都要被加载和搬运。 这个现象在Agent智能体场景尤其明显。 我们对Agent的诉求是它能够连续工作、记住上下文、帮助我们完成复杂的任务，但所有的更懂你，其实都是更多更有效的上下文。 对话长、记忆多、任务复杂，数据搬运反而成为了瓶颈。 资源错配：旱的旱死，涝的涝死。 现在主流的 AI 推理系统，把工作分给两类员工： 这个分工听起来很合理，专业的人做专业的事。 但问题来了： 所有的旧记忆，都要通过预填充引擎的存储网卡搬运。 想象一下前台既要招呼新客人，又要负责去仓库取所有的旧档案。忙到焦头烂额。 与此同时，后厨的厨师们闲着，他们也有自己的通道，但几乎没有档案要走。 这就是 DeepSeek 发现的资源错配：一边的通道堵死，另一边的通道闲置。 DualPath：换条路走，反而更快 既然预填充引擎的通道堵了，为什么不换条路？ 论文的想法很简单：旧记忆不一定非要走前台，走后厨的通道也行。 这就是论文的核心思想： 等等，走后厨再转到前台，不是绕远了吗？ 恰恰相反。 其实和我们开车时很像的，只要不堵车，绕远点其实可能更快。 这里有个技术细节：后厨到前台之间有一条内部高速通道，叫RDMA（远程直接内存访问）。 它的速度非常快，传档案几乎不花时间，所以绕路的代价很小，收益却很大。 这个论文还设计了两套机制确保在绕路的时候不出问题。 第一，给正事让路。 后厨的通道（计算网络）本来是用来传递菜品的，也就是模型计算过程中需要交换的数据。 现在也要用来传档案，会不会耽误正事？ 论文的方案是设置优先级：做菜的流量是最高优先级，预留 99% 的带宽，搬档案的流量只能蹭剩下的带宽。 这样，搬档案永远不会耽误做菜。 第二，智能调度。 系统会实时监控每个通道的拥堵情况，自动选择最优路径。前台通道是空的，就走前台，堵了，就走后厨绕行。 调度员盯着两个指标：通道里排了多少档案（磁盘队列长度），有多少新客人要接待（Token 数量）。 然后做出最优决策。 论文在自研推理系统上，用真实感更强的 agentic 工作负载做了离线/在线评测，场景覆盖离线推理和在线服务。 结果相当惊人： 最关键的是：这一切不需要增加额外的GPU算力。 只是换了一种搬运数据的方式，性能就翻了近一倍。 最后 对于AI应用来说，DualPath的结果意味着：在长上下文、高KV复用的智能体推理负载下，成本会大幅下降。 对于我们来说，在长上下文、多Agent的时候，还能保障AI响应的速度能更快，体验能变得更好。 DualPath的启发是I/O 瓶颈不是不可突破的。 与其堆硬件，不如重新思考数据该怎么流动，存储到计算的路该怎么走。 当然，DualPath 不是万能的，它需要RDMA的网络支持，比较适合长对话场景，如果是短的对话，双路径的优势并不明显。 而且降低了GPU的显存占用，但却会增加DRAM 与 CNIC 的带宽压力 随着上下文窗口的暴涨，如何高效地搬运旧记忆，可能比如何快速地计算新内容更重要。 参考资料：https://arxiv.org/pdf/2602.21548 原文：https://mp.weixin.qq.com/s/zjthG0NFWqJnrB51LbJjMg 原文：https://mp.weixin.qq.com/s/zjthG0NFWqJnrB51LbJjMg 网传 DeepSeek V4 最快本周发布。 就在所有人盯着 V4 的参数、能力、benchmark 时，DeepSeek 却悄悄和北大在 ArXiv 上发了一篇论文：DualPath。 这是一个新的推理框架。它解决了一个更根本的问题：显卡明明够快，为什么 AI 还是会卡？ 这其实是推理系统的KV Cache读取瓶颈，论文表示不是算得慢，而是搬得慢，性能被KV Cache Storage I/O主导。 当我们和我们的 AI 助手聊天，聊到第 50 轮了。 突然，AI 回复变慢了。 我们的第一反应可能是：被限流了，算力不够，或者我们自己的显卡不够用？ 但论文发现了一个反直觉的真相：显卡经常在等数据，根本没满负荷运转。 就像一个米其林大厨，刀工火候都是顶级的，但每次炒菜前都要等助手从仓库取食材。大厨闲着，仓库到厨房的走廊却堵满了人。 问题不在做菜，而在运菜。 左边其实是将所有的KV都放在Prefill节点的存储网卡和带宽，从图上很明显发现左边下面的通道满载，但右边的通道没有利用起来，GPU的利用率也只有40%。 通过右边的双通道处理后，利用率就大大提高了。 AI 95%的时间在翻旧账？ 要理解这个问题，先得知道 AI 是怎么拥有记忆的。 当你和 AI 聊天时，它会把你说的每句话都记下来。 这个记忆有个专业名字，叫KV Cache（键值缓存）。聊得越久，这个缓存就越大。 在智能体的长对话场景中，95% 以上Tokens都会被多轮重复使用，所以很多时候都能够命中缓存，只有新追加的部分需要去计算。 它不需要重新计算，只需要从存储里搬运过来。