多模型路由规则设计实战：第一版系统别做成黑盒

第一版多模型路由，最容易犯的错不是规则太少，而是规则写得太像"聪明系统"。条件很多，评分很细，线上一抖就没人能解释结果。对工程团队来说，这种方案上线很痛苦，因为它看上去高级，排障时却不友好。

我的建议是先做一版能读懂、能回放、能切换的路由。

第一版先保证什么

目标	作用
可解释	出了问题知道系统为什么这么选
可回放	事后能复盘命中条件和切换过程
可切换	主模型波动时，备用链路能真实顶上

先定字段

路由规则至少把几个关键输入固定下来：

task_type：任务类型，比如 rewrite、qa、document_understanding
token_size：输入规模，大文本和短文本别混跑
latency_budget_ms：时延预算，实时链路和离线链路分开
cost_ceiling：成本上限，避免轻任务误打高价模型
risk_level：风险等级，决定是否强制主备
fallback_policy：超时切换、限流切换还是禁用切换

这些字段不是为了把配置表做漂亮，而是为了让每一次命中都有依据。

可参考的规则

yaml 复制代码

routes:
  - name: doc_parse_v1
    when:
      task_type: document_understanding
      token_size_gte: 12000
      risk_level: high
    primary_model: claude
    fallback_model: gpt
    latency_budget_ms: 12000

  - name: rewrite_batch_v1
    when:
      task_type: rewrite
      token_size_lt: 4000
      cost_ceiling_lte: 0.02
    primary_model: gemini
    fallback_model: gpt
    latency_budget_ms: 3000

这里的重点不在于模型名字，而在于规则表达的是业务取舍。

规则	业务含义
`doc_parse_v1`	高风险长文本，宁可慢一点，也别乱切
`rewrite_batch_v1`	高频轻任务，优先控成本，但要保留切换余地

上线前一定要演练三件事

主模型超时后，fallback 是否真的会触发。
供应商限流时，切换是否会把业务参数一起带过去。
失败后日志里能不能完整看到 request_id、命中规则、实际模型和切换原因。

很多团队的 fallback 配置写得很完整，真正出故障时才发现参数不兼容，或者备用模型根本没在那类任务上压测过。

观测面比评分器更重要

第一版先盯四个指标就够了：

成功率
P95 时延
单次成本
fallback 触发率

只要这四项能稳定回看，规则就能慢慢长出来。日志口径没对齐时，动态路由只会把问题藏得更深。

统一接入其实是多模型路由能不能跑稳的底座。像 147api 这样的服务，更适合放在路由层前面，先把协议、鉴权、参数和报错口径收成一套。这样规则层就能专心处理任务判断和 fallback，而不用在业务代码里反复补兼容。出了问题，也能顺着统一日志更快看清到底是路由没配好，还是模型本身在波动。

最后一句

第一版系统不用追求聪明，先追求能解释。能解释，才好调；好调，才可能越跑越准。