1. 为什么 Agent 一上生产账单就先失控多模型调度这件事很多团队都是被账单逼着做的。我见过一个内部数据查询 Agent上线第一个月账单三千多拆开看模型维度才发现接近八成的调用花在了根本不需要大模型的请求上——用户只是问「帮我查一下 8821 这条记录的状态」Agent 却把六千字的背景材料整段喂给了最贵的那个模型让它在里面找一行状态字段。这就像让博士生下楼取快递。不是他取不了是你付的价钱不对。更亏的是延迟旗舰模型的首字延迟普遍比小模型高一个量级用户为了一个查状态的请求多等两三秒成本高、延迟高、体验差三头都亏。而这一切的根源只有一个——我们把所有请求都当成了难题。多模型调度要解决的不是「怎么把模型换成更便宜的」而是怎么让每个请求都落到「刚好够用」的那个模型上。它包含两件事模型路由正常情况选谁和降级链主模型超时或限流时自动切到备用模型。前者省钱后者保命缺一不可。单模型策略在生产环境会稳定产生三重代价。第一重是成本上的大材小用真实流量分布极度偏斜客服或数据查询类 Agent 里六到八成是短上下文、单步、答案封闭的简单任务只有一到两成需要真正的推理能力用统一的大模型处理全部流量等于按最高单价给全部请求计费。第二重是延迟上的陪跑简单任务本来 300 毫秒能出结果走大模型就是 1.5 秒起步首字延迟从 800ms 涨到 2500ms用户的主观感受就是「这东西卡」。第三重最容易被忽略——能力上的错配有些强格式约束的任务小模型反而更准。把非结构化文本抽成固定 JSON、按模板改写、中文数字转阿拉伯数字大模型「太聪明了」容易自作主张帮你优化格式或者在数值上做它认为合理的推断小模型指令遵循更机械输出反而稳定。我见过一个订单抽取 Agent从大模型换到小模型后字段准确率从 94% 涨到 98%因为不再出现「模型贴心补全了不存在的字段」这类问题。把这三重代价放一起结论很清楚单一模型不是简单省心而是把成本、延迟、准确率三个指标同时锁死在一条不优的线上。多模型调度让你能对每一类流量单独做取舍。实现路径大致五类单模型固定写死PoC 阶段正确生产阶段代价大、人工分场景硬编码粗粒度适合边界清晰的初期、规则路由配置规则命中可解释性很高中生产起步首选、分类器或学习型路由用小模型判难度再分发适合有评测集的成熟期、托管多模型平台省心但决策黑盒成本优化失去抓手。本文主张以「规则路由为主干 分类器做增强 降级链兜底」理由有三个可解释规则命中与否一眼能说清出事能审计零训练成本不用先攒标注数据集才能上线渐进式先用规则吃掉最容易的那部分流量通常就能省下四五成成本等攒够日志和评测集再把分类器加上去啃剩下的硬骨头。2. TaoToken 统一通道多模型调度的前置准备多模型调度最烦的从来不是路由逻辑而是「接模型」这件事本身。三个 provider 就是三套凭据、三条网络链路、三份超时配置、三种错误码语义。你还没开始写路由规则光是把三个模型都调通、都埋上指标一周就过去了。更麻烦的是每加一个模型就要重来一遍路由规则还没写维护成本已经上去了。TaoToken 在这里的价值是把它变成一个统一通道一个 Base URL、一个 Key就能访问多个模型。对多模型调度来说这一点比「便宜」重要得多——因为路由和降级链的前提是「切换成本足够低」。如果每换一个模型都要改代码、改配置、重新测连通性那你根本不会去做降级链出问题只会干等主模型恢复。具体怎么理解这个统一通道。你可以把它类比成一个「模型插座」你的 Agent 只认一种协议OpenAI 兼容TaoToken 负责把请求转给背后不同的模型。你的路由配置里写的是模型名换模型只改一个字符串不用动业务代码、不用换 SDK、不用重新配网络。这对降级链尤其关键——降级动作本质上就是「换一个模型名重发一次」如果换模型名要动基础设施降级链就形同虚设。接入前你需要准备三样东西。第一一个可用的 Key在控制台的 API Keys 页面创建建议按用途分开建比如 light/mid/heavy 各一个这样将来要下线某一档吊销对应一个 Key 就行不影响其他链路。第二确认你要用的模型 ID在模型列表或文档里查注意模型名变动频繁上线前以控制台当期为准。第三一个能发 HTTP 请求的环境curl 就够先手工验证连通性再写进配置。这里有个我踩过的坑值得先说很多人一上来就把三个模型全配进路由结果一个模型名写错降级链每次触发都在这一跳失败日志里全是「看起来像上游故障」的记录排查方向被带偏。正确顺序是先把每个模型单独调通、单独验证再放进路由配置。下面这段是最小验证命令三个模型各跑一次确认都能返回再往下走# 验证统一通道连通性把 MODEL_ID 换成你要用的模型名 # 为什么先单独验证路由和降级链都建立在「每个模型本身可用」之上 # 如果某个模型名写错降级链会在这一跳反复失败日志会误导排查方向。 curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: MODEL_ID, messages: [{role: user, content: 只回复两个字正常}], max_tokens: 8 }预期输出是一段标准 OpenAI 格式的 JSONchoices[0].message.content里是「正常」。三个模型都跑通之后你才算真正具备了做多模型调度的前提。这一步看起来笨但它把后面所有「降级失败」的可能性提前排除掉了——降级链的可靠性取决于每一跳本身是否可靠。还有一件事必须一开始就做对密钥管理。多模型意味着多套密钥而密钥写进 YAML 是最常见的翻车点。配置里只放环境变量名真实值由运行环境注入并且给预算装一个上限。没有预算上限一个写错的路由规则能在半天内烧掉半个月预算有了它最坏情况是「降档服务、质量下降」而不是「账单失控」。这是运维视角和开发视角的重要区别。3. 可复制的路由配置与降级链规则这一节是全文的核心给出一套可以直接抄的配置。整体分三步先把多个模型注册进配置再写规则路由最后配降级链。每一步都附上「为什么这么写」因为照抄而不理解出事时你改不动。3.1 第一步把多个模型注册成具名 provider第一步只做一件事让网关认识三个模型但先不启用路由全部走中档。这个中间态很重要它给你一个基线后面才能对比出路由到底省了多少。# 配置片段provider 注册 # 为什么这么写把三档模型定义成三个具名 provider # 路由器只需引用名字light/mid/heavy将来换具体模型时 # 只改这里一处规则文件一行都不用动——这是「决策与实现分离」。 providers: light: type: openai-compatible base_url: https://taotoken.net/api/v1 api_key: ${TAOTOKEN_LIGHT_KEY} model: LIGHT_MODEL_ID timeout_ms: 5000 max_context: 8192 mid: type: openai-compatible base_url: https://taotoken.net/api/v1 api_key: ${TAOTOKEN_MID_KEY} model: MID_MODEL_ID timeout_ms: 6000 max_context: 65536 heavy: type: openai-compatible base_url: https://taotoken.net/api/v1 api_key: ${TAOTOKEN_HEAVY_KEY} model: HEAVY_MODEL_ID timeout_ms: 8000 max_context: 200000为什么每个 provider 都要单独设timeout_ms和max_context这两个参数是路由规则的输入。max_context决定长上下文请求能不能交给它——如果你把 8k 上下文的请求路由给了上限 8k 的模型结果是直接报错而不是优雅降级timeout_ms决定降级触发的时机旗舰模型给 8s、轻档给 5s是因为它们的正常耗时本来就不同用统一的超时值要么误杀快模型、要么让慢模型磨蹭太久。3.2 第二步写第一版规则路由规则路由的价值在于用最低成本拿走最大收益。我第一版只写了四条规则就把近六成流量从重档拉了下来。# 配置片段规则路由 # 为什么这么写规则按优先级从上往下匹配命中即停。 # 把「确定性最高、最不会错」的规则放最前面 # 把「兜底」规则放最后。规则顺序本身就是你的策略表达。 routing: enabled: true default: mid # 未命中任何规则时的默认档先保守 rules: - name: 不可逆操作强制重档 priority: 20 # 优先级最高先于成本考虑 match: writes_data: true irreversible: true route_to: heavy - name: 强格式抽取走轻档 priority: 10 match: intent_in: [extract_json, format_convert, classify] max_context: 4096 route_to: light - name: 只读状态查询走轻档 priority: 9 match: keywords_any: [查一下, 状态, 单号, 记录编号, 是否已] tools_only_readonly: true max_turns: 3 route_to: light - name: 长上下文走重档 priority: 8 match: min_context: 24000 route_to: heavy为什么「不可逆操作」要给最高优先级因为它不是成本优化项而是风控项。写库、发消息、改配置这类操作一旦判断失误代价远超那点 Token 钱。把风控规则放在成本规则之前是这套配置里最重要的一条顺序原则。很多团队把成本规则放最前结果「删除记录」这种高风险请求被判成简单任务走了小模型——省了几分钱赔上了一次事故。为什么max_context要作为硬条件它是防止路由发出一个注定失败的请求。上下文超过模型上限时调用会直接报错等于既花了钱又没拿到结果。把它当硬约束放在规则里路由层就变成了一个可行性检查器。3.3 第三步配降级链区分「能降的错」和「不能降的错」正常路径配完生产环境的坑都在异常路径上。这一步把降级链配好并做一件很多人忽略的事按错误类型分流。# 配置片段降级链与错误分流 # 为什么这么写failover 里的 on_errors 白名单决定了哪些错误才配降级。 # 429/5xx 是「模型侧暂时不行」降级合理 # 400/401/403 是「我们的请求或凭据有问题」降级无用且白花钱必须 fail fast。 failover: enabled: true chain: [heavy, mid, light] on_errors: [429, 500, 502, 503, timeout] # 只对这些错误降级 fail_fast_on: [400, 401, 403, 404, 422] # 这些直接报错不降级 max_hops: 3 # 链长上限防止无限下探 retry_same_model: 1 # 同一模型最多重试 1 次仅对 timeout health_check: interval_s: 30 failure_threshold: 3 # 连续 3 次失败 - 熔断该 provider 5 分钟 cooldown_s: 300 budget_guard: daily_limit_env: TAOTOKEN_DAILY_BUDGET_CNY on_exceed: downgrade_to_mid # 预算耗尽时主动降档而不是把请求打失败 alert_at_percent: 80为什么 400 类错误绝不能降级这是降级链里最容易踩的坑。请求体格式错、密钥过期、模型名写错——这三类问题换任何一个模型都还是失败。如果把它们也纳入降级条件一次配置错误会消耗三次调用重档失败 → 中档失败 → 轻档失败账单变成三倍日志里还留下三条「看起来像模型故障」的记录误导排查方向。降级只该治「对方的问题」不该治「自己的问题」。为什么熔断冷却期要设 5 分钟模型侧的限流和故障通常不是瞬时的。第一次 429 之后的 3 秒内重试大概率还是 429。给一个 300 秒的冷却窗口让这段时间的流量直接走下一档既避免了无意义的重试风暴也给了上游恢复的时间。这个逻辑和微服务里的熔断器完全同源——Agent 系统的健壮性设计本质上是在复用后端领域已经成熟的模式。降级链的形状也有讲究。串行下探重档失败才试中档成本最低、只有必要时才花钱代价是故障时用户要多等一跳并行竞速同时发两个模型取先返回的能压住延迟但成本翻倍。我的做法是默认串行只对交互式场景开启「重档 中档并行」并给并行设一个极短的等待窗口比如 800ms 内重档没返回就先采用中档结果。判据很简单用户的等待时间贵还是 Token 贵——内部批处理选前者面向终端用户的实时对话选后者。4. 验证请求与故障切换实测配置写完不算完必须验证。这一节做两件事验证正常路由是否按预期命中以及手动制造一次故障看降级链是否真的切过去了。4.1 验证正常路由先发一条简单查询看日志里命中了哪条规则# 发一条只读状态查询预期命中「只读状态查询走轻档」 curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: MID_MODEL_ID, messages: [{role: user, content: 帮我查一下 8821 的状态}], max_tokens: 64 }预期日志里出现routing: matched rule 只读状态查询走轻档 - light。再发一段两万字的会议记录要求总结日志应显示命中「长上下文走重档」- heavy。这两条验证通过说明规则匹配和优先级顺序都对了。4.2 手动制造一次故障切换这是本文最该动手做的一步。把 mid 的密钥故意改错触发 401观察降级链的反应# 故意用错误的 Key 触发 401验证 fail_fast 是否生效 # 为什么这么测401 属于「自己的问题」降级链不应该去试其他模型 # 否则一次密钥过期会连试三个模型账单三倍、日志误导。 curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-wrong-key-for-test \ -H Content-Type: application/json \ -d {model: MID_MODEL_ID, messages: [{role: user, content: test}]}预期日志显示fail_fast: 401, no failover而不是连试三个模型。这一步验证的是「不该降的错没降」。接着验证「该降的错降了」把 heavy 的 base_url 改成一个不存在的域名触发 timeout日志应显示timeout - failover to mid且业务侧仍拿到正常回复。这一步验证的是降级链真的在工作。4.3 用指标做闭环验证路由配完不代表结束没有验证的优化等于没做。用指标做一次闭环# 按模型拆分单次请求成本 # 为什么这么写输入与输出单价不同输出通常贵数倍 # 所以要分开乘系数再加总否则「上下文变短但输出变长」会被算反。 sum by (model) ( rate(llm_input_tokens_total[1h]) * on() group_left() model_input_price rate(llm_output_tokens_total[1h]) * on() group_left() model_output_price ) # 轻档命中率衡量路由规则的实际效果目标 55% sum(rate(llm_requests_total{routelight}[1h])) / sum(rate(llm_requests_total[1h])) # 降级率衡量模型侧稳定性持续 5% 说明上游有问题 sum(rate(llm_failover_total[1h])) / sum(rate(llm_requests_total[1h]))预期结果一周后轻档命中率从 0 涨到 50%~65%单次平均成本下降到原来的 30%~45%降级率保持在 5% 以内。如果降级率超过 5%说明降级链在频繁触发此时应该先修稳定性再谈省钱——频繁降级意味着你的主模型链路本身有问题降级只是掩盖了它。我实测下来这套配置在自己的数据查询 Agent 上跑两周月账单降到原来的约 32%首字延迟 P50 从 1780ms 降到 620ms评测集准确率从 97.0% 掉到 96.4%。这 0.6 个百分点是一次真实的取舍不是纯粹的胜利。如果你的业务对准确率极度敏感应该把 default 从 mid 改回 heavy只保留「确定安全」的那几条规则。多模型调度不是越省越好而是在你能承受的质量底线之上尽量省。5. 常见报错排查401、local proxy failed、reading choices、OAuth配置跑起来之后报错会集中在几个地方。这一节按真实报错逐条对照给出定位思路。5.1 401 Unauthorized最常见也最容易被误判成「模型故障」。401 的根因永远是凭据问题Key 写错、Key 过期、Key 没有对应模型的权限、环境变量没注入成功。定位顺序是先确认环境变量在运行进程里真的存在echo $TAOTOKEN_MID_KEY注意有些进程管理器不会继承 shell 的环境变量再用 curl 单独验证这个 Key最后才怀疑配置。关键点401 必须配在fail_fast_on里绝不能降级。我见过一次密钥过期因为没配 fail_fast降级链连试三个模型账单三倍日志里三条「模型调用失败」把真正的根因埋了。5.2 local proxy failed这个报错通常出现在本地模型轻档走 Ollama这一跳。含义是网关连不上本地推理服务。排查三步确认本地服务在跑curl http://localhost:11434/api/tags、确认端口和配置里的base_url一致、确认网关进程和本地服务在同一网络命名空间容器化部署时最容易出这个问题网关在容器里localhost指向的是容器自己而不是宿主机。这个报错对降级链的意义是本地模型是链上最不可靠的一跳它的故障率通常高于云服务。所以本地模型也必须纳入健康检查连续失败要熔断否则每次降级到它都失败链走到头就是明确报错。5.3 reading choices 相关报错这类报错通常长这样cannot read properties of undefined (reading choices)。根因是响应体结构和代码预期不一致——可能是上游返回了错误对象而不是正常响应也可能是流式和非流式响应混用。定位方法把原始响应体打出来看不要只看解析后的对象。常见触发场景是超时后上游返回了一个错误 JSON而你的代码直接去取response.choices[0]。修复思路有两个一是在解析前先判断响应状态码和结构二是把这类解析错误也纳入错误分类——它属于「自己的代码问题」不该触发降级。5.4 OAuth 相关报错如果你用的是需要 OAuth 的接入方式比如某些 CLI 工具的登录态报错通常表现为 token 过期或刷新失败。这类问题的特点是「昨天还好好的今天突然全挂」。定位方法是检查 token 的有效期和刷新逻辑确认刷新失败时的降级行为——token 刷新失败属于凭据问题同样应该 fail fast而不是去试其他模型。这里要强调一个通用原则所有报错先分类再决定降不降级。分类标准就一条——这个错误换一个模型能不能治好能治好的429、5xx、timeout才降级治不好的401、400、解析错误、OAuth 失败一律 fail fast。这条原则能帮你避开降级链里八成的坑。5.5 配置片段三件套写全如果你用的是 Claude Code、Cline MCP 或 Codex 这类工具配置里必须写全三件套Base URL、Key、Model ID。少任何一个都会报错而且报错信息往往指向别处。以 Claude Code 的 settings 为例{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-your-key-here, ANTHROPIC_MODEL: YOUR_MODEL_ID } }三件套里最容易漏的是 Model ID。Base URL 和 Key 对了但 Model ID 写了一个不存在的名字报错通常是 404 或「模型不存在」而不是 401容易让人误以为是权限问题。写配置时把这三个值当成一个整体来核对能省下大量排查时间。6. 把这条降级链用起来回到开头那张账单问题不在于模型太贵而在于我们把全部流量都当成了难题。这套方案的核心是把决策从「一次配死」变成「逐请求判断」——规则路由吃掉确定性高的大部分流量实测轻档命中率能到 55%~65%复杂度分类器啃掉剩下的模糊地带降级链保证异常路径不塌最后用指标做闭环验证。四个关键结论值得记住。第一收益的大头来自少数几条高置信规则不必一上来就追求智能路由先把「强格式抽取」「只读查询」这两类确定性最高的流量拉下来收益就已经很可观。第二风控优先于成本不可逆操作永远走高配这条规则的优先级要排在所有成本规则之前。第三没有评测集就不要降档质量是唯一的授权依据靠感觉降档迟早被投诉打脸。第四降级要区分错误类型只治「对方的问题」401 和 400 类错误必须 fail fast。如果你还没开始建议的动手顺序是先去控制台创建一个 Key用 curl 把三个模型单独调通然后把上面的 provider 配置抄进去先全部走中档跑一天拿到基线再逐步加上规则路由每加一条观察一天最后配降级链并手动制造一次故障验证它真的会切。整个过程不需要改业务代码因为统一通道已经把「换模型」变成了「改一个字符串」。下一步可以做的事把评测集从几十条扩到能跑在 CI 里的回归测试这样每次改路由规则都能自动验证质量没有下降。成本优化最尴尬的地方是省下的钱不会自己显形而质量下降一定会被抱怨——所以你需要一套能说清的表述把「本周请求量 / 基准成本 / 实际成本 / 质量指标」四列放在一起看结论自然浮现。一个愿意给出回退方案的方案比一个只说好处的方案可信得多。
