LLM 正在从单轮对话的 ChatBot 演进为 Agentic 系统——自主规划、调用工具、通过多轮交互解决真实任务。1. 背景从 ChatBot 到 Agent推理范式的根本转变LLM 正在从单轮对话的 ChatBot 演进为Agentic 系统——自主规划、调用工具、通过多轮交互解决真实任务。这种范式转变对推理基础设施产生了根本性影响传统对话用户输入 → 模型回复 → 几轮交互结束Agentic 模式模型与外部环境浏览器、Python 解释器、终端交互一次任务可能持续数十甚至数百轮论文给出的生产级数据令人印象深刻平均交互轮数157 轮平均上下文长度32,700 tokens每轮新增 token仅 429 tokens平均KV-Cache 命中率98.7%Cache-Compute Ratio22 GB/PFLOPDeepSeek-V3.2这意味着每次推理只需计算 1.3% 的新 token其余 98.7% 都是从存储加载已有的 KV-Cache。推理的瓶颈从 GPU 算力变成了存储 I/O 带宽。Figure 2Agentic 推理轨迹示例——多轮交互中上下文持续累积2. 核心问题Prefill 端 NIC 饱和Decode 端 NIC 空闲当前主流推理架构采用Prefill-Decode 分离PD Disaggregation•Prefill 引擎PE负责加载 KV-Cache 计算新 token 的注意力•Decode 引擎DE负责自回归生成 token• KV-Cache 存在外部分布式存储SSD跨轮复用问题在于所有 KV-Cache 都从存储加载到 Prefill 引擎。在 98.7% 命中率下Prefill 端的存储 NICSNIC很快饱和成为整个系统的吞吐瓶颈。与此同时Decode 引擎的存储 NIC 几乎完全空闲。现有方案的局限•Mooncake月之暗面用分布式 DRAM 缓存 KV-Cache但在 RL rollout 阶段 DRAM 被训练状态占满大规模在线服务场景下 DRAM 成本也不划算•加购 NIC 带宽昂贵且在通用集群中不现实•压缩/稀疏化减少数据量但没解决 I/O 不均衡的根因Figure 1现有架构瓶颈左vs DualPath 双路径设计右3. DualPath双路径 KV-Cache 加载核心洞察KV-Cache 加载不必只走 Prefill 引擎。Decode 引擎有闲置的存储 NIC可以「帮忙搬运」。DualPath 引入两条数据路径路径 A传统存储 → SNIC → Prefill 引擎路径 B新增存储 → SNIC → Decode 引擎 → RDMA/CNIC → Prefill 引擎路径 B 利用了两个关键事实1Decode 引擎的存储 NIC 在传统架构中几乎完全空闲2Decode → Prefill 之间本来就有高性能 RDMA 计算网络CNIC带宽充足调度器根据实时负载动态选择走哪条路径。当 Prefill 端 SNIC 接近饱和时自动切换部分流量走 Decode 路径。Figure 4双路径加载示意——调度器动态分配存储→Prefill 和存储→Decode→Prefill 两条路径4. 工程难点NIC 级流量隔离引入新路径最大的风险是KV-Cache 传输可能干扰模型推理的集合通信AllReduce 等导致延迟抖动。现代 AI 数据中心的关键架构特征• 每个节点 8 张 GPU每张 GPU 配一个400Gbps 计算 NICCNIC东西向• 每个节点另有独立的400Gbps 存储 NICSNIC南北向• 计算网络与存储网络物理隔离DualPath 的解法• 路径 B 中 Decode→Prefill 的传输走计算网络CNIC但通过精确的 NIC 分配避免与推理通信在同一 NIC 上竞争• 在常见的 P/D 比例如 1:2下数学上可以证明不会产生拥塞• 实测结果KV-Cache 传输对 Token 间延迟TBT的影响几乎为零Figure 3硬件趋势——从 Ampere 到 BlackwellI/O-Compute 比值下降 14.4 倍I/O 瓶颈愈发严重5. 全局调度器计算 网络双维联合优化调度器要回答三个问题Q1每个请求分配到哪个 Prefill 引擎计算负载均衡Q2该请求的 KV-Cache 走路径 A 还是路径 B网络负载均衡Q3如果走路径 BKV-Cache 经由哪个 Decode 引擎中转中转节点选择关键设计•引擎间调度基于「读取队列长度阈值 α」和「未完成预填充比例 β」两个参数在 PE 之间做负载感知分发•引擎内调度基于计算配额的批次选择——每层注意力计算前先加载该层 KV-Cache流水线重叠 I/O 和计算•Layerwise Prefill逐层分配/释放 KV-Cache单层 HBM 占用 ≈ 总量/层数有效批次大小提升约等于层数倍Figure 5引擎间调度——8 张 GPU 在同一 PE 内的负载分发示意Figure 6引擎内调度——计算配额批次选择 GPU 时间线6. 实验结果在三个模型 生产级 Agentic 工作负载上测试数据来自真实 coding 任务 trace离线推理Offline• 端到端作业完成时间JCT降低最高 46.5%• 吞吐提升最高 1.87ו 在不同 Agent 数量64-1024和最大 Agent 长度32K-128K下均有显著提升在线服务Online• 吞吐平均提升 1.96×DS 27B: 1.67×, DS 660B: 2.25ו 所有配置下均不违反 SLO延迟服务等级目标• TTFT首 Token 延迟显著降低TBTToken 间延迟保持不变消融实验证明三个组件都有贡献• Layerwise Prefill 降低 JCT 17.2%• 双路径加载在此基础上再降 25.2%• 全局调度进一步优化负载均衡NIC 流量 Max/Avg 比仅 1.06Figure 7不同 Agent 数量和上下文长度下的离线推理性能Figure 10在线服务延迟指标TTFT/TTST/TPOT随到达率变化Insight这篇论文的启示1. Agentic 推理是一个全新的系统问题98.7% 的 KV-Cache 命中率、157 轮平均交互、22 GB/PFLOP 的 cache-compute ratio——这些数字说明 Agentic 推理和传统对话推理是完全不同的工作负载需要专门的系统优化。2. 硬件趋势在加剧这个问题论文指出从 Ampere 到 BlackwellI/O-Compute 比值下降了 14.4 倍。GPU 算力增长远快于存储带宽意味着I/O 瓶颈只会越来越严重。3. 「不加硬件只改编排」的务实思路DualPath 不需要额外硬件投入——Decode 引擎的 SNIC 带宽本来就在只是没被利用。这种重新编排已有资源的思路对大规模部署非常友好。4. DeepSeek 在 Agentic 基础设施上的投入信号这篇论文来自 DeepSeek 内部推理系统团队 北大合作测试使用的是「生产级 coding 任务 trace」。这暗示 DeepSeek 正在大力投入 Agentic 场景的基础设施优化为其 AI Agent 产品做技术储备。论文精读推荐PaperScope想深入阅读这篇 78,000 字的论文全文推荐使用PaperScopeP 站•左右对照 PDF 翻译原文 中文翻译并排显示逐段对照阅读•AI 问答对论文内容直接提问快速定位关键公式和实验细节 https://www.paperscope.ai/hf/2602.21548 https://huggingface.co/papers/2602.21548论文速览•问题Agentic 推理瓶颈从 GPU 计算转移到了 KV-Cache 存储 I/O•根因Prefill 引擎存储 NIC 饱和Decode 引擎 NIC 闲置•方案双路径 KV-Cache 加载存储→Prefill 存储→Decode→RDMA→Prefill•结果离线 1.87x / 在线 1.96x 吞吐提升首 Token 延迟显著降低•团队北京大学 清华大学 DeepSeek