DeepSeek联手清华北大发布DualPath框架：双路径KV-Cache加载如何让智能体推理效率翻倍？

快速摘要
DeepSeek联合清华、北大团队发布了面向AI智能体推理的全新框架DualPath，核心解决了大规模KV-Cache从外部存储加载时的I/O瓶颈问题。 在传统的预填充-解码分离（PD分离）架构中，预填充引擎的存储网卡承担了全部KV-Cache读取压力，而解码引擎的存储网卡却处于闲置状态。DualPath通过引入「Storage-to-Decode」第二条加载通路，利用解码端闲置的网络带宽分担数据搬运任务，再经由高速RDMA网络将缓存传输至预填充引擎，从而打破了存储带宽这一关键瓶颈。实测结果显示，离线推理吞吐量最高提升1.87倍，在线服务场景下每秒智能体运行次数提升1.96倍——这几乎是纯软件架构优化带来的近两倍性能增长。文章下方将从底层原理、架构设计到实验数据，为你做一次完整的技术拆解。
—— 莫潇羽@无忆研习社

一、为什么需要DualPath？从智能体推理的真实痛点说起

2026年开年以来，AI智能体（Agent）赛道迎来了前所未有的爆发。无论是自主执行任务的OpenClaw、还是各类编程辅助智能体，它们都有一个共同的特征：需要进行大量的多轮对话式推理。

OpenClaw作为一个开源AI智能体项目，在短短几周内就在GitHub上收获了超过15万颗star，成为近年来增长最快的开源项目之一。它能够连接到WhatsApp、Telegram、Slack等消息平台，自主执行邮件管理、日历调度、代码部署、网页浏览等真实世界的任务。与传统的对话式AI不同，OpenClaw不仅仅是回答问题，它真正在「动手做事」。类似的，各种编程辅助智能体也在快速发展，它们能够自主阅读代码库、理解需求、编写代码、运行测试、修复bug，整个过程只需要极少的人类干预。

这些智能体的共同点是：每一次任务执行都涉及大量的多轮模型推理。模型需要不断地接收环境反馈、更新自己的「工作记忆」、制定下一步行动计划。

一个典型的智能体编码任务可能持续几十分钟甚至数小时。在这期间，模型需要反复阅读上下文、生成代码、调用工具测试、回看结果再修改。上下文长度动辄达到数万甚至数十万token，而每一轮交互都要求极快的响应速度。

DeepSeek团队从真实的智能体编码任务中采集了大量轨迹数据，发现了几组关键数字：

• 平均每个任务的交互轮次高达157轮，说明模型确实在进行极为频繁的多轮对话
• 平均上下文长度约32,700个token
• 每次新增的追加内容平均仅429个token
• 这意味着KV-Cache的命中率高达98.7%——几乎所有的历史「记忆」都在被反复复用

这些数据揭示了一个此前被行业低估的问题：在智能体场景下，推理的瓶颈已经不是计算本身，而是数据搬运。

1.1 什么是KV-Cache？为什么它这么重要？

要理解DualPath解决的问题，首先需要搞清楚KV-Cache这个核心概念。莫潇羽@无忆研习社在这里用一个通俗的比喻来解释。

当你和大语言模型对话时，模型每生成一个token（可以理解为一个字或一个词），都需要「回头看」之前所有的对话内容。在Transformer架构中，这个「回头看」的动作通过注意力机制（Attention）来完成。具体来说，模型会为每一层的每一个token计算出一组Key向量和Value向量——这就是所谓的KV对。

如果每次生成新token都要重新计算所有历史token的KV对，计算量会非常恐怖。因此，业界的通用做法是把已经算好的KV对缓存起来，下次直接取用。这个缓存，就叫做KV-Cache。

你可以把KV-Cache理解成模型的「草稿纸」：每次思考的中间结果都记在上面，下次继续写的时候翻翻草稿就行，不用从头再算一遍。

问题在于，这张「草稿纸」会随着对话轮次和上下文长度的增加而变得越来越厚。在智能体场景下，一个长时间运行的任务可能积累出数十GB的KV-Cache数据。

让我们来具体算一笔账，感受一下KV-Cache的体积有多惊人。以一个使用GQA（分组查询注意力）机制的典型模型为例，假设模型有80层、每层的KV头数为8、每个头的维度为128，存储精度为BF16（每个数值占2字节）。对于一个包含32,000个token的上下文，单个请求的KV-Cache大小大约为：

KV-Cache大小 ≈ 2(K和V) × 80(层数) × 8(KV头数) × 128(维度) × 32000(token数) × 2(字节)
           ≈ 2 × 80 × 8 × 128 × 32000 × 2
           ≈ 约 7.8 GB

如果使用DeepSeek独创的MLA（Multi-Head Latent Attention）机制，情况会好很多。MLA的核心思想是在存储KV对之前，先将它们压缩到一个低维的潜在空间中。具体来说，MLA不是直接缓存原始的Key和Value向量，而是缓存一个维度远小于原始KV的压缩潜在向量。在推理时，这个压缩向量会被重新投影回原始维度参与计算。这种设计虽然增加了一次矩阵乘法运算，但大幅减少了显存占用。

DeepSeek-V3的MLA将KV压缩维度设为512。相比标准多头注意力机制下动辄数百KB/token的KV-Cache开销，MLA可以将其压缩到约70KB/token的水平。这是一个接近数量级的改进。

然而即便有了MLA的压缩优势，当上千个智能体任务同时运行、每个任务都带着几万token的上下文时，KV-Cache的总量仍然是一个天文数字。举个例子，如果同时运行5000个智能体任务，每个任务的平均上下文长度为32K token，即使使用MLA压缩，总KV-Cache量也接近：

5000 × 32000 × 70KB ≈ 10.7 TB

超过10TB的数据，显然不可能全部放在GPU的HBM显存中。这就是为什么外部存储方案成为了刚需。

1.2 HBM显存困境与外部存储方案

KV-Cache理想的存放位置是GPU的高带宽显存（HBM）。HBM的读写速度极快，能够让GPU在需要时立即获取到缓存数据。但问题是HBM的容量非常有限——即便是当前先进的GPU卡，单卡HBM容量也不过80GB到192GB级别。当多个智能体任务并发运行时，HBM根本装不下所有的KV-Cache。

更糟糕的是，HBM的产能供给一直处于紧张状态。由于AI行业对HBM的需求急剧增长，制造商将大量产能向HBM倾斜，导致消费级DRAM内存的供应受到挤压，价格出现了明显上涨。

即便抛开成本因素，HBM容量的物理限制也是一个硬约束。以NVIDIA H100为例，单卡配备80GB HBM3显存。模型权重本身就需要占用相当一部分显存空间，在启用张量并行的情况下，留给KV-Cache的空间往往只有几十GB。而KV-Cache的空间需求会随着并发请求数和上下文长度线性增长，很快就会把剩余显存吃光。

存储层级及其特性对比（莫潇羽@无忆研习社 整理）

存储类型     | 典型容量      | 带宽           | 每GB成本  | 延迟
------------|-------------|---------------|---------|--------
GPU HBM     | 80-192 GB   | 2-5 TB/s      | 最高     | ~ns级
主机 DRAM   | 512GB-2TB   | 200-400 GB/s  | 中等     | ~100ns级
NVMe SSD    | 数TB-数十TB  | 5-15 GB/s     | 较低     | ~μs级
分布式存储   | PB级         | 聚合数TB/s     | 最低     | ~ms级

因此，行业普遍采用的方案是：将暂时不需要的KV-Cache卸载（offload）到更便宜、容量更大的外部存储中——比如主机的DRAM内存，或者更大容量的NVMe SSD，甚至是像3FS这样的分布式文件系统。当模型需要使用这些缓存时，再从外部存储搬运回GPU显存。这种策略在技术上被称为「KV-Cache卸载」或「分层KV-Cache存储」。

DeepSeek自家开源的3FS分布式文件系统（Fire-Flyer File System）就是为这类场景设计的。3FS利用RDMA网络和现代SSD提供高吞吐的共享存储层，非常适合作为KV-Cache的外部存储后端。

但这里有一个问题：搬运速度跟不上计算速度。

1.3 I/O瓶颈：GPU在「空转」

让我们来看一组DeepSeek论文中给出的真实数据。在智能体编码场景下，缓存-计算比（Cache-Compute Ratio，定义为需要加载的KV-Cache数据量与所需计算量之比）对于DeepSeek-V3.2模型约为22GB/PFLOP。

这个数字意味着什么？简单来说，每执行1 PFLOP（即 (10^{15}) 次浮点运算）的计算，就需要从外部存储加载约22GB的KV-Cache数据。考虑到现代GPU的算力增长远快于存储带宽增长，这就构成了一个严重的不对称问题。

DeepSeek团队在论文中进一步指出了三个层面的矛盾：

• 网络带宽增速落后于GPU算力增速：近年来，GPU的浮点运算性能（FLOPS）的增长幅度远超网络带宽和HBM容量的增长，导致I/O与计算的比率下降了约14.4倍。换句话说，GPU越来越快，但「喂」给GPU的数据管道却没有等比例变粗。
• HBM容量限制了并发处理能力：有限的HBM容量直接限制了GPU内核能够同时处理的token批次大小。批次太小，GPU的张量核心（Tensor Core）等计算单元就无法被充分利用。
• 存储网络利用率严重失衡：在现有的PD分离推理架构中，预填充引擎和解码引擎对存储网络的使用极不均衡——预填充端忙到起飞，解码端却基本闲着。

这第三点，正是DualPath要解决的核心问题。

二、PD分离架构：理解DualPath的前置知识

在深入DualPath的设计之前，我们需要先了解当前大语言模型推理系统的主流架构——PD分离（Prefill-Decode Disaggregation）。无忆研习社的读者如果对这部分已经熟悉，可以直接跳到第三节。

2.1 LLM推理的两个阶段

大语言模型的推理过程天然地分为两个阶段：

预填充阶段（Prefill）：模型一次性并行处理完整的输入序列（即你发送给模型的所有文本），为每一层每一个token生成KV对并存入KV-Cache，同时产出第一个输出token。这个阶段是计算密集型的——大量矩阵运算需要GPU的算力全力支持，但对显存的占用压力相对可控。

解码阶段（Decode）：模型基于预填充阶段建立的KV-Cache，逐个生成后续的输出token。每生成一个token，就需要用新的Query向量去和所有历史token的KV对做注意力计算。这个阶段是访存密集型的——计算量不大，但需要频繁地从KV-Cache中读取大量数据。

这两个阶段的资源需求特征截然不同，好比一个需要大马力发动机（算力），另一个需要大油箱（内存带宽）。

为了更直观地理解这两个阶段的差异，我们可以从数学角度做一个简化分析。在预填充阶段，处理一个长度为 (N) 的输入序列，注意力计算的浮点运算量大致正比于 (N^2)（因为每个token都需要和所有其他token计算注意力分数）。而在解码阶段，每生成一个token的计算量只正比于 (N)（新token只需和已有的KV-Cache计算一次注意力）。但解码阶段需要从KV-Cache中读取所有 (N) 个token的KV数据，这对内存带宽的需求远大于对算力的需求。

用一个更形象的数据来说明：在预填充阶段，GPU的算力利用率（MFU）通常可以达到60%以上，因为有大量并行的矩阵运算可以充分利用GPU的Tensor Core。但在解码阶段，由于每次只处理一个新token（或很少量的token），GPU的算力利用率可能不足10%，大部分时间都花在了从显存中读取KV-Cache数据上。

2.2 为什么要分开部署？

在传统的统一部署方案中，预填充和解码在同一组GPU上交替执行。这带来了严重的资源争抢问题：当GPU忙于处理计算密集的预填充任务时，需要低延迟响应的解码任务就必须排队等待；反之亦然。

PD分离架构的核心思想是：把预填充和解码部署到不同的GPU节点上，让它们各司其职。

• 预填充引擎（PE，Prefill Engine）：专门负责处理新请求的预填充计算。通过选择高算力配置，最大化预填充吞吐量。
• 解码引擎（DE，Decode Engine）：专门负责逐token生成。通过优化内存带宽利用，降低单token生成延迟。

当预填充引擎完成一个请求的处理后，会把生成的KV-Cache通过高速RDMA网络传输给解码引擎，由后者接手后续的token生成工作。

这个架构已经成为行业共识。包括SGLang、vLLM、Mooncake等主流开源推理框架，以及各大云厂商的推理服务，都在不同程度上采用了PD分离方案。

2.3 PD分离的「阿喀琉斯之踵」

PD分离架构解决了计算资源的争抢问题，但也引入了一个新的瓶颈。

在智能体多轮推理场景中，每一轮新的交互都可能只追加很少的新内容（前面提到的平均429个token），但需要加载的历史KV-Cache却非常庞大（对应数万token的缓存数据）。这些缓存数据通常存储在外部存储系统中（如DeepSeek的3FS分布式文件系统）。

在传统的PD分离架构下，KV-Cache的加载完全由预填充引擎负责。也就是说，当一个新请求到来时：

1. 预填充引擎通过自身节点上的存储网卡（SNIC）从外部存储读取命中token的KV-Cache
2. 对未命中的新增token进行计算生成新的KV对
3. 将完整的KV-Cache通过计算网络（CNIC）传输给解码引擎

问题出在第一步：所有的存储I/O压力都集中在了预填充引擎的SNIC上。

与此同时，解码引擎的SNIC却几乎完全空闲——因为在标准流程中，解码引擎不需要从外部存储读取任何数据，它只需要接收预填充引擎传过来的KV-Cache就好了。

这就好比一条四车道高速公路，左边两条车道堵得水泄不通，右边两条车道却空空如也。整体带宽的利用率远低于理论上限。

三、DualPath核心原理：把「回忆」和「思考」变成并行

莫潇羽@无忆研习社认为，DualPath的设计精髓可以用一句话概括：让闲着的人也来搬砖。

3.1 核心洞察：KV-Cache加载不必以预填充为中心

传统思维是：谁负责计算，谁就负责搬数据。预填充引擎要用KV-Cache来做计算，那自然是预填充引擎自己去存储里把数据取回来。

但DualPath打破了这个固有假设。它提出了一个看似简单却具有颠覆性的洞察：

KV-Cache的加载可以由解码引擎来完成。解码引擎先把KV-Cache从外部存储读取到自己节点的DRAM中，再通过高速RDMA计算网络传输给预填充引擎。

为什么这样做是可行的？因为在PD分离架构中：

• 解码引擎的存储网卡（SNIC）本身就处于闲置状态，拿来读数据不额外占用任何资源
• 解码引擎到预填充引擎之间的RDMA计算网络（通过CNIC）带宽通常很高，而且传输方向（DE→PE）与正常的KV-Cache传递方向（PE→DE）不冲突
• 通过DualPath的流量隔离设计，这条新的数据通路不会干扰延迟敏感的模型执行通信

3.2 双路径设计详解

DualPath在传统的单路径（Storage→Prefill）基础上，新增了第二条路径（Storage→Decode→Prefill），形成了完整的双路径KV-Cache加载机制。

路径一：Storage-to-Prefill（传统路径）

[外部存储/3FS] --SNIC--> [预填充引擎PE的DRAM] --加载到GPU--> [PE的GPU HBM]

这条路径和传统架构一样，预填充引擎直接通过自身的存储网卡从外部存储读取KV-Cache。

路径二：Storage-to-Decode-to-Prefill（新增路径）

[外部存储/3FS] --SNIC--> [解码引擎DE的DRAM] --RDMA/CNIC--> [预填充引擎PE的DRAM] --加载到GPU--> [PE的GPU HBM]

这条路径利用解码引擎闲置的存储网卡带宽，先将KV-Cache数据读入解码节点的主机内存（DRAM），然后通过GPUDirect RDMA技术经由计算网卡（CNIC）将数据传输到预填充引擎。

全局调度器会根据实时的网络负载和请求队列状态，动态地在两条路径之间分配KV-Cache加载任务，从而实现存储网络带宽的全局池化和动态负载均衡。

3.3 一个直观的比喻

想象你在网上看一部长视频。

传统方案相当于必须等整部电影全部下载完毕，你才能点击播放。如果你的网速一般，可能要等上很长时间——在这段时间里，你的屏幕（GPU）一直处于空闲的黑屏状态。

DualPath则相当于流媒体播放：视频被切成一个个小片段，只要缓冲好了前面几秒的画面，你就可以立刻开始观看。后台的下载和前台的播放同时进行，互不干扰。而且，DualPath还聪明地利用了你家所有的网络设备（包括平时没在用的那台旧路由器）来分担下载任务，让缓冲速度更快。

四、DualPath的技术实现：从分层预填充到块式流处理

DualPath不仅仅是「多了一条数据通路」这么简单。要让双路径机制真正发挥效果，还需要一系列精密的工程设计。

4.1 分层预填充（Layerwise Prefill）

传统的预填充方式是：先把某个请求所有层的KV-Cache全部加载到GPU显存中，然后一次性完成该请求在所有层上的计算。

但这种方式有两个问题：第一，大量KV-Cache同时驻留在GPU显存中，会严重挤占可用空间；第二，必须等所有数据都加载完毕才能开始计算，造成GPU长时间空等。

DualPath采用了分层预填充的策略：GPU显存只需容纳单层的KV向量即可开始处理一个请求。具体流程如下：

• 当GPU正在执行第N层的计算时，系统同时在后台从DRAM加载第N+1层的KV-Cache
• 更后面层的KV-Cache则以滑动窗口的方式从外部存储（SSD/3FS）加载到DRAM中
• 每一层的KV-Cache在计算完成后即可释放，为下一层腾出空间

这种设计极大地降低了对GPU显存容量的要求，同时实现了计算和数据加载的流水线并行。

4.2 块式流处理（Chunk-based Streaming）

DualPath将KV-Cache数据切分为两种粒度的块结构：

Full Block（完整块）：包含某个请求在所有层的KV-Cache数据。这是逻辑上的完整单位。

Layer Block（层块）：包含某个请求在单一层的KV-Cache数据。这是实际传输和处理的基本单位。

在双路径加载过程中，数据以Layer Block为最小单位进行传输。当Layer Block到达预填充引擎或解码引擎的DRAM缓冲区后，系统会按需将它们组装成完整的Full Block。

DualPath在预填充引擎和解码引擎两端各设置了DRAM缓冲区（PE Buffer和DE Buffer），用于暂存和组装从层块构建出的完整块。

下面用伪代码展示这个流水线过程：

# DualPath分层预填充伪代码示意
# (莫潇羽@无忆研习社 整理)

def layerwise_prefill(request, num_layers):
    """分层预填充：逐层加载KV-Cache并计算"""
    for layer_idx in range(num_layers):
        # 步骤1：确保当前层的KV-Cache已就绪
        kv_cache = wait_for_layer_block(request, layer_idx)

        # 步骤2：在GPU上执行当前层的注意力计算
        output = gpu_compute_attention(layer_idx, kv_cache, new_tokens)

        # 步骤3（异步）：在后台预加载下一层的KV-Cache
        if layer_idx + 1 < num_layers:
            async_prefetch_layer_block(request, layer_idx + 1)

        # 步骤4：释放当前层的GPU显存
        release_gpu_memory(layer_idx)

    return output

4.3 流量隔离与网络设计

在实际的GPU集群中，计算网卡（CNIC）同时承担着多种关键通信任务：模型并行中的集合通信（如All-Reduce、All-to-All）、PE到DE的KV-Cache正向传输、以及现在DualPath新增的DE到PE的反向传输。

如果这些不同类型的流量互相干扰，可能导致模型执行延迟不稳定，甚至引发死锁。

DualPath通过以下机制确保流量隔离：

• 利用RDMA的虚拟通道（Virtual Lane）机制：RDMA网络支持多个虚拟通道，每个通道可以配置不同的优先级和流控策略。DualPath将反向传输流量（DE→PE方向的KV-Cache搬运）分配到低优先级通道上。这样，即使反向传输占用了大量带宽，也不会影响高优先级通道上的集合通信原语（如模型并行中的All-Reduce操作）。在InfiniBand网络中，通常支持15个虚拟通道（VL0-VL14），DualPath可以灵活地选择一个低优先级VL来承载反向传输流量。
• 使用GPUDirect RDMA写操作：GPUDirect RDMA允许网卡直接读写GPU显存或主机DRAM，无需经过CPU的中间拷贝。在DualPath中，DE端通过RDMA Write操作将KV-Cache数据直接写入PE端的DRAM缓冲区。这种操作是单边的——PE端的CPU无需参与，不会产生中断或上下文切换的开销。这比传统的基于Socket或基于CPU中转的数据传输方式效率高出数个数量级。据论文描述，一次RDMA Write的延迟甚至可能低于一次cudaMemcpyAsync操作。
• 单向传输设计：DualPath的反向路径只有DE→PE方向的数据流。在正常的PD分离架构中，RDMA网络主要承载PE→DE方向的传输（预填充完成后将KV-Cache发送给解码引擎）。DualPath新增的反向传输与正常传输方向相反，因此在物理链路层面天然不会产生冲突。此外，现代RDMA网络（无论是InfiniBand还是RoCE）都支持全双工通信，两个方向的数据流可以独立并行，互不影响。

4.4 全局调度器

DualPath配备了一个全局调度器，负责在双路径之间动态分配负载。调度器的决策基于以下信息：

• 各引擎当前的待处理token数量
• 各引擎的读取队列深度
• 未完成token的阈值上限
• 当前的网络拥塞状态

调度器分为两个层级：

引擎间调度（Inter-Engine Scheduling）：在一组PE引擎中选择最优的目标引擎来处理某个请求。论文中的示例展示了8张GPU同属一个PE引擎组的情况，调度器会从中选择负载最轻的一个或一组进行分配。

引擎内调度（Intra-Engine Scheduling）：在单个引擎内部，基于计算配额（Compute Quota）来选择当前批次中应该优先处理哪些请求。计算配额机制的核心思想是：在给定的时间片内，优先处理那些KV-Cache已经加载就绪的请求，避免GPU空等数据。

# 计算配额调度示意
# 假设当前批次中有请求A、B、C

请求A：KV-Cache已100%加载到GPU显存 → 立即执行
请求B：KV-Cache已加载60%，剩余正在传输  → 等待或部分执行
请求C：KV-Cache尚未开始加载           → 排入后续批次

# 通过这种机制，GPU不会因为等待某个请求的数据而空转
# 而是先处理数据已就绪的请求，最大化利用计算资源

五、关键基础设施：DeepSeek的存储网络分析

DualPath并非脱离实际的理论设计，而是紧密结合了DeepSeek真实生产环境的基础设施条件。论文中对网络接口卡（NIC）与DRAM带宽进行了详细的分析，以确定实际可行的PE:DE配置范围。

5.1 硬件参数约束

在DeepSeek的集群中，每个节点配备了多块GPU和多块网卡。关键参数包括：

• (P)：预填充节点数
• (D)：解码节点数
• (g)：每个节点的GPU数量
• (B)：单块网卡的带宽
• (s)：每台机器的存储网卡数量
• (M)：每台机器的DRAM带宽

DualPath的可行性取决于以下条件是否满足：

• 解码端SNIC的聚合带宽足以为预填充端提供有意义的数据补充
• DE到PE的RDMA传输不会成为新的瓶颈（即CNIC带宽足够）
• DE端的DRAM带宽足以支撑同时进行的本地token生成和KV-Cache中转

5.2 最优配比

论文的分析表明，DualPath在P:D比例从1:7到7:2的范围内都能带来性能提升。这是一个非常宽泛的适用范围，说明该方案对不同的集群配置具有良好的鲁棒性。

在DeepSeek的实际部署中，他们测试了1:2、1:1、2:1三种P:D配比，发现在这三种场景下DualPath都能带来约两倍的性能提升，差异不大。这表明DualPath的收益相对稳定，不会因为配比微调而大幅波动。

5.3 与3FS分布式文件系统的协同

DualPath的外部存储后端正是DeepSeek自研的3FS分布式文件系统。3FS全称Fire-Flyer File System，于2025年初开源，专门为AI训练和推理场景设计。它的几个核心特性与DualPath形成了良好的配合：

• RDMA原生支持：3FS的所有组件（集群管理器、元数据服务、存储服务、客户端）全部通过RDMA网络互连，支持InfiniBand和RoCE两种协议。这与DualPath的RDMA传输路径天然兼容，无需额外的协议转换开销。
• 高吞吐设计：3FS采用解耦（Disaggregated）架构，聚合了数千块SSD和数百个存储节点的带宽，使得应用可以以位置无关（locality-oblivious）的方式访问存储资源。在DeepSeek的实际测试中，其KV-Cache客户端的峰值读取吞吐可达40 GiB/s。在一项大规模排序基准测试中，3FS在25个存储节点和50个计算节点的集群上，30分钟内完成了110.5 TiB数据的排序，平均吞吐达到3.66 TiB/min。
• 强一致性保证：3FS采用CRAQ（Chain Replication with Apportioned Queries）协议实现强一致性。与许多使用最终一致性的分布式存储系统不同，CRAQ确保数据在任何时刻都是一致的，这对于KV-Cache这种对数据正确性有严格要求的场景尤为重要。CRAQ的工作原理是：写操作从链头传播到链尾，每经过一个节点就标记为「dirty」状态；只有当写操作到达链尾并被确认后，才会反向传播「clean」确认。读操作只会返回「clean」状态的数据，保证了读取的一致性。
• 无状态元数据服务：3FS的元数据服务基于FoundationDB这样的事务型键值存储，本身是无状态的。这意味着元数据服务可以水平扩展，不会成为系统瓶颈。在大规模智能体推理场景中，频繁的KV-Cache创建、读取、删除操作会产生大量的元数据请求，无状态设计确保了元数据层的可扩展性。
• 灵活的数据布局：3FS支持按目录配置chunk大小和stripe大小，允许管理员根据不同的工作负载特征进行精细调优。对于KV-Cache这种读取模式相对固定的数据，可以选择较大的chunk大小来减少元数据开销，同时使用较大的stripe宽度来实现更高的并行读取吞吐。

六、实验结果深度解读

DualPath的论文提供了非常详尽的实验数据。莫潇羽@无忆研习社在这里为大家逐项解读。

6.1 实验配置

研究团队使用了三个不同规模的模型进行评估：

• DeepSeek-V3.2 660B：660B参数的大型MoE模型
• DeepSeek-V3.2 27B：27B参数的中型模型
• Qwen 2.5-32B：32B参数的对比模型

评估数据来自真实的智能体编码任务轨迹数据集。对比基准包括：

• Basic：未启用DualPath的标准PD分离架构
• SGLang + HiCache：开源推理框架SGLang配合HiCache缓存方案
• SGLang + Mooncake：SGLang配合字节跳动开源的Mooncake KV-Cache存储方案
• Oracle：理论最优值（假设KV-Cache加载没有任何开销）

6.2 离线推理性能（强化学习Rollout场景）

在离线场景中，评估指标是作业完成时间（JCT，Job Completion Time）。这个场景对应强化学习训练中的Rollout阶段——模型需要与环境进行大量交互，生成大批量的推理轨迹。

实验结果显示：

• 在DeepSeek-V3.2 660B上，DualPath相比Basic基线最高实现了1.87倍的加速，性能接近Oracle理论上限。这意味着KV-Cache的I/O开销基本被消除。
• 在DeepSeek-V3.2 27B上，DualPath相比Basic最高实现了1.78倍提升。但由于1P1D配置下存储带宽受限，性能仍比Oracle慢1.09到1.85倍。
• 在更大的批大小（Batch Size）和更长的平均追加长度（MAL）下，DualPat