上个月看到账单的时候我整个人是懵的。调用次数只比上上个月涨了 12%费用却翻了将近一倍。一开始我以为是模型厂商在悄悄调价拉出明细一看才发现问题根本不在单价而在于所有请求无差别地打向了同一个高配模型简单分类、短问题问答、长文档总结、复杂推理全挤在同一条路上。也是从那次对账开始我才真正意识到AI 调用成本要做模型路由的系统性分流而不是永远一刀切“上最好的”。我把这套方案沉淀成了星链4SAPI一个跑在业务和模型之间的路由网关。稳定运行一个月后AI 调用成本省下了 30%用户侧效果评分没有任何回退部分场景的响应延迟反而更低。这篇文章想完整记录一下实战过程怎么从账本里找出浪费点、路由决策该怎么做、落地灰度有哪些坑、30% 的节省数据到底怎么算出来的。无论你是在做 AI 应用但账单越来越难看的团队还是准备多模型接入的开发者应该都能用得上。1. 先看账本AI 调用成本到底花在了哪里1.1 “无差别补贴”什么都让旗舰模型扛我先说一个很反直觉的结论很多时候你的 AI 成本不是被某个复杂任务拖高的而是被大量简单任务“补贴”上去的。我当时的项目里有大量短文本分类、关键词抽取、标题生成这类需求。单个请求的输入也就一两百字输出也短完全属于轻量模型能搞定的范畴。但因为接入初期图省事所有业务方统一走一个网关入口网关默认转发给旗舰模型。结果就是一天几百万次请求超过六成都是高射炮打蚊子。这类简单请求的单价不高但架不住量大一个月累积下来数字相当吓人。所以做成本优化的第一步永远不是去谈判打折而是先搞清楚是哪些请求在消耗预算。把账本按请求量、token 数、任务类型三个维度拆开你通常会看到一条“二八定律”的变体20% 的复杂任务吃掉了 50% 的成本而剩下 50% 的成本是被80%的简单任务平均消耗掉的。后者才是模型路由最值得动手的地方。1.2 账单里的隐形漏斗不止 token 单价只看 token 单价是新手才会犯的错。我复盘账单时列了一张成本因素拆解表才发现单价只是冰山一角成本项常见来源典型浪费表现基础 token 单价请求全部打给旗舰档简单短文本也按高配模型计费输出长度失控不设 max_tokens任由模型长写分类任务生成了整段解释上下文重复计费对话历史全部塞进每次调用长会话重复计费成倍增长失败重试超时或限流后无脑重发一次失败带来三倍成本缓存缺失相同或相似请求重复计算同一文档摘要反复生成其中特别要提的是“上下文重复计费”。如果你在做客服助手类的场景每次调用都把前面十轮对话原样带上模型每处理一个新问题都要重新读一遍历史。请求量一大这个费用占比会迅速超过生成 token 本身。我当时就是因为这个原因把长会话改成了“前置摘要 近两轮原文”再路由给不同的处理模型。注意这两种虽然都属于“模型路由”的范畴但省钱逻辑完全不一样前者是选对模型后者是控制输入结构。1.3 算账的正确姿势按请求画像分组而不是看平均价我建议所有团队在优化之前都先做一次“请求画像分群”。把线上日志按任务类型、输入长度、输出长度、用户反馈质量分成若干组每组单独计算成本和价值。这样做的好处是你能清晰地看到哪组请求花了很多钱但业务价值很低哪组请求只花了少量钱却支撑着核心体验。我当时把请求分成了四类轻量分类与抽取类短输入、短输出结构化明显占 55% 的请求量成本占比约 20%常规生成类标题、摘要、邮件草稿中等长度占 30% 请求量成本占比约 30%复杂推理类代码审查、长文档综合分析、多步推理占 10% 请求量成本占比约 30%多模态与高价值任务类图像理解、复杂报表解读占 5% 请求量成本占比约 20%这是最核心的行动依据。想省钱的杠杆点一眼就能看出来优先处理第一类请求把它们从旗舰模型切走。这比跟所有业务方喊“少用 AI”要有说服力得多。2. 星链4SAPI 的四个动作Select、Split、Stash、Switch2.1 4S 的四个字母分别管什么事星链4SAPI 之所以起这个名字是因为它的核心路由决策收敛成了四个动作英文首字母都是 SSelect、Split、Stash、Switch。能力作用对成本的影响Select 选择根据请求的复杂度、任务类型、风险等级选择候选模型减少高配模型的无意义调用Split 拆分把复合任务拆解成多个子任务分别匹配不同模型避免为简单部分支付高价Stash 缓存语义级缓存相似请求直接复用结果直接省掉重复生成的 tokenSwitch 切换在限流、超时、质量异常时自动降级或升级降低失败重试成本保住效果下限这四个动作不是顺序执行的而是在一次请求生命周期里组合出现。比如一个长文档综合分析请求进来路由层先做 Split把“抽取关键段落”和“综合推理”拆开前者走轻量抽取模型后者走旗舰推理模型。两个结果再由一个轻量的汇总模型拼装。用户拿到的是一次完整分析但成本被摊到了不同价位的模型上。2.2 一张路由表如何同时兼顾成本、延迟与效果路由表是整个网关的决策核心。在我的实践里它不是简单一个“任务类型对应一个模型”的映射而是包含候选模型、回退顺序、输出上限、超时时间等条件。routes: - name: short-classify match: biz_type: classify max_input_chars: 200 target: provider-b.lite fallback: provider-a.standard max_output_tokens: 128 priority: high - name: long-summary match: biz_type: summarize min_input_chars: 3000 target: provider-a.standard fallback: provider-c.flagship max_output_tokens: 1024这里的核心是我自己比较满意的一个原则绝不只给一个目标模型必须给一个 fallback 链。因为便宜模型的稳定性通常弱一些在高并发或复杂输入下更容易超时。有了 fallback请求不会直接失败而是自动升级到性能更强的模型。从成本角度看这等于只用“必要时”的高价模型来兜底。效果把控方面我建议给每个路由目标加一个“质量验收规则”。比如分类任务要求输出必须是枚举值之一摘要任务要求不超过某个长度。路由层发现目标模型输出不符合规则就会自动触发一次升级调用而不是直接把垃圾结果返回给用户。这个机制能有效防止省了钱、砸了口碑。2.3 “先便宜后升级”的降级路径才是省钱重点很多人做模型路由脑子里想的都是静态分流简单任务走便宜模型复杂任务走贵模型。但真正让成本下降一个数量级的是“低规格起步 失败再升级”的动态策略。我举一个很常见的例子。用户问了一个中文数学题输入只有几十个字。静态分层会把它归入“短文本问答”走轻量模型。但轻量模型计算能力弱很可能算错。如果我们直接把所有数学题都路由到旗舰模型成本又回去了。动态升级的做法是先用轻量模型跑一次同时让一个小型验证器判断输出是否符合题目约束如果验证不通过再升级到标准档或旗舰档跑第二次。这样做的成本曲线是绝大多数简单题目一次通过只有少数疑难题目触发升级。算总账下来比一刀切全走旗舰模型省得多效果还不差。你要愿意可以把验证器本身也做成一个小模型调用但它的成本远低于一次旗舰生成整体依然划算。2.4 路由层应该放网关还是客户端关于这一点我的观点很明确除非你的客户端属于完全受控的内部工具否则路由层必须放在服务端网关而不是每个 SDK 里。放在服务端的价值不只是“统一改配置”更重要的是可观测和可审计。所有请求都经过星链4SAPI 的 bridge 入口日志里能记录真实的路由决策、token 消耗、回退次数、缓存命中率。一旦成本异常或者用户投诉质量问题你能直接拉出是哪条路由规则导致的而不必让客户端同学逐机排查。如果放在客户端虽然省了一跳网络请求的延迟但规则更新会很痛苦而且很难做到跨业务方统一成本归因。延迟不是路由层的首要矛盾可控性和可观测性才是。3. 从日志审计到灰度切流路由落地的四个步骤3.1 第一步用离线日志跑一次成本回放很多团队一上来就直接改网关配置把线上流量切到新路由结果出问题只能手忙脚乱地回滚。我的习惯是先在离线环境里做一次成本回放这一步几乎能让事故减半。具体操作不复杂取最近一周的访问日志把每个请求的输入 token 数、输出 token 数、任务类型都导出来。然后用星链4SAPI 的新路由规则跑一遍模拟每条请求会被分到哪个模型再按厂商价格表计算总成本。这样不需要真实调用外部 API就可以对比新旧方案的成本差异。当时我在回放阶段就发现自己的第一版路由规则会让 15% 的请求因为“长度误判”升级到旗舰模型导致估算降幅从预想的 40% 缩水到 22%。如果直接上线上我可能还以为是模型厂商偷偷涨了价。3.2 第二步给请求打上复杂度标签路由表里的 match 条件不能只有 biz_type还需要能反映真实复杂度的信号。我建议为每个请求维护一套复杂度标签来源有三类规则信号输入长度、关键词命中、是否包含代码块、是否包含图片业务信号业务方传入的任务类型、期望输出格式、风险等级模型信号用一个小模型对请求做分类打分判断难度等级规则信号优先模型信号兜底。比如一个请求同时满足“输入小于 100 字”和“输出格式为 JSON”基本可以直接打上 low 标签。如果输入长度很长但又没有明显结构化需求再交给打分模型判断。这套做法的好处是早期规则不够完善时模型信号能兜住边界情况规则稳定后又可以逐步去掉模型信号省下那部分分类成本。3.3 第三步把预算上限写进路由策略省钱的工程方案如果缺少预算约束通常会慢慢失控。我建议在路由策略里加入预算控制逻辑而不只是依赖业务方自觉。星链4SAPI 支持设置月度预算和单请求成本上限。月度预算用百分比来控制比如当月已消耗 80% 预算时新请求的成本权重自动上调更多流量会被切到缓存或轻量档。单请求成本上限则是硬约束一旦目标模型的预估成本超过阈值直接选择另一个更便宜的替代模型。这个机制的落地价值在于它不是让你人工盯着账单看而是把“花多少钱”变成策略的一部分。成本优化不能靠感觉要把预算参数化。3.4 第四步灰度比例怎么定才不背锅路由切流最怕的问题是改了路由效果下降用户投诉然后谁也说不清楚是哪一步造成的。所以灰度比例不能拍脑袋我的建议是 10% - 50% - 100% 三步走关键是每一步都要对比质量分。先说明白质量分怎么定义。我在项目里用的是“成功返回率 业务验收通过率 用户显式反馈”三者的加权值。在灰度期间这组指标必须跟基准期保持同口径对比。比如第一步只放 10% 的流量走轻量模型其他 90% 继续走旗舰模型观察两天。如果质量分波动小于 1%再扩大到 50%。一旦发现质量分下降立刻停止放量并借助路由日志定位是哪类请求出了问题。这里有个小提醒灰度期千万别只看平均成本下降了多少还要看分位数。第二周的某一天我当时就是因为只看平均值没有看 P95 延迟结果便宜模型在高负载下把尾部延迟拉高了 40%。这类问题不放大流量根本发现不了。4. 第一批上线后踩掉的坑误判、缓存与限流4.1 简单问题被误判成复杂任务比原来更贵第一个坑是路由误判。当时我们的业务方传了一个长文档过来做分类长度超过 3000 字我的规则里没有针对“长文档但低难度”的处理分支于是一律按复杂推理走旗舰模型。结果这批请求花的钱比原来还多用户拿到的却只是一个简单的分类标签。修复思路不是把阈值调高而是给路由规则加“内容价值密度”的判断。长文档不代表难关键是判断输出需求如果业务只要一个标签或一段摘要无论输入多长都可以先做抽取再走轻量模型生成。按这个思路我把长输入任务统一改为先按固定逻辑截断/抽取关键段落再进行轻量模型处理。节省力度比特意提高阈值大得多。4.2 语义缓存命中率低根子出在相似度阈值缓存是我一直很看重的省钱手段但第一版做得很失败。我把相似度阈值设成了 0.99结果命中率只有 3%基本等于没缓存。后来调到 0.92命中率上到了 18%成本立刻又降了一截。但这个阈值不是越低越好。阈值太低会把“相似但不同”的问题混在一起比如“帮我写一封给客户的涨价通知”和“帮我写一封给员工的降薪通知”表面相似结果完全不同。所以我的最终方案是给缓存分两层精确匹配缓存负责完全相同的请求语义缓存只对高价值、低风险的长任务开放并且每次都返回相似度分数供业务方判断。缓存命中率优化的本质是找出那些“重复算但不值得重算”的请求。不要把缓存当作万能药它在短文本上没那么好用但在长文档总结、周报生成、常用问答这几类场景里收益非常大。4.3 便宜模型的并发限流重试策略比想象中更激进第三个坑出在便宜模型本身。短文本请求切到轻量档后单日调用量陡增厂商侧开始出现限流部分请求返回 429 或超时。我当时天真的做法是写了个重试逻辑第一次失败后等 100 毫秒再试一次第二次失败等 500 毫秒第三次直接放弃。听起来很常规但问题在于这类便宜模型往往有并发配额你的重试请求会跟正常请求抢配额反而加重了限流。后来我把策略改成两步一是把同类型请求放进队列限制并发数让流量变得平滑二是当连续重试超过两次时不再换时间重试同一厂商而是通过 Switch 动作把请求升级到另一家的标准档。这个改动同时解决了限流和重试成本问题。4.4 成本监控口径不一致差点回退整个项目这是最让我失眠的一个坑。上线一周后业务方反馈成本监控大盘显示“没有下降”跟我们的预测完全对不上管理层一度打算回退整个方案。后来排查才发现业务方的监控用的是“请求次数 × 平均单价”完全没算 token 损耗和缓存命中我们自己的口径则是按计费表的真实计量来算。把口径统一后两边数据才终于对上了。这件事给我的教训是成本优化上线前先确认大家说的是同一个“成本”。最稳妥的口径是“计费表口径”即输入 token 数 输出 token 数再叠加缓存命中减免。所有团队的监控大盘统一用这套口径对比才有效。5. 数据复盘30% 的降幅是怎么抠出来的5.1 分层路由、语义缓存、降级切换各贡献了多少稳定运行四周后我拿前后各 10 万次请求做了个对照综合成本从每 10 万次 5.0 万元降到了 3.5 万元刚好比原来省了 30%。这一部分并非全是路由的功劳具体拆解如下优化项每 10 万次成本相较原始成本全部请求走旗舰模型5.0 万元基准分层路由Select/Split3.9 万元约省 22%叠加语义缓存Stash3.6 万元累计约省 28%叠加降级与排队Switch3.5 万元累计约省 30%这里的分层路由是绝对主力因为它改变的是“大部分请求用哪个模型”这个基础问题。缓存的价值在于把重复计算清零而降级和排队主要减少的是失败重试和限流带来的额外成本。5.2 用户侧的真实感受延迟反而下降省钱和体验经常被认为是对立的但我们的真实数据显示切换到路由方案后部分场景的响应速度反而快了。原因很简单之前的请求要挤在少数高配模型的队列里高负载下反而慢现在简单任务分流到轻量档单请求延迟通常更低整体吞吐也上去了。用户端能感知到的变化主要是复杂场景偶尔会出现一次“先快后慢”的升级流程。比如最开始给轻量模型 2 秒生成结果质量分不达标再升级到旗舰模型多花 3 秒。虽然最终结果更准但感知上多了 3 秒。为了对冲这种体验我在升级点加了轻量级“占位反馈”先回一段保底内容再后台补充优化结果。这个技巧在长文档场景里尤其管用。5.3 为什么说 30% 只是起点30% 听起来不错但它更多是“低垂果实”的收益。第一版路由只是把明显简单和明显复杂的请求分开了还有大量中等复杂度的请求仍在按照固定策略处理。后续如果再想省空间依然存在一是把更多的个性化长任务改成离线批处理错峰调用便宜模型二是对缓存做更细的分层增加短期记忆和长期知识库的分离三是引入多模型并行候选在关键任务上让标准档和轻量档同时输出再选质量更好的结果。这三块如果做扎实我个人判断总成本还能在 30% 的基础上再往下压 15% 到 20%前提是可观测性不能丢。6. 把路由策略做成一条持续优化的流水线6.1 影子测试与离线回放先验证再切流我在落地后的第三周开始形成一个固定习惯每次要修改路由规则都先在影子环境里跑一遍。影子测试的做法是从线上日志抽取一组真实请求同时构造“新策略预测结果”但不真实向模型厂商发请求。通过比对旧策略和新策略的模型选择差异、预估成本变化、输出长度分布就能提前发现一些明显问题。比如某条规则会导致大量请求升级到旗舰模型或者某类业务完全没匹配上任何路由直接走到了默认出口。这轮测试不需要强大的算力只需要一份干净的历史日志和一套可重复回放的策略引擎。它最大的价值是让你在切流量之前对结果有预期而不是上线后看监控面板拍脑袋。6.2 按周自动生成成本账单和路由报告成本优化是持续工程不是一次性整改。我建议每周自动跑一份成本账单格式固定覆盖五个维度总成本、请求量、各路由命中比例、缓存命中率、P95 延迟。任何一项出现超过 10% 的波动就要自动告警并反向追踪到具体路由规则。这周报不是给管理层看的更多是给自己用的。看到某个路由命中比例在悄悄变化你就能提前察觉到业务侧行为的变化。比如分类请求的输入长度越来越长说明业务方开始把更复杂的任务塞进同一个接口此时就该考虑更新路由规则。6.3 后续还能加什么批处理、缓存分层、混合编排文章最后稍微往远处看一眼。模型路由这条路我做完第一轮后明确感觉到还可以继续延展的东西有三件批处理通道把非实时的周报生成、数据聚合类请求统一放入队列在每天低峰期批量发给便宜模型单次成本能再降不少。缓存分层把长期知识库、短期会话记忆、完全重复请求分离用不同策略处理避免用一个语义缓存去套所有情况。混合编排对高风险任务同时调用两个不同厂商的模型输出结果做交叉验证。虽然增加了单次成本但能在不拆路由的前提下显著降低“返工重算”的隐性费用。这些方向都是基于星链4SAPI 的同一套策略机制扩展出来的不需要另起炉灶。我自己现在做成本优化的第一反应已经不再是“换更便宜的模型”而是先问一句这个请求真的需要模型吗如果需要它需要多大能力的模型很多成本问题本质上不是模型不够好而是路由不够聪明。模型路由就是把每一分钱花在刀刃上的那层开关你越懂自己的业务请求它就越好用。