1. 从一次账单暴涨说起AI API 聚合平台的路由策略到底在解决什么问题去年下半年我帮一个做智能客服的朋友看他们的大模型调用账单。他们团队大概二十来号人产品上线三个月日活不算高但每个月的模型调用费用从最初的几千块一路涨到接近六位数。老板急了让他们技术负责人查原因。查了一圈发现问题不在业务量暴增而在于他们把所有请求都打到了同一个最贵的模型上——不管是简单的意图分类、关键词抽取还是复杂的多轮推理、长文总结统统走同一个高配模型。这就好比你去楼下买瓶矿泉水非要开一辆重型卡车去拉运费比水本身还贵。这件事让我开始认真研究AI API 聚合平台的路由策略。所谓聚合平台就是把多家模型服务商的接口统一封装成一套 API开发者只需要对接一个入口就能调用不同厂商、不同规格的模型。而路由策略就是决定每一个请求到底该发给哪个模型、走哪条链路的规则引擎。它的核心价值主张很直接用更便宜的模型处理简单任务把贵模型留给真正需要它的复杂任务从而降低整体 LLM 成本。但事情没这么简单。路由策略本身也会带来成本——我把它叫做回退成本。什么叫回退就是你本来想让便宜模型处理结果它答得不好或者超时了或者格式不对系统不得不重新把请求发给贵模型再跑一遍。这一来一回你不但没省钱反而多花了一次便宜模型的钱还搭上了额外的延迟。所以路由策略能不能真正降本取决于一个关键问题省下来的钱能不能覆盖回退带来的额外开销这个临界点就是盈亏平衡点。这篇文章适合三类人看一是正在为 LLM 账单发愁的技术负责人二是正在选型或自建聚合平台的工程师三是对成本优化感兴趣、想搞清楚路由策略底层逻辑的产品经理。我会从整体设计思路讲起拆解核心细节和实操要点然后给出完整的实现流程和参数计算方法最后分享我在实际项目中踩过的坑和排查技巧。整篇内容基于常见工程实践展开涉及的具体数值均为示例你可以根据自己的业务场景替换。2. 路由策略的整体设计与方案选型2.1 为什么要在聚合层做路由而不是在业务代码里写死最原始的做法是在业务代码里硬编码这个接口调 A 模型那个接口调 B 模型。团队小的时候没问题一旦模型数量超过三五个或者业务线多起来维护成本就爆炸了。每换一次模型要改几十处代码测试回归一遍上线还得小心翼翼。更麻烦的是你没法做动态调整——今天发现某个模型降价了想切过去得重新发版。在聚合层做路由本质上是把“选哪个模型”这个决策从业务逻辑里抽离出来变成一个独立的、可配置的、可动态调整的策略层。业务代码只管发请求聚合平台根据预设规则决定转发给谁。这样做的好处有三个第一变更成本低改一条路由规则比改代码快得多第二可观测性强所有请求的走向、耗时、成本都集中在聚合层方便统计和分析第三可以叠加高级策略比如按用户等级分流、按时间段切换、按预算动态限流这些在业务代码里做会非常别扭。我个人的经验是如果你的模型调用量每月超过一万次或者用到了三家以上的模型服务商就值得考虑在聚合层做路由。量太小的话维护聚合平台的成本可能比省下来的钱还多。2.2 路由策略的三种典型模式静态、动态、混合路由策略按决策方式可以分成三类。静态路由是最简单的规则写死比如“意图分类走模型 A文本生成走模型 B”。它实现容易延迟低但不够灵活没法应对模型服务波动或价格变化。动态路由会根据实时指标做决策比如当前哪个模型响应快、哪个模型队列短、哪个模型剩余预算多就发给谁。它灵活但实现复杂而且动态决策本身也会消耗计算资源和时间。混合路由是两者的结合先用静态规则做粗筛再在候选集合里用动态指标做细选。实际项目中混合模式用得最多因为它兼顾了稳定性和灵活性。选哪种模式取决于你的业务对延迟的敏感程度和对成本的敏感程度。如果你的业务是实时对话延迟要求高那就别搞太复杂的动态决策静态加简单的健康检查就够了。如果是离线批处理延迟不敏感那可以大胆用动态策略把成本压到最低。2.3 回退机制的设计什么时候该回退什么时候不该回退是路由策略里最容易被低估的部分。很多人设计路由时只想着“怎么把请求发给便宜模型”却没想清楚“便宜模型搞不定的时候怎么办”。回退的触发条件通常有几类质量不达标比如输出格式不符合预期、置信度低于阈值、超时便宜模型响应太慢、服务不可用接口报错或限流、内容安全拦截便宜模型拒绝了某些请求。但回退不是无条件的。有些场景下回退的代价太高还不如一开始就用贵模型。比如一个需要严格 JSON 格式输出的抽取任务如果便宜模型经常格式出错每次都要回退重跑那还不如直接上贵模型。所以设计回退机制时要明确哪些错误类型值得回退哪些应该直接失败或者降级处理。我的做法是给每类错误设一个权重只有权重超过阈值的错误才触发回退避免因为一些无关紧要的小问题频繁回退。2.4 盈亏平衡点的核心逻辑省的钱要能覆盖回退的额外开销盈亏平衡点的计算其实不复杂但需要你把所有成本项都考虑进去。假设便宜模型的单次调用成本是 C_cheap贵模型是 C_expensive回退率是 r即 r 比例的请求需要回退到贵模型重跑。那么使用路由策略后的平均单次成本是平均成本 C_cheap r × (C_cheap C_expensive)这个公式的意思是每个请求先花一次便宜模型的钱其中 r 比例的请求还要再花一次便宜模型的钱因为回退时通常也会重新调用一次便宜模型做校验或重试加上一次贵模型的钱。如果不使用路由策略全部走贵模型成本就是 C_expensive。盈亏平衡的条件是C_cheap r × (C_cheap C_expensive) C_expensive化简后得到r (C_expensive - C_cheap) / (C_cheap C_expensive)举个例子假设便宜模型单次成本是 0.001 元贵模型是 0.01 元。代入公式r (0.01 - 0.001) / (0.001 0.01) 0.009 / 0.011 ≈ 0.818。也就是说只要回退率低于 81.8%路由策略就是划算的。这个阈值看起来很高说明在价格差距大的情况下路由策略的容错空间其实挺大。但如果两个模型价格差距不大比如便宜模型 0.005 元贵模型 0.01 元那 r (0.01 - 0.005) / (0.005 0.01) 0.005 / 0.015 ≈ 0.333回退率超过 33.3% 就不划算了。这个计算还没考虑延迟成本和工程维护成本。如果回退导致用户等待时间翻倍影响了转化率那实际盈亏平衡点会比公式算出来的更苛刻。所以我在实际项目中会把公式算出来的阈值再打个七折作为安全边际。3. 核心细节解析与实操要点3.1 模型能力画像怎么知道哪个模型适合哪类任务路由策略的前提是你得知道每个模型擅长什么、不擅长什么。这不是看官方 benchmark 就能解决的因为官方跑的分和你实际业务的分往往差很远。我的做法是建一个模型能力画像表针对自己业务里的典型任务类型用真实数据跑一轮评测记录每个模型在准确率、格式合规率、平均延迟、单次成本四个维度上的表现。任务类型可以按业务场景分比如意图分类、实体抽取、短文本生成、长文总结、多轮推理、代码生成等。每个任务准备 50 到 100 条真实样本让每个候选模型都跑一遍人工或自动评估结果。这个过程大概需要一两天但非常值得因为它直接决定了你的路由规则有没有依据。下面是一个能力画像表的示例结构任务类型模型准确率格式合规率平均延迟(ms)单次成本(元)意图分类模型A92%99%3200.0008意图分类模型B95%99%5800.003实体抽取模型A78%85%4100.0012实体抽取模型B94%97%6200.004长文总结模型A65%90%12000.005长文总结模型B91%98%18000.015从这张表能看出来模型 A 在意图分类上表现不错且便宜但在实体抽取和长文总结上明显不如模型 B。那路由规则就很清晰了意图分类走 A实体抽取和长文总结走 B。这种基于数据的决策比拍脑袋靠谱得多。3.2 路由规则的表达方式从简单映射到条件表达式最简单的路由规则是键值对映射比如{intent_classify: model_a, entity_extract: model_b}。这种规则适合任务类型明确、边界清晰的场景。但实际业务里同一个任务类型下不同请求的复杂度可能差很多。比如同样是文本生成有的只需要写一句话有的要写一整篇。这时候就需要更细粒度的规则。我常用的规则表达方式是条件表达式类似这样if task_type text_generate and input_length 200: route_to(model_a) elif task_type text_generate and input_length 200: route_to(model_b) elif task_type entity_extract and required_accuracy 0.9: route_to(model_b) else: route_to(model_a)这种表达方式灵活但维护起来要注意版本管理。规则一多很容易出现冲突或遗漏。我的经验是给每条规则加一个优先级字段匹配时按优先级从高到低依次判断命中即停。同时给规则加注释说明这条规则是为了解决什么问题、基于什么数据得出的方便后续复盘和调整。3.3 回退触发条件的量化阈值怎么定回退触发条件不能凭感觉设得有量化依据。常见的触发条件包括格式校验失败比如要求输出 JSON但模型返回了纯文本。这个可以直接用解析器判断失败即触发。置信度低于阈值如果模型返回了置信度分数可以设一个阈值比如 0.7低于就回退。但很多模型不返回置信度这时候可以用输出长度、关键词命中率等间接指标替代。超时设一个超时时间比如 3 秒超过就回退。超时时间要根据业务对延迟的容忍度来定不能拍脑袋。内容安全拦截如果便宜模型因为安全策略拒绝了请求而业务判断这个请求是合规的可以回退到贵模型重试。阈值设定需要结合历史数据做校准。我的做法是先用一个保守的阈值跑一周收集回退率和回退后的效果数据然后逐步调整。比如一开始把置信度阈值设成 0.8发现回退率高达 40%但回退后准确率只提升了 2 个百分点那就说明阈值设太高了可以降到 0.6 再观察。3.4 成本追踪与归因每一分钱花在哪里要做成本优化首先得能准确追踪成本。聚合平台需要记录每一次调用的模型、输入输出 token 数、单价、总成本并且把这些数据关联到具体的业务线、用户、任务类型上。这样你才能知道钱花在哪里哪些地方有优化空间。我建议在聚合层做一个成本归因模块每次请求结束后把成本信息写入日志或时序数据库。字段至少包括请求 ID、业务线标识、任务类型、路由决策、实际调用模型、输入 token 数、输出 token 数、单次成本、是否回退、回退原因、总延迟。有了这些数据你可以做很多分析比如“哪个业务线的回退率最高”“哪个任务类型的成本占比最大”“回退导致的额外成本占总成本的比例是多少”。注意成本追踪的粒度要足够细但也不能细到影响性能。我的做法是异步写入不阻塞主请求链路。同时设置采样率比如高频请求只记录 10% 的详细日志低频请求全量记录平衡精度和开销。4. 实操过程与核心环节实现4.1 环境准备与基础架构搭建假设你要从零搭一个带路由策略的聚合平台第一步是确定技术栈。我推荐用 Python 或 Go 写核心服务因为这两个语言的生态里有很多现成的模型 SDK 和 HTTP 客户端库。数据库方面规则配置可以用 PostgreSQL 或 MySQL成本日志可以用 ClickHouse 或 TimescaleDB后者更适合时序数据的聚合查询。基础架构大概长这样一个 API 网关接收请求一个路由引擎根据规则决定目标模型一个适配层负责把统一格式的请求转换成各模型厂商的格式一个回退控制器负责监控调用结果并决定是否回退一个成本追踪模块负责记录和统计。这些模块可以放在一个服务里也可以拆成微服务看你的团队规模和运维能力。我个人的建议是初期不要拆太细一个单体服务加清晰的模块划分就够了。等调用量上来了再把路由引擎和成本追踪拆出去。过早微服务化只会增加复杂度拖慢迭代速度。4.2 路由引擎的核心代码实现路由引擎的核心逻辑其实不复杂就是一个规则匹配器。下面是一个简化版的 Python 实现用来说明思路class RouteRule: def __init__(self, priority, condition, target_model): self.priority priority self.condition condition self.target_model target_model def matches(self, request): return self.condition(request) class RouteEngine: def __init__(self, rules): self.rules sorted(rules, keylambda r: r.priority, reverseTrue) def route(self, request): for rule in self.rules: if rule.matches(request): return rule.target_model return default_model # 示例规则 rules [ RouteRule( priority100, conditionlambda req: req.task_type entity_extract and req.required_accuracy 0.9, target_modelmodel_b ), RouteRule( priority90, conditionlambda req: req.task_type text_generate and req.input_length 200, target_modelmodel_a ), RouteRule( priority80, conditionlambda req: req.task_type text_generate, target_modelmodel_b ), ] engine RouteEngine(rules) target engine.route(request)这段代码的关键点是优先级排序和条件匹配。优先级高的规则先判断命中就返回不再往下走。条件用 lambda 表达式写灵活但要注意可读性复杂的条件最好抽成独立函数并加注释。实际生产中规则不应该硬编码在代码里而应该存在数据库或配置中心支持热更新。每次请求都查数据库太慢可以在服务启动时加载到内存同时监听配置变更事件有更新时刷新内存中的规则。这样既保证了性能又保证了灵活性。4.3 回退控制器的实现与参数调优回退控制器的逻辑是调用便宜模型后检查结果是否满足要求不满足则调用贵模型重试。下面是一个简化的实现class FallbackController: def __init__(self, cheap_model, expensive_model, timeout_ms3000, confidence_threshold0.7): self.cheap_model cheap_model self.expensive_model expensive_model self.timeout_ms timeout_ms self.confidence_threshold confidence_threshold def call(self, request): start time.time() try: result self.cheap_model.invoke(request, timeoutself.timeout_ms) elapsed (time.time() - start) * 1000 if elapsed self.timeout_ms: return self._fallback(request, timeout) if not self._validate(result, request): return self._fallback(request, validation_failed) if result.confidence self.confidence_threshold: return self._fallback(request, low_confidence) return result except Exception as e: return self._fallback(request, ferror: {str(e)}) def _fallback(self, request, reason): log_fallback(request, reason) return self.expensive_model.invoke(request) def _validate(self, result, request): if request.expected_format json: try: json.loads(result.text) return True except json.JSONDecodeError: return False return True参数调优的重点在timeout_ms和confidence_threshold这两个值。超时时间设太短会导致大量正常但稍慢的请求被误判为超时回退率飙升设太长用户等待时间增加体验变差。我的经验是从业务可接受的最大延迟倒推比如用户能接受 5 秒那便宜模型的超时时间可以设 3 秒留 2 秒给贵模型重试。置信度阈值同理设太高回退率飙升设太低回退后效果提升不明显。建议先用历史数据做离线模拟画出不同阈值下的回退率和准确率曲线找到性价比最高的那个点。4.4 盈亏平衡点的实际计算与监控前面给了盈亏平衡点的公式实际计算时还需要考虑几个因素。第一回退时是否重新调用便宜模型。有些实现是回退时直接调贵模型不再调便宜模型那公式里的r × C_cheap就不存在了平均成本变成C_cheap r × C_expensive。第二贵模型和便宜模型的价格可能按 token 计费输入和输出价格不同需要分别计算。第三有些平台有阶梯定价或包月套餐单价不是线性的。我建议在聚合平台里内置一个盈亏平衡计算器输入便宜模型单价、贵模型单价、当前回退率实时算出当前是否盈利以及盈亏平衡的回退率阈值。同时把这个指标做成监控面板回退率接近阈值时告警提醒团队调整策略。下面是一个更贴近实际的成本计算示例项目便宜模型贵模型输入单价(元/千token)0.0010.01输出单价(元/千token)0.0020.02平均输入token500500平均输出token200200单次成本(元)0.00090.009回退率15%-平均成本(元)0.0009 0.15 × 0.009 0.002250.009从这个例子看即使有 15% 的回退率平均成本也只有全量走贵模型的四分之一。盈亏平衡的回退率阈值是 (0.009 - 0.0009) / 0.009 ≈ 90%说明容错空间很大。但这是假设回退时不再调便宜模型的情况如果回退时还要再调一次便宜模型做校验阈值会降低。4.5 灰度发布与效果验证路由策略上线不能一步到位得灰度。我的做法是先把 5% 的流量导入新策略对比这 5% 和剩下 95% 的成本、延迟、准确率指标。如果成本下降且准确率没有明显下降再逐步扩大到 20%、50%、100%。每一步观察至少一天覆盖不同时间段的流量特征。灰度期间要重点关注几个指标回退率是否在预期范围内P99 延迟是否可接受用户投诉率是否有上升成本节省是否达到预期。如果回退率远超预期说明路由规则或回退阈值有问题需要回滚调整。如果成本节省不明显可能是便宜模型和贵模型的价格差距不够大或者回退率太高吃掉了节省。提示灰度期间最好保留一键回滚能力发现异常能立刻切回全量走贵模型的策略。这个能力在初期特别重要能让你大胆尝试而不怕出事。5. 常见问题与排查技巧实录5.1 回退率居高不下怎么排查回退率高是最常见的问题原因通常有几类。第一类是路由规则太激进把太多请求分给了便宜模型超出了它的能力范围。排查方法是按任务类型统计回退率看哪个任务类型的回退率异常高。如果某个任务类型的回退率超过 50%基本可以判断是路由规则的问题需要把这类任务改回贵模型或者换一个更强的便宜模型。第二类是回退阈值设得太严。比如置信度阈值设成 0.9但便宜模型的置信度普遍在 0.7 到 0.85 之间那大部分请求都会被回退。排查方法是看回退原因的分布如果大部分回退都是“低置信度”就说明阈值需要调低。第三类是便宜模型服务不稳定。超时或报错导致的回退往往是因为便宜模型的服务质量波动。排查方法是看回退原因里“超时”和“错误”的占比如果超过 30%就要考虑换一个更稳定的便宜模型或者在路由层加健康检查自动剔除不健康的模型。第四类是输入数据分布变化。比如业务突然来了一批超长文本超出了便宜模型的处理能力。排查方法是看回退请求的输入长度分布如果明显偏长就要在路由规则里加长度判断长文本直接走贵模型。5.2 成本节省不明显钱到底花在哪了有时候回退率控制得不错但成本下降不明显。这时候要检查几个地方。第一贵模型的调用是否真的减少了。有些实现里回退时虽然调了贵模型但便宜模型的调用并没有取消导致两边都花钱。第二是否有隐藏成本。比如聚合平台本身的服务器成本、网络传输成本、日志存储成本这些虽然单次不高但量大起来也不容忽视。第三价格计算是否准确。不同模型厂商的计费方式不同有的按 token 计费有的按请求次数计费有的有最低消费算错了会导致成本统计失真。我的做法是每周做一次成本对账把聚合平台统计的成本和各家模型厂商的实际账单做对比差异超过 5% 就要查原因。同时把成本按业务线、任务类型、模型三个维度拆开看哪个维度的成本最高优先优化。5.3 回退导致延迟飙升用户体验怎么保障回退意味着用户要等两次模型调用延迟自然翻倍。如果便宜模型平均 1 秒贵模型平均 2 秒回退一次就是 3 秒用户可能已经不耐烦了。保障体验的方法有几个。第一设置总超时比如整个请求最多等 4 秒超过就返回降级结果或错误提示不要让用户无限等。第二并行调用对于延迟敏感的场景可以同时调便宜模型和贵模型谁先返回且质量达标就用谁另一个取消。这样延迟取决于快的那个但成本会高一些。第三异步回退先返回便宜模型的结果同时在后台调贵模型如果贵模型结果更好再通过推送或下次请求时替换。这种方式适合对实时性要求不高的场景。注意并行调用虽然能降延迟但成本会增加因为两个模型都在跑。是否值得要看业务对延迟的敏感程度和成本预算。我的经验是只有对延迟极度敏感且成本预算充足的场景才用并行大部分场景用串行回退加总超时就够了。5.4 常见问题速查表问题现象可能原因排查方法解决措施回退率超过 50%路由规则太激进按任务类型统计回退率调整路由规则复杂任务走贵模型回退率突然上升便宜模型服务波动查看超时和错误占比加健康检查自动切换模型成本节省不明显隐藏成本或计费错误成本对账按维度拆解修正计费逻辑优化隐藏成本延迟飙升串行回退导致等待翻倍统计 P99 延迟和回退率设总超时或改用并行调用准确率下降便宜模型能力不足对比回退前后的准确率提高回退阈值或换更强便宜模型规则冲突多条规则命中同一请求检查规则优先级和条件调整优先级消除条件重叠5.5 几个我踩过的坑和独家技巧第一个坑是回退时重复计费。早期实现里回退时我重新调了一次便宜模型做格式校验结果成本比预期高了不少。后来改成回退时直接调贵模型不再调便宜模型成本立刻降下来了。这个细节在公式里很容易被忽略但实际影响不小。第二个坑是规则热更新导致请求抖动。有一次我更新了一条路由规则把某个任务从贵模型切到便宜模型结果那段时间回退率飙升因为便宜模型对这个任务的支持确实不行。后来我加了灰度机制新规则先对 5% 流量生效观察一天再全量避免了类似问题。第三个技巧是用回退数据反哺路由规则。每次回退都是一次“便宜模型搞不定”的样本把这些样本收集起来分析能发现路由规则的盲区。比如发现某个任务类型下输入长度超过 500 字的请求回退率特别高那就可以在规则里加一条“长度超过 500 字直接走贵模型”提前避免回退。第四个技巧是给回退加预算上限。有些极端情况下回退率可能突然飙升导致成本失控。我在回退控制器里加了一个每日回退预算比如每天最多回退 1000 次超过就停止回退直接返回便宜模型的结果或错误提示。这样能防止意外情况导致账单爆炸。6. 路由策略的边界与后续扩展方向路由策略不是万能的。它的前提是存在价格差距明显、能力有差异的多个模型并且你的业务能容忍一定的质量波动。如果你的业务对准确率要求极高一点错误都不能有那路由策略可能不适合你老老实实全量走最贵的模型更稳妥。另外路由策略的收益随着模型价格趋同而递减如果未来各家模型价格都差不多那路由的价值就只剩下可用性保障和延迟优化了。后续可以扩展的方向有几个。一是基于强化学习的自适应路由让系统根据历史回退数据和成本数据自动调整路由规则减少人工调参。二是多级回退比如便宜模型失败后先回退到中等模型中等模型再失败才回退到贵模型进一步细化成本控制。三是按用户分层的路由付费用户走贵模型保证体验免费用户走便宜模型控制成本。四是结合缓存的路由对于重复或相似的请求先查缓存命中就直接返回连便宜模型都不用调。我在实际项目中的体会是路由策略的收益在初期最明显因为一开始大家都是无脑走贵模型随便优化一下就能省很多。但越往后优化空间越小需要更精细的数据分析和更复杂的策略。所以不要指望一次设计就能一劳永逸要持续监控、持续调优。最后分享一个小技巧把每次路由决策和回退原因都记录下来定期做一次复盘你会发现很多之前没注意到的优化点。