企业官网建设流程全解析

上个月看到账单的时候，我整个人是懵的。调用次数只比上上个月涨了 12%，费用却翻了将近一倍。一开始我以为是模型厂商在悄悄调价，拉出明细一看才发现，问题根本不在单价，而在于所有请求无差别地打向了同一个高配模型：简单分类、短问题问答、长文档总结、复杂推理，全挤在同一条路上。也是从那次对账开始，我才真正意识到，AI 调用成本要做模型路由的系统性分流，而不是永远一刀切“上最好的”。

我把这套方案沉淀成了星链4SAPI，一个跑在业务和模型之间的路由网关。稳定运行一个月后，AI 调用成本省下了 30%，用户侧效果评分没有任何回退，部分场景的响应延迟反而更低。这篇文章想完整记录一下实战过程：怎么从账本里找出浪费点、路由决策该怎么做、落地灰度有哪些坑、30% 的节省数据到底怎么算出来的。无论你是在做 AI 应用但账单越来越难看的团队，还是准备多模型接入的开发者，应该都能用得上。

1. 先看账本：AI 调用成本到底花在了哪里

1.1 “无差别补贴”：什么都让旗舰模型扛

我先说一个很反直觉的结论：很多时候你的 AI 成本不是被某个复杂任务拖高的，而是被大量简单任务“补贴”上去的。

我当时的项目里有大量短文本分类、关键词抽取、标题生成这类需求。单个请求的输入也就一两百字，输出也短，完全属于轻量模型能搞定的范畴。但因为接入初期图省事，所有业务方统一走一个网关入口，网关默认转发给旗舰模型。结果就是：一天几百万次请求，超过六成都是高射炮打蚊子。这类简单请求的单价不高，但架不住量大，一个月累积下来，数字相当吓人。

所以做成本优化的第一步，永远不是去谈判打折，而是先搞清楚是哪些请求在消耗预算。把账本按请求量、token 数、任务类型三个维度拆开，你通常会看到一条“二八定律”的变体：20% 的复杂任务吃掉了 50% 的成本，而剩下 50% 的成本，是被80%的简单任务平均消耗掉的。后者才是模型路由最值得动手的地方。

1.2 账单里的隐形漏斗：不止 token 单价

只看 token 单价是新手才会犯的错。我复盘账单时列了一张成本因素拆解表，才发现单价只是冰山一角：

其中特别要提的是“上下文重复计费”。如果你在做客服助手类的场景，每次调用都把前面十轮对话原样带上，模型每处理一个新问题，都要重新读一遍历史。请求量一大，这个费用占比会迅速超过生成 token 本身。我当时就是因为这个原因，把长会话改成了“前置摘要 + 近两轮原文”，再路由给不同的处理模型。注意，这两种虽然都属于“模型路由”的范畴，但省钱逻辑完全不一样：前者是选对模型，后者是控制输入结构。

1.3 算账的正确姿势：按请求画像分组，而不是看平均价

我建议所有团队在优化之前，都先做一次“请求画像分群”。把线上日志按任务类型、输入长度、输出长度、用户反馈质量分成若干组，每组单独计算成本和价值。这样做的好处是，你能清晰地看到：哪组请求花了很多钱但业务价值很低，哪组请求只花了少量钱却支撑着核心体验。

我当时把请求分成了四类：

• 轻量分类与抽取类：短输入、短输出，结构化明显，占 55% 的请求量，成本占比约 20%
• 常规生成类：标题、摘要、邮件草稿，中等长度，占 30% 请求量，成本占比约 30%
• 复杂推理类：代码审查、长文档综合分析、多步推理，占 10% 请求量，成本占比约 30%
• 多模态与高价值任务类：图像理解、复杂报表解读，占 5% 请求量，成本占比约 20%

这是最核心的行动依据。想省钱的杠杆点一眼就能看出来：优先处理第一类请求，把它们从旗舰模型切走。这比跟所有业务方喊“少用 AI”要有说服力得多。

2. 星链4SAPI 的四个动作：Select、Split、Stash、Switch

2.1 4S 的四个字母分别管什么事

星链4SAPI 之所以起这个名字，是因为它的核心路由决策收敛成了四个动作，英文首字母都是 S：Select、Split、Stash、Switch。

这四个动作不是顺序执行的，而是在一次请求生命周期里组合出现。比如一个长文档综合分析请求进来，路由层先做 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%。这一部分并非全是路由的功劳，具体拆解如下：

这里的分层路由是绝对主力，因为它改变的是“大部分请求用哪个模型”这个基础问题。缓存的价值在于把重复计算清零，而降级和排队主要减少的是失败重试和限流带来的额外成本。

5.2 用户侧的真实感受：延迟反而下降

省钱和体验经常被认为是对立的，但我们的真实数据显示，切换到路由方案后，部分场景的响应速度反而快了。原因很简单：之前的请求要挤在少数高配模型的队列里，高负载下反而慢；现在简单任务分流到轻量档，单请求延迟通常更低，整体吞吐也上去了。

用户端能感知到的变化，主要是复杂场景偶尔会出现一次“先快后慢”的升级流程。比如最开始给轻量模型 2 秒生成，结果质量分不达标，再升级到旗舰模型多花 3 秒。虽然最终结果更准，但感知上多了 3 秒。为了对冲这种体验，我在升级点加了轻量级“占位反馈”，先回一段保底内容，再后台补充优化结果。这个技巧在长文档场景里尤其管用。

5.3 为什么说 30% 只是起点

30% 听起来不错，但它更多是“低垂果实”的收益。第一版路由只是把明显简单和明显复杂的请求分开了，还有大量中等复杂度的请求，仍在按照固定策略处理。

后续如果再想省，空间依然存在：一是把更多的个性化长任务改成离线批处理，错峰调用便宜模型；二是对缓存做更细的分层，增加短期记忆和长期知识库的分离；三是引入多模型并行候选，在关键任务上让标准档和轻量档同时输出，再选质量更好的结果。这三块如果做扎实，我个人判断总成本还能在 30% 的基础上再往下压 15% 到 20%，前提是可观测性不能丢。

6. 把路由策略做成一条持续优化的流水线

6.1 影子测试与离线回放：先验证，再切流

我在落地后的第三周开始形成一个固定习惯：每次要修改路由规则，都先在影子环境里跑一遍。

影子测试的做法是，从线上日志抽取一组真实请求，同时构造“新策略预测结果”，但不真实向模型厂商发请求。通过比对旧策略和新策略的模型选择差异、预估成本变化、输出长度分布，就能提前发现一些明显问题。比如某条规则会导致大量请求升级到旗舰模型，或者某类业务完全没匹配上任何路由，直接走到了默认出口。

这轮测试不需要强大的算力，只需要一份干净的历史日志和一套可重复回放的策略引擎。它最大的价值是让你在切流量之前，对结果有预期，而不是上线后看监控面板拍脑袋。

6.2 按周自动生成成本账单和路由报告

成本优化是持续工程，不是一次性整改。我建议每周自动跑一份成本账单，格式固定，覆盖五个维度：总成本、请求量、各路由命中比例、缓存命中率、P95 延迟。任何一项出现超过 10% 的波动，就要自动告警，并反向追踪到具体路由规则。

这周报不是给管理层看的，更多是给自己用的。看到某个路由命中比例在悄悄变化，你就能提前察觉到业务侧行为的变化。比如分类请求的输入长度越来越长，说明业务方开始把更复杂的任务塞进同一个接口，此时就该考虑更新路由规则。

6.3 后续还能加什么：批处理、缓存分层、混合编排

文章最后稍微往远处看一眼。模型路由这条路，我做完第一轮后，明确感觉到还可以继续延展的东西有三件：

• 批处理通道：把非实时的周报生成、数据聚合类请求统一放入队列，在每天低峰期批量发给便宜模型，单次成本能再降不少。
• 缓存分层：把长期知识库、短期会话记忆、完全重复请求分离，用不同策略处理，避免用一个语义缓存去套所有情况。
• 混合编排：对高风险任务，同时调用两个不同厂商的模型，输出结果做交叉验证。虽然增加了单次成本，但能在不拆路由的前提下显著降低“返工重算”的隐性费用。

这些方向都是基于星链4SAPI 的同一套策略机制扩展出来的，不需要另起炉灶。

我自己现在做成本优化的第一反应，已经不再是“换更便宜的模型”，而是先问一句：这个请求真的需要模型吗？如果需要，它需要多大能力的模型？很多成本问题，本质上不是模型不够好，而是路由不够聪明。模型路由就是把每一分钱花在刀刃上的那层开关，你越懂自己的业务请求，它就越好用。