本篇选取 10 篇相关论文，覆盖 agentic LLM serving 生态从基础设施到调度再到应用层的完整层次，与 DualPath 形成多维对比。
DeepSeek-V3 (2412.19437) — DualPath 的基础设施母体。DualPath 的全部底层组件（FlashMLA、DeepGEMM、DeepEP、3FS）均源自 DeepSeek-V3 的训练/推理 stack。DeepSeek-V3 在训练端通过 DualPipe 实现计算-通信完全重叠，DualPath 在推理端通过 CNIC-centric data path 实现 KV-Cache 传输-推理通信隔离——两者共享"利用 InfiniBand 硬件特性做流量隔离"的工程方法论。DualPath 实质上是 DeepSeek inference stack 面对 agentic workload 的架构演进。Kind: upstream。
PrfaaS (2604.15039) — 与 DualPath 最直接可比。两者都解决 PD 分离架构下 KV-Cache 传输瓶颈，但路径相反：DualPath 在单集群内利用 DE 端空闲 SNIC + RDMA 计算网络做 dual-path loading；PrfaaS 把长上下文 prefill offload 到跨 DC 独立集群，通过 commodity Ethernet 回流 KV。两者都依赖层间 prefill pipelining 实现计算-传输重叠。PrfaaS 的核心前提是混合注意力（KDA:MLA=3:1）把单实例 KV 吞吐 $\Phi_{\text{kv}}$ 压缩到 ≈3 Gbps，DualPath 则不限制模型架构但要求 InfiniBand 双网。Kind: related。
fabric-lib (2510.27656) — DualPath 的通信层对照。DualPath 使用 DeepSeek 内部 RDMA 实现（强绑定 InfiniBand），fabric-lib 提供跨 ConnectX-7 和 AWS EFA 的可移植 RDMA P2P 库，通过 ImmCounter 原语统一了异构 NIC 的完成通知。fabric-lib 的 KvCache 传输方案同样使用层间 pipeline overlap，TTFT 增加仅 1.9%。如果 DualPath 的 dual-path loading 逻辑构建在 fabric-lib 之上，可将采纳门槛从"必须有 InfiniBand 双网"降低到"有任何 RDMA 硬件即可"。Kind: related。
JITServe (2504.20068) — SLO-aware 调度的代表。JITServe 面向混合 SLO 工作负载（latency/deadline/compound），用 QRF 上界预测 + GMAX 调度最大化 goodput。与 DualPath 的交集在于都面对 agentic workload，但切入维度正交：DualPath 优化数据通路层的存储 I/O 带宽，JITServe 优化调度层的 SLO 满足率。JITServe 证明了"batch 内长度异质降低 per-token 速度"，这个发现对 DualPath 的 PE 端 compute quota 调度策略有直接启示。Kind: related。
KVFlow (2507.07400) — 用 workflow-aware 的 steps-to-execution 优先级替换 LRU 驱逐策略，针对 multi-agent workflow 的 GPU 级 prefix cache 管理。与 DualPath 的层次不同：KVFlow 优化 GPU HBM 内的 KV cache 驱逐/预取，DualPath 优化从远端存储到 GPU 的 KV-Cache 加载路径。KVFlow 假设 workflow 拓扑已知，DualPath 不需要这一假设。两者互补：KVFlow 决定"哪些 KV 留在 GPU"，DualPath 决定"怎么最快把 KV 从存储搬到 GPU"。Kind: related。
GLM (2511.01633) — 将 Graph-CoT 推理框架与 LLM serving co-design。GLM 的四级优先级 KV 驱逐（shared prompt > notebook > 历史 notebook > 临时数据）和 vertex-centric cache reuse 与 DualPath 完全正交：GLM 从应用语义层优化 KV 复用率（hit rate +17.7%），DualPath 从数据通路层优化 KV 加载速度。GLM 的"serving-aware agent boundaries = cache priority boundaries"的理念可指导 DualPath 的调度器引入语义感知。Kind: related。
Sutradhara (2601.12967) — 聚焦 agentic 推理中 orchestrator-engine 协同设计。通过 prompt splitting、streaming tool dispatch 和语义 KV cache 管理降低 FTR 延迟。与 DualPath 的交集在于都针对 agentic workload 多轮特性，但 Sutradhara 优化 intra-request 并行性（tool 等待期间提前 prefill），DualPath 优化 inter-request 的存储 I/O 瓶颈。Sutradhara 的生产 trace 显示中位请求仅 2 次 LLM 迭代，远少于 DualPath 的 157 轮。Kind: related。
Concur (2601.22705) — 提出 agent-level AIMD admission control 解决 agentic batch inference 中的 KV-cache middle-phase thrashing。与 DualPath 共享"agentic workload 导致 KV-cache 资源紧张"的前提，但切入角度不同：Concur 认为问题在并发 agent 过多导致 cache 驱逐（scheduling-bound），DualPath 认为问题在存储 NIC 带宽不足（I/O-bound）。两者互补——Concur 的控制器可以在 DualPath 的双路径架构上进一步优化 admission。Kind: related。
Helium (2603.16104) — 从数据库查询优化视角出发，把 batch agentic workflow 重构为 query plan，通过 Templated Radix Tree、plan pruning 和 cache-aware scheduling 实现全局最优调度。与 DualPath 互补：Helium 优化 workflow 级 operator 编排和前缀复用（scheduling-bound），DualPath 优化底层存储 I/O 带宽（I/O-bound）。Helium 的 nested-sequence schedule 思想——同时优化两层前缀复用——可以指导 DualPath 调度器的请求排序。Kind: related。
PASTE (2603.18897) — 通过模式感知的推测性工具执行（speculative tool execution）实现 tool 执行与 LLM generation 的时间重叠，将 agent 端到端延迟降低 48.5%。PASTE 优化的是 CPU 侧的 tool 执行等待时间，DualPath 优化的是 GPU 侧的 KV-Cache I/O 等待时间——两者攻击 agentic 推理 pipeline 中完全不同的瓶颈环节。PASTE 的"投机执行 + 验证"范式与 DualPath 的"双路径加载 + 路径选择"在设计模式上有类比关系。Kind: related。
DualPath 的核心 delta 是将 PD 分离架构中的存储 NIC 带宽从单点瓶颈转化为全局可调度资源池——DE 端空闲的 SNIC 被纳入 KV-Cache 加载路径，配合 CNIC-centric 流量隔离，在不引入新硬件的前提下使存储 I/O 吞吐翻倍。
| 维度 | DualPath | PrfaaS | fabric-lib | JITServe | KVFlow | GLM | Sutradhara | Concur | Helium | PASTE |
|---|---|---|---|---|---|---|---|---|---|---|
| 瓶颈定位 | Storage NIC BW | Cross-DC Ethernet BW | Vendor lock-in | SLO violation | LRU 误驱逐 | Lost-in-middle + LRU | Tool latency + 串行编排 | KV-cache thrashing | Scheduling + prefix thrash | Tool 执行等待 |
| 优化层面 | 数据通路 (RDMA) | 跨 DC 架构 | 通信原语 | SLO-aware 调度 | Cache eviction | Agent-cache co-design | Orchestrator-engine API | Admission control | Query plan rewriting | Speculative tool exec |
| 网络假设 | InfiniBand + VL QoS | Commodity Ethernet | ConnectX + EFA | 无 | 无 | 无 | 无 | 无 | 无 | 无 |
| 存储假设 | 3FS (SSD) | N/A (HBM/DRAM) | 无 | 无 | CPU DRAM 二级 | 无 | 无 | GPU HBM | GPU HBM pinned | 无 |
| 模型要求 | 无 | Hybrid attention | 无 | 无 | 无 | 无 | 无 | 无 | 无 | 无 |
| 规模验证 | 1152 GPU | 96 GPU | 384 GPU | 16 GPU | 1 GPU | 8 GPU | 1 GPU | 16 GPU | 2 GPU | 32 GPU |
| 开源 | 否 | 否 | 是 | 否 | 否 | 否 | 否 | 否 | 是 (demo) | 否 |
DualPath vs DeepSeek-V3 — 基础设施演进。DeepSeek-V3 的 DualPipe 通过双向 pipeline + 细粒度 overlap 实现训练端 all-to-all 通信隐藏；DualPath 的 CNIC-centric data path 通过 InfiniBand VL QoS 实现推理端 KV-Cache 传输隐藏。两者共享的核心工程洞察是利用 NIC 级硬件 QoS 做流量优先级隔离——DualPipe 在 SM 级别用 warp specialization 分离通信和计算，DualPath 在 NIC 级别用 VL arbiter 分离模型通信和数据搬运。从 DualPipe 到 DualPath 的跃迁体现了 DeepSeek infra 团队对 InfiniBand 硬件特性的深度积累——外部团队即使读了 DualPipe 论文也难以推导出"所有 H2D/D2H 绕路走 NIC"这个违反直觉的设计决策。
DualPath vs PrfaaS — KV-Cache I/O 的两条解法路线。两者代表 KV-Cache 传输瓶颈的根本性分歧：DualPath 在单集群内"借道" DE 端 SNIC + RDMA 计算网络，强依赖 InfiniBand VL QoS 隔离；PrfaaS 通过混合注意力把单实例 KV 吞吐 $\Phi_{\text{kv}}$ 降低 4–13× 后走跨 DC Ethernet。DualPath 对模型架构无要求（MLA 和 GQA 均可），但硬件要求极高；PrfaaS 对模型有要求（混合注意力），但硬件门槛低。这是"模型约束 vs 基础设施约束"的根本 trade-off。两者的层间 prefill pipelining 设计高度相似——这不是巧合，而是 PD 分离架构下消除传输-计算串行化的唯一正确做法。
DualPath vs fabric-lib — RDMA 生态的通用化路径。DualPath 的 CNIC-centric data path 深度绑定 InfiniBand libibverbs；fabric-lib 用 ImmCounter + reliable-but-unordered 语义统一了 ConnectX 和 EFA。fabric-lib 在 ConnectX-7 上 MoE decode 超越 DeepEP，证明 host proxy + RDMA Write 方案在当代硬件上可行且高效。DualPath 的 RDMA Write work submission ~1μs 性能优势与 fabric-lib 的 TransferEngine 架构（per-GPU worker + per-NIC domain）可以互相借鉴。若 DualPath 的 dual-path loading 逻辑迁移到 fabric-lib 之上，将打破 InfiniBand 强绑定，使方案可部署到 AWS EFA 等云原生环境。
DualPath vs Concur — 互补而非替代。Concur 通过限制并发 agent 数避免 KV-cache thrashing（GPU HBM 层面），完全不涉及存储 I/O 瓶颈。DualPath 解决的是"从 SSD 加载 KV-Cache 到 HBM"的带宽问题。两个瓶颈在不同负载区间交替出现：低负载下 I/O 是瓶颈（DualPath 场景），高并发下 cache thrashing 是瓶颈（Concur 场景）。Concur 的实验数据揭示了一个关键现象：middle-phase thrashing 中 49% 的延迟是纯 KV 重算开销——如果 DualPath 能将 KV 重加载速度翻倍，Concur 的 recomputation penalty 将相应减半，两者的收益是乘性叠加的。
DualPath 的独有增量：
与现有认知的矛盾：DualPath 的"DE 端 SNIC 帮忙读 KV-Cache"假设 decode engine 的 storage NIC 几乎完全空闲。但论文描述了 KV-Cache 持久化写回机制（每 64 token 写一次到 3FS）。在高吞吐场景下大量 DE 同时产生 token 并写回，DE 端 SNIC 写流量不可忽略。论文未量化写流量对 DE 端 SNIC 可用带宽的影响。
以下攻击针对 DualPath L2 §6 论证链中的具体步骤。
Attack 1: 98.7% KV-Cache 命中率的数据代表性 (L2 §6 step 1)
DualPath 的核心前提是 agentic workload 下 KV-Cache 命中率极高（98.7%），推导出 prefill 从 compute-bound 转变为 I/O-bound。这个数字来自 DeepSeek 内部 RL training 的 coding agent trace（平均 157 轮、每轮 429 token append）。但这是高度特化的 workload：coding agent 的上下文增长模式（短追加、长历史）是所有 agentic workload 中 KV-Cache 最友好的。Sutradhara 的生产 trace 显示中位请求仅 2 次 LLM 迭代，远少于 DualPath 的 157 轮。JITServe 评估的 Deep Research compound 请求的输入均值达 12K tokens/stage，上下文结构与 DualPath 假设的"短追加"模式差异巨大。PASTE 的跨 agent/benchmark 分析显示 tool 执行占总时间 35–61%——在 tool 等待期间，KV-Cache 的 working set 模式可能与 DualPath 假设的"稳定高命中率"显著不同。如果命中率降至 80%，cache-compute ratio 显著下降，I/O 瓶颈假设可能不成立，dual-path loading 无收益。
Attack 2: CNIC-centric 流量隔离的脆弱性 (L2 §6 step 7)
DualPath 声称通过 InfiniBand VL 的 WRR 策略将模型推理通信分配 ~99% 带宽优先级。这个隔离效果高度依赖 InfiniBand switch 的 VL 实现质量——不同厂商的 WRR 实现对突发流量处理不同。fabric-lib 的经验表明，在 EFA 上 256KiB write 仅达 54 Gbps（ConnectX 的 47%），说明 RDMA 实现之间的性能差异远非理论分析所能覆盖。更关键的是，DualPath 假设集合通信是 sub-millisecond 级脉冲，但在 DeepSeek-V3 的 EP AllToAll 中，如果 expert 分布不均匀导致通信持续时间拉长，KV-Cache 流量可能显著干扰模型推理。论文未给出 VL 隔离下模型通信延迟的分布数据——只给了 SNIC load balance 和 attention balance 数据。DeepSeek-V3 L2 中提到的"EP AllToAll 通信时间几乎等于计算时间"进一步质疑了"推理通信为脉冲式"的假设。
Attack 3: Bottleneck-free 条件的静态假设 (L2 §6 step 6)
论文推导在 $g=8, s=1$ 配置下 bottleneck-free P/D 比范围为 $1/7 \leq P/D \leq 7/2$。但推导假设稳态负载——所有 PE 和 DE 同时处理相同量的工作。Concur 的三阶段执行模式分析表明，真实 agentic workload 存在 warmup→thrashing→cooldown 的动态变化，在 middle-phase KV-cache 使用率锁定在 ~100% 但命中率崩溃到 ~30%。这种动态失衡会导致 PE/DE 负载瞬时极端不均，有效 P/D 比可能暂时超出 bottleneck-free 范围。此外，1152 GPU 部署规模下部分节点故障导致 P/D 比动态变化，论文承认 failure handling 完全未涉及。
Attack 4: 基线对比的公平性漏洞 (L2 §6 step 9)
DualPath 的 1.87× 和 1.96× 加速相对于"自家 in-house framework 未修改版（Basic）"。论文自承与 SGLang(MC) 的对比"is unfair due to implementation differences"。关键问题：(1) SGLang(MC) 使用 1.5TB DRAM/node 做 Mooncake Store，DualPath 仅 80GB——Mooncake 的 DRAM cache 命中率未报告。Concur 的实验表明 HiCache（CPU offloading）可达 97% hit rate，如果 Mooncake 的 DRAM 足以覆盖 working set，DualPath 解决的问题被 DRAM cache 直接规避；(2) DualPath 使用 DP attention，SGLang(MC) 使用 TP=8——attention 计算效率不同，混淆了 I/O 优化的真实贡献；(3) 缺少与 Helium、KVFlow、Concur 等近期 agentic serving 系统的对比。
Attack 5: DE 端 SNIC "完全空闲"的过度简化 (L2 §6 step 4)
DualPath 的核心洞察建立在"DE 端 storage NIC 几乎完全空闲"的观察上。但论文同时描述了 KV-Cache 持久化写回机制——每 64 token 写一次到 3FS。结合 Concur 的分析——单个 agent 在 10 步内 KV-Cache 从数千 token 增长到数万 token，每步 decode 产生新 KV 并需要持久化——高吞吐场景下 DE 端 SNIC 的写流量不可忽略。按 DualPath 自己的数据（DS 660B, 2P4D, 2048 agents），如果每个 DE 以 SLO 速率（40 tok/s）decode、每 64 token 持久化一次，4 个 DE 节点共 4 张 SNIC 的写负载可能达到非零水平——论文没有量化这个数字，也没有分析写流量与 DualPath 新增读流量的竞争关系。
Attack 6: Working set model 的 tool call latency 零假设 (L2 §6 step 1 间接)
DualPath 的 working set 模型（§8.2 Little's law）估算中 tool call latency 为零——论文自己承认"真实场景中 tool call latency 使 JCT 增长 $r$ 倍 → working set 增长 $r^2$ 倍"。PASTE 的实验数据显示 tool 执行占总时间 35–61%，Sutradhara 显示 tool 延迟占 FTR 的 30–80%。如果 working set 实际因 tool call 膨胀 $r^2$，那么 DualPath 模拟的 working set 规模（DS 660B 在线服务 69–681 GB）显著低估了真实场景的存储需求，进而低估了 SNIC 带宽压力——DualPath 的双路径可能在真实 tool-call-heavy workload 下仍然不够。
范式定位：DualPath 代表 PD 分离推理架构从"单通道 I/O"到"全局可调度 I/O 资源池"的范式转变。在此之前 PE 端 SNIC 是固定单点资源；DualPath 之后整个集群的 SNIC 带宽成为可被调度器动态分配的弹性资源。这与网络领域"资源池化"思路一脉相承（类似从固定路由到 SDN 的转变），在 LLM serving 系统中是首次实现。
DeepSeek 生态强绑定：DualPath 不是独立系统，而是 DeepSeek inference stack 的有机组成部分。底层依赖全部来自 DeepSeek 自研：3FS（分布式存储）、FlashMLA（attention kernel）、DeepGEMM、DeepEP。与 DeepSeek-V3 的 DualPipe 共享 InfiniBand 硬件级优化经验——从 all-to-all kernel 的 warp specialization 到 VL QoS 配置，这些 know-how 是 DualPipe→DualPath 技术传承链条上的隐性壁垒。外部团队移植面临巨大工程门槛——不仅是 ~5K 行代码修改，还包括对 InfiniBand QoS 配置、3FS 部署、RDMA verbs API 的深入理解。
采纳信号：
竞争方案生态位对比：
| 生态位 | 方案 | DualPath 的相对优势 | DualPath 的相对劣势 |
|---|---|---|---|
| Storage I/O 瓶颈 | Mooncake (DRAM pool) | DRAM 被 RL optimizer state 占用时 DualPath 是唯一出路 | DRAM 充足时 Mooncake 更简单 |
| 跨 DC offload | PrfaaS | 单集群内延迟更低 | 无法利用跨 DC 异构硬件的成本优势 |
| KV-cache 驱逐 | KVFlow / Helium | 不需要 workflow 拓扑假设 | 不优化 GPU 内 cache 驱逐策略 |
| 并发控制 | Concur | 消除 I/O bound 后 Concur 才有用武之地 | 高并发 thrashing 仍需 Concur |
| SLO-aware | JITServe | I/O 层优化与调度层正交、可叠加 | 不提供 SLO-aware 能力 |
| Tool 延迟 | PASTE / Sutradhara | 正交互补 | 不优化 tool 执行延迟 |
| 可移植性 | fabric-lib | 性能更优（生产级 InfiniBand 深度优化） | 强绑定 InfiniBand，云原生环境不可部署 |
定位判断：DualPath 是 DeepSeek 内部 agentic RL infrastructure 的关键一环，其 1.87–1.96× 提升数字可信（来自真实生产环境），但可复现性极低。对外部研究者的价值主要在于三个可移植的设计思想：(1) dual-path loading——聚合空闲 NIC 带宽；(2) CNIC-centric traffic isolation——用 NIC QoS 替代不存在的 PCIe QoS；(3) layerwise streaming——细粒度 KV 传输与计算重叠。这三个思想都不依赖 DeepSeek 的具体实现，可在 vLLM/SGLang + fabric-lib 上渐进式实现。
方向 1: DualPath + Concur 联合调度。DualPath 解决 I/O-bound（存储带宽不足），Concur 解决 scheduling-bound（KV-cache thrashing）。两者瓶颈在不同负载区间交替出现：Concur 的三阶段分析表明 middle-phase 中 49% 延迟是 KV 重算开销。一个自适应系统可以在 I/O 阶段激活 DualPath 双路径加载最大化带宽利用，在 thrashing 阶段激活 Concur 的 AIMD admission control 防止 cache 驱逐。统一反馈信号可以是 Concur 的 $(U_t, H_t)$ 双信号加上 DualPath 的 disk reading queue 长度——三维联合控制比任一方案的单维控制更精准。具体实现路径：在 DualPath 的 Central Scheduler 中嵌入 Concur 的 agent-level 窗口，admission 决策同时考虑"是否有足够 SNIC 带宽"和"是否有足够 HBM cache 容量"。
方向 2: 分层存储 × 双路径。DualPath 假设 KV-Cache 全在 SSD（3FS），但实际部署存在 DRAM → SSD → remote storage 的层次结构。将双路径思想扩展到多层：hot KV 在 DRAM（如 Mooncake pool 命中时直接走 DRAM→HBM），warm KV 走 DualPath 双路径从 SSD 加载，cold KV 走 PrfaaS 风格的跨 DC 路径。需要一个统一 cost model 在 DRAM 命中率、SNIC 带宽、跨 DC 延迟三维联合优化——PrfaaS 的 throughput model（Eq.1–8）可以作为跨 DC 层的子模型。DualPath 自身承认"零 tool call latency 假设使 working set 偏小"——在真实 tool-heavy workload 下，working set 膨胀可能使 DRAM 层变得比论文假设的更重要。
方向 3: Workflow-aware 路径选择。DualPath 的 adaptive scheduler 选择读取路径仅基于"哪侧 disk reading queue 更短"——没有利用任何 application-level 信息。KVFlow 的 Agent Step Graph 提供了"哪些 agent 即将被调用"的预测信息，Helium 的 TRT 提供了全局 workflow 依赖图，PASTE 的 Pattern Tuple 提供了 tool 调用序列预测。将这些 application-level 预测信号下推到 DualPath 路径选择器，可实现"对即将被调用 agent 的 KV-Cache 做 proactive dual-path prefetch"——不是 reactive 地响应队列长度，而是 proactive 地基于 workflow 拓扑预加载。具体地，Helium 的 nested-sequence schedule 可以告诉 DualPath "接下来 5 秒内哪些 KV-Cache block 会被需要"，DualPath 据此预先分配双路径带宽。
方向 4: Split-read 优化。DualPath 自承"将单个请求的 KV-Cache 拆分到两条路径分别读取可能更好"作为 future work 搁置。当前设计是整个请求选择一条路径。如果一个请求的 KV-Cache 很大（64K 上下文对应数百 MB），按层或按 block 拆分到 PE 路径和 DE 路径同时读取，理论上可将单请求加载延迟减半。DualPath 已有的 layerwise streaming 机制为此提供了基础——Layer Block 是逐层传输的基本单位，天然支持按层分配到不同路径。split-read 的关键挑战是调度复杂度：需要在 PE 和 DE 两侧同时管理同一请求的不同层的传输进度，并确保 attention compute 在所需层到达时立即启动。
方向 5: 通用 RDMA 通信层降低采纳门槛。DualPath 使用 DeepSeek 内部 RDMA 实现，强绑定 InfiniBand。fabric-lib 已经证明了"reliable-but-unordered"是异构 RDMA 硬件的最大公约数，ImmCounter 在此语义上可实现高效完成通知。将 DualPath 的 dual-path loading 逻辑构建在 fabric-lib 的 TransferEngine 之上——利用其 per-GPU worker + per-NIC domain 两级抽象、多 NIC 透明聚合、以及 EFA + ConnectX 双平台支持——可将 DualPath 思想从 InfiniBand-only 扩展到云原生 RDMA 硬件。这对 DualPath 设计思想的外部扩散至关重要：当前 DualPath 的价值被锁在 DeepSeek 内部，fabric-lib 是唯一经过生产验证的可移植 RDMA 通信层。
方向 6: SLO-aware dual-path 调度。DualPath 的调度器完全面向吞吐优化（offline RL rollout），不考虑 per-request SLO。JITServe 证明了 goodput-aware 调度可将 service goodput 提升 1.4–6.3×，其 GMAX 算法把每个请求建模为需要 $\text{bw}_\Delta(r)$ 带宽的矩形。将这个抽象扩展到 DualPath 的场景：每个请求不仅需要 GPU compute bandwidth，还需要 storage I/O bandwidth（PE read path 或 DE read path）。在线服务场景下，DualPath 的路径选择不应仅看"哪侧 disk queue 更短"，而应联合考虑"走这条路径后该请求是否能在 deadline 前完成 TTFT"——这是将 JITServe 的 margin goodput priority 与 DualPath 的双路径机制融合的自然方向。