网站开发知识点总结,wordpress多功能代码,wordpress专题页面,详情页模板psd这篇新论文介绍了一个名为「DualPath」的创新推理系统#xff0c;专门针对智能体工作负载下的大语言模型#xff08;LLM#xff09;推理性能进行优化。「DeepSeek V4 来了#xff01;」这样的消息是不是已经听烦了#xff1f;我们也是。不过 DeepSeek V4 虽然迟迟未发&…这篇新论文介绍了一个名为「DualPath」的创新推理系统专门针对智能体工作负载下的大语言模型LLM推理性能进行优化。「DeepSeek V4 来了」这样的消息是不是已经听烦了我们也是。不过 DeepSeek V4 虽然迟迟未发但今天我们等来了其与清华、北大合作撰写的一篇新论文。总结来说这篇新论文介绍了一个名为「DualPath」的创新推理系统专门针对智能体工作负载下的大语言模型LLM推理性能进行优化。具体来讲通过引入「双路径 KV-Cache 加载」机制解决了在预填充 - 解码PD分离架构下KV-Cache 读取负载不平衡的问题。该推理系统带来了显著效果在离线推理场景中实现了 1.87 倍的吞吐量提升在线服务场景下实现了 1.96 倍的服务吞吐量提升。论文标题DualPath: Breaking the Storage Bandwidth Bottleneck in Agentic LLM InferencearXiv 地址https://arxiv.org/pdf/2602.21548我们知道如今智能体已经成为主流 AI 开发范式。但是智能体范式下出现了全新的瓶颈即存储带宽。在多轮互动的智能体场景中上下文信息会随轮次迅速累积导致其呈现出 「长上下文、短追加」 的特征。研究指出这类负载的 KV-Cache 命中率通常高于 95%。这意味着系统性能的决定性因素已不再是纯粹的计算能力而是从存储中加载 KV-Cache 的效率。在现有的预填充 - 解码分离PD-disaggregated架构中所有的存储 I/O 压力都集中在预填充引擎PE的存储网卡上而解码引擎DE的存储带宽则被闲置。这种带宽利用的极度不平衡成为了限制系统吞吐量的核心障碍。针对这一痛点DualPath 重新设计了数据加载路径核心创新在于引入了存储到解码Storage-to-Decode路径包括以下两个特征一方面是双路并行。KV-Cache 不仅可以直接读入预填充引擎还可以先加载到解码引擎随后通过高带宽 RDMA 计算网络高效传输至预填充引擎。另一方面是带宽资源池化通过动态分配两条路径的负载DualPath 成功将集群中所有引擎的存储网卡聚合为一个 全局容量池彻底打破了单节点 I/O 的限制。另外为了确保大规模数据传输不干扰延迟极其敏感型的模型推理任务DualPath 还采用了以下两项关键技术一是以计算网卡CNIC为中心的流量管理系统将所有 GPU 相关的流量包括本地内存拷贝统一通过计算网卡进行管理同时利用网络的服务质量QoS机制将推理通信设为高优先级确保加载 KV-Cache 的流量仅利用闲置带宽不影响延迟 SLO。二是自适应请求调度调度器实时监控各引擎的磁盘读取队列长度和计算负载动态决定每个请求的最优路径。同时通过计算配额机制优化引擎内调度最大限度减少 GPU 执行过程中的气泡。研究团队在包含 1152 个 GPU 的大规模生产集群上对 DualPath 进行了评估并验证了离线与在线服务场景下吞吐量的显著提升。接下来解析 DualPath 系统细节。DualPath 系统概览为了打破 Prefill 侧存储 I/O 的瓶颈DeepSeek 提出了一种双路径加载架构重新设计了在 Prefill–Decode 解耦PD-disaggregated推理架构中 KV-Cache 的读取方式。传统做法是所有 KV-Cache 都从存储直接读入 Prefill 侧 GPU导致 Prefill 侧存储网卡成为单点瓶颈。DualPath 则在此基础上增加了一条新的加载路径从而缓解这一不平衡问题。DualPath 仍然建立在两项已有技术之上1P/D 解耦PD Disaggregation将 prompt 处理与 decode 处理分离以提高整体效率2Layerwise Prefill通过按层加载 KV-Cache避免了 LayerKV 和 PrefillOnly 指出的 Prefill 引擎上的 HBM 显存瓶颈问题从而提升 GPU 利用率。DualPath 整个系统由三部分组成推理引擎Inference Engines。每个引擎管理一张 GPU。引擎分为两类用于执行 prefill 的 Prefill EnginePE以及用于执行 decode 的 Decode EngineDE。流量管理器Traffic Manager。每个引擎内部都包含一个流量管理器负责1主机与设备之间的内存拷贝H2D 与 D2H2PE 与 DE 之间的 KV-Cache 传输3通过存储网卡进行 KV-Cache 的读写操作。DeepSeek 采用以 CNIC 为中心的流量管理方案以防止 KV-Cache 相关流量干扰模型推理过程中的通信。请求调度器Request Scheduler。一个中心化调度器负责接收客户端请求并将其分配到不同引擎。同时它还负责在两条加载路径之间动态分配数据流量如图 4 所示。双路径加载Dual-Path Loading传统系统中KV-Cache 只能从存储直接读入 Prefill 引擎因此所有存储带宽压力都集中在 Prefill 侧形成单点瓶颈。DualPath 在此基础上增加了一条新的加载路径KV-Cache 可以先从存储读入 Decode 引擎再通过高速 RDMA 计算网络传回 Prefill 引擎。这样系统就可以同时利用 Prefill 和 Decode 两侧的存储网卡带宽而不是只依赖 Prefill 一侧从而消除带宽不均衡问题。为了实现双路径加载DualPath 在每个 Prefill EnginePE和 Decode EngineDE上分配少量 DRAM 作为缓冲区分别称为 PE buffer 和 DE buffer。Prefill 侧读取路径。首先将命中 token 的 KV-Cache 从持久化存储中读取到 PE buffer如图 4a 中标注 1 和 2。在某一注意力层开始计算之前该层对应的 KV-Cache 会从 PE buffer 传输到 PE 的 HBM3 和 4用于计算未命中cache-miss的 prompt token 的 KV-Cache。随后命中和未命中 token 的所有 KV-Cache 都会被传输到 DE buffer以组成完整的 prompt KV-Cache 5–7。步骤 3–7 的流程会重复 n_layer 次。在 prefill 前向计算过程中数据传输与计算是重叠执行的。预填充 DE 读取路径。首先命中 token 的 KV-Caches 会被读取到 DE 缓冲区中如图 4b 中的标签 1 和 2 。在 PE 预填充期间相应层的 KV-Cache 会从 DE 缓冲区中读取这同样与计算过程相重叠 3-5。此过程会重复 n_layer 次。当每一层的计算完成后只有缺失 token 的 KV-Caches 会被传输到 DE 缓冲区并与现有的命中 token KV-Cache 进行合并。解码阶段。在 DE 缓冲区接收到完整的提示 KV-Cache包括通过 PE 读取路径加载的 KV-Cache 以及新追加 token 的 KV-Cache后解码阶段正式开始。DE 首先分配 HBM 并执行主机到设备H2D传输如图 4a 中的标签 8 和 9图 4b 中的标签 6 和 7 随后在开始解码前释放 CPU 内存。DE 缓冲区的设计虽然给 DRAM 和 CNIC 带来了额外的带宽压力因为增加了一次额外的 H2D 拷贝这本可以通过 GPU Direct RDMA 直接绕过来避免。然而由于在此类智能体场景下生成的长度通常较短首 token 延迟在整个端到端请求时间中占据了不可忽视的比例。引入 DE 缓冲区有助于减少 GPU 内存占用。在解码过程中每当累积一个完整的 token 块例如 64 个 token时系统会立即将其持久化到磁盘中。不同的数据块布局。DualPath 采用了两种不同的数据块布局完整块和层级块它们分别包含所有层的信息和单个层的信息。对于所有与存储系统的交互均采用完整块。在 PE 读取的情况下KV-Cache 加载到 PE HBM 以及传输到 DE 缓冲区的过程是以层级流式方式进行的两者都使用层级块。同样地对于 DE 读取路径从 DE 缓冲区到 PE HBM 的传输也使用层级块。无瓶颈Bottleneck-Free分析比例预填充 / 解码比例下证明了该系统可以完全打满所有存储网卡NIC的带宽且不会引入计算网卡或 DRAM 的瓶颈。假设 PCIe 拓扑配置良好即每一对 GPU - NIC 都位于同一个 PCIe 交换机下、任务调度负载均衡、计算网络无拥塞且存储读取带宽得到了充分利用。首先是 PE CNIC 带宽分析。对于 PE CNIC由于存在回环流量即不经过交换机的 H2D 和 D2H 拷贝因此无论读或写操作PCIe 侧的总流量始终大于或等于交换机方向的流量。因此只需要计算 PCIe 侧的压力。读取操作包括 PE 路径 (3) 和 (5)其在所有配对上的总流量为其次是 DRAM 压力分析。DRAM 是半双工的因此将读取和写入压力相加。对于 PE 内存其压力为 2sB这通常不会超过内存带宽。对于 DE 内存遵循上述类似的分析可以得出其压力为 (3 2P / D) Bs。要求 DE 内存压力小于或等于 M得到如下更多公式请参考原论文。实际挑战双路径架构从根本上重新定向了数据移动方式KV-Cache 既可以直接从存储加载到预填充引擎也可以通过解码引擎间接加载 。通过这种方式系统聚合了所有引擎的存储带宽从而打破了预填充侧的 I/O 瓶颈 。然而在实际系统中实现这一高层设计引入了三个相互关联的挑战 。一是细粒度数据传输。层级执行范式虽然对于克服 HBM 容量限制至关重要但它会将 KV-Cache 碎片化为海量的细粒度数据块。为了实现吞吐量增益在存储、主机 DRAM 和 GPU HBM 之间传输这些海量的细粒度数据块时必须确保产生极低的开销并与计算任务无缝重叠。二是流量隔离。DualPath 中复杂的数据路径在计算网络和 PCIe 链路上都引入了额外的 KV-Cache 传输流量。一个主要的顾虑是这些流量可能会干扰模型执行中至关重要的、对延迟敏感的现有集合通信操作 —— 例如专家并行中的 AllToAll以及张量 / 上下文并行中的 ReduceScatter 和 AllGather。由于这些集合通信直接决定了端到端的推理延迟因此在不降低模型推理性能的前提下利用空闲 I/O 带宽是一个关键挑战。三是动态负载均衡。由于采用了两种不同的 KV-Cache 加载路径系统必须及时决定每个请求使用哪条路径。过于简单的策略可能会导致某条路径过载从而重新产生原始瓶颈。流量调度器必须实时平衡多个因素存储网卡队列长度、GPU 上的计算负载以及请求的工作负载特性。评估结果在评估部分论文核心任务只有一个证明 DualPath 在真实 agent 工作负载下确实能解决存储带宽瓶颈并带来稳定、可扩展的性能提升。论文在自研推理框架上实现 DualPath核心改动约 5000 行代码。底层使用 FlashMLA、DeepGEMM、DeepEP 等高性能算子存储后端采用 3FS 分布式存储。评测模型包括DS 660BMoE 稀疏注意力、DS 27B缩小版实验模型Qwen 32B稠密模型。离线批量推理这一部分模拟 RL rollout 场景n 个 agent 同时启动测整体完成时间JCT。不同 Agent 批量规模与最大 Agent 长度MAL的影响。 随着批量规模增大以及 MAL 变长DualPath 的优势更加明显。图 7 展示了在不同 batch size 与 MAL 组合下的 JCT 表现。SGL (MC) 出现错误未能完成部分大规模配置图中 token 为 N/A。在 DS 660B 模型上DualPath 相比 Basic 最高实现了 1.87× 的加速并展现出接近 Oracle 的性能这表明 KV-cache 的 I/O 开销基本被消除。在 DS 27B 上DualPath 相比 Basic 最高提升 1.78×但由于 1P1D 架构下存储带宽受限其性能仍比 Oracle 慢 1.09–1.85×见图 8。对于 Qwen 32B趋势与 DS 27B 类似。不同追加长度Append Length与生成长度Generation Length的影响。如图 9 所示随着追加长度增加Basic 的性能逐渐接近 DualPath 和 Oracle而 DualPath 与 Oracle 的性能变化较小这表明系统瓶颈始终主要来自 GPU 计算压力。与 Basic 相比DualPath 在不同追加规模下实现了 1.82–1.99× 的加速。生成长度扩展时的趋势类似。Online Serving在线推理服务在线服务实验部分则模拟真实生产环境下 agent 按泊松分布持续到达的场景设置 TTFT ≤ 4 秒、TPOT ≤ 50 毫秒为服务等级目标。结果表明DualPath 显著提高系统可承载的到达率上限在 DS 27B 上提升 1.67 倍在 DS 660B 上提升 2.25 倍。与此同时DualPath 的 TTST 与 Basic 基本持平TPOT 也未引入额外解码开销说明其优化集中在 KV-Cache 读取与排队阶段而不会影响解码阶段效率。更重要的是在负载升高时DualPath 能保持 TTFT 结构稳定而 Basic 的排队时间会因存储带宽不足迅速上升成为延迟恶化的主要来源。最后论文还做了大量消融实验感兴趣的读者可以参考原论文查看更多内容。