DualPath：打破 Agentic LLM 推理的存储带宽瓶颈

  • 关联论文：2602.21548
  • 作者：flyP
  • 更新：2026-07-06

原文标题：Breaking the Storage Bandwidth Bottleneck in Agentic LLM Inference，arXiv:2602.21548v2（2026-02-26），cs.DC。 作者：Yongtong Wu、Shaoyuan Chen、Yinmin Zhong 等共 13 人。

一句话结论

DualPath 是为多轮 Agentic LLM 推理设计的 KV-Cache 加载系统，它绕过"prefill 引擎 storage NIC 带宽打满、decode 引擎 NIC 闲置"的不对称瓶颈，用一条 storage→decode→RDMA→prefill 的新数据路径，配合全局调度器，把系统吞吐最高拉到 1.87×、在线 SLO 内平均 1.96×。

它在解决什么真问题

当下 Agent 推理（多轮工具调用、长会话、coding agent 反复重读历史）和一次性问答有本质区别：每一轮都要把上一轮（甚至上 N 轮）算出来的 KV-Cache 从外部存储拉回来，否则就要重算，代价极高。

主流方案是 disaggregated 架构：把 prefill（处理长 prompt、计算密集）和 decode（逐 token 生成、访存密集）拆到不同 GPU 集群，靠高速网络互联。问题是这种架构在 Agent 场景下出现了一条结构性死结：

  • KV-Cache 体量大（一张 H100 上百 GB 不稀奇），只能放外部存储（RDMA NVMe、对象存储、CXL 池等）。
  • 加载 KV-Cache 的活只能由 prefill 引擎干（prefill 完成后才能继续算），所以prefill 引擎的 storage NIC 一直满载排队。
  • decode 引擎的 storage NIC 几乎闲置，因为传统数据路径根本没让它参与这件事。
  • 结果：整张网络呈"prefill 堵死、decode 饿着"的死锁形态，系统总吞吐被存储带宽钉死。

DualPath 的问题陈述就一句话：让 decode 引擎那条闲置的 storage 链路也参与 KV-Cache 加载。

核心方法：双路径 KV-Cache 加载 + 全局调度

路径一：传统 storage→prefill（保留）

作为对照基线和 fallback，保留原始路径。当 prefill 引擎 storage 链路空闲时仍走老路，不引入额外复杂度。

路径二：storage→decode→RDMA→prefill（核心创新）

新路径分三步：

  1. decode 引擎直接读 storage：把 KV-Cache 分片拉到 decode 引擎的本地 HBM / 主机内存。这步利用了 decode 引擎闲置的 storage NIC 带宽。
  2. decode 引擎之间 RDMA 转发：在 compute fabric（RoCE / RDMA over Converged Ethernet）上，decode 引擎之间做 RDMA 转发，把不属于本节点的 KV-Cache 块送到目标 prefill 引擎所在的节点。
  3. prefill 引擎接收并继续计算：prefill 引擎从 compute fabric 拿到 cache，继续做 prefill。

关键设计点：第二步走的 compute network 是已有用于张量并行 / 流水线并行的低延迟 RDMA 通道，它在 LLM 推理的"稳态"里并不总是满载（尤其在 Agent 场景下，每轮 prefill 之间有明显的空闲窗口）。DualPath 显式把 KV-Cache 转发流量塞进 compute network 的空闲时隙，不与延迟敏感的模型执行通信抢带宽。

全局调度器

光有路径不够，还得在两条路径间动态分流。论文的调度器至少需要回答：

  • 当前 prefill 引擎的 storage NIC 剩余带宽多少？
  • 哪些 decode 引擎 storage NIC 闲置、内存够装下这一片 KV-Cache？
  • 这片 KV-Cache 转发到目标 prefill 节点要走几跳 RDMA，延迟是否在 SLO 之内？
  • prefill 引擎上 compute fabric 端口此刻是否被 tensor parallel 通信占用？

调度器对每个调度周期输出一个"路径 + 目标节点"对。

关键实验与数据

论文评测了 3 个不同尺寸的模型（原文未明确具体模型名），并在 production agentic workload 上跑：

  • 离线推理吞吐：最高 1.87× 相对基线。
  • 在线 serving 吞吐：在不违反 SLO的前提下，平均提升 1.96×。
  • 与之对比的基线是传统单路径 disaggregated 推理系统。
  • 论文还做了 ablation，说明增益主要来自双路径而非单纯 RDMA 转发（原文未明确给出每个 ablation 单独的百分比，仅在论文里以图表形式呈现）。

被引情况：截至解读日 8 次引用、影响力被引 0 次，属于新发不久的工程系统论文，引用热度还没起来。

⚠️ 就地修正：本卡片里「集成到 Continuum agent serving system 后平均 job latency 降低 18.1%」这条数据不属于 2602.21548 的实验结果，而属于另一篇相关工作（Continuum 平台集成实验）。⚠️ 同理，关于「首个将 GPU attention kernel 行为纳入 cache eviction 决策」的描述对应的是 AsymCache 类工作，也不属于 DualPath。以上两条为原文/解读混杂，已注明排除，不影响主体数字的正确性。

亮点与局限

亮点

  • 对症下药：DualPath 的问题陈述极其精准——把 disaggregated 推理在 Agent 场景下的"prefill 堵、decode 空"不对称性讲清楚了，这一点对所有做 LLM 推理 infra 的人都有共鸣。
  • 不颠覆、只补一条路：保留了原路径作为 fallback，新路径叠加而非替换，工程上更易落地。
  • 利用 compute network 的空闲时隙：这是个非常漂亮的设计——compute fabric 之前是模型并行专用，DualPath 把它升级为"模型并行 + cache 转发"双用途，不增加硬件成本。
  • 真实 production 工作负载评测：比纯合成 benchmark 更有说服力。

局限

  • 依赖 compute fabric 的空闲时隙：在 decode-heavy 但 prefill 也很频繁的场景下，compute network 可能本身就吃紧，这时双路径的边际收益会显著下降。论文未明确给出 compute fabric 拥塞时的退化曲线。
  • KV-Cache 一致性管理复杂：原本 KV-Cache 只需从 storage 拉一次到 prefill，现在可能经 decode 中转，如何处理并发请求之间 KV-Cache 的一致性、失效、和多版本是个大问题，论文未明确给出完整的协议。
  • 与 PagedAttention / vLLM 风格的分页 KV 兼容性：是否需要重新设计 KV 分块策略以适配双路径，原文未明确。
  • 调度器策略选择：全局调度器是论文性能的关键，但其策略细节、参数、是否需要离线 profiling 原文未明确。
  • 可复现性未知：是否开源、是否提供 repro 脚本，原文未明确。

对工程落地的启发

  1. 先看自己是否真要拆 prefill/decode：DualPath 的存在本身就说明传统 co-located 架构在 Agent 场景下会撞墙；如果还没拆，可能根本不用碰这套系统。
  2. 在自建推理栈里预留"双路径"扩展点：即使今天只走 storage→prefill，也把 KV-Cache 读路径设计成可插拔，未来加双路径无需重写调度器。
  3. 先做 compute fabric 流量画像：RDMA 转发能塞进去的前提是 compute network 有空闲时隙，建议先抓一周 RoCE 端口利用率分布，再决定是否值得上 DualPath 思路。
  4. 淘汰策略要硬件感知：DualPath 的哲学（不均衡利用链路、靠调度补齐）提醒所有 KV-Cache 淘汰/预取团队——淘汰策略必须考虑底层链路状态，纯 LRU 注定低效。
  5. 对 vLLM / SGLang / TensorRT-LLM 用户：DualPath 是论文级创新，短期内不会直接进开源框架，但它指明了一个值得社区投入的方向——把 KV-Cache 加载从"单机 IO 问题"升级为"集群级流量工程问题"。

与同方向工作的关系

  • Disaggregated 推理系统：与 DistServe、Mooncake、Splitwise 同属 disaggregation 路线，DualPath 是在这一路线内部补 KV-Cache IO 短板。
  • KV-Cache 压缩/淘汰：与 H2O、Scissorhands、AsymCache 这类工作正交——后者省的是 cache 体积，DualPath 省的是 cache 加载时间，可以叠加。
  • Agent 推理优化：与 Continuum、MemServe 这类"为 Agent 设计的推理栈"直接相关——DualPath 的双路径天然适合 Agent 每轮都要重拉历史的模式。
  • 上下文工程/Prompt Cache：CacheBlend、ChunkAttention、Prompt Cache 属于"省掉 cache 加载"的另一条路，DualPath 是"省不掉 cache、就把它加载得更快"的另一条路，两者目标互补、机制正交。

适合谁读

  • 做 LLM 推理 infra / GPU 集群调度的工程师：必读，是近期最具落地参考价值的系统论文之一。
  • 做 Agent 平台 / 长会话 Agent 架构的人：搞清楚底层 KV-Cache 加载是 Agent 推理的隐形天花板。
  • 做 RDMA / 高速网络 / DPU 的人：DualPath 把 compute fabric 玩出新花样，是典型"在现有硬件约束下重新分配流量"的案例。
  • 不太适合只关注模型/算法的人——这是纯系统工程工作。

不确定处

  • 实验用的 3 个模型具体是哪些，原文未明确（仅在论文内文以代号出现）。
  • 每个 ablation 的单独百分比贡献只以图表形式给出，原文未明确逐一标注。
  • 是否开源、是否提供 repro 脚本，原文未明确。
  • 调度器策略的完整形式化与参数选择未在 abstract 层级披露。

工程落地与核查（Jay）

事实核查

核查项 原文表述 核查结果 存疑程度
1.87× / 1.96× 吞吐提升 abstract 直接引述 ✅ 原文明确给出数字 —
离线 vs 在线吞吐区分 「离线推理吞吐」vs「在线 serving 吞吐」 ⚠️ abstract 未区分离线/在线，解读做了区分；需确认 1.87× 是离线、1.96× 是在线 中
吞吐基线是「传统单路径 disaggregated 推理系统」 原文/解读 ✅ 符合 disaggregation 架构背景 —
13 位作者（Yongtong Wu, Shaoyuan Chen, Yinmin Zhong 等） arXiv metadata ✅ arXiv 记录一致 —
arXiv:2602.21548v2（2026-02-26） arXiv metadata ✅ 与 arXiv 版本记录一致 —
⚠️ Continuum 集成 +18.1% latency 降低 卡片正文（存疑） ❌ 正文已注明：此条不属于 2602.21548，属其他工作混入；已就地修正 已修正
⚠️ 「首个将 GPU attention kernel 行为纳入 cache eviction」 卡片正文（存疑） ❌ 正文已注明：属于 AsymCache 类工作，不属于 DualPath；已就地修正 已修正
实验模型具体名字 「3 个不同尺寸模型」 ⚠️ abstract 未明确模型名，解读照原文标注「未明确」 低（诚实标注）
调度器完整策略 调度器描述 ⚠️ 论文未在 abstract 给出调度器形式化 低（诚实标注）
开源代码/repro 脚本 全文未提及 ⚠️ 解读已注明「可复现性未知」 低（诚实标注）

可读性精修

  • 逻辑：问题陈述（"prefill 堵、decode 空"）→ 解法（双路径）→ 调度器 → 实验，链条清晰；
  • 明显错误就地修正：正文末尾已注明 Continuum 集成数据与 AsymCache 描述不属于本论文；
  • 术语统一：全文使用 disaggregated / prefill / decode / compute fabric 等术语，一致性良好；
  • ⚠️ 风险提示不足：建议在「对工程落地的启发」第 3 条加一条：RDMA 空闲时隙假设在多租户或高并发场景下可能不成立，需实际测量。

工程落地实操指引

复现可行性：目前无开源代码已确认（arXiv 原文 + GitHub 均未检索到 DualPath 实现仓库）。如需在生产环境落地：

  1. RDMA 基础设施是前提：DualPath 第二步完全依赖 decode 引擎之间的高带宽 RDMA（RoCEv2）。如果集群没有 RDMA 网卡（如 InfiniBand 或 RoCE），这条路完全走不通；
  2. 调度器需要自研：论文未给出调度器的完整形式化，实际落地需要自行实现全局调度器。建议先用「静态阈值」策略（prefill NIC > 70% 利用率时切 DualPath）跑通最小路径，再迭代调度算法；
  3. KV-Cache 一致性是最大工程坑：decode 引擎参与转发后，同一 KV-Cache 块可能被多个 decode 引擎持有，如何处理并发修改和版本失效，需要引入类似「分布式 lease」的机制。

⚠️ 关键工程风险： - 没有开源代码 = 调度器、RDMA 转发路径都需要从零实现，工作量较大； - compute fabric 空闲时隙假设不一定成立：在 Tensor Parallelism 负载高的集群，RoCE 端口本身就满，双路径增益趋近于零； - 与 vLLM PagedAttention 的 KV 分块策略可能不兼容：如果 vLLM 的 KV block 分配逻辑假设 KV-Cache 是单路径直接加载，双路径转发可能破坏 block 映射； - SLO 边界条件未披露：1.96× 是在什么 SLO 约束（p50/p99 latency）下测得的？超载场景下双路径是否有退化？

适合立即动手的场景： - 已有 disaggregated prefill/decode 架构 + RDMA 网络 → 立即在 staging 环境做 compute fabric 利用率 profiling，验证 DualPath 思路的增益空间； - 正在设计 KV-Cache 淘汰策略的团队 → 借鉴 DualPath「硬件链路感知调度」思路，把 NIC 利用率纳入淘汰优先级； - 评估 Mooncake / DistServe / Splitwise 等 disaggregation 方案的团队 → 把 DualPath 双路径作为「未来可选升级」纳入架构设计。