双路径救场：让 Agent 推理里"闲着"的网卡重新上岗

  • 关联论文：arXiv:2602.21548

做 Agent 推理的人，最近都在撞同一堵墙。

Agent 跟单次问答不一样。每一轮工具调用、每一轮长会话重读历史，都要从外部存储把上一轮算好的 KV-Cache 拉回来，不拉就得重算。所以现代推理栈几乎都拆成了"prefill + decode"分离的 disaggregated 架构，KV-Cache 走高速网络互联，理论上很美。

但现实是堵车的：

  • 一张 H100 上的 KV-Cache 能到上百 GB，必须放外部存储（RDMA NVMe / 对象存储 / CXL 池）；
  • 只有 prefill 引擎有资格拉 KV-Cache（拉完才能算），于是 prefill 的 storage 网卡一直排长队；
  • decode 引擎的 storage 网卡几乎空闲——传统数据路径根本不让它干活；
  • 整张网络呈"prefill 堵死、decode 饿着"的死锁形态，总吞吐被存储带宽钉死。

DualPath 把这件事一句话捅破：让 decode 那条闲着的链路也参与加载。

它怎么做

不颠覆原方案，只叠一条新路：

  • 路径一（保留）：storage → prefill，沿用老链路，作为 fallback。
  • 路径二（创新）：storage → decode → RDMA → prefill。 1. decode 引擎先从 storage 把 KV-Cache 拉到本地内存（用掉自己闲置的 storage 带宽）； 2. decode 节点之间在 compute fabric（RoCE）上做 RDMA 转发，把不属于自己的分片送到目标 prefill 节点； 3. prefill 引擎从 compute fabric 收到 cache，继续算。

核心巧思在第二步。 Compute fabric 本来是张量并行/流水线并行专用的低延迟通道，但在 Agent 场景下，prefill 之间存在明显空闲窗口——DualPath 把 cache 转发流量塞进这些空闲时隙，不抢模型执行的带宽，等于零硬件成本复用基础设施。

光有路径还不够，还需要一个全局调度器按周期决策：哪片 cache 走哪条路、送到哪个节点、当前 prefill 网卡剩余带宽多少、目标节点的 compute fabric 端口是否被张量并行通信占用。论文没有给出调度器的完整形式化，这是落地时最值得补的一块。

数字怎么读

评测是 3 个不同尺寸模型（具体名原文未明确）+ production agentic workload：

  • 离线吞吐最高 1.87×；
  • 在线 SLO 内平均 1.96×；
  • 基线是传统单路径 disaggregated 系统；
  • ablation 表明增益主源是双路径而非单纯 RDMA 转发，具体贡献数字只以图表形式呈现。

几条注释：关于"集成到 Continuum 后 latency -18.1%"、"首个把 GPU attention 行为纳入 cache eviction"这些描述，对应的是 AsymCache / Continuum 相关工作，不属于 DualPath 的实验结果，遇到引用时要注意。

证据边界与工程局限

漂亮的问题陈述不等于零坑落地：

  1. 依赖 compute fabric 的空闲时隙——在 decode-heavy 且 prefill 也很频繁的场景下，RoCE 端口本身就满，双路径边际收益会显著塌缩。原文未给出拥塞退化曲线。
  2. KV-Cache 一致性协议未完整披露——同一分片可能被多个 decode 持有，并发修改、多版本失效如何处理，论文未给完整协议。
  3. 与 PagedAttention / vLLM 分页 KV 的兼容性未知——若 vLLM 假设 KV-Cache 单路径直加载，双路径转发可能破坏 block 映射。
  4. 调度器完整形式化缺失——策略细节、参数选择、是否需要离线 profiling，原文均未明确。
  5. 可复现性未知——目前未检索到开源仓库，调度器与 RDMA 转发路径需自研。
  6. SLO 边界条件未披露——1.96× 对应的 p50/p99 latency 阈值、超载退化等未给出。

为什么值得做工程的人读

  • 给出"集群级流量工程"的视角：把 KV-Cache 加载从单机 IO 问题升维到集群链路调度问题，淘汰/预取策略必须硬件感知，纯 LRU 注定低效。
  • 先抓一周 RoCE 端口利用率画像再决定是否上 DualPath 思路，比直接撸代码靠谱得多。
  • 已有 disaggregated + RDMA 集群的团队，建议立即在 staging 环境做算力网流量画像评估升级空间，并把"双路径"作为未来可插拔扩展点。

DualPath 是论文级创新，短期内不会直接进 vLLM / SGLang / TensorRT-LLM，但它指明了一个社区值得投入的方向——把现有推理栈从"让 GPU 算得更快"升级到"让整张网络流得更顺"。

一句话带走：Agent 推理的天花板不在算力，在存储带宽；DualPath 用一条 decode 中转的新路径，把闲置链路变成加速器。但落地前，先量自己 compute fabric 的空闲时隙，别被数字冲昏头。

标题变体

  1. 双路径救场：让 Agent 推理里"闲着"的网卡重新上岗
  2. 1.87× 是怎么来的：拆掉 Agent 推理的存储带宽死结
  3. 别让 KV-Cache 在 prefill 上排队：DualPath 的链路调度思路

小红书卡片文案

Agent 推理为什么总卡？

因为 KV-Cache 太大，prefill 引擎负责把它从存储拉回来，结果 storage 网卡堵到飞起，decode 那边的网卡却全程看戏——一堵一闲，整张网络被钉死。

DualPath 的解法很优雅：不拆架构，只叠一条新路径。先让 decode 把 cache 拉到自己内存（吃闲置带宽），再让 decode 之间用 RDMA 互相转，最后送到 prefill。compute fabric 的空闲时隙顺手复用，零额外硬件成本。

实测下来，离线吞吐拉到 1.87×，在线 SLO 内平均 1.96×。

但落地别只看数字：它依赖 compute fabric 的空闲窗口，论文也没给完整协议和开源代码。先抓一周自己 RDMA 端口的利用率画像，再决定值不值得抄这条路。

把 KV-Cache 加载从单机 IO 问题，升维到集群流量工程问题——这才是 DualPath 真正留给行业的遗产。