一路重试穿过你限流器的 agent

你的网关给每个 tenant 干净利落地强制执行每秒 100 次请求的限制。dashboard 显示每个 tenant 都舒舒服服地在那个上限之下。但模型 provider 寄来的账单告诉你,你的支出上限照样被打穿了。rollout 电话会议上没有人能给出一个干净的解释。

答案在于限流器和账单衡量的是不同的东西。当用户点击一个按钮时,限流器看到的是一次"用户请求"。而 provider 看到的是一次 planner 调用、三次工具结果反思、一次因更严格 JSON schema 触发的格式修正重试,以及一次最终综合——每一次都带着自己的内部重试预算,在瞬时 429 或 500 回来时就会触发。一次点击可以扇出成三十次模型调用。限流器只数到一次。桶以它被设计容量的三十倍漏水。

在 HTTP 边界上对 agentic 系统做限流,就像在高速公路入口立速限标志,而入口里面的车却在自我繁殖。除非限流器理解了这个循环,否则循环就会绕过它。

面向用户的调用与面向 provider 的调用之间的核算缺口

经典的 web 限流有一个整洁的不变式:用户的一次 HTTP 请求大致等于一个单位的后端工作。token bucket 按这个不变式定容,dashboard 围绕它构建,on-call runbook 也信任它。

Agentic 工作流故意打破这个不变式。orchestrator 的全部工作就是把单一的用户意图扇出成许多次模型调用——规划、检索、工具调用、反思、格式修正、综合。最近的分析显示典型的放大因子是每次面向用户的请求 10 到 100 次模型调用,自主编码 agent 和深度研究循环位于这个区间的高端。在 50 次推理步数下,每次请求的成本倍数可以超过等价单次 completion 的三十倍。

这个缺口出现在两个地方。在成本侧,你的 FinOps dashboard 在跨数百万次 provider 调用求和美元数,而你的产品 dashboard 在跨几千次用户点击求和请求数。两张图静悄悄地分叉好几个星期。在可靠性侧,你的网关限流预算是按用户点击数定容的,而不是按模型调用数。当点击图上流量飙升 30%,模型调用图上飙升 900%,而 provider 自家的限流器——那个真正决定你的 tenant 是否能拿到服务的限流器——会远早于你的网关先开火。

修复方法不是在 HTTP 层再加一个 token bucket。修复方法是让每一层都学会按真正消耗资源的工作单位来计数。对于由 LLM 驱动的系统,这个单位是 token,不是请求。基于 token 的限流反映了 provider 在向你收什么钱,以及 provider 自己的限流器会按什么节流。基于请求的限流反映的是这样一个世界:一次 HTTP 调用大致等于一个单位的后端工作——而这个世界在你把循环放在 endpoint 后面的那一刻就结束了。

把循环感知的预算作为首要控制手段

最有用的单一模式是一个每用户请求的 token 预算,它随着请求穿过 orchestrator 的每一层。用户点击。orchestrator 分配一个预算——比如,200,000 输入 token 和 40,000 输出 token。循环中每一次模型调用都在发起调用之前从预算中扣减。当预算归零时,orchestrator 用一个结构化的错误大声失败,产品可以解读它:"这次请求需要的推理超出了允许的范围;这里是部分结果。"

让它在实践中起作用,需要做好几件事。

预算必须是请求的一个属性,而不是一个全局计数器。全局计数器会变成竞争点,且它不会告诉你哪个用户的请求行为不端。每请求预算给你一个干净的问责单位:每条错误日志都带着设置的预算、消耗的预算,以及耗尽它的那一步。

预算必须在模型调用之前强制执行,而不是之后。事后核算会告诉你超支了;调用前的强制才是阻止超支的手段。当剩余预算小于下一步预计的成本时,orchestrator 应当拒绝发起调用。

预算必须包含投机性的支出,而不仅是已消耗的支出。如果 planner 已经决定发起三次并行的检索调用,那么这三次的预算都必须在第一次开火之前预留出来。否则循环可能把你绑在一笔它无法承担的支出上。

预算必须对模型可见。知道还剩多少预算的 agent 可以选择更早地总结、跳过可选的工具调用,或者带着一个标志返回部分答案。不知道的 agent 会烧穿上限,然后在最后一步失败。中止一个失控循环的最便宜的地方是在 planner 里,不是在限流器里。

一个有用的默认比例:把每请求预算设成那条路由观测到的中位数支出的两到三倍,把 p99 视为一个需要查看的信号,而不是一个需要去迁就的预算。p99 高出预算的路由会大声失败;那正是重点所在。

加载中…