面向低延迟多智能体工具调用的有状态推理架构

# 面向低延迟多智能体工具调用的有状态推理
来源：https://arxiv.org/html/2605.26289

###### 摘要

多智能体工具调用正成为基于 LLM 的系统的主导交互模式：编排器将工具调用分派到多个专门智能体，每个智能体维护自己的对话历史，包含系统提示、工具模式和累积的工具结果。现有的推理框架将每次工具调用视为独立请求，即使只有少数几个 token 发生变化，也会从头开始重新处理整个对话。这非常低效：在典型的 5 轮智能体对话中，连续轮次间 85-95% 的提示是相同的。

我们提出了一种架构，将传统推理中每轮 O(nt) 的成本转换为 O(Δt) 的仅增量成本，其中 Δt 是第 t 轮追加的新 token。核心构建是一个有状态的 KV 缓存，它跨持久会话存在，通过仅摄取每轮的新 token 来推进。一个基数前缀缓存通过统一 KV 缓存中的元数据仅序列别名，将此属性扩展到顺序和交错的多智能体流量；一个提示确定性响应缓存完全消除了重复提示上的 GPU 工作；一个具有并发限制准入的提示查找推测解码器加速了结构化工具调用输出的生成。我们在多智能体工具调用工作负载上，与两个生产级推理引擎（vLLM 和 SGLang）进行了基准测试。在全新多轮工作流中，每个 token 都必须生成且没有缓存响应，参考实现在 6 轮智能体工作流中每轮比 vLLM 和 SGLang 都快 2.1 倍，并且优势随着对话深度增加而扩大，在 35 轮编码工作流的中位数轮次中达到 4.2 倍，端到端用时几乎减半。性能提升来自于重用单调增长的对话前缀以及推测结构化输出，而非缓存：一个提示确定性响应缓存额外以网络延迟服务完全相同的重复流量（这是对比引擎缺乏的能力），但我们有意识地排除了这个因素，以隔离对新任务的加速效果。在现实生成长度下，所有三个引擎都能发出有效的工具调用，因此优势在于延迟，而不是正确性。

## 1 引言

智能体范式已将 LLM 推理从单次问答转变为多轮、多智能体的工具调用。一个现代 AI 应用可能会同时编排一个旅行规划器、一个代码审查员和一个数据分析师，每个都发出工具调用序列并接收结构化结果。每一轮都会向可能跨越数千 token 的对话中追加几百个 token。

这种工作负载有一个独特的结构：对话单调增长，每一轮新轮次都会在一个大的、之前见过的前缀上附加一个小的增量。在一个 5 轮智能体对话中，如果系统提示有 200 个 token，每轮有 150 个 token，最后一轮的提示包含约 950 个 token，但只有约 150 个是新的。其余 800 个 token 已在之前的轮次中处理过。

现有的推理框架处理得很差。诸如 vLLM（Kwon 等人，2023 (https://arxiv.org/html/2605.26289#bib.bib1)）和 SGLang（Zheng 等人，2024 (https://arxiv.org/html/2605.26289#bib.bib2)）之类的请求驱动系统将每次 API 调用视为独立，在请求之间丢弃或部分保留 KV 缓存状态。有些提供前缀缓存（SGLang 中的 RadixAttention，vLLM 中的自动前缀缓存），但这些是为许多用户共享静态系统提示设计的，而不是为单个智能体增量构建对话。当多个智能体交错请求时，针对共享前缀优化的缓存驱逐策略会失败：智能体 B 的请求驱逐了智能体 A 的缓存状态，强制在智能体 A 的下一轮次进行完全重计算。

浪费的工作并非理论问题。众所周知，大型生产推理集群的加速器持续利用率在 10-45% 之间，而达到峰值的差距中很大一部分正是由这种冗余的每请求预填充模式消耗的，这种模式应用于长尾的智能体流量，其中每一轮都重新处理前一轮的前缀。对于一个为用户会话分派数千次工具调用的编排框架，集群支出的乘数是直接的：实现真正进展所需的 FLOPs 的 5 倍转化为 GPU 小时计费的 5 倍，并成比例地降低有效利用率。缩小这一差距需要跨请求保留和重用中间状态，而不是将每次调用视为从未见过。

我们通过九种机制来应对，这些机制共同涵盖了有状态推理、准入、前缀共享、生成和验证：

1. 有状态会话：一个跨请求存在的持久 KV 缓存，而不是在每次调用时重建，因此一个长期存在的对话或数据流通过仅摄取每轮的新 token 来推进。这是系统其余部分构建的前提：有状态而非无状态推理是智能体和实时 AI 的正确基础。
2. 序列池：在单个统一推理上下文中预分配的一组命名序列 ID，通过线程安全的空闲列表在请求间回收，并保留到瞬态池和会话池中，消除了每请求上下文构建的开销。
3. 基数前缀缓存：一个缓存前缀的基数树，其状态通过统一 KV 缓存上的元数据仅序列别名在请求间共享，在常数时间内恢复一个 m-token 前缀（与 m 无关），并将每轮成本从 O(nt) 转换为 O(Δt)。
4. 带前缀感知分组预填充的单元预算准入：一个连续批处理调度器，根据单元上限准入预填充，并将共享字节相同前缀的槽分组为单个领导者-跟随者预填充，将共享系统提示和工具模式的 N 个冗余前向传递合并为一个。
5. 提示确定性响应缓存：一个全响应 LRU 缓存，通过从提示的 FNV-1a 哈希中种子采样器来实现，因此相同的提示在任何温度下都会产生相同的输出，重复请求以网络往返延迟返回，零 GPU 工作。
6. 并发限制的提示查找推测：一个每槽的提示查找推测解码器，从该槽最近的 token 历史中预测续文，并在批量前向传递中验证，具有自适应每槽上限，可防止在高准入下吞吐量崩溃。
7. 流式工具调用验证器：一个通过逐片流式回调馈送的括号平衡 JSON 解析器，在工具调用的结构闭合处发出提前停止信号，并根据已声明工具集过滤掉幻想的工具名称，消除了调用完成后浪费的解码，并在无效调用到达客户端之前拒绝它们。
8. 设备上贪心采样：设备特定的 argmax 内核，直接在加速器上执行贪心 token 选择，消除了在每个 token 上的同步和扫描往返，否则这在短响应上主导采样延迟预算。
9. RAII 会话生命周期：在异常安全保护下自动获取和释放序列槽，防止并发多智能体工作负载下的泄漏。

## 2 问题形式化

### 2.1 多智能体工具调用工作负载

考虑 A 个并发智能体，每个执行 T 次工具调用序列。智能体 a 在第 t 轮提交提示：

Pa(t) = [Sa; Ma(1); Ra(1); ...; Ma(t)]  (1)

其中 Sa 是系统提示（工具模式、指令），Ma(i) 是第 i 个用户/助手消息，Ra(i) 是第 i 个工具结果。关键的观察结果是：Pa(t) 是 Pa(t-1) 的严格前缀扩展：

Pa(t) = [Pa(t-1); Aa(t-1); Ra(t-1); Ma(t)]  (2)

其中 Aa(t-1) 是助手的工具调用响应，Ra(t-1) 是返回的工具结果。

对于单个智能体，前缀缓存很简单：每一轮扩展前一轮。对于 A > 1 个交错的智能体（调用按 A1, B1, C1, A2, ... 分派），朴素的单条目缓存会驱逐每个智能体的状态为下一个腾出空间，迫使每次跨智能体转换都从头开始重计算。同时保留所有 A 个活动前缀需要缓存容量 ∑(a=1 to A) || KV(Pa(ta))||，这超过了在有持续交错的情况下块分页缓存所能保留的容量。

### 2.2 成本分析

令 nt = ||Pa(t)|| 表示第 t 轮的总提示长度，Δt = nt - nt-1 表示新 token。在没有有效缓存的请求驱动框架中：

C_standard = ∑(t=1 to T) O(nt) = O(T· n̄)  (3)

其中 n̄ 是平均提示长度。使用完美的前缀重用：

C_cached = O(n1) + ∑(t=2 to T) O(Δt) = O(n1 + T· Δ̄)  (4)

由于在工具调用工作负载中 Δ̄ ≪ n̄（通常 Δ̄/n̄ ≈ 0.05–0.15），节省非常显著。后续轮次的加速因子接近：

Speedup_t = nt / Δt ≈ nt / (nt - nt-1)  (5)

## 3 架构

### 3.1 序列池

构建推理上下文开销很大：它分配完整的 KV 缓存内存并初始化 GPU 状态。对于请求频繁到达的多智能体工作负载，每次请求分配会增加约 50–200 毫秒的开销。

我们改为在服务器启动时分配单个统一的推理上下文，并将其序列 ID 空间划分为一个固定池：

Pool = {σ1, σ2, ..., σN}  (6)

其中每个 σi 是统一 KV 缓存内的一个命名序列。序列 ID 被分为两个不相交的区域：一个用于无状态请求的瞬态池和一个用于长期有状态会话的会话池。每个传入请求从相应的池中获取一个序列，在请求期间使用它，并在完成后通过一个互斥锁保护的空闲列表返回。如果池被耗尽，请求会阻塞（具有可配置超时），直到序列被释放。固定池的大小限制了 GPU 内存使用，并提供了可预测的资源消耗。RAII 保护在每条退出路径上返回序列，防止在错误条件下泄漏。

这种单一上下文、多序列的设计是有意为之。一次前向传递会将来自任何序列 ID 子集的预填充和解码 token 混合在一个批次中，因此跨请求的前缀共享简化为同一 KV 缓存内的元数据仅别名，而不是跨上下文协调。

### 3.2 连续批处理调度器

上面的序列池前面是一个“多准入 / 少运行”的连续批处理调度器，每次迭代构建异构的 PREFILL++DECODE 批次。四种机制共同让许多具有广泛不同前缀缓存命中情况的工具调用请求能共存于一个 GPU 上。

**单元预算准入。** 调度器以*单元*（每层每个 token 一个单元）跟踪统一 KV 缓存占用情况，并且仅当所有已准入槽的预计总和（prompt + max_tokens）低于固定上限 C_budget = 1/2 ||pool|| 时，才准入新的预填充。另一半保留给基数缓存的前缀和正在进行的中间状态。当占用率超过高水位线（95%）时，传入的预填充块会按块粒度推迟，而不是按请求粒度，提供细粒度的背压，无需拒绝请求。

**工作负载自适应块式预填充。** 对于有待处理预填充工作的 N 个槽，每个槽每迭代分配一个大小为 chunk = clamp(n_batch / N, 128, 4096)  token 的块。当只有一个活动的预填充时，块填满批次（最多 4,096 个 token）；当有许多并发预填充时，块会缩小，以便解码槽在同一迭代内不被饿死。当存在争用且有延迟敏感的请求（小的 max_tokens）共存时，上限会缩小到公平的 1,024 token 块，以便该请求的解码能及时交错，而不是等待一个大预填充。这与某些服务系统使用的静态块大小（例如 vLLM 的默认 512）以及其他系统使用的预填充优先门控（例如 SGLang）形成对比，这两者都可能在高准入下阻塞解码。

**前缀感知分组预填充。** 提示超过基数缓存匹配点后共享字节相同前缀的槽，通过 FNV-1a 哈希下一个 K=8 个 token 来识别，被分组为单个领导者-跟随者预填充。领导者处理该块；跟随者通过元数据仅序列别名获取结果状态。对于共享系统提示和工具模式，这将 N 次冗余前向传递转换为一次。此优化在多租户工具调用工作负载的突发开始时特别有效，因为许多智能体会同时提交共享相同模式前言的请求。

**并发限制推测。** 调度器还驱动第 3.6 节的每槽提示查找推测解码器。没有协调，推测在高准入时会崩溃：验证成本与每槽草稿长度和并发解码器数量的乘积成正比，同时接受率在不熟悉的内容上下降。调度器根据活动解码器数量和每槽历史接受率联合函数来限制每槽草稿长度，特定阈值针对每个加速器类和模型大小调整。每槽预测步骤在工作线程之间并行化，使其脱离关键路径。

### 3.3 基数前缀缓存

跨请求共享的前缀在按 token 序列键控的基数树中跟踪。树节点记录其 KV 状态仍然保存匹配单元的捐赠序列 ID。当一个新请求到达，其提示扩展了一个缓存分支时，调度器通过统一 KV 缓存上的元数据仅序列别名操作，将前缀恢复到新获取的序列中：新序列的页表被重写指向捐赠者的单元，该操作在常数时间内完成，与前缀长度 m 无关。

算法 1 基数缓存的每轮处理  
输入: 提示 token T, 基数树 R, 获取的序列 σ  
1: (m, σ_donor) ← R.longest_prefix(T)  {遍历树}  
2: if m > 0 then  
3:     SeqAlias(σ_donor, σ, 0, m)  {常数时间，仅元数据}  
4: end if  
5: n_past ← m