最近在搞一个内部工具我把原本写死在业务代码里的模型调用全部收到一个统一入口后面用一套配置文件把 Coding Plan、Kimi、GLM 按请求场景分发到不同模型上。整个过程业务代码一行没改只是改配置、reload路由就生效了。有朋友问这样值不值我的结论是非常值尤其当产品已经过了 demo 阶段开始认真算 token 成本的时候模型路由几乎是成本优化的第一课。所谓模型路由就是让每个请求先经过一个“分诊台”按规则判断这段请求适合哪个模型处理再转给对应模型。它解决的是单模型打天下的两个痛点一是贵二是“不专”。适合谁呢正在用单一模型做线上业务、被账单吓到过、又不想每次切换模型都要改代码发版的人。这篇我就把零代码配置的思路、规则设计、实操配置和踩过的坑完整捋一遍。1. 为什么需要模型路由单模型看似省事实际很费钱1.1 单一模型的隐性成本很多人一开始都图省事所有请求打在同一个模型上逻辑最简单出问题也好排查。但当请求量上来之后问题就藏不住了。我做过一个模拟项目X某客服助手每天大概 10 万次请求。最开始用的同一个强模型功能没问题但账单很疼。后来我拉了一次请求日志发现 60% 以上是“退款流程怎么走”“营业时间是什么”“发票抬头怎么填”这类固定问答它们根本不需要很强的推理能力。真正需要硬核推理的可能不到 15%。把高配模型用在低难度任务上就像让大厨天天负责切葱花不是不行是太浪费。token 费用是实打实的输入量越大浪费越多。而且单一模型还有连锁问题模型限流或故障时你没有任何备胎业务直接断。所有请求都走同一个上下文策略遇到超长文档只能硬着头皮截断。不同模型各有擅长领域强迫一个模型什么都干结果就是什么都“一般”。模型路由不是炫技不是为了混而混而是让每类请求都有对应的最优解。低成本只是结果真正的收益是该花的钱花不该花的一分不花。1.2 不同模型/套餐的“性格”差异在配置路由之前得先搞清楚手头的模型各擅长什么。我这里用到的三款是 Coding Plan、Kimi、GLM它们并不完全重合。模型/套餐定位适合路由到的场景需要注意的点Coding Plan编程增强套餐代码生成、Bug 分析、重构建议、SQL 编写对上下文里的代码格式敏感输出可能偏“话痨”要控制 max_tokensKimi长上下文文本理解长文档总结、PDF 分析、长篇阅读、多轮长对话上下文窗口长但超长输入会拉高延迟超时要给足GLM综合问答与工具调用日常对话、结构化输出、工具调用、通用业务逻辑兼容性比较好适合当默认模型兜底这个表是我实际使用的经验判断不是官方定位。而且模型版本更新很快今天适合 Router 的明天未必适合所以路由规则要保持可调整。这也是为什么我特别强调“零代码配置”规则不写死在代码里哪天发现某个模型变强了改配置就能切。2. 零代码不等于没有规则而是把规则从代码里挪到配置层2.1 模型路由的几种玩法做模型路由大体有四条路在业务代码里写一个 Router 类每次请求前判断走哪个模型。问题很明显改规则要发版每个接入方都要重复造轮子。在框架中间件里做拦截。可以但绑定语言换语言全重来。独立网关统一出口。业务侧只调一个固定 API路由规则全部在网关侧维护改规则就是改配置文件。利用模型厂商的多模型接口。部分平台自带路由能力但规则通常比较粗。我推荐第三种思路也是标题里“零代码配置”的核心业务代码只对接一个入口路由决策完全下沉到网关层。业务方的工作量从“写一段切换逻辑”变成“改一行 base_url 配置”。2.2 为什么先从规则路由入手模型路由再往下分有三类实现固定规则路由根据关键词、正则、请求来源、上下文长度、用户标签等条件做分发。语义路由把请求文本做向量化算相似度把相近意图归到指定模型。分类器路由用小模型或标注数据判断请求属于哪个场景再决定目标模型。零代码起步阶段我的建议是先做固定规则路由。原因很直白规则路由命中原因可解释排查故障时能直接说出“为什么走这个模型”而语义路由是个黑盒它觉得像就像出了问题很难给老板讲清楚。语义路由固然能处理长尾意图但你需要先有足够的日志和数据否则就是盲调。用生活类比来说规则路由就像前台按你手里的单据分流办存款的去柜台A办贷款的去柜台B。语义路由则是让前台看一眼你的表情判断你情绪不好估计是来投诉的。后者更智能但前台培训成本高而且会误判。先做简单的数据多了再升级是成本最优的路径。2.3 配置文件里到底放什么零代码配置本质上是把路由逻辑抽象成三类数据模型池每个模型的基础信息比如 provider、模型名、超时时间、最大输出 token 数。路由规则按优先级排列的匹配条件与目标模型。治理策略fallback、重试、熔断、成本预算、审计日志。这三块全都写在 YAML 配置文件里业务代码不感知。后续所有调整都只动配置读完配置就生效。接下来的章节我会逐个拆解。3. 路由规则设计怎么判断一段请求该走哪个模型3.1 先定义你的路由维度路由规则不是随便拍脑袋写的而是先想清楚用什么维度来切流量。我常用的维度有五个请求来源哪个业务方、哪个应用调进来的。Prompt 关键词 / 正则标题、内容里是否包含某个主题词。估算 token 数输入长度超过多少走长文本模型。用户标签 / 付费等级高级用户走更强模型内部测试走便宜的。需求意图借助分类器打上“代码”“文档”“闲聊”等标签。实际配置时我很少只用一个维度通常是组合判断。比如“请求来源是代码助手应用 关键词包含报错信息”走 Coding Plan“输入超过 8000 token 关键词包含总结/摘要”走 Kimi“其他所有情况”走 GLM。组合维度更稳不会因为某一个词出现在奇怪的上下文里就误判。3.2 配置示例一个最基础的三模型路由下面这段是我在模拟项目X里用过的简化版路由规则完全可以作为起点模板route: default: glm_chat fallback: glm_chat rules: - name: coding_task match: prompt_contains: - 写代码 - debug - bug - 重构 - SQL - 正则表达式 target: coding_plan - name: long_doc_task match: est_tokens: gt: 8000 prompt_contains: - 总结 - 摘要 - 长文档 - 合同 - 论文 target: kimi_long - name: default_chat match: pass: true target: glm_chat逐行解释一下default是兜底目标。所有规则都没命中时走它。我把它设成 GLM因为 GLM 综合能力强、价格适中适合当默认值。fallback是异常降级目标。目标模型报错、超时或限流时请求会转给我们指定的模型避免业务死掉。rules是规则数组按顺序从上到下匹配命中即停不再往下执行。所以顺序很重要越具体的规则越要放前面。prompt_contains做的是子串匹配简单粗暴但有效。实际生产环境建议再加一层正则例如把 “修复一段 JS 的报错” 中的 “JS” 也识别出来。est_tokens是网关侧对输入文本做的粗略 token 估算。8000 这个阈值不是拍脑袋我是按业务平均请求长度和长文本模型的性价比交点算出来的。如果你的业务以短问答为主阈值可以降到 4000如果到处都是长文档再往上调。这里有一个非常容易踩的坑default一定要写而且最好写“够用且便宜”的模型而不是“最强”的模型。很多人觉得反正都兜底了那就兜到最强模型上结果所有未命中的未知请求全打到高配月底账单教你做人。未知请求优先级最低花最少的钱才是合理的。3.3 组合判断避免误判的细节只用关键词最大的问题是误判。比如一句话 “我想总结一下代码里的 bug”同时包含“总结”和“bug”按上面的顺序会命中 coding_task走到 Coding Plan但如果用户真正想要的是“代码 bug 的总结报告”这个路由又没错。怕就怕用户说的是“帮我总结这份代码的功能”结果因为带了一个“代码”就进了编程模型。解决思路是为每条规则增加必要的上下文条件。比如 coding_task 可以要求prompt_contains里的关键词至少命中 2 个或者配合请求来源维度。YAML 里可以加一个match_any或min_hits的配置不同网关叫法不同思路是一样的- name: coding_task_strict match: min_hits: 2 prompt_contains: - 写代码 - debug - bug - 重构这个min_hits: 2的意思是下面关键词至少命中两个才认为它是代码任务。可以显著降低“单关键词误触发”的情况。配置成多关键词命中之后路由精度会提高不少代价是一部分弱相关的代码请求会漏到默认模型。所以 min_hits 到底设 1 还是 2要结合你的业务容错能力来定不能照搬。4. 实操配置一套低成本混合路由并验证效果4.1 模型池与全局参数配置路由规则只是骨架真正撑起稳定性的是模型池和治理策略。我放出整套配置的骨架这个可以直接抄到自己的环境里改成实际值server: port: 8080 reload_interval: 30s providers: glm_provider: base_url: ${GLM_BASE_URL} api_key: ${GLM_API_KEY} kimi_provider: base_url: ${KIMI_BASE_URL} api_key: ${KIMI_API_KEY} coding_provider: base_url: ${CODING_BASE_URL} api_key: ${CODING_API_KEY} models: glm_chat: provider: glm_provider model_name: glm-chat timeout: 30s max_tokens: 2048 temperature: 0.7 kimi_long: provider: kimi_provider model_name: kimi-long timeout: 60s max_tokens: 8192 temperature: 0.3 coding_plan: provider: coding_provider model_name: coding-plan-v1 timeout: 60s max_tokens: 4096 temperature: 0.2有一点要提醒timeout一定要按模型差异分开设。长文本模型处理十几万 token 的输入30 秒内根本没可能返回而普通问答模型如果你给它 60 秒超时一遇到模型异常请求就要傻等一分钟用户早跑了。我自己的习惯是普通模型 20 到 30 秒长文本和编程模型 60 秒起步同时配合重试策略。另外api_key一定要用环境变量引用千万别把 key 写到配置里提交到仓库。这是个很低级但很多人犯过的错误。配置里的模型名和参数只是示意接入时以对应平台实际提供的模型标识为准。4.2 预算、限额与审计钱要花得明明白白零代码路由不只是把流量分出去就完事还得有能力控制成本。我在配置里加了三项你可以直接参考cost_limit: monthly_budget_usd: 300 daily_limit_usd: 15 model_limits: coding_plan: max_daily_usd: 5 kimi_long: max_daily_usd: 5 glm_chat: max_daily_usd: 8 audit: enabled: true log_field: [route_reason, target_model, latency_ms, prompt_tokens, completion_tokens, estimated_cost] request_tag: true先说monthly_budget和daily_limit。这是保命项防止某天模型异常把预算打穿。模型级限额更有针对性比如 Coding Plan 套餐按 token 计价偏高我给它单独设一个每日 5 美元的封顶超了就自动降级到 GLM而不是直接报错。再说审计日志。这是路由调优的灵魂我强烈建议把route_reason记录到每条请求的日志里。这样出现问题你能直接看到“这个请求为什么被路由到了 Kimi”是关键词命中了还是长度阈值触发了还是走了 default。没有这些日志你调规则就是在瞎猜。生产上不要记录 prompt 原文涉及用户隐私只记录必要的元数据就够了。request_tag: true是让接入方在请求头带一个项目标识方便月底做成本分摊。多个业务共用同一个网关的时候没有 tag 你根本说不清这笔钱是哪个项目烧的。4.3 成本对比一个模拟场景的计算过程说个小场景还是上面那个模拟项目X客服助手。日均 10 万次请求平均每次输入约 1500 token输出 300 token。先算出每天的总 token 量输入100000 次 × 1500 token 150,000,000 token也就是 150M token输出100000 次 × 300 token 30,000,000 token也就是 30M token如果全部用同一个强模型假设输入单价 6 元/百万 token、输出单价 18 元/百万 token那么输入成本 150 × 6 900 元输出成本 30 × 18 540 元单日总成本 1440 元切换路由后我用的是前面那套 60/25/15 的比例假设60% 的普通请求走 GLM假设输入单价 1.5 元/百万 token、输出单价 4.5 元/百万 token25% 的长文本请求走 Kimi假设输入单价 2.5 元/百万 token、输出单价 6 元/百万 token15% 的编码请求走 Coding Plan假设输入单价 3 元/百万 token、输出单价 9 元/百万 token单日成本变成大约模型输入token量输出token量输入费用输出费用GLM90M18M135元81元Kimi37.5M7.5M93.75元45元Coding Plan22.5M4.5M67.5元40.5元合计150M30M296.25元166.5元总额约 462.75 元相比原来的 1440 元降幅大概在 68% 左右。这个数字看起来很夸张但前提是我把强模型价格设得比较高、且普通场景占比够大。不同平台的定价和模型能力差异很大你的数字可能完全不同。我真正想让你看的是这个计算思路先统计请求分布再对比各模型单价就能算出路由的大致收益再决定值不值得做。4.4 灰度上线的四步走配置写完别急着全量切我的习惯是分四步第一步影子模式。流量照旧打到现有模型但网关同时记录“如果走新规则会路由到哪个模型”。跑三到五天对比虚拟路由结果和线上真实结果看差异多大。第二步切 5% 到 10% 的流量观察错误率和 P95 延迟。这个阶段重点关注路由命中率、目标模型是否频繁报错、有没有超时。第三步逐步扩大到 50%对照前一天的延迟和成本曲线确认没有异常。第四步全量切换。但保留旧配置随时准备 rollback。零代码的好处在这里体现得很明显rollback 就是把旧配置重新加载一下不需要回滚代码。5. 常见问题与排查技巧实录5.1 路由总是“不听话”老往默认模型跑这是最常见的问题明明写了代码关键词请求却走了 GLM 默认。我排查下来基本都是这几种原因规则写错了优先级把default规则放在最前面后面匹配规则还没轮到就终止了。规则匹配是从上到下、命中即停优先级全部藏在顺序里。关键词没覆盖用户的真实表达用户习惯说“帮我看看这段代码哪里有问题”而不是“debug”。这种场景要么加更多同义词要么上正则。min_hits设得太严要求命中 2 个关键词但用户只提了一次“代码”。排查方法就是看日志里的route_reason它能明确告诉你这个请求是因为哪条规则或者说哪个默认兜底被选中的。只要原因可见修复通常一分钟内能完成。5.2 超时重试配置不当反而放大了故障我在早期犯过一个错误所有模型统一设 30 秒超时重试次数设 3。结果某个模型故障时一次请求变成四次调用流量放大四倍直接把模型打挂。正确做法是重试次数通常设 1 次最多 2 次并且要加上指数退避和随机抖动。没有抖动所有超时的请求会在同一秒全部重试等于自己给自己制造流量峰。fallback 目标不要设成最强模型。模型故障时你也希望控制成本fallback 到够用且便宜的那个更合理。有条件的可以加熔断连续 N 次失败就短路不再把请求发到故障模型。5.3 模型参数不一致导致输出行为“玄幻”同一段 prompt从 GLM 切到 Kimi 后输出风格忽然变了。很多人第一反应是“模型能力不行、幻觉了”但很多时候只是参数不一致temperature 从 0.7 变成了 0.3top_p 不同输出长度变了。更隐蔽的是工具调用格式差异。不同模型的 function calling 格式不是完全兼容的结构化的 JSON 里字段名可能不同。如果你要让模型输出严格 JSON不要在 system prompt 里只写一句“输出JSON”而是要给出明确的示例格式并针对不同模型做一层适配。零代码路由解决的是“分发”问题但模型之间的格式差异不是配置一把梭就能解决的需要在接入层做好这层兼容。5.4 上下文窗口估算不准导致长文本被截断中文场景特别容易踩这个坑。不要用字符串长度判断一个汉字在部分 tokenizer 里等于 1 到 2 个 token而且不同模型的 tokenizer 不完全一致。正确的做法是路由前先做一次估算可以用目标模型对应的 tokenizer 库也可以用网关内置的估算器至少保证估算误差在一个量级内。长文本走 Kimi 没问题但你要明白“能处理超长文本”不等于“所有模型都能处理超长文本”。如果一条很长的问题被规则切到了默认模型而默认模型窗口不够它会在入口就拒绝或截断导致输出质量崩掉。所以路由规则里必须有一条长度上限判断超过安全线要么走长文本模型要么提示用户分段处理。5.5 预算没设好账单失控模型路由上线后如果某个规则误命中了大量高价模型又没有模型级限额月底账单会非常难看。我见过一个团队把“长文档”规则写得过于宽泛结果四成请求全走了长文本模型预算翻了三倍。防呆手段就是我在 4.2 节写的model_limits以及日志里的estimated_cost。建议每周看一次各模型的调用占比和成本分布如果发现某个模型费用占比异常说明规则要调整了。5.6 一张避坑速查表问题一句话避坑要点规则总走默认模型检查优先级顺序和关键词覆盖看 route_reason 日志模型故障后流量放大重试次数不超过 2加指数退避和抖动fallback 到便宜模型输出格式变了检查 temperature/top_p确认 function calling 兼容性长文本被截断用 tokenizer 估算规则里设置长度安全线成本失控设置模型级每日限额按 tag 做成本归集上线不敢收敛影子模式先行灰度流量到 10% 再放大关键词误触发用 min_hits 多关键词命中减少单词判断最后分享一点个人经验模型路由入门不难难的是持续调优。不要一上来就搞一堆规则先挑两个最典型的场景写进配置跑一两周看日志再往里加。规则是越迭代越准确的不是一次设计出来的。我一般从三条规则起步编程任务、长文档任务、默认问答跑一段时间后再根据日志拆出更细的意图。另外配置里永远要给default和fallback留活路。我见过很多线上事故都是因为他漏写了 fallback目标模型一挂所有请求全部报错。一句话路由可以先粗但兜底绝对不能少。