面向LLM代理中功能等价工具的延迟-质量路由

# 面向LLM智能体中功能等价工具的延迟-质量路由
来源：https://arxiv.org/html/2605.14241
Dawei XiangWei Zhang 康涅狄格大学 \{kexin\.chu, ieb24002, wei\.13\.zhang\}@uconn\.edu

###### 摘要

增强工具的大型语言模型（LLM）智能体越来越多地通过多个功能等价的提供商访问同一工具类型，例如网络搜索API、检索器或暴露在共享接口后的LLM后端。这带来了运行时负载下的提供商路由问题：路由器必须在延迟、可靠性和答案质量各不相同的提供商之间做出选择，而在部署时通常没有黄金标签。我们提出了LQM-ContextRoute，一种用于同功能工具提供商的上下文赌博机路由器。其核心设计是延迟-质量匹配：不是让低延迟用加性奖励来补偿糟糕的答案，而是根据每个服务周期内的预期答案质量对提供商进行排序。它将这种容量感知评分与查询特定的质量估计以及LLM作为评判者的反馈相结合，使其能够在线上同时适应负载变化和提供商质量差异。在主要的网络搜索负载基准测试中，LQM-ContextRoute相对于SW-UCB在F1上提升了+2.18个百分点，同时保持在延迟-质量前沿。在高异质性的StrategyQA环境下，LQM-ContextRoute避免了加性奖励的崩溃，并将准确率相对于SW-UCB提升了最多+18个百分点；在异质性检索器池上，它相对于SW-UCB在NDCG上提升了+2.91到+3.22个百分点。这些结果表明，同功能工具路由受益于将延迟视为服务容量，特别是在运行时压力与提供商质量异质性并存的情况下。

面向LLM智能体中功能等价工具的延迟-质量路由

Kexin Chu、Dawei Xiang、Wei Zhang
康涅狄格大学
\{kexin\.chu, ieb24002, wei\.13\.zhang\}@uconn\.edu

## 1 引言

增强工具的LLM智能体越来越多地通过共享工具接口调用外部服务。例如，一个单一的 `web_search` 调用可能由背后的Tavily、Brave或DuckDuckGo通过MCP（Anthropic, 2024 (https://arxiv.org/html/2605.14241#bib.bib2)）或函数调用接口提供服务。这些提供商在API意义上是*功能等价的*：每个都接受一个查询字符串并返回排序后的片段。但它们在操作上并不等价：延迟、速率限制和答案贡献因提供商和负载情况而异。最近的行业压力测试对MCP服务器和搜索API（Digital Applied, 2026 (https://arxiv.org/html/2605.14241#bib.bib1); Gupta, 2026 (https://arxiv.org/html/2605.14241#bib.bib10)）报告了因超时、配额耗尽、上游错误和速率限制导致的运行时故障。我们对三个搜索提供商的270次调用进行的实时分析显示，即使所有调用都成功，延迟模式也明显不同（附录C (https://arxiv.org/html/2605.14241#A3.SS0.SSS0.Px5)）。提供商的选择会影响智能体的运行时行为；这不仅仅是一个部署细节。

先前关于工具增强智能体（Toolformer (Schick等人, 2023 (https://arxiv.org/html/2605.14241#bib.bib17))， Gorilla (Patil等人, 2023 (https://arxiv.org/html/2605.14241#bib.bib18))， ToolLLM (Qin等人, 2023 (https://arxiv.org/html/2605.14241#bib.bib19))， ReAct (Yao等人, 2022 (https://arxiv.org/html/2605.14241#bib.bib20))）的工作主要研究智能体应调用*哪种工具类型*。我们研究的是工具选择之后的网关决策：在当前负载下，该工具的哪个提供商应接收调用，且在线黄金标签不可用？这种提供商视角与网关实际配置方式相匹配：路由通常在一个选定的接口范围内进行，因此候选集是该接口的提供商池，而不是智能体的完整工具清单。生产环境路由器，如Portkey (Portkey, 2026 (https://arxiv.org/html/2605.14241#bib.bib5))和LiteLLM (BerriAI, 2026 (https://arxiv.org/html/2605.14241#bib.bib7))，通过优先级列表、冷却和回退来处理可用性问题。这些机制很有用，但它们在很大程度上是被动且忽略质量的。在一个K=10的优先级路由器重放中，一个生产风格的优先级加冷却策略，在手动调优的优先级顺序下达到了0.610 F1，但在顺序不匹配时下降到0.005 F1，表明仅靠可用性信号无法恢复提供商质量。

一个自然的学习替代方案是使赌博机具有负载感知能力，使用加性的延迟-质量奖励：`r = αu - (1-α)τ̃`。当提供商具有相似答案质量时，这类奖励简单且合理，但当质量异质性时可能失败：低延迟可以补偿一个对答案贡献甚微的提供商。在这种情况下，路由器可能满足服务水平协议（SLA），同时悄然降低任务性能。核心问题不仅在于路由器是否适应负载，还在于延迟应如何进入学习目标。

我们提出LQM-ContextRoute，一种用于同功能提供商的上下文赌博机路由器。其主要设计选择是*延迟-质量匹配*：不是将延迟视为加性惩罚，而是通过更新-奖励率 `ûᵢ / (1 + τ̂ᵢ / Lᵣₑf)` 对每个提供商进行评分。这将延迟视为服务周期成本。一次调用消耗一个记账单位加上与 `τ / Lᵣₑf` 成比例的服务时间惩罚，因此一个快速但低质量的提供商不会仅仅因为快而得到奖励。路由器将此目标与LinUCB质量头和LLM作为评判者的反馈相结合，使其能够在没有在线黄金标签的情况下学习查询特定的质量估计。

#### 贡献.

- • 我们形式化了运行时负载下的同功能提供商路由问题，将提供商选择与上游的调用哪种工具类型的决策分离。
- • 我们识别出加性的延迟-质量补偿是一种具体的失败模式，并提出了一种吞吐量风格的目标，将延迟视为服务周期成本而非加性奖励惩罚。
- • 我们在网络搜索负载轨迹、高异质性问答、检索器池以及LLM提供商池上评估了LQM-ContextRoute。它在主要负载基准测试中将静态提供商延迟降低了50–67%，将F1相对于SW-UCB提升了+2.18个百分点，将StrategyQA准确率提升了最多+18个百分点，并在检索器池上增加了+2.91到+3.22个百分点的NDCG。

## 2 背景与问题形式化

#### 任务.

一个选定的函数类别 `C` 由一个由 `K` 个功能等价工具组成的池 `T_C = {T₁, ..., T_K}` 提供服务：每个臂实现相同的外部接口，但在答案质量、延迟、速率限制或后端模态上可能不同。在第 `t` 轮，查询 `qₜ` 到达；路由器选择 `iₜ ∈ [K]`，立即观察到延迟 `τ_{iₜ}(t) ≥ 0`，并在稍后收到来自在线评估器（在我们的实验中是LLM评判者）的质量标量 `u_{iₜ}(t) ∈ [0,1]`。目标是选择能够在满足操作员设置的服务时间预算 `Lᵣₑf` 的同时，提供高预期质量的提供商。

#### 为何该设置不同.

此提供商路由问题既不同于工具选择，也不同于简单的上下文赌博机。上游智能体已经选择了工具类型；网关仅在面向该接口的提供商中进行选择。反馈是部分的，因为路由器仅观察到它调用的提供商的延迟和质量。负载是非平稳的，质量标签在线不可用，并且提供商偏好可能依赖于查询。提供商可能具有异质性：一个低延迟提供商在某些任务中可能不是好的答案来源，而一个较慢的提供商可能更有用。

#### 为何该设置重要.

外部压力测试报告激发了问题的负载面：Digital Applied (2026 (https://arxiv.org/html/2605.14241#bib.bib1)) 发现，62% 的MCP服务器故障是运行时/负载相关的，并且当并发从1个请求增加到32个时，可靠性下降18个百分点，而Gupta (2026 (https://arxiv.org/html/2605.14241#bib.bib10)) 报告速率限制是最具破坏性的注入故障。尽管我们的实时搜索分析比生产流量小，但它显示了网关即使在没有故障时也能看到的提供商级差异：在270次调用中，Tavily的暖启动p₅₀为76毫秒，伴有冷启动尾部，Brave的暖启动p₅₀为316毫秒，分布更紧凑，而DDG保持在约2.5秒（附录C (https://arxiv.org/html/2605.14241#A3.SS0.SSS0.Px5)）。这些观察结果激发了一种既能跟踪服务状态，又能同时考虑答案质量的路由器。

#### 为何加性奖励不匹配.

一种标准的负载感知奖励（Poon等人, 2025 (https://arxiv.org/html/2605.14241#bib.bib25); Chadderwala, 2025 (https://arxiv.org/html/2605.14241#bib.bib29)）是 `r = αu - (1-α)τ̃`，其中 `τ̃` 归一化到 [0,1]。这两个轴会*相互补偿*：当 `α=0.4` 时，`τ̃=0, u=0.1` 得分为0.04，而 `τ̃=1, u=0.65` 得分为-0.34，因此低质量低延迟的提供商排名更高。我们反而将路由框架化为约束问题：

`π* = arg max_π E_{i~π}[u_i]   s.t.   E_{i~π}[τ_i] ≤ Lᵣₑf`  (1)

其中 `Lᵣₑf` 是操作员设置的服务时间预算（在我们的实验中为SLA阈值）。该目标明确了权衡：延迟约束了有用答案的交付频率，但它不应直接补偿低答案质量。

## 3 方法：LQM-ContextRoute

### 3.1 路由器概述

LQM-ContextRoute 是一个面向固定功能等价提供商池的路由器。在第 `t` 轮，它接收一个查询表示 `xₜ`，选择一个提供商 `iₜ`，观察到其延迟 `τ_{iₜ}(t)`，接收在线质量得分 `u_{iₜ}(t)`，并仅更新被选中的提供商。路由器为每个提供商维护三个量：一个查询条件质量估计、一个提供商级延迟估计以及一个用于探索的不确定性估计。选择规则将它们组合成一个得分：预测质量除以当前服务成本，并且乐观奖励在质量不确定时鼓励探索。

这种分离反映了部署场景。负载本质上是上游服务在给定时间的属性，因此延迟在提供商级别进行跟踪。质量是查询条件的，因为共享同一个API的两个提供商仍可能在问题类型、检索覆盖范围或推理适用性上有所不同。更新率项是目标；LinUCB头估计查询特定质量；指数移动平均（EMA）跟踪当前服务成本。表1 (https://arxiv.org/html/2605.14241#S3.T1) 总结了这些角色。

表1：路由器使用的每个提供商状态。

### 3.2 延迟-质量匹配

核心设计选择是选择目标。加性奖励 `αu - (1-α)τ̃` 允许一个低质量提供商通过低延迟得到补救。我们反而通过更新-奖励率对提供商进行评分：

`V_i = u_i / (1 + τ_i / Lᵣₑf)`  (2)

其中 `Lᵣₑf` 是操作员设置的延迟预算。该评分实现了公式 (1) 中的约束目标：质量是奖励，而延迟消耗服务容量。在线性周期校准下，一次调用占用一个记账单位加上一个与 `τ_i / Lᵣₑf` 成比例的服务时间惩罚。更新-奖励定理给出了长期奖励率 `u_i / (1 + τ_i / Lᵣₑf)`（Ross, 1996 (https://arxiv.org/html/2605.14241#bib.bib39)，Thm. 3.6.1）。附录B (https://arxiv.org/html/2605.14241#A2) 给出了形式化描述并讨论了替代校准。对于路由的重要属性是非补偿性：如果 `u_i` 接近零，无论提供商多快，得分都接近零。

该目标还赋予 `Lᵣₑf` 直接的操作含义：它是延迟尺度，在此尺度下一次调用大致消耗一个额外的服务时间单位。较小的值使路由器对延迟更敏感，而较大的值则接近质量优先路由。在实验中，我们将 `Lᵣₑf` 设置为SLA阈值，并在附录C (https://arxiv.org/html/2605.14241#A3.SS0.SSS0.Px3) 中检查敏感性。

### 3.3 上下文质量与延迟估计

LQM-ContextRoute 使用每个提供商的LinUCB头估计质量，并使用指数移动平均估计延迟。对于提供商 `i`，令 `ûᵢ(xₜ) = xₜ^T Aᵢ⁻¹ bᵢ` 为上下文质量估计，`τ̂ᵢ` 为当前延迟估计。在选择提供商 `iₜ` 后，路由器使用观察到的延迟更新 `τ̂_{iₜ}`，并使用对 `(xₜ, u_{iₜ}(t))` 更新选中的LinUCB头。未选中的提供商不更新，这与网关中可用的赌博机反馈相匹配。

### 3.4 选择规则

路由器选择得分最大的提供商：

`sᵢ(t, xₜ) = ûᵢ(xₜ) / (1 + τ̂ᵢ / Lᵣₑf) + (α_ucb √(xₜ^T Aᵢ⁻¹ xₜ)) / (1 + λ Δᵢ(xₜ))`  (3)

其中 `Δᵢ(xₜ) = max(0, max_j ûⱼ(xₜ) - ûᵢ(xₜ))`。第一项是应用于上下文质量的延迟-质量匹配得分；第二项是LinUCB探索奖励，对于估计质量已被占优的臂进行缩减。我们在所有实验中使用 `λ=1`。滑动窗口Sherman–Morrison更新高效维护 `Aᵢ⁻¹`；算法1 (https://arxiv.org/html/2605.14241#alg1) 总结了在线循环。

缩减项是有意不对称的。它不会仅仅因为慢而惩罚一个慢的提供商，因为一个慢的提供商可能恰好是唯一具有有用证据的提供商。它仅在当前上下文模型已经估计另一个提供商具有更高质量时减少探索。这就是区分LQM-ContextRoute与纯负载均衡器的机制：当预期的质量回报很大时，路由器可能花费延迟，同时减少对当前查询分布下预测质量已被占优的臂的探索。

算法1 LQM-ContextRoute在线路由
1: 初始化
    Aᵢ ← λᵣ I,
    bᵢ ← 0,
    τ̂ᵢ ← τ₀
    对于每个提供商 i
2: 对于 t = 1,...,T 执行
3:     将查询 qₜ 嵌入为 xₜ
4:     对于每个活动提供商 i 执行
5:         ûᵢ ← xₜ^T Aᵢ⁻¹ bᵢ
6:         cᵢ ← α_ucb √(xₜ^T Aᵢ⁻¹ xₜ)