做 LLM 应用的人现在基本都会面临同一个选择是把所有请求都发给同一个大模型还是让不同难度的请求走不同模型。这个问题看起来像选型问题实际上是个成本问题。更准确地说是一个“按成功计费”的成本问题。很多团队把目光放在单次调用价格上却忽略了失败重试、质量返工、人工介入这些隐性费用。LLM 路由就是那个把请求分到合适模型的机制但路由值不值得做不该看单次调用省了多少钱而要看最终每成功一次到底花了多少钱。这篇笔记想把口径拆开讲一遍重点落在怎么定义成功、怎么统计、怎么排查。1. 路由解决的不是“选模型”而是“把请求分到对的档位”1.1 一个请求到底需要多大模型很难一眼判断在实际业务里请求类型通常不是单一的。比如一个后台系统可能有这些任务用户提问分类、关键词抽取、标题改写、长文档摘要、复杂数据分析、代码生成。前面几个任务很多 7B 级别或者更小的模型就能做得不错后面几个任务小模型经常会出现信息丢失、逻辑断裂、格式不符合预期的情况。这里要理解一个基本事实大模型和小模型之间的能力差距是真实存在的但不是所有任务都能体现出来。简单任务上大小模型的差距可能很小甚至因为小模型延迟低体验反而更好。复杂任务上差距会迅速拉开。LLM 路由要做的事情就是把请求按难度、类型、质量要求放到对应的模型档位而不是所有请求都往最大最贵的模型上塞。很多人会把这个过程理解成“模型选择器”其实更准确的理解是“请求分级器”。先判断请求属于哪一档再决定用哪一个模型。判断的逻辑可以是规则、可以是分类模型也可以是运行时的反馈。顺带说一句在 LLM 应用开发里路由这个概念经常和 Agent、RAG 一起出现。Agent 需要决定调用哪个工具RAG 需要决定检索哪部分知识路由则决定把请求交给哪个模型。它们属于不同层做的事情但都会被成本问题牵住。很多人觉得路由只是省钱的优化手段实际上它还会影响成功率、延迟和最终用户体验。1.2 路由本身也有成本不能只看省下的调用费路由不是一个免费机制。规则路由需要有人维护规则分类器路由需要额外调用一个小模型也会产生 token 费用反馈路由需要先跑一次小模型失败后再升级等于多做了一次请求。这些成本都要算进总账里。如果每天的请求量很小比如一天几百次路由省下的钱可能连维护成本都不够。反过来如果请求量每天几十万次模型错误率哪怕只差 1%重试和返工带来的损失也可能非常明显。所以做路由之前要先有一个数据判断当前请求量多少、失败率多少、单位失败成本多少。我的习惯是先别急着设计路由策略先把现有链路的数据打出来。哪怕只有一个简单的日志表记录每次请求用的模型、输入输出 token、是否成功也能提供最基本的判断依据。没有这些数据后面所有优化都是拍脑袋。2. 单次调用价格便宜不代表真实成本低2.1 成本三件事调用价、失败率、重试代价如果把一次 LLM 请求比作一次工厂加工调用价只是“开机费”。真正要计算的是一批毛坯件进去有多少件直接合格有多少件需要返工有多少件直接报废。返工要再花钱报废之后换成更贵的设备重新做又是成本。对应到 LLM 场景调用价模型按输入输出 token 收费这是最直观的成本。失败率包括 API 报错、超时、内容校验不通过、格式解析失败、关键信息缺失。重试代价失败之后重新调用同一个模型、换更大模型、或者让用户重新提问都会产生额外费用。举一个简单的算术场景。假设小模型调用一次 0.001 元成功率 70%。大模型调用一次 0.01 元成功率 98%。处理 100 个请求时如果全部用小模型直接成功的只有 70 个其余 30 个失败。这 30 个如果继续用小模型重试假设成功率不变成本会滚雪球如果失败后直接切换到大模型就要额外付出 30 次大模型调用的费用。这样算下来每成功一个请求的真实成本可能比全部直接使用大模型还要高。这个例子里的数字是示意不是精确测算但它说明一个问题只看单次调用价格会严重低估小模型的真实成本。2.2 失败不只是“返回报错”更多时候是“返回了但没用”在 LLM 应用里真正的失败往往不是 HTTP 错误。API 返回 200JSON 也解析出来了但字段是空的或者模型把“浙江省”写成了“浙江市”或者模型把用户问题理解偏了回答了一段完全跑题的内容。这些都属于失败但系统不会自动知道。所以定义“成功”比定义“调用成功”要困难得多。需要把业务层的质量校验加进去。一个真正有用的成本口径是花出去的所有调用费用除以通过业务校验的成功次数。这里的“所有调用费用”包含重试、升级、被丢弃的结果都不能漏。2.3 还有几类看不见的成本人工复核成本模型输出不确定时需要人去检查。人的时间比 API 费用贵得多。延迟体验成本小模型虽然便宜但如果因为反复重试导致最终响应时间翻倍用户就走了。链路维护成本路由规则、模型升级、提示词变更每一样都要有人维护。事故成本一条错误信息发给用户产生的信任损失和客服成本很难量化为 token 费用。这些成本没法用一张 API 价格表算出来但它们会实实在在出现在账单和留存数据里。所谓“成本按成功算”就是把它们全部纳入考虑而不是只盯着模型报价。3. 把“一次成功”定义清楚统计才有意义3.1 成功的定义要和具体任务绑定不要试图定义一个通用的“成功”。“成功”必须挂在任务类型下面。任务类型成功标准示例文本分类类别标签正确且置信度不低于阈值信息抽取所有必填字段存在格式可解析无冲突值内容生成满足长度要求通过敏感词和规则校验主题不跑偏代码生成语法可解析通过静态检查或基本测试对话问答用户没有在短期内重复提问或有明确反馈表示解决每个标准都要能通过代码或人工判断。能用规则判断的不要依赖模型自己说“我觉得没问题”。规则校验最直接的做法是写一段校验函数解析完模型输出后立刻检查字段、类型、取值范围和格式。3.2 至少要记录哪些字段要做成本统计日志里需要包含这些信息请求 ID 和业务任务 ID用于关联前后链路路由决定本次请求被分到哪个模型为什么实际执行模型最终用了哪个模型可能是升级后的输入 token、输出 token用于还原调用费用是否第一次成功0 表示直接成功1 表示失败后重试成功-1 表示最终失败失败类型超时、API 错误、格式错误、质量校验不通过、其他重试次数和升级模型名称端到端延迟包括路由判断时间和模型处理时间最终是否通过业务校验日志字段越完整事后分析越容易。字段缺失时很多成本问题只能靠猜。一个简化版的日志记录长这样{ request_id: req_20250112_001, task_type: information_extract, routed_model: small_model, final_model: large_model, input_tokens: 320, output_tokens: 180, first_try_success: 0, retry_count: 1, failure_type: schema_check_failed, success: 0, latency_ms: 1850 }这是一个示例结构实际字段可以根据业务调整。关键是要能回答三个问题这次请求原本该走哪个模型、实际走了哪个模型、最终成没成功。3.3 统计口径怎么算核心公式其实很简单每成功一次的成本等于总调用费用除以通过业务校验的成功次数。总调用费用包含所有重试和升级调用不能只算第一次。再拆细一点可以有这些指标直接成功率 第一次调用就成功的次数 / 总请求次数最终成功率 最终成功的次数 / 总请求次数重试放大倍数 总调用次数 / 总请求次数单次成功成本 总调用费用 / 最终成功次数一个简化版的计算函数长这样def cost_per_success(total_cost, success_count): if success_count 0: return float(inf) return total_cost / success_count我建议先跑一周的数据不急着优化。先把基线打出来当前所有请求都用同一个大模型时的成本和用路由后的成本对比。没有基线后面所有优化都说不清楚有没有效果。4. 从影子模式到规则路由再到反馈兜底4.1 第一步先跑影子模式不碰线上流量影子模式的思路是线上请求照常走原来的逻辑同时把请求复制一份给新的路由方案只记录路由会怎么选、选了之后输出什么但不把结果返回给用户。这样做的好处是没有线上风险。你可以拿真实流量来验证如果按新路由规则这条请求会被分到小模型那小模型的输出到底能不能通过质量校验。收集几天数据后再决定要不要把路由策略切到线上。这里最容易踩的坑是影子模式看起来在跑但日志没有单独打点或者打了点没人看。等跑了一周想复盘时数据是断的。所以影子模式开始之前先把日志查询语句和汇总脚本写好。4.2 第二步规则路由优先做最简单的一版规则路由就是把判断逻辑写成代码。常见的判断维度可以组合使用任务类型代码任务走大模型分类任务走小模型prompt 长度上下文超过一定长度时小模型容易丢失信息直接走大模型输出格式要求需要严格 JSON Schema 的任务优先选格式稳定性更高的模型用户身份付费用户或高价值用户优先保证质量业务线不同业务线对质量要求不同可以单独配模型规则路由的优点是稳定、可解释、排查方便。缺点是需要人工维护。业务形态变化快的时候规则会越堆越多。4.3 第三步分类器路由处理规则覆盖不了的情况当请求类型不固定、没法用关键词或字段判断时可以用一个小型分类器或者一个文本嵌入模型先把请求做一个难度或类型预判再映射到对应模型档位。要特别注意分类器本身也会出错。分类错误会导致请求被分到过小的模型最终结果不合格又触发升级。因此分类器路由通常要搭配质量校验和兜底升级机制。分类器调一次也有 token 成本这个成本会摊到每成功一次的成本里不能忽略。4.4 第四步反馈路由用结果来判断反馈路由的做法是先让一个小模型处理拿到结果后做规则校验校验不通过时自动升级到更大的模型重新生成。这种模式在小模型能力足够、失败率不是特别高的时候非常实用。但需要关注两点第一次调用不是白白浪费的即使结果被丢弃也要计算费用。升级条件要写得具体且保守。不要因为“感觉不太对”就升级否则小模型基本等于白跑成本会直接翻倍。升级条件可以写成类似这样的逻辑如果 JSON 解析失败或者必填字段为空或者关键字段不在允许取值范围内才升级。条件越明确升级成本越可控。4.5 降级预案不能省路由不是只负责“把请求分到最好的模型”还要负责“模型不可用时怎么办”。大模型服务抖动、配额超限、限流都需要有降级预案是返回错误码让业务端处理还是切到备用模型还是把请求放进队列延迟处理。这些决定会直接影响最终成功率也就直接影响每成功一次的成本。5. 成本变怪了先按这个顺序排查5.1 排查顺序日志、输入、参数、路由规则、模型成本突然上涨时不要第一时间怀疑模型涨价或者模型变笨。按这个顺序看先看日志里的调用次数和失败类型分布。是总次数涨了还是重试次数涨了再看输入。prompt 是不是被业务代码拼接得越来越长上下文是否把大量无关历史记录都带进去了输入 token 变大费用会直接上涨。再看模型参数。max_tokens 是不是被设成了一个很大的值有些模型会一直生成到上限导致输出 token 费用虚高。再看路由规则。是不是某个新规则把所有请求都导向了大模型规则优先级有没有冲突最后看模型本身。是不是某个模型连续返回异常格式导致升级重试比例上升。5.2 常见误判报错不一定是模型问题。可能是 API Key 权限、套餐配额、网络超时、JSON 转义错误、输入格式不符合模型要求。这些都会引发重试成本。“延迟高”不一定代表模型慢。也可能是路由判断代码里做了很多次 IO 操作或者日志写入阻塞了主流程。“改用小模型后执行成功”不一定代表没问题。也许只是输出格式碰巧符合了解析要求内容质量并没过关。排查时要用数据说话。打开日志按任务类型、模型、失败类型分组先看哪个组的成本贡献最高再针对这个组定位原因。5.3 一个实用的预防手段成本看板和告警可以按天统计“每成功一次的成本”做成一个简单的看板。当这个指标连续几天超过阈值时触发告警。比如某类请求的单次成功成本突然上涨 20%就值得排查。这个指标比“总花费”更敏感因为它把调用量变化的影响排除了。调用量涨一倍总花费涨一倍很正常但每成功一次的成本如果也涨了说明链路内部出了问题可能是失败率上升、重试变多或者模型被错误地升级了。6. 什么场景适合做 LLM 路由什么场景不必折腾6.1 适合做的信号如果存在下面几个特征路由大概率值得投入请求类型差异大。有简单分类、关键词抽取也有复杂推理、长代码生成。调用规模有明显差异。不同模型的价格差异在业务体量下能累积成可观金额。失败和重试现象已经出现。说明当前链路对部分请求的质量把控不够。团队有日志、监控和基本的数据分析能力。没有这些路由做出来也说不清效果。如果你的业务同时踩中上面两三条可以认真做一轮路由评估。评估周期不用太长影子模式跑一到两周基本就能看出差距。6.2 不适合做的信号请求量很小。比如一天几百次路由维护的成本可能超过省下的费用。业务类型单一。所有请求都是同一类任务直接选一个合适的模型即可。质量要求极高且不可妥协。如果任何一次失败都不能接受那使用最强模型并做好缓存和重试可能比路由更稳妥。团队没有能力维护日志和校验逻辑。路由带来的是决策复杂度没有数据支撑时会成为新的故障源。路由不是越复杂越好。很多时候一个合适的模型加一个合理的重试策略就比一套花里胡哨的路由系统更划算。6.3 我的习惯先跑稳单条链路再做路由我自己的做法一般是这样先用最大模型把核心链路跑通确认输入输出格式和业务校验规则。然后把日志字段补全跑一周拿到基线数据。接下来用小模型做一次影子测试只记录质量失败率不切换流量。最后才开始设计路由规则。这个流程看起来很慢但踩过的坑告诉我跳过任何一步后面都要花更多时间去返工。很多团队一上来就把规则写了十几条结果每条规则都在把请求导向同一个模型等于没做路由还多了一层维护负担。真正把“每成功一次成本”这个指标盯住之后很多争论会变得简单不该问“这个模型便宜不便宜”而该问“这个模型在这个任务上的最终成功率是多少算下来每成功一次要花多少钱”。这个口径就是 LLM 路由最值得记录的数字。