KVFlow: Efficient Prefix Caching for Accelerating LLM-Based Multi-Agent Workflows

Conference: NeurIPS'25

Github: https://github.com/PanZaifeng/KVFlow/tree/main

论文主题概括： 这篇论文研究的是 LLM-based multi-agent workflows 中的系统级推理加速问题，重点不是提升模型能力，也不是改 prompt 或 agent 协作策略，而是优化底层 LLM serving system 中的 KV cache 管理机制。论文指出，现有系统通常使用 LRU 策略管理 prefix KV cache，但 LRU 只根据过去访问时间做决策，无法理解多智能体工作流中 agent 的未来执行顺序，因此容易把“马上就要再次使用”的 agent prefix cache 提前驱逐掉。KVFlow 利用 workflow 结构预测 agent 的未来调用顺序，并据此进行 cache eviction 和 prefetching，从而减少 cache miss、降低 prefill 或 CPU-GPU loading 开销，提高多智能体工作流的执行效率。

核心关键词：

LLM Serving
Agentic Workflow
Multi-Agent Workflow
Prefix Caching
KV Cache
Cache Eviction
LRU
Radix Tree Cache
Workflow-aware Cache Management
Agent Step Graph
Steps-to-execution
KV Prefetching
CPU-GPU Transfer
SGLang
HiCache

Abstract

这篇论文的出发点是：现在很多复杂任务会通过 LLM-based agentic workflows 来完成，即把一个复杂任务拆成多个 agent，每个 agent 有自己的角色、固定 prompt 和子任务。例如一个软件开发类 workflow 可能包含 Product Manager、Architect、Engineer、Reviewer 等 agent。每个 agent 在 workflow 中会被反复调用，每次调用 LLM 时都要处理自己的 prompt。

在 LLM serving 系统中，一个重要优化是 prefix caching。对于每个 agent 来说，其 prompt 通常可以分成两部分：

固定部分：agent 的角色、职责、行为规则、few-shot examples 等
动态部分：当前用户问题、当前任务上下文、前一个 agent 的输出等

固定部分在多次调用中重复出现，因此可以把它对应的 KV cache 缓存起来，避免每次都重新进行 prefill。

但是问题在于：GPU 显存有限。现有系统通常采用 LRU，即 Least Recently Used 策略来决定驱逐哪些 KV cache。LRU 的核心逻辑是：最近最少使用的 cache 最先被驱逐。然而在 multi-agent workflow 中，这种策略并不理想。因为一个 agent 虽然很久没有被访问，但它可能马上就要被执行；而另一个 agent 虽然刚刚被访问过，但短期内可能不会再次使用。

论文提出 KVFlow，一个面向 agentic workflow 的 workflow-aware KV cache management framework。它主要包含两个技术：

Workflow-aware eviction policy KVFlow 将 agent 的执行流程抽象成 Agent Step Graph，并为每个 agent 计算一个 steps-to-execution 值，用来表示该 agent 距离下一次被执行还有多少步。这个值被用于指导 KV cache eviction：距离执行越近的 agent，其 KV cache 越应该保留；距离执行越远的 agent，其 KV cache 越可以被驱逐。
Overlapped KV prefetching 当某些 agent 的 KV cache 已经被 offload 到 CPU 后，KVFlow 不等到 agent 真正执行时才加载，而是根据 Agent Step Graph 提前预测下一步可能调用的 agent，并在后台线程中提前从 CPU 将 KV cache 预取回 GPU。这样 CPU-GPU 传输可以和当前 agent 的 GPU 推理计算重叠，从而减少等待时间。

论文实验基于 SGLang v0.4.4 实现 KVFlow。结果显示，在大 prompt 的单 workflow 场景下，KVFlow 相比带 hierarchical radix cache 的 SGLang 最高取得 1.83× 加速；在大量并发 workflows 场景下，最高取得 2.19× 加速。

一句话总结 Abstract： KVFlow 的核心思想是：LLM serving 系统不应该把 multi-agent workflow 中的请求看成互相独立的请求，而应该利用 workflow 中 agent 的未来执行顺序来管理 KV cache。

1. Introduction

1.1 研究背景：LLM-based agentic workflows

近年来，基于 LLM 的 agentic workflow 成为一种常见范式。它不是让一个单独的 LLM 一次性完成所有工作，而是将任务拆成多个角色明确的 agent，由这些 agent 协同完成复杂任务。

例如：

Planner：负责拆解任务
Executor：负责执行子任务
Reviewer：负责检查结果
Expresser：负责组织最终回答

这种 workflow 的优点是：

模块化：每个 agent 负责不同子任务；
可解释：每个阶段的职责清楚；
可复用：相同 agent 可以在不同任务中重复使用；
更适合复杂任务：复杂问题可以分阶段解决。

但是它也带来了明显的系统性能问题：

一个 workflow 中可能需要多次调用 LLM，每个 agent 调用都需要处理自己的 prompt，因此整体推理延迟显著增加。

1.2 Prefix caching 为什么重要？

在 agentic workflow 中，每个 agent 通常都有一段固定 prompt。例如：

You are a Planner agent. Your responsibility is to decompose the user's request into executable subtasks...

这部分 prompt 在不同任务、不同轮次中经常保持不变。对于 Transformer LLM 来说，这些 token 在 prefill 阶段会产生对应的 KV cache。如果每次都重新计算，会造成大量重复计算。

因此现代 LLM serving 系统通常会使用 prefix caching：

如果一个 request 的 prompt 前缀和之前某个 request 的前缀相同，
则直接复用之前计算好的 KV cache，
避免重新计算这部分 prefix。

对于 multi-agent workflow 来说，这一点特别重要，因为每个 agent 的固定 prompt 都可以被缓存。

1.3 现有系统的问题：LRU 不适合 agentic workflow

现有系统在 GPU 显存不足时，一般采用 LRU 策略驱逐 KV cache。LRU 的假设是：

最近没有被访问的 cache，将来也不太可能马上被访问。

这个假设在普通 workload 中经常有效，但在 agentic workflow 中并不成立。

原因是 agent 的执行通常遵循 workflow 结构。例如：

Planner -> Executor -> Expresser -> Reviewer -> Planner -> ...

某个 agent 可能已经很久没有被访问，但根据 workflow，它马上就要执行。LRU 看不到这一点，只会机械地认为它“最近没用过”，于是可能把它驱逐掉。

1.4 Figure 1 详细解释

Figure 1 展示了一个循环式 agentic workflow，包含四个 agent：

Planner
Executor
Expresser
Reviewer

图中当前时间戳为 13，Executor 是当前 active agent。此时不同 agent 的 KV cache 有不同的 last access time。

LRU 策略根据最近访问时间判断，认为 Expresser 的 cache 比较久没有被访问，于是将其驱逐。然而从 workflow 顺序来看，Executor 执行之后马上就会轮到 Expresser。也就是说，LRU 刚刚驱逐了一个即将被复用的 KV cache。

结果是在时间戳 14：

Expresser 被调用
但是 Expresser 的 KV cache 已经被驱逐
发生 cache miss
系统需要重新计算 prefix KV，或者从 CPU 加载回来
导致 prefill latency 增加

这个例子很好地说明了论文的核心动机：

LRU 只根据历史访问时间做 cache eviction，而 agentic workflow 中真正重要的是未来执行顺序。

1.5 KVFlow 的核心想法

KVFlow 的基本思路是：

不要只看一个 KV cache 最近有没有被访问，
而是判断它对应的 agent 距离下一次执行还有多远。

如果一个 agent 马上要执行，即使它已经很久没被访问，也应该保留它的 KV cache。如果一个 agent 刚刚执行完，但很久之后才会再次执行，那么它的 KV cache 反而可以被优先驱逐。

1.6 本文主要贡献

论文的贡献可以总结为三点：

指出 LRU 在 agentic workflow 中存在根本低效性 LRU 缺少 workflow awareness，无法预测 agent 的未来调用顺序，导致可能错误驱逐即将复用的 KV cache。
提出 KVFlow 的 workflow-aware KV cache management 方法 通过 Agent Step Graph 计算每个 agent 的 steps-to-execution，并据此进行细粒度 KV node-level eviction。
提出 fully overlapped KV prefetching 利用 workflow 信息提前预取即将执行 agent 的 KV cache，将 CPU-GPU 数据传输与 GPU 推理计算重叠，从而减少 cache miss stall。

2. Background

这一节主要补充两个背景：

LLM serving system 中的 prefix caching 和 KV cache；
agentic workflow 中固定 prompt 的缓存价值。

2.1 LLM 推理中的 KV cache

Transformer LLM 在生成文本时，每一层 self-attention 都会为输入 token 计算 Key 和 Value。对于已经处理过的 token，这些 Key/Value 可以缓存起来，后续生成新 token 时直接复用。

对于一个 batch size 为 $B$、序列长度为 $T$、层数为 $L$ 的模型，KV cache 的大小大致可以表示为：

$$ \text{KV Cache Size} \propto B \times T \times L \times 2 \times H_{kv} \times D_{head} \times \text{bytes} $$

其中：

$B$：batch size；
$T$：token 数；
$L$：Transformer 层数；
$2$：对应 Key 和 Value；
$H_{kv}$：KV heads 数量；
$D_{head}$：每个 head 的维度；
$\text{bytes}$：每个数值占用的字节数，例如 FP16 通常为 2 bytes。

因此，KV cache 的大小与 prompt 长度近似线性增长：

$$ \text{KV Cache Size} = O(T) $$

这也是 Figure 2(a) 展示的结论：随着 prefix length 增加，KV cache size 也线性增加。

2.2 Prefill latency 与 KV cache transmission

LLM 推理分为两个阶段：

2.2.1 Prefill 阶段

Prefill 阶段处理完整 prompt，并为 prompt 中所有 token 构建 KV cache。

特点：

输入 token 多；
计算量大；
长 prompt 下 latency 明显；
固定 prompt 重复出现时，适合缓存。

2.2.2 Decode 阶段

Decode 阶段每次生成一个 token，并复用已有 KV cache。

特点：

每步只生成一个 token；
输出越长，decode 时间越长；
KV cache 对 decode 性能很关键。

2.3 Prefix caching 的基本机制

现代 LLM serving systems 通常使用树结构组织 prefix cache，例如 radix tree。每个节点保存一段 token 以及对应的 KV tensor。

当一个新 request 到来时，系统会从 tree root 开始匹配 request 的 prefix。如果发现某些 prefix 已经存在，就直接复用对应的 KV cache；未命中的部分才需要重新 prefill。

例如两个 prompt：

Prompt A: You are an expert agent. Your task is planning...
Prompt B: You are an expert agent. Your task is reviewing...

它们共享前缀：

You are an expert agent. Your task is

radix tree 可以只存一份共享 prefix 的 KV cache，从而减少冗余。

2.4 GPU memory pressure

虽然 prefix caching 能减少重复计算，但 KV cache 本身会占用大量 GPU 显存。

GPU 显存不足通常来自两个场景：

高并发请求 多个用户、多个 workflow 同时运行，每个 workflow 又包含多个 agent，导致 GPU 上 active KV cache 数量迅速增加。
agent prompt 很长 某些 agent 的 fixed prompt 包含大量 instruction、role description、few-shot examples，可能达到几千 tokens。长 prompt 的 KV cache 体积很大。

2.5 CPU memory 作为 secondary cache

当 GPU 显存不足时，一种常见策略是把部分 KV cache offload 到 CPU memory。这样下次需要时，可以从 CPU 加载回来，而不是重新 prefill。

这形成了两级缓存：

GPU memory：一级 cache，访问最快，但容量有限
CPU memory：二级 cache，容量大，但需要 PCIe 传输

Figure 2(b) 比较了：

重新 prefill 的时间；
通过 PCIe 从 CPU 传输 KV cache 的时间。

论文观察到：

CPU-GPU KV cache transmission 通常比重新 prefill 更快。

因此，将 evicted KV cache 备份到 CPU 是有价值的。

但是，CPU-GPU 传输虽然比 recomputation 快，仍然会带来 latency。如果系统等到真正需要某个 agent 时才开始加载 KV cache，就会造成 GPU 等待。这正是 KVFlow 后面提出 proactive prefetching 的原因。

2.6 Agentic workflow 的 prompt 结构

在 agentic workflow 中，每个 agent 的 prompt 通常由两部分组成：

fixed part + dynamic part

fixed part

固定部分通常包括：

agent 名称；
agent 角色；
agent 职责；
行为规范；
task description；
few-shot examples；
输出格式要求。

这部分在多轮执行中高度稳定，因此非常值得缓存。

dynamic part

动态部分通常包括：

用户当前问题；
上游 agent 的输出；
当前任务上下文；
临时 instruction；
当前轮次的中间结果。

这部分经常变化，因此缓存价值较低。

2.7 背景部分的核心结论

这一节为 KVFlow 的设计提供了基础：

KV cache 对 LLM 推理性能非常重要；
prefix caching 能避免重复 prefill；
agent fixed prompt 具有高度复用性；
GPU 显存有限，需要 eviction；
CPU memory 可以作为 secondary cache；
但传统 LRU eviction 和 reactive loading 不能充分利用 agent workflow 的未来执行信息。

3. Design of KVFlow

KVFlow 的设计目标是：

利用 agentic workflow 的结构信息，优化 LLM serving backend 中的 KV cache eviction 和 loading。

它不是改模型，也不是改 agent 的 prompt，而是改系统层的 cache 管理方式。

整体设计包括两个主要部分：

KVFlow
├── Workflow-aware Eviction Policy
│   └── 根据 agent 未来执行距离决定驱逐优先级
│
└── Overlapped KV Prefetching
    └── 根据 workflow 提前加载即将执行 agent 的 KV cache

3.1 Workflow-Aware Eviction Policy

3.1.1 为什么 LRU 不够？

LRU 策略只考虑：

这个 cache 上一次什么时候被访问？

但是在 agentic workflow 中，更重要的问题是：

这个 cache 对应的 agent 下一次什么时候会被执行？

两者并不等价。

例如：

Agent A 刚刚执行完，但下一次要很久以后才执行；
Agent B 很久没执行，但根据 workflow 下一步马上就要执行。

LRU 会倾向于保留 Agent A，驱逐 Agent B。 KVFlow 则认为应该保留 Agent B，驱逐 Agent A。

因此，KVFlow 需要一种方式来描述 agent 的未来执行顺序。

3.1.2 Agent Step Graph

KVFlow 引入 Agent Step Graph 来抽象 agentic workflow。

Agent Step Graph 中：

每个节点表示一个 agent invocation；
边表示 agent 之间的依赖关系；
每个节点有一个 steps-to-execution 值；
每个节点还可以有 step aggregation function，用于计算该 agent 距离执行还有多少步。

这里的 steps-to-execution 是一个非常关键的概念。

它表示：

从当前执行状态开始，某个 agent 距离下一次被执行还需要经过多少步。

例如当前 agent 是 Planner，workflow 是：

Planner -> Searcher -> Executor -> Expresser

那么：

Planner: 0
Searcher: 1
Executor: 2
Expresser: 3

这个值越小，说明 agent 越快会被执行，因此其 KV cache 越应该保留。

3.1.3 为什么不能只用普通 DAG 或 CFG？

论文指出，真实 agent workflow 的结构很复杂，并不只是简单的线性顺序。

可能出现：

顺序执行：
A -> B -> C

并行执行：
A -> B
A -> C

同步 barrier：
B 和 C 都完成后，D 才执行

条件分支：
B 或 C 完成后，D 就可以执行

循环 workflow：
A -> B -> C -> A

普通 DAG 或 CFG 很难统一表达所有这些执行语义，尤其是不同依赖关系对“下一次执行距离”的计算方式不同。

因此 KVFlow 不是简单地用边数表示距离，而是给每个节点配一个 step aggregation function。

3.1.4 Step Aggregation Function

Step aggregation function 用来根据前驱 agent 的 steps-to-execution 计算当前 agent 的 steps-to-execution。

情况一：普通顺序依赖

如果：

A -> B

并且 $A$ 的 steps-to-execution 为 $E_A$，那么：

$$ E_B = E_A + 1 $$

情况二：同步 barrier，AND 依赖

如果某个 agent 需要等待多个前驱都完成才能执行，例如：

Executor 1 ----\
                -> Expresser
Executor 2 ----/

也就是：

Expresser depends on Executor 1 AND Executor 2

那么 Expresser 的 steps-to-execution 是：

$$ E_{\text{Expresser}} = \max(E_1, E_2) + 1 $$

原因是 Expresser 必须等两个 Executor 都完成。谁更晚完成，Expresser 就要等谁。

例如：

Executor 1: 1 step 后执行
Executor 2: 2 steps 后执行

则：

$$ E_{\text{Expresser}} = \max(1, 2) + 1 = 3 $$

情况三：条件分支，OR 依赖

如果某个 agent 只需要任意一个前驱完成即可执行，例如：

Executor 1 ----\
                -> Expresser
Executor 2 ----/

但是依赖语义是：

Expresser depends on Executor 1 OR Executor 2

那么：

$$ E_{\text{Expresser}} = \min(E_1, E_2) + 1 $$

原因是只要其中一个分支完成，Expresser 就可能被触发。谁更早完成，就以谁为准。

例如：

Executor 1: 1 step 后执行
Executor 2: 2 steps 后执行

则：

$$ E_{\text{Expresser}} = \min(1, 2) + 1 = 2 $$

3.1.5 Figure 3(a) 详细解释

Figure 3(a) 展示了两个 Agent Step Graph。

上半部分对应同步 barrier：

Expresser 需要 Executor 1 和 Executor 2 都完成后才能执行。

因此 Expresser 的 step aggregation function 是：

$$ \max(E_1, E_2) + 1 $$

下半部分对应条件分支：

Expresser 可以在 Executor 1 或 Executor 2 任意一个完成后执行。

因此 Expresser 的 step aggregation function 是：

$$ \min(E_1, E_2) + 1 $$

这说明 Agent Step Graph 可以统一描述不同 workflow 结构，并为 cache eviction 提供未来执行距离信息。

3.1.6 从 agent-level priority 到 KV node-level priority

如果每个 agent 的 prompt 完全独立，那么直接给每个 agent 一个 eviction priority 就可以。

但现实中 prefix cache 通常是树结构，多个 agent 可能共享部分 prefix。

例如：

Agent A:
You are an AI assistant in a software team. You are the Planner...

Agent B:
You are an AI assistant in a software team. You are the Executor...

Agent C:
You are an AI assistant in a software team. You are the Reviewer...

它们共享：

You are an AI assistant in a software team. You are the

在 radix tree 中，这部分 prefix 只会存一份。如果只按 agent 级别管理，就无法正确处理共享 prefix。

因此 KVFlow 将 eviction priority 分配到 KV cache tree node 级别，而不是 agent 级别。

3.1.7 Eviction priority 的含义

KVFlow 中，一个 KV node 的 eviction priority 越大，越容易被驱逐。

对于某个 agent：

steps-to-execution 越大
说明距离下一次执行越远
因此 eviction priority 越高
越容易被驱逐

对于马上要执行的 agent：

steps-to-execution 越小
说明很快会复用
因此 eviction priority 越低
越应该保留

可以理解为：

priority 小：重要，保留
priority 大：不重要，可以驱逐

3.1.8 Figure 3(b) 详细解释

Figure 3(b) 展示了如何在 cache tree 中传播 eviction priority。

具体过程如下：

第一步：只对 fixed prompt 部分赋予 workflow-aware priority

KVFlow 只关心 agent 的固定 prompt，因为固定 prompt 才有高复用价值。

动态 suffix 由于通常随任务变化，缓存价值低，因此直接赋予最高驱逐优先级。

论文中用 $+\infty$ 表示动态 suffix 的最高 eviction priority：

$$ P_{\text{dynamic suffix}} = +\infty $$

这意味着动态 suffix 最容易被驱逐。

第二步：将 agent 的 steps-to-execution 赋给固定 prompt 的最后一个 KV node

对于某个 agent $a$，假设它的 steps-to-execution 是 $E_a$，那么 KVFlow 将这个值赋给该 agent fixed prompt 的最后一个 cache node：

$$ P(v_a) = E_a $$

其中 $v_a$ 是 agent $a$ 的 fixed prompt 最后一个 KV node。

第三步：沿 cache tree 向上传播 priority

如果一个 cache node 被多个 agent 共享，那么它对多个 agent 都有用。因此它的 priority 应该取所有子节点中最小的值：

$$ P(v) = \min_{u \in \text{children}(v)} P(u) $$

这样做的含义是：

只要这个共享 prefix 对任何一个即将执行的 agent 有用，
它就应该被保留。

例如：

Agent A 的 step = 1
Agent B 的 step = 5
二者共享某个 prefix node

那么共享 node 的 priority 应该是：

$$ \min(1, 5) = 1 $$

因为它马上会被 Agent A 用到，所以不能轻易驱逐。

3.1.9 KVFlow 的 eviction 顺序

当 GPU memory 不足时，KVFlow 按以下顺序驱逐：

1. 优先驱逐动态 suffix
2. 再驱逐 fixed prompt 中 priority 最大的 KV nodes
3. 保留 priority 小的 KV nodes

也就是说：

先驱逐最不可能复用的内容；
再驱逐未来较晚才会复用的内容；
尽量保留马上要复用的内容。

可以用伪代码表示：

def evict_until_enough_memory():
    # Step 1: evict dynamic suffix first
    evict_nodes_with_priority(float("inf"))

    # Step 2: evict fixed-prefix KV nodes with large priority
    candidates = get_evictable_prefix_nodes()
    candidates.sort(key=lambda node: node.priority, reverse=True)

    for node in candidates:
        evict(node)
        if gpu_memory_is_enough():
            break

3.1.10 多 workflow 并发时的 priority 冲突

在高并发场景中，多个 workflow 可能同时运行，而且它们可能共享部分 prefix cache node。

如果某个 node 被多个 workflow 使用，那么 KVFlow 采用保守策略：

取最低 priority，即最不容易被驱逐的 priority。

公式仍然是：

$$ P(v) = \min(P_1(v), P_2(v), \ldots, P_n(v)) $$

这样可以避免某个 workflow 中即将使用的 shared prefix 被另一个 workflow 的 eviction 决策错误驱逐。

3.2 Overlapped KV Prefetching

Workflow-aware eviction 可以减少错误驱逐，但不能完全避免 cache miss。

例如：

GPU 显存太小；
workflow 并发太高；
某个 agent 很久之后才复用；
fixed prompt 很长。

这些情况下，某些 agent 的 fixed prompt KV cache 仍然可能被驱逐出 GPU。

如果该 KV cache 在 CPU 中有备份，那么系统有两种选择：

1. 等 agent 执行时，从 CPU 加载 KV cache 到 GPU；
2. 在 agent 执行前，根据 workflow 提前加载。

传统 HiCache 更接近第一种 reactive loading，而 KVFlow 采用第二种 proactive prefetching。

3.2.1 Reactive Loading 的问题

Reactive loading 的流程是：

Executor 1 被调度执行
系统发现 Executor 1 的 KV cache 不在 GPU
于是从 CPU 加载 Executor 1 的 KV cache
加载完成后 Executor 1 才能执行

问题是：

CPU-GPU 加载发生在关键路径上，
GPU 可能需要等待 KV cache 加载完成。

虽然 CPU-GPU loading 比重新 prefill 快，但它仍然会增加 latency。

3.2.2 Proactive Prefetching 的思路

KVFlow 利用 Agent Step Graph 预测下一步可能执行的 agent。

例如当前正在执行 Planner，并且 workflow 显示下一步会执行 Executor 1。那么 KVFlow 可以在 Planner 执行期间，后台预取 Executor 1 的 KV cache：

GPU: Planner 正在进行 model forward / decoding
CPU: 同时将 Executor 1 的 KV cache 传输到 GPU

这样等 Planner 执行结束后，Executor 1 的 KV cache 可能已经在 GPU 上了。

这就把原本位于关键路径上的 CPU-GPU loading 隐藏到了当前 agent 的执行时间中。

3.2.3 为什么 prefetch 可以和推理计算重叠？

论文认为 agent execution 和 KV loading 使用的硬件资源有所不同：

agent execution:
主要使用 GPU 进行 model forward，
并伴随少量 GPU -> CPU 输出传输和 CPU sampling。

KV loading:
主要是 CPU -> GPU 的 KV tensor 传输。

由于二者资源不同，可以并行执行。论文还提到 PCIe 支持 full-duplex transfer，即 CPU 到 GPU 和 GPU 到 CPU 的传输可以同时进行，因此预取有机会与推理过程重叠。

KVFlow 追求的效果是：

用当前 agent 的计算时间隐藏下一个 agent 的 KV cache 传输时间。

3.2.4 分支 workflow 下的 prefetch

如果 workflow 存在条件分支，例如 Planner 后面可能执行 Executor 1，也可能执行 Executor 2，那么 KVFlow 会保守地预取所有可能下一步执行的 agent：

Planner -> Executor 1
Planner -> Executor 2

KVFlow 会根据 Step Graph 判断：

Executor 1 和 Executor 2 都可能是 next-step agents

因此可以尝试同时 prefetch 它们的 KV cache。

但是为了避免预取过多造成 GPU memory pressure 或 PCIe bandwidth contention，论文中提到会有一个 predefined limit 限制并发 prefetch 数量。

3.2.5 仅有 prefetch 还不够

如果当前 agent 的执行时间足够长，prefetch 可以完全被隐藏。

但是如果当前 agent 很快执行完，而下一个 agent 的 KV cache 还没加载完，那么 GPU 仍然会等待。

例如：

Planner 很快执行完；
Executor 1 的 KV cache 还在 loading；
Executor 1 被调度后仍然需要等待 loading 完成。

这种情况在高并发场景尤其常见，因为多个 workflow 可能同时竞争 CPU-GPU bandwidth，导致 loading 排队。

因此 KVFlow 进一步引入 Status-Aware Scheduling。

3.2.6 Status-Aware Scheduling

Status-aware scheduling 的核心思想是：

如果某个 request 需要的 KV cache 还在 loading，
调度器先跳过它，
优先调度其他已经 ready 的 request。

例如：

Executor 1 的 KV cache 正在 loading；
Executor 2 的 KV cache 已经在 GPU；
那么调度器先执行 Executor 2。

这里的 Executor 2 可以来自同一个 workflow，也可以来自另一个并发 workflow。

这样 GPU 就不必空等 Executor 1 的 KV cache 加载完成，从而提升整体利用率。

3.2.7 KV node 的四种状态

为了实现 status-aware scheduling，KVFlow 给每个 KV cache node 增加一个状态变量。状态包括四种：

1. In GPU memory
2. Backup in CPU
3. Loading
4. Offloading

含义如下：

状态	含义
In GPU memory	KV node 当前在 GPU 上，可以直接使用
Backup in CPU	KV node 不在 GPU，但 CPU 中有备份
Loading	KV node 正在从 CPU 加载到 GPU
Offloading	KV node 正在从 GPU offload 到 CPU

调度器在调度某个 request 前，会检查它需要的所有 KV nodes：

如果所有需要的 nodes 都在 GPU，则可以调度；
如果有 node 正在 loading，则暂时跳过；
如果有 node 只有 CPU backup，则可以触发 prefetch；
如果 node 正在 offloading，则不能再次驱逐，避免 race condition。

3.2.8 Figure 4 详细解释

Figure 4 对比了三种执行方式。

第一种：Reactive Loading

GPU: Planner -> cache miss -> 等待 Load Executor 1 -> Executor 1 -> Executor 2
CPU:           Load Executor 1

问题是 GPU 在 cache miss 后必须等待 CPU-GPU loading。

第二种：Proactive Prefetching

GPU: Planner -> Executor 1 -> Executor 2
CPU: Load Executor 1 与 Planner 执行重叠

相比 reactive loading，prefetch 提前发生，可以减少等待。

但是如果 Planner 执行时间短于 loading 时间，Executor 1 仍然可能被阻塞。

第三种：Proactive Prefetching + Status-Aware Scheduling

GPU: Planner -> Executor 2 -> Executor 1
CPU: Load Executor 1

当 Executor 1 还在 loading 时，调度器先执行已经 ready 的 Executor 2。等 Executor 1 loading 完成后，再执行 Executor 1。

这样可以最大限度减少 GPU idle time。

3.2.9 KVFlow prefetch 和 scheduling 的伪代码理解

可以用如下伪代码理解 KVFlow 的预取过程：

def on_agent_execution(current_agent):
    next_agents = predict_next_agents_from_agent_step_graph(current_agent)

    for agent in next_agents:
        required_nodes = get_fixed_prompt_kv_nodes(agent)

        if nodes_are_in_cpu(required_nodes):
            launch_background_prefetch(required_nodes)

status-aware scheduling 可以理解为：

def schedule_ready_request(request_queue):
    for request in request_queue:
        required_nodes = request.required_kv_nodes

        if any(node.status == "loading" for node in required_nodes):
            continue

        if all(node.status == "in_gpu" for node in required_nodes):
            dispatch(request)
            return

这个策略的关键是：

不要让 GPU 等一个正在 loading 的 request；
只要还有其他 ready request，就优先执行 ready request。

3.3 Implementation

论文将 KVFlow 原型实现到 SGLang v0.4.4 上。

SGLang 是一个 LLM serving system，包含：

frontend API：用于构建 structured language model programs
backend：用于执行 LLM 推理和管理 KV cache

SGLang 后端本身使用 radix tree 管理 prefix KV cache。KVFlow 在这个基础上扩展：

1. workflow-aware eviction policy
2. fully overlapped KV prefetching
3. workflow metadata transmission
4. status-aware scheduling

3.3.1 前端和后端都需要修改

KVFlow 不是只改后端 cache policy 就够了，因为后端默认不知道 workflow 结构。

因此论文修改了：

frontend：
负责收集 agent workflow 信息，并通过 HTTP request 发送给 backend。

backend：
根据 workflow metadata 更新 cache tree 的 eviction priority，
并触发 prefetching。

3.3.2 Step Information Capture

KVFlow 需要在 runtime 获取 Agent Step Graph 中的 steps-to-execution 信息。

论文实现中假设：

每个 sgl.function 对应一个独立 agent。

在 agent 执行时，KVFlow 会通过 just-in-time substitution 修改 LLM call，将 workflow metadata 嵌入 HTTP request。

metadata 包括：

1. 当前 agent 的 identity
2. Agent Step Graph 中所有 agent 的 steps-to-execution
3. 后续可能被调用的 agents

backend 收到这些信息后，可以：

1. 更新 KV cache tree 中每个 node 的 eviction priority；
2. 判断下一步可能执行哪些 agent；
3. 如果 GPU memory 允许，则提前 prefetch 对应 KV cache。

3.3.3 固定 prompt 和动态 prompt 的边界识别

KVFlow 的 eviction policy 需要区分：

fixed prompt：值得缓存
dynamic suffix：优先驱逐

但是在一个普通 request 中，后端并不天然知道哪部分是 fixed prompt，哪部分是 dynamic suffix。

论文提出两种方案。

方案一：显式标记

KVFlow 提供 primitive interface，让用户或上层框架显式标记 fixed part 的结束位置。

例如：

[fixed prompt ends here]

优点：

准确，后端可以明确知道 fixed prefix 范围。

缺点：

需要应用开发者或 agent framework 配合。

方案二：启发式识别

KVFlow 追踪 agent 的 cache hit history，将持续命中的 prefix 视为 fixed part。

优点：

对用户更透明，不需要显式标记。

缺点：

如果 prompt 格式变化较多，可能不如显式标记准确。

3.3.4 Client Tracking

多个 agentic workflows 可能同时运行在同一个 backend 上。不同 workflow 可能有同名 agent，例如都叫 Planner。

如果只用 agent name 作为标识，就会出现冲突。

因此 KVFlow 为每个 application 分配唯一的 client ID，并将 client ID 附加到每个 request 中。

这样 agent identity 实际上变成：

client_id + agent_name

例如：

client_1 / Planner
client_2 / Planner

这样可以避免不同 workflow 的同名 agent 相互干扰。

3.4 Design 部分总结

KVFlow 的方法可以总结为一条完整链路：

应用层提供 agent workflow 结构
        ↓
KVFlow 构建 Agent Step Graph
        ↓
计算每个 agent 的 steps-to-execution
        ↓
将 steps-to-execution 映射到 KV cache tree node priority
        ↓
GPU memory 不足时，优先驱逐动态 suffix 和未来较晚使用的 prefix
        ↓
根据 workflow 预测 next-step agents
        ↓
后台从 CPU prefetch 对应 KV cache 到 GPU
        ↓
scheduler 跳过正在 loading 的 request，优先执行 ready request
        ↓
减少 cache miss stall，提高 workflow 执行效率

KVFlow 的核心不是单独某个技巧，而是将 workflow-level semantic information 引入到了 system-level cache management 中。

4. Evaluation

Evaluation 部分主要验证 KVFlow 在不同条件下是否能够降低 multi-agent workflow 的执行延迟。

论文关注两个核心问题：

1. 对单个 workflow，如果 agent fixed prompt 很长且 GPU memory 紧张，KVFlow 能否降低 end-to-end latency？

2. 对多个 workflow 高并发执行的场景，KVFlow 是否仍然有效？

论文强调：KVFlow 只改变系统级 cache management，不改变模型权重、prompt 内容或 decoding 逻辑，因此输出语义保持不变。实验只关注系统性能指标，主要是 latency 和 speedup。

4.1 Baselines

论文比较了三个系统配置。

4.1.1 SGLang

这是 GPU-only cache baseline。

特点：

1. 使用 radix-structured KV cache；
2. KV cache 只保存在 GPU memory；
3. GPU memory 不足时，prefix nodes 被驱逐；
4. 被驱逐后再次访问，需要重新 prefill。

因此，如果发生 cache miss，代价是重新计算 fixed prompt 的 KV cache。

4.1.2 SGLang w/ HiCache

这是 SGLang 的 hierarchical radix cache 配置。

特点：

1. GPU 上仍然使用 radix tree 管理 prefix cache；
2. 被驱逐的 KV cache 可以异步备份到 CPU memory；
3. 再次需要时，从 CPU 加载回来，而不是重新计算；
4. 通过简单 pipeline 让 GPU 计算 layer l 时加载 layer l+1。

HiCache 相比 GPU-only SGLang 的优势是：

CPU loading 通常比重新 prefill 快。

但问题是：

它仍然主要是 reactive loading；
只有当 cache miss 发生或 request 被调度时，才开始加载；
不能充分利用 workflow 信息提前预取。

4.1.3 KVFlow

KVFlow 在 SGLang 上增加：

1. workflow-aware eviction；
2. KV node-level priority；
3. CPU secondary cache；
4. proactive prefetching；
5. status-aware scheduling。

它的优势在于：

不仅减少错误驱逐，还尽量把必要的 CPU-GPU transfer 提前隐藏起来。

4.2 Single-Workflow Latency

Figure 5 对应单 workflow latency 实验。

4.2.1 实验目的

这一实验模拟交互式使用场景：

用户单独触发一个 agentic workflow，
系统需要尽快返回最终结果。

这种场景下 batch size 为 1，不依赖大规模 batching 提升吞吐，而是关注单个 workflow 的响应延迟。

4.2.2 Workflow 设置

论文构造了一个顺序执行的 10-agent workflow。

每个 agent 的输入 prompt 都由两部分组成：

fixed prefix + dynamic suffix

实验使用合成 prompt，并控制：

fixed part token 数量
dynamic part token 数量
output token 数量

Figure 5 横坐标格式为：

Fixed / Dynamic / Output

例如：

8192 / 32 / 32

表示：

每个 agent 的 fixed prompt 长度为 8192 tokens；
dynamic prompt 长度为 32 tokens；
output 长度为 32 tokens。

论文故意测试很长的 fixed prefix，例如 4096 或 8192 tokens，用来制造 GPU memory pressure，迫使系统发生 cache eviction。

4.2.3 Models and Testbeds

论文使用两组模型与硬件。

设置一：Llama-3.1-8B on A10G

Model: Llama-3.1-8B
GPU: NVIDIA A10G
GPU memory: 24GB
PCIe bandwidth: 2GB/s PCIe Gen1
Attention heads: 32
KV heads: 8

这个设置的特点是：

GPU memory 较小；
PCIe bandwidth 较低；
更容易出现 cache eviction 和 CPU-GPU transfer bottleneck。

因此它代表资源相对紧张的部署环境。

设置二：Qwen2.5-32B on H100

Model: Qwen2.5-32B
GPU: NVIDIA H100
GPU memory: 80GB
PCIe bandwidth: 64GB/s PCIe Gen5
Attention heads: 40
KV heads: 8

这个设置的特点是：

GPU 更强；
显存更大；
PCIe bandwidth 更高；
但模型也更大。

因此它代表大模型部署环境下的显存压力场景。

解码设置

论文采用 deterministic decoding：

temperature = 0
greedy sampling

这样可以减少生成随机性对 latency 测量的影响，保证不同系统之间的比较更稳定。

4.2.4 Evaluation Method

实验流程如下：

Cache warmup 先多次执行每个 agent 的 fixed prompt，确保对应 prefix cache 已经构建。对于 HiCache，还确保 fixed prompt KV cache 已经备份到 CPU memory。
执行 10-agent workflow 之后执行完整的 10-agent workflow。
动态 suffix 变化 每次 workflow 执行时，dynamic suffix 会变化，用来模拟真实场景中用户输入或中间上下文变化。
重复执行并取平均 workflow 执行 10 次，最终 latency 取平均。

这模拟了现实中常见的重复 workflow 调用或 loop-like behavior。

4.2.5 Figure 5 结果分析

Figure 5 展示的是相对于 SGLang GPU-only baseline 的 speedup。

总体结论：

KVFlow 在几乎所有设置下都取得最高 speedup。

特别是在 A10G 上，fixed prefix 很长、dynamic 和 output 很短的场景，KVFlow 优势非常明显。

例如：

8192 / 32 / 32 on A10G

KVFlow 的结果为：

相比 SGLang w/ HiCache 快 1.83×；
相比 GPU-only SGLang 快 2.91×。

这说明：

当 fixed prompt 很长，并且 cache miss 代价很高时，
KVFlow 的 workflow-aware eviction 和 proactive prefetching 能显著降低延迟。

4.2.6 为什么 KVFlow 比 HiCache 快？

HiCache 的优势是：

cache miss 后从 CPU 加载，而不是重新 prefill。

但是它的问题是：

loading 往往仍然发生在 request 被调度之后；
CPU-GPU transfer 没有充分提前；
容易出现在关键路径上等待加载的情况。

KVFlow 则利用 Agent Step Graph 提前知道下一步可能执行哪些 agent，因此可以在当前 agent 执行时提前 prefetch 下一个 agent 的 KV cache。

因此 KVFlow 可以把：

CPU-GPU transfer latency

隐藏到：

当前 agent 的 GPU computation latency

之中。

4.2.7 为什么 fixed prompt 越长，KVFlow 收益越大？

fixed prompt 越长，cache miss 成本越高。

原因包括：

1. 重新 prefill 更慢；
2. KV cache 更大；
3. CPU-GPU loading 更耗时；
4. GPU memory pressure 更大，更容易 eviction。

论文报告：

fixed tokens = 8192 时，KVFlow 平均 speedup 约为 1.48×；
fixed tokens = 4096 时，KVFlow 平均 speedup 约为 1.28×。

这说明：

KVFlow 特别适合长 fixed prompt 的 agent workflow。

4.2.8 为什么 output token 越多，KVFlow 相对收益越小？

当 output token 很多时，总 latency 中 decode 阶段占比变大。

KVFlow 主要优化的是：

fixed prefix 的 prefill / cache loading / cache eviction

而不是每一步 auto-regressive decoding。

如果 output 很长，例如：

8192 / 1024 / 1024

那么生成 1024 个 token 的 decode 时间会成为主导，prefix cache 优化在总时间中的占比下降，因此 speedup 变小。

这说明 KVFlow 与 speculative decoding、KV sparsity、early exit 等 decode 优化方法是互补的。

4.2.9 H100 上 HiCache 有时表现下降的原因

论文观察到，在 H100 的一些大上下文设置中，例如：

8192 / 32 / 32

HiCache 的表现可能只是略好，甚至比 GPU-only SGLang 更差。

论文推测原因包括：

1. SGLang 的 pipelining logic 在 memory contention 或大量 transfer 下没有充分 overlap；
2. CPU-GPU transfer 没有有效隐藏；
3. cache loading 干扰了 schedule-compute pipeline。

这进一步说明，仅仅有 CPU backup 不够，还需要更合理的 workflow-aware prefetching 和 status-aware scheduling。

4.3 High-Concurrency Workflow Performance

Figure 6 对应高并发 workflow 实验。

4.3.1 实验目的

这一实验模拟在线 serving 场景：

多个独立 agentic workflows 同时运行在同一个 GPU 上。

与 single-workflow 不同，高并发场景中：

1. GPU memory pressure 更大；
2. KV cache 数量更多；
3. cache eviction 更频繁；
4. CPU-GPU transfer 竞争更明显；
5. 调度策略对整体性能影响更大。

因此这是检验 KVFlow 是否能在实际 serving 场景中发挥作用的重要实验。

4.3.2 实验设置

论文在单个 H100 GPU 上同时启动多个独立 workflow。

这些 workflow：

1. 相互独立；
2. 不共享信息；
3. 不共享 agent；
4. 不发生 workflow 间通信。

Figure 6 中每个配置由：

fixed prompt length / concurrent task number

表示。

例如：

512 / 128-Task
1024 / 64-Task

dynamic token 和 output token 固定为：

dynamic tokens = 256
output tokens = 256

论文还特别说明：并发数不是无限提高，而是选择 GPU 能够承受、且仍然有一定空间用于 prefix caching 的合理并发数。如果并发过高，所有显存都被 active requests 占满，系统已经无法维护 reusable prefix cache，那就超出了 KVFlow 的优化范围。

4.3.3 Figure 6 结果分析

Figure 6 显示：

KVFlow 在所有高并发设置中都优于 SGLang 和 HiCache。

在这些实验中，KVFlow 相比 SGLang 最高达到：

1.25× speedup

虽然这个数字小于 single-workflow 长 prompt 场景中的 2.91×，但在高并发 serving 环境中已经很有意义。

4.3.4 为什么 1024 fixed prompt 比 512 fixed prompt 收益更大？

当 fixed prompt 从 512 增加到 1024 时：

1. 每个 agent 的 KV cache 更大；
2. cache miss 成本更高；
3. CPU-GPU transfer 更重；
4. eviction 决策更关键。

因此 workflow-aware eviction 和 proactive prefetching 的收益更明显。

4.3.5 为什么 HiCache 在高并发下表现很差？

论文指出，HiCache 在高并发下有时甚至落后于 GPU-only SGLang。

例如：

1024 fixed prompt tokens / 64 concurrent workflows

HiCache 仅达到：

0.57× of SGLang

也就是说，它比没有 CPU-based cache 的 SGLang 还慢。

论文推测原因主要有两个：

原因一：频繁 reactive load-back 干扰调度

高并发下 cache miss 很多，HiCache 会频繁从 CPU 加载 KV cache 回 GPU。这些 reactive loading 操作发生在 request 需要执行时，容易阻塞 schedule-compute pipeline。

原因二：KV storage fragmentation 限制 PCIe bandwidth 利用

SGLang 的 KV storage layout 存在一定碎片化，导致 CPU-GPU transfer 不能充分利用 PCIe bandwidth。

KVFlow 没有根本解决 fragmentation 问题，但它通过更合理的 eviction 和 proactive prefetching，让 transfer 更容易与 GPU computation 重叠，从而减少实际等待。

4.3.6 KVFlow 相比 HiCache 的优势

在高并发实验中，KVFlow 相比 naive LRU-based HiCache with reactive loading 最高达到：

2.19× performance gain

这个结果说明：

CPU backup 本身并不能保证性能；
真正关键的是何时加载、加载谁、是否与 GPU computation 重叠。

KVFlow 利用 workflow 信息解决了这三个问题：

何时加载：在 agent 执行前提前加载；
加载谁：加载下一步可能执行的 agent；
如何避免阻塞：status-aware scheduling 优先调度 ready requests。

4.4 Realistic Workflow Simulation

Figure 7 和 Figure 8 对应 realistic workflow simulation。

前面的实验属于 microbenchmark，prompt 长度和 workflow 结构都是人为控制的。为了验证 KVFlow 在更真实场景下是否有效，论文基于 PEER framework 构造了 realistic multi-agent workload。

4.4.1 PEER-style workflow 设置

每个 workflow 包含四个 agent。

论文使用 PEER 提供的 workflow templates，并为每个 agent 采样：

1. role
2. instruction

然后通过 LLM 生成 agent prompt。

由于 LLM sampling 有随机性，即使 role 和 instruction 类似，生成的 prompt 也可能有差异。这使得 workload 更接近真实场景。

同时，由于所有 agents 属于同一个 application context，它们的 prompt 之间通常会共享部分 prefix。因此这个设置同时具有：

1. prompt diversity；
2. partial prefix redundancy。

这正是现实 multi-agent application 的常见特征。

4.4.2 数据集

论文使用：

Financial QA dataset from PEER

作为 workflow 输入。

这种任务中，不同 agent 可能负责：

1. 理解金融问题；
2. 检索或分析相关信息；
3. 生成答案；
4. 检查或修正答案。

虽然论文没有重点评估 answer quality，但这个数据集用于构建更真实的系统 workload。

4.4.3 Figure 7：Token distribution

Figure 7 展示了 PEER-style workflows 中：

fixed tokens
dynamic tokens
output tokens

的分布。

与 microbenchmark 中 4096 或 8192 tokens 的 fixed prompt 不同，PEER-style workload 中 agent prompts 通常只有几十到几百 tokens。

这说明 realistic workload 的 fixed prompt 更短，cache miss 成本也相对较低。

4.4.4 Figure 8：Realistic workload 结果

Figure 8 显示，在 PEER-style realistic multi-agent applications 上，KVFlow 仍然优于 SGLang 和 HiCache。

具体提升为：

最高 1.12× speedup over SGLang；
最高 1.08× speedup over HiCache。

这个提升幅度小于长 prompt microbenchmark，但仍然说明 KVFlow 在真实 workload 中具有实践价值。

4.4.5 为什么 realistic workload 中 speedup 较小？

原因主要是：

1. fixed prompt 较短；
2. cache miss 代价没有 4096/8192 token 场景那么高；
3. CPU-GPU loading 时间较短；
4. output 和 dynamic 部分在总 latency 中占比更高。

因此 KVFlow 的优势不像长 prompt 场景那么显著。

但是，即使在这种较温和的真实 workload 中，KVFlow 仍然能取得稳定提升，说明其设计具有通用性。

4.5 Evaluation 总结

Evaluation 部分可以总结为：

KVFlow 在长 fixed prompt 场景中收益最大 因为 cache miss 和 recomputation 成本很高。
KVFlow 在 GPU memory pressure 下特别有效 因为 eviction decision 更重要。
KVFlow 在高并发场景中优于 HiCache 因为它不是 reactive loading，而是 workflow-aware prefetching。
KVFlow 对真实 PEER-style workload 仍然有效 虽然 prompt 较短，收益降低，但仍然有加速。
KVFlow 不改变输出语义 因为它只修改 cache management，不改模型、prompt 和 decoding。

4.6 对实验的进一步思考

这篇论文的实验设计比较聚焦，主要验证系统性能，而不是 agent 任务质量。这是合理的，因为 KVFlow 本身是 serving-system optimization。

不过也可以看到一些潜在限制：

1. 真实 workflow 实验中的 fixed prompt 较短，speedup 相对有限；
2. 实验主要基于 SGLang，尚未展示在 vLLM、TensorRT-LLM 等系统中的实现；
3. prefetch limit 如何设置没有深入展开；
4. 对复杂动态 branching workflow 的预取浪费问题讨论较少；
5. 没有系统分析不同 PCIe bandwidth、不同 GPU memory size 下的敏感性。

但总体来说，实验已经比较清楚地证明了论文主张：

workflow-aware cache management 可以显著提升 LLM multi-agent workflows 的 serving efficiency。

论文相关工作主要分为两类：

1. LLM serving optimizations
2. Agentic workflow frameworks

5.1 LLM Serving Optimizations

这一类工作主要关注如何提高 LLM 在线服务系统的吞吐、延迟和显存利用率。

代表方向包括：

5.1.1 Request scheduling

例如：

continuous batching / iteration-level scheduling
multi-level feedback queues
QoE-aware scheduling

这些方法主要优化多个 request 的调度顺序，减少 head-of-line blocking，提高 GPU 利用率。

5.1.2 KV cache management

代表工作包括：

vLLM PagedAttention
SGLang RadixAttention
Automatic Prefix Caching
CachedAttention
Pensieve
RAGCache

这些工作关注 KV cache 的存储、复用、分页、前缀匹配或多轮对话缓存。

其中：

vLLM PagedAttention

主要解决 KV cache memory fragmentation 问题。

SGLang RadixAttention

主要通过 radix tree 复用 shared prefix，减少 prefix caching 中的冗余。

5.1.3 InferCept

InferCept 预测 tool calling duration，并通过 cost model 决定某个 intercepted request 的 KV cache 应该保留、swap 还是丢弃。

它和 KVFlow 有一定相似性，因为二者都关注 KV cache 是否值得保留。但区别是：

InferCept 面向 tool calling / intercepted requests；
KVFlow 面向 multi-agent workflows，并利用 agent execution graph 预测未来执行顺序。

5.2 Agentic Workflow Frameworks

另一类相关工作是 multi-agent frameworks，例如：

MetaGPT
CAMEL
AutoGen
GPTSwarm
AFlow
AgentScope
LangGraph
PEER
Cognify

这些系统关注如何组织 agent：

1. 定义 agent roles；
2. 管理 agent 之间的 message passing；
3. 构建 dependency graph；
4. 集成 tool use；
5. 优化 workflow topology；
6. 提升任务正确性和协作质量。

部分框架也会将 agentic workflow 表示为 computation graph，其中：

nodes 表示 LLM-invoking agents；
edges 表示 control flow 或 message dependencies。

这些图结构可用于：

edge pruning
operator insertion
topology optimization
workflow autotuning

但是这些工作大多集中在 application layer，即关注 agent 如何协作、任务质量如何提升。

KVFlow 的不同点是：

它将 agent workflow 的结构信息传递到底层 serving backend，
利用这些信息优化 KV cache eviction 和 prefetching。

因此 KVFlow 与现有 agent framework 是互补关系。上层 agent framework 可以继续负责 workflow 构建，下层 KVFlow 负责更高效地执行这些 workflow。

5.3 KVFlow 的定位

KVFlow 位于两个领域的交叉点：

LLM Serving Systems
        ×
Agentic Workflow Semantics

它不是单纯的 serving 优化，也不是单纯的 agent framework，而是提出：

serving backend 应该理解 agent workflow 的未来执行结构。

这是本文最重要的系统设计思想。

6. Conclusion

KVFlow 提出了一个面向 LLM-based multi-agent workflows 的 workflow-aware KV cache management framework。

它的核心结论是：

在多智能体工作流中，KV cache 是否应该保留，不应该只由过去访问时间决定，
而应该由未来 agent 执行顺序决定。

传统 LRU 的问题是：

只看过去，不看未来。

KVFlow 的改进是：

利用 Agent Step Graph 预测未来 agent 调用，
根据 steps-to-execution 决定 KV cache eviction priority，
并提前 prefetch 即将执行 agent 的 KV cache。

具体来说，KVFlow 做了两件关键事情：

Workflow-aware eviction 将 agent execution schedule 抽象为 Agent Step Graph，并计算每个 agent 的 steps-to-execution。然后在 radix-tree KV cache 中将这个值传播到 KV node 级别，实现细粒度 eviction。动态 suffix 被赋予最高驱逐优先级，固定 prefix 根据未来复用距离决定是否保留。
Fully overlapped KV prefetching 将 CPU memory 作为 secondary cache，当某个即将执行的 agent 的 KV cache 不在 GPU 时，提前从 CPU 异步加载到 GPU。同时利用 status-aware scheduling 避免调度仍在 loading 的 request，使 GPU 尽量执行已经 ready 的请求，从而隐藏 CPU-GPU transfer latency。

实验表明：

1. 在长 fixed prompt 的单 workflow 场景下，KVFlow 相比 SGLang w/ HiCache 最高 1.83× 加速；
2. 相比 GPU-only SGLang 最高 2.91× 加速；
3. 在高并发 workflow 场景下，KVFlow 相比 SGLang 最高 1.25× 加速；
4. 相比 naive LRU-based HiCache with reactive loading 最高 2.19× 加速；
5. 在 PEER-style realistic workload 中，KVFlow 仍然取得最高 1.12× over SGLang 和 1.08× over HiCache 的提升。

这篇论文的意义在于，它指出了一个很重要的方向：

未来 LLM serving system 不应该只面向孤立 request 优化，
而应该理解上层 LLM application 的结构，
尤其是 multi-agent workflow 的执行语义。

从更大的角度看，KVFlow 体现了一种趋势：

LLM application semantics 和 LLM serving system optimization 正在逐渐结合。

过去 serving system 只看到 token sequence；而 KVFlow 让 serving system 进一步看到：

这些 token sequence 属于哪个 agent；
这个 agent 在 workflow 中什么时候会再次执行；
哪些 prefix 是固定可复用的；
哪些 suffix 是动态且低复用价值的；
哪些 KV cache 应该提前加载。

因此，KVFlow 的核心价值不是某个单独机制，而是提出了一种新的系统优化视角：

用 workflow semantics 指导底层 KV cache 管理。

对于未来工作，可以进一步考虑：

1. 在 vLLM、TensorRT-LLM 等更多 serving backend 中实现类似机制；
2. 结合更细粒度的 bandwidth-aware prefetch scheduling；
3. 对 branching workflow 进行概率预测，减少无效 prefetch；
4. 将 KVFlow 与 speculative decoding、KV sparsity、PagedAttention 等方法结合；
5. 进一步优化 fragmented KV storage，提高 PCIe bandwidth 利用率；
6. 支持更复杂的动态 agent graph 和在线 workflow 修改。

最终总结： KVFlow 证明了，在 LLM-based multi-agent workflows 中，agent 执行结构不仅是应用层信息，也可以成为底层系统优化的重要依据。它通过 Agent Step Graph、workflow-aware eviction 和 overlapped KV prefetching，有效减少了 prefix cache miss 和 CPU-GPU loading stall，从而提升了多智能体 LLM 工作流的 serving efficiency。

KVFlow: Efficient Prefix Caching for Accelerating LLM-Based Multi-Agent Workflows#

Abstract#

1. Introduction#

1.1 研究背景：LLM-based agentic workflows#

1.2 Prefix caching 为什么重要？#

1.3 现有系统的问题：LRU 不适合 agentic workflow#

1.4 Figure 1 详细解释#

1.5 KVFlow 的核心想法#

1.6 本文主要贡献#

2. Background#

2.1 LLM 推理中的 KV cache#

2.2 Prefill latency 与 KV cache transmission#

2.2.1 Prefill 阶段#

2.2.2 Decode 阶段#

2.3 Prefix caching 的基本机制#

2.4 GPU memory pressure#

2.5 CPU memory 作为 secondary cache#

2.6 Agentic workflow 的 prompt 结构#

fixed part#

dynamic part#

2.7 背景部分的核心结论#

3. Design of KVFlow#

3.1 Workflow-Aware Eviction Policy#

3.1.1 为什么 LRU 不够？#

3.1.2 Agent Step Graph#

3.1.3 为什么不能只用普通 DAG 或 CFG？#

3.1.4 Step Aggregation Function#

情况一：普通顺序依赖#

情况二：同步 barrier，AND 依赖#

情况三：条件分支，OR 依赖#

3.1.5 Figure 3(a) 详细解释#

3.1.6 从 agent-level priority 到 KV node-level priority#

3.1.7 Eviction priority 的含义#

3.1.8 Figure 3(b) 详细解释#

第一步：只对 fixed prompt 部分赋予 workflow-aware priority#

第二步：将 agent 的 steps-to-execution 赋给固定 prompt 的最后一个 KV node#

第三步：沿 cache tree 向上传播 priority#

3.1.9 KVFlow 的 eviction 顺序#

3.1.10 多 workflow 并发时的 priority 冲突#

3.2 Overlapped KV Prefetching#

3.2.1 Reactive Loading 的问题#

3.2.2 Proactive Prefetching 的思路#

3.2.3 为什么 prefetch 可以和推理计算重叠？#

3.2.4 分支 workflow 下的 prefetch#

3.2.5 仅有 prefetch 还不够#

3.2.6 Status-Aware Scheduling#

3.2.7 KV node 的四种状态#

3.2.8 Figure 4 详细解释#

第一种：Reactive Loading#

第二种：Proactive Prefetching#

第三种：Proactive Prefetching + Status-Aware Scheduling#

3.2.9 KVFlow prefetch 和 scheduling 的伪代码理解#

3.3 Implementation#

3.3.1 前端和后端都需要修改#

3.3.2 Step Information Capture#

3.3.3 固定 prompt 和动态 prompt 的边界识别#

方案一：显式标记#

方案二：启发式识别#

3.3.4 Client Tracking#

3.4 Design 部分总结#

4. Evaluation#

4.1 Baselines#

4.1.1 SGLang#

4.1.2 SGLang w/ HiCache#

4.1.3 KVFlow#

4.2 Single-Workflow Latency#

4.2.1 实验目的#

4.2.2 Workflow 设置#

4.2.3 Models and Testbeds#

设置一：Llama-3.1-8B on A10G#

设置二：Qwen2.5-32B on H100#

解码设置#

4.2.4 Evaluation Method#

4.2.5 Figure 5 结果分析#

4.2.6 为什么 KVFlow 比 HiCache 快？#

4.2.7 为什么 fixed prompt 越长，KVFlow 收益越大？#

4.2.8 为什么 output token 越多，KVFlow 相对收益越小？#

4.2.9 H100 上 HiCache 有时表现下降的原因#

4.3 High-Concurrency Workflow Performance#

4.3.1 实验目的#