Agent 一次任务要调上百次模型：路由层正在变成 AI 的成本中枢

2026-09-25T09:20:00+08:00 | 10分钟阅读 | 更新于 2026-09-25T09:20:00+08:00

@ William Yi

前天我翻了一下自己那台跑日报的机器，一个任务从抓取数据到把文章推上博客，日志里躺着六十多次模型调用。

真正需要「想一下」的没几个。大部分调用都在干这些事：给工具填参数、判断某个字段是不是空、把一段日志压缩成一句话、在几个候选里挑一个。这些调用全都走同一个模型，也全都按同一个价格计费。

这就是 Agent 和聊天机器人的根本差别。聊天是一次请求一次回答，Agent 是一个循环：计划、执行、观察、再计划。一圈下来几十上百次调用，每一次调用都自带一个选择：这件事真的需要一个前沿模型吗？

过去两年行业在讨论「哪个模型更好」，现在开始有人认真算另一笔账：「这一次调用，哪个模型才合适」。这个问题的答案正在沉淀成一层独立的中间件，也就是模型路由与 AI 网关。

一、先看市场信号：中间层正在变厚

今天 GitHub 趋势榜上跟这一层直接相关的项目，密度高得有点反常。

Go 榜上,weave-os/router 的自我描述是「给 agentic 系统用的模型路由器，把每个 prompt 路由到正确的模型」。同一个榜上的 bifrost 更直接，标语就是「比 LiteLLM 快 50 倍的企业级 AI 网关」。TypeScript 侧一个叫 CLIProxyAPI 的项目已经攒到 5.3 万 star，它做的事情是把 Codex、Claude Code 这类 CLI 订阅包成统一的 API 出口。再往边上看,flexprice 在做按量计费与账单,mnfst 那份「永久免费 LLM API 清单」有 8.3k star。

更能说明趋势的是老玩家的动作。LiteLLM 最近一边在博客里连续发 Auto-Router 的降本战报（45% lower cost on 25 SWE-bench Tasks、Same Quality 46% Less Cost 这类标题一个接一个），一边把网关本体从 Python 迁到 Rust，还专门发了一篇基准测试文章来证明迁移的收益。

一个组件从「顺手写在业务代码里的代理」变成「需要单独发版、单独做基准测试的产品」，通常意味着三件事同时发生了：成本开始按调用次数放大、稳定性问题从偶发变成常态、合规审计开始要求一个统一的出入口。这三件事任意一个单独出现，都可以用脚本凑合过去；一起出现，就必须有专门的组件。

二、微软的三层拆解：一个值得抄的参考架构

今年 7 月，微软发布了一份在 Azure Kubernetes Service 上为 Agent 流量做路由的参考架构。它最值得学习的地方不是具体用了哪些开源项目，而是它把「路由」这个模糊的词拆成了三个互不重叠的问题：

用哪个模型来回答这次调用，判断依据是 prompt 内容
这次调用怎么被管理，判断依据是策略、配额、身份
哪一块 GPU 副本接这次请求，判断依据是此刻的硬件状态

三层分别由不同组件承担，最后收敛到一个 OpenAI 兼容的端点。

第一层是语义路由，用的是 RouteLLM，读 prompt 并预测便宜模型能否给出接近强模型的答案质量，内部是一个在人工偏好数据上训练出来的矩阵分解路由器。

第二层是策略网关 agentgateway，负责认证、按 Agent 限流、成本追踪和护栏。它的关键设计是完全不看 prompt 的语义，只看策略。这个边界划得很干净：做治理的组件不要去理解内容，做理解的组件不要去管策略。

第三层是 GPU 感知的副本选择，由 Kubernetes Gateway API Inference Extension 的 Endpoint Picker 负责。它读的是 vLLM 暴露的实时指标：KV cache 占用率、等待队列深度。微软特意解释了这个设计的必要性：普通的 round-robin 负载均衡会干出这种事，把一个 200 token 的 completion 排在一个 100k token 的 prefill 后面，而旁边正好有一块空闲的 GPU。请求的体量差异在 Agent 场景里极大，按连接数均摊是错的。

那组数字与微软自己的警告

任何人都想引用的数字是这一组：在 RouteLLM 测试的模型对上，矩阵分解路由器拿到了 GPT-4 在 MT-Bench 上约 95% 的质量，只把约 26% 的调用发给 GPT-4，相比全部走强模型省下最多 85% 的成本。

但微软在文中明确加了一句警告：这个数字绑定的是训练时的模型对，不能自动套用到「phi-4-mini 配 GPT-5.1」这种新组合上。使用者必须用自己的真实流量重新校准阈值，并参照网关统计的强/弱分流比例来调整，而不是直接采信论文里的估计值。

还有一个容易被忽略的成本细节：prompt 缓存让「强模型调用」的真实价格比牌价低。命中缓存的输入 token 有折扣，而路由在模型之间来回切换会让两边的缓存都变冷。也就是说，省钱的那一半收益，可能被丢掉缓存折扣的另一半成本抵消掉一部分。这一点在第三节还会再出现。

三、路由器本身比看上去难得多

把「简单问题给便宜模型」写成一行 if 很容易，难的是判断什么算简单。

RouteLLM 的路线是用人类偏好数据训练一个胜率预测模型，再配一个成本阈值 α。α 越大就越偏向弱模型，越小就越偏向强模型。评估上也有一套专门的指标，比如 APGR（不同成本约束下平均恢复了多少性能差距）和 CPT（要达到强模型 x% 的性能，至少需要把百分之多少的调用发给强模型）。这套框架在 MT-Bench 上的结论是：把 14% 的调用发给 GPT-4，就能拿到约 95% 的 GPT-4 质量。

工具调用是完全不同的问题

微软研究院今年 5 月的 Switchcraft 指出了一个经常被混淆的点：现有路由器几乎都是为聊天补全设计的，而 Agent 的核心动作是工具调用，两者的信号完全不同。

为工具调用做路由，反而有几个聊天场景不具备的便利。工具调用的正确性可以用 AST 比对自动打分，不需要 LLM 裁判，标签更可靠。Switchcraft 用的是一个 6600 万参数的 DistilBERT 分类器，在八个候选模型之间做选择，准确率达到 82.9%，比最好的单个模型 82.3% 还略高一点，同时把推理成本降了 84%，折算下来每百万次查询能省 3600 美元以上。

它刻意不用大模型做路由器，原因是延迟预算。在 T4 显卡上，这个分类器的 P99 延迟是 64 token 输入 3.2 毫秒、512 token 输入 17.1 毫秒，比 LLM 生成延迟低一个数量级；换更强的编码器（比如 ModernBERT）精度没有实质提升，却慢 2.7 到 5.6 倍。路由器必须是透明的，它一慢，路由这件事本身就失去了意义。

这里有一个值得警惕的价值取向问题。路由研究常把「便宜」和「好」描述成两个可以连续调节的旋钮，但对工具调用来说，正确性是有硬门槛的：填错一个工具参数，整个任务就失败了，省下来的钱会连本带利退回去。Switchcraft 选择在「保证正确」的前提下最小化成本，而不是在质量与成本之间做平滑折中，这个选择本身比它的模型结构更重要。

也要看反方证据

如果只读论文，很容易得出「路由已经解决了」的错觉。今年 1 月发布的 LLMRouterBench 给了一个更冷静的结论。

这个基准整合了 33 个模型、上万个 prompt、最多 22.9 万个评估实例、十亿级别的 token 消耗，把当前主流的路由方法放进同一套流程里比较。它的发现里有一条特别扎眼：没有任何一个路由器能在所有任务和成本预算下占优，而且若干近期方法，甚至包括 OpenRouter 这样的商业路由器，都没有稳定跑赢「永远用最好的那个单模型」这个朴素基线。

我对这条结论的解读是：**路由不是一个通用算法问题，而是一个分布匹配问题。**一个路由器在你的流量上有效，是因为它的训练分布恰好贴近你的实际分布。别人的 benchmark 说明不了你的情况，这也是为什么第三节那些漂亮的数字，微软都要加一句「请用你自己的流量重新校准」。

四、网关层的工程现实：几毫秒也值得较真

语义路由之上，还有一个更朴素的问题：这个中间层自己有多重。

LiteLLM 在把网关迁到 Rust 后公布了 AIGatewayBench 的结果。在同一个本地 mock 上游、关掉日志与持久化的条件下，四个网关的 p99 增加延迟分别是：LiteLLM Rust 约 0.7 毫秒，Portkey 2.3 毫秒，Bifrost 4.5 毫秒，LiteLLM Python 版 257.7 毫秒。峰值内存 21.8MB 对 90.4MB、199.1MB、329.5MB。按实测 CPU、内存和吞吐折算，每百万请求的基础设施成本约 0.000175 美元，比另外三家低六倍左右。在 30 轮的 Agent 循环里，Rust 版额外增加的墙钟时间是 0.03 秒和 0.016 秒，Python 版是 0.97 秒和 0.24 秒。

读这组数字要注意三件事：这是厂商自测，上游是本地 mock，而且四家都关掉了日志、支出统计和持久化，测的只是转发开销，不含 token 成本。它的用途是横向比较，不是预测你的线上延迟。

一个比任何 benchmark 都值钱的教训

更有价值的是一份第三方复测。一位开发者在自己的共享 CPU 机器上用 Bifrost 官方开源的压力工具对比两个网关，过程中发现了一件与网关选型无关、但更致命的事：LiteLLM 的官方镜像没有设置 --num_workers，而 CLI 默认值是 1，也就是一个 Python 进程跑在四个核上。

改成 --num_workers 4 之后，500 RPS 下的 p50 从 20446 毫秒掉到 13.29 毫秒，成功率从 89.1% 回到 100%。一个 flag，三个数量级。如果那次对比只跑一遍，结论就会变成「LiteLLM 架构上撑不住」，而真实原因是默认配置。

顺带说一个结论，它决定了这件事你应该花多少精力：**在单轮聊天里，网关开销是噪声。**另一个用 k6 做的测试直接说明了这一点，换成真实 provider 后，5 个虚拟并发下两个网关的平均延迟是 923 毫秒和 908 毫秒，几乎分不出来，因为 900 毫秒的推理把网关那几毫秒的差距完全吃掉了；只有并发升到 10、20 之后曲线才开始分叉。

所以网关的几毫秒只有在两种场景里才真的重要：高频短请求（embedding、分类、护栏判断）和 Agent 循环。后者的关键不只是延迟，还有内存与 CPU 占用，因为它直接决定你要开几个 pod、每个 pod 离 OOM kill 有多近。

五、三个已经被踩过的坑

**第一，路由和 prompt 缓存会互相伤害。**缓存命中的输入 token 有折扣，而路由把请求在模型之间来回切，会让两边缓存都变冷。省下的牌价差有可能被丢掉的缓存折扣吃回去。工程上应该把粘性做进路由策略：同一会话、同一系统提示，尽量留在同一个模型上，把跨模型的切换留给那些确实需要升级的调用。

**第二，阈值必须用你自己的流量校准。**RouteLLM 官方文档说得很直白：有意义的阈值范围取决于路由器类型和你收到的查询类型，建议用真实流量样本标定，而不是照抄文档示例里的 0.11593 或 0.1881。阈值是一个运营参数，不是超参数，它会随着你的流量构成变化而漂移。

**第三，路由器最危险的失败模式是安静地降质。**它不会报错，只会给你一个稍差的答案，而且这类偏差往往只在多步任务里才暴露。离线 benchmark 帮不了你，你需要的是一条影子评估通道，把真实流量同时喂给两个模型做对比。LiteLLM 已经把这个做成了产品功能（Shadow Evaluations），思路可以借鉴到任何自建网关里。

六、分层落地：不要一上来就上语义路由

微软在那篇文章里给了一条很务实的落地路径，我基本认同，并且把它改写成了更适合中小团队的顺序。

只有托管模型加几个 Agent 的时候，你需要的只是治理层：统一认证、按 Agent 限流、成本归属。没有第二个模型可选，也就没有东西需要路由。

自建单一模型的时候，GPU 感知的副本选择有价值，语义路由依然不需要，因为只有一个模型。

只有当强模型和弱模型之间存在明显价差、并且容易的流量占比足够大的时候，语义路由才会回本。微软的措辞是「几乎任何跑在循环里的 Agent 都符合这个条件」，但前提是你真的能区分易解与难解。

具体到执行顺序，我会这样排：

**先量化。**按 Agent、按会话把调用次数、token 数和费用打点。没有这份数据，后面全是猜。
**再做显式降级。**把分类、抽取、是/否判断、日志摘要这些调用直接改成小模型。这一步不需要任何算法，通常也能拿走大部分收益。
**然后统一接入与故障转移。**多 provider、多密钥、自动切换，这是可用性问题而不是成本问题，但优先级更高。
**最后才考虑语义路由。**前提是价差够大、流量够多，并且你已经能持续评估质量。

关于自建还是托管，还有一个现实约束：语义层的托管形态已经出现，微软 Foundry 的 model router 就是 RouteLLM 语义层的托管版本；但 GPU 感知的副本选择目前没有托管选项，必须在集群内运行。对中小团队来说，这一层通常可以跳过，交给云厂商的推理服务去处理。

结语

Agent 的成本结构正在从「模型单价」变成「调用次数乘以每次调用选了什么模型」。前一个变量你几乎无法影响，后一个变量完全由你的架构决定。

路由层值钱的真正原因不是它省钱，而是它把一个原本散落在业务代码里的决策，变成了一个可以被观测、被评估、被回滚的组件。做不做语义路由可以晚点再定，但把调用打点和质量可评估这两件事做起来，越早越好。

毕竟，能被测量的成本才可能被优化，能被评估的质量才敢往下调。

参考来源

下一页 📊 GitHub 趋势日报 — 2026-09-25