当前做 LLM 应用路由Routing是很多团队的标配简单问题丢给廉价小模型复杂任务才上旗舰大模型目标是压低每次调用的成本。但这个优化口径有一个明显的盲区——它只统计“每次调用花了多少钱”没有统计“这笔调用到底帮业务办成了多少事”。实际跑下来很可能出现这种情况小模型便宜但失败率高AI Agent 会在一个任务上反复重试、回退到强模型、甚至最后还要靠人工兜底总账单不但没降反而比全程使用大模型更贵。这次我们来拆一个更值得盯的指标Cost-per-success也就是“每成功一次任务的真实成本”。它不是一个新的开源项目也不是某个推理框架的隐藏参数而是一套基于 LLM 路由日志和业务成功标准建立起来的核算口径。这篇文章会讲清楚它为什么比 cost-per-call 更有参考价值、怎么做成功的定义、成本怎么归集、日志结构怎么设计以及如何用一段简单的 Python 脚本把指标跑出来。1. 核心概念速览能力项说明指标名称Cost-per-successCPS每次成功任务的综合成本对比对象Cost-per-callCPC每次 API 调用的平均成本适用范围LLM 路由、模型网关、AI Agent、多模型编排、批量任务管线核心思路将全部成本除以成功次数而不是除以总调用次数依赖条件可落地的成功定义、结构化日志、成本归集口径落地方式路由层记录日志 → 清洗归集 → 聚合计算 → 监控报警典型收益发现路由阈值设错、小模型兜底成本失控、失败重试账单翻倍适合读者LLM 应用开发、平台工程、AI 产品负责人、成本治理工程师这里先给一个最简公式后文会逐步拆开Cost-per-success 任务全过程的直接调用成本 失败重试成本 / 成功任务数分母是成功的任务数不是请求数。这个差别决定了指标是应付一下还是真正对业务负责。2. 为什么只看每次调用成本会失真很多团队做 LLM 路由时最初的优化目标非常朴素把部分请求从 GPT-4 切到 GPT-4o-mini或从 Claude 大模型切到本地小模型。监控面板上每次调用的成本确实下降明显从几分钱变成几厘钱看起来优化成功了。但问题在于Cost-per-call 是一个“前视指标”它只看你调用模型这一个动作花了多少钱完全不关心这次调用之后发生了什么。真实业务中一次 LLM 调用后面往往跟着一串连锁动作小模型输出的格式不符合下游解析程序报错需要重新调用。Agent 根据小模型生成的错误中间结果做推理导致整个任务链跑偏最后只能强行回退到大模型重跑。小模型在简单任务上表现尚可但遇到稍微复杂的指令就输出质量不稳最终结果需要人工修改或重新生成。你为了“省钱”把路由阈值调得过于激进导致大量本该走大模型的请求落到了小模型上失败率从 2% 涨到 20%重试次数翻了几倍。LLM 输出没有明确的成功校验机制失败被“静默吞掉”业务方只看到结果不对但根本不知道是模型选择错了。只看 cost-per-call等于只统计了加油站的加油费没有统计这辆车到底有没有到目的地。到了目的地才算运输成功没到目的地中途所有加油费都是沉没成本甚至还要额外支付拖车费。举一个简化例子。假设某个任务有三种路由路径路由路径单次成本成功率完成 100 个任务总成本全部使用旗舰大模型0.0595%100 × 0.05 失败重试 ≈ 5.3全部使用低成本小模型0.00550%100 × 0.005 大量重试 回退放大 ≈ 8.7路由混合策略0.03 平均92%单个任务按路由选择失败重试较少 ≈ 3.6这个例子里的数字是示意性的但它反映了一个常见现象路由混合策略的单次调用均价比“全部用小模型”高但任务级的总成本反而更低因为失败率降下来了。如果你只看 cost-per-call就会错误地认为“全部用小模型”是最便宜的方案。3. 什么是 Cost-per-success先定义“成功”Cost-per-success 的核心不是成本而是“成功”。如果连“成功”两个字都定义不清楚这个指标就只是把分母换了一下没有任何工程价值。3.1 成功的三层定义第一层技术成功。LLM 调用返回了 200没有超时没有截断。这只说明接口通了完全不代表任务做对了。第二层结构成功。输出的内容通过了 JSON Schema 校验、正则校验、字段完整性校验、类型转换校验。对很多程序化任务来说走到这一层才能被下游代码消费。第三层任务成功。LLM 的输出在业务场景中真正达成目标。比如客户工单分类是否正确、代码片段是否能编译运行、文档抽取出来的字段是否与原始 PDF 一致、Agent 是否完成了用户指定的多步操作。强烈建议至少做到第二层并尽量向第三层靠近。如果只把“调用成功”当作成功那么 cost-per-success 和 cost-per-call 的差距可能并不大因为这个指标根本没有过滤掉低质量输出。3.2 不同任务的成功判定模板下面是一组可落地的判定思路具体阈值按业务调整任务类型失败信号如何判定成功意图识别分类结果不符合预定义标签集合命中标签且置信度 ≥ 0.8文档抽取关键字段为空、字段格式错误必填字段全部非空schema 校验通过代码生成生成代码无法运行或测试失败单元测试通过率 100%文本摘要摘要长度异常、关键实体丢失关键词覆盖率 ≥ 阈值长度在范围内Agent 多步任务中间步骤失败、工具返回错误最终目标状态完成无人工干预客服邮件回复驳回率、客户满意度差通过自动策略评分或人工抽样复核这里要特别强调一点“成功”不是一个静态概念。随着路由策略迭代你要定期重新评估这个成功定义是否还合理。比如你最开始只要求 JSON 格式通过后来发现格式对了但内容经常答非所问那就应该把内容相关性评估也加入成功判定哪怕这会增加一些额外的评测成本。4. 成本归集把哪些钱算进“总成本”Cost-per-success 的分子不是某一次调用的账单而是“完成一批任务所付出的全部可归因成本”。下面是必须计算的成本项以及容易被漏掉的项。4.1 直接模型调用成本这个最简单按大模型厂商的 token 计费换算。无论是 GPT、Claude、Gemini还是本地部署的 LLaMA、Qwen 等都要根据实际推理参数计算。模型网关一般会返回 usage 字段按输入 token 和输出 token 分别计价。{ request_id: req_20250510_001, task_id: task_20250510_0001, model: gpt-4o-mini, input_tokens: 850, output_tokens: 320, cost: 0.00098 }4.2 失败重试成本一个任务第一次调用小模型失败又自动重试一次还是失败最后回退到旗舰模型。整个过程其实发生了三次调用但很多团队的日志只记录了最终成功的那一次前两次失败调用的成本被漏掉了。正确的做法是把任务 ID 作为关联键将同一任务的所有调用记录全部串起来。聚合时一个任务的成本是所有调用的总和而不是最后一次调用的成本。4.3 回退与升级成本路由层常见的策略是“弱模型先试失败再升级到强模型”。这里的回退成本可能非常高日志显示实际调用的是小模型但最终费用大头却来自旗舰模型的补刀调用。如果日志只看“最终模型”不看“回退链路”成本归因就会严重失真。4.4 人工兜底成本这是最容易忽略也往往最昂贵的一项。当自动链路反复失败后运营或研发人员介入处理。虽然这类成本不体现在模型 API 账单里但对业务真实支出影响很大。如果你们是内部平台可以用“平均人工处理一个工单的时间 × 人力成本”来估算如果暂时估不准至少应该先记录下来留一个拓展字段。4.5 基础设施成本包括本地部署 GPU 推理服务器的摊销、自建网关的服务器费用、向量检索数据库的费用等。对中小团队来说如果路由主要依赖云厂商 API基础设施成本占比不高可以直接忽略但如果是大规模自建推理集群一定要把 GPU 的时长成本按比例分摊到任务上。5. 为什么路由是 Cost-per-success 的最佳落点理解了这个指标之后你在路由层做成本治理会有一个全新的视角。路由不只是“查一下任务难度选一个模型”它本质上是一个业务资源分配器。好的路由策略应该追求的是每个任务花费的调用来尽量少最终成功率尽量高且在质量和成本之间取得平衡。不过这里要提醒一句路由本身不是银弹。如果你的业务对某个任务的要求是“必须由人类写一份专业报告”无论怎么路由LLM 都无法达成成功标准。此时强行优化 cost-per-success 就失去了意义。那么路由在哪些环节能真正影响成本指标路由判级判断任务难度决定首次调用使用哪个模型。这个决策直接决定单任务的起步成本。路由降级某些场景可以自适应降级比如高峰期将部分非核心任务路由到便宜模型。但如果降级导致失败率升高你需要用 cost-per-success 这个指标来验证降级是否总体划算。路由回退当一个模型失败是否回退、回退到哪个模型、最多重试几次。这个环节对成本影响极大也是设定成本阈值的关键。路由熔断当某个模型连续失败率超过阈值就切换到备选模型。这个机制能避免小模型故障导致雪崩式的重试成本。6. 如何通过日志和计算落地 Cost-per-success6.1 日志结构设计推荐的思路是采用两层日志调用层日志记录每一次模型调用的元数据是一个独立条目。任务层日志记录一个业务任务的全链路结果包含成功的定义、最终模型、所有调用链路的引用。下面是一个任务层日志的示例{ task_id: task_20250510_0001, task_type: document_extraction, success: true, success_checked_by: schema_validation, first_model: qwen7b, first_model_cost: 0.0002, retry_model: gpt-4o, retry_model_cost: 0.0368, total_cost: 0.0370, attempt_count: 2, latency_ms: 6300, created_at: 2025-05-10T10:30:00Z }注意这里的关键点任务成本是“全链路成本”包含第一次失败尝试和第二次成功尝试。如果把这两条日志拆成两个无关联的调用记录最终成本聚合就完全失真了。6.2 使用 Python 进行成本聚合下面是一段简化但可直接运行的计算脚本目的是把任务日志读取出来统计 cost-per-success 和成本分布。from typing import List, Dict def aggregate_cps(task_records: List[Dict]) - Dict[str, float]: 输入任务级日志列表 输出 cost-per-success 相关指标 if not task_records: return {total_cost: 0, success_count: 0, cps: None} total_cost sum(float(r.get(total_cost, 0)) for r in task_records) success_records [r for r in task_records if r.get(success, False)] success_count len(success_records) # 失败的请求成本也计入总成本只是不计入分母 cps total_cost / success_count if success_count 0 else None total_fail_cost sum( float(r.get(total_cost, 0)) for r in task_records if not r.get(success, False) ) fallback_count sum( 1 for r in task_records if int(r.get(attempt_count, 1)) 1 ) return { total_cost: total_cost, success_count: success_count, fail_count: len(task_records) - success_count, cps: cps, fail_cost: total_fail_cost, fallback_count: fallback_count } # 模拟数据 sample_records [ {task_id: 1, total_cost: 0.001, success: True, attempt_count: 1}, {task_id: 2, total_cost: 0.037, success: True, attempt_count: 2}, {task_id: 3, total_cost: 0.002, success: False, attempt_count: 3}, ] result aggregate_cps(sample_records) print(result)这里有一个很容易犯的错误如果你拿“总成本 / 总调用次数”算出来的是一个很小的数就误以为很便宜。但通过聚合之后你可能会发现一个失败任务平均消耗了 X 次调用导致整体 cost-per-success 比策略优化前更高。6.3 分任务类型的指标分解千万不要只看一个全局成本指标。如果业务里有多种任务类型必须按 task_type 拆分否则指标会被高量低质的任务拉平。任务类型任务数成功数总成本单次调用成本Cost-per-success意图识别10009701.80.00110.00186文档抽取50043012.30.01200.02860代码生成20016016.80.03400.10500在这个示例中如果只看“文档抽取”这个任务的单次调用成本大约是 0.012看起来很便宜但把失败重试和人工兜底成本算进去cost-per-success 高达 0.0286是单次调用成本的 2 倍多。这个数字会非常直观地提醒你该优化这个任务的提示词或路由策略了。6.4 建立监控和报警对于平台型团队建议把 cost-per-success 作为核心成本监控项并设置每日环比/周环比报警。以下是一个大致规则rule_name: cost_per_success_abnormal aggregation_window: 24h group_by: task_type metric: cost_per_success condition: p95 3 * baseline: daily_mean alert_level: warning当某个任务类型的 cost-per-success 突然超过最近 7 天的均值 3 倍时就需要怀疑是不是 LLM 路由阈值或模型服务出了问题。7. 一个可参考的核算流程把上面的内容综合起来可以整理出一个标准化的核算流程。1. 确定任务边界 - 明确一次“业务任务”的起点和终点 - 例如识别一条工单意图 一次任务解析一份PDF 一次任务 2. 定义成功标准 - 写清楚通过和失败的判断逻辑 - 技术校验、结构校验、业务校验至少选一种 - 建议在代码中实现为可调用的判定函数 3. 收集完整日志 - 调用层记录每个模型请求的 token、成本、时间 - 任务层按 task_id 聚合所有调用记录最终结果 - 必须有 “attempt_count” 和 “retry_model” 等字段 4. 成本归集 - 将直接调用成本、重试成本、回退成本、人工兜底成本归入同一任务 - 暂时无法量化的成本项可用估算值但要留字段 5. 聚合计算 - 按 task_type 分组计算 cost-per-success - 对比 cost-per-call、成本分布、失败率 6. 定位增长原因 - 是失败率升高还是回退比例过高 - 是路由判级不准还是模型本身质量退化 7. 策略迭代 - 调整路由阈值、回退次数、模型选择 - 继续观察 cost-per-success 的变化这个流程的核心并不是让你多做一套复杂报表而是让你每次调整路由策略前后都能回答同一个问题整体成功率和总成本到底变好了还是变差了。8. 常见问题与误区问题现象可能原因排查方式解决方案单次调用成本下降但月底账单上涨失败重试和回退成本上升按 task_id 聚合成本增加回退策略或提高首次调用的模型等级小模型使用率 90% 但成本没降多少剩余 10% 的旗舰模型调用成本极高查看成本分布 P90/P99分析哪些任务必须走大模型针对性优化提示词任务成功率统计不准确成功判定只到“接口成功”层检查成功标准是否包含校验逻辑加入 schema 校验和业务规则校验路由日志模型字段与最终实际调用不一致日志记录的是路由意图而非实际模型对比网关日志在网关层记录真实模型和回退链大量任务需要人工兜底自动链路成功率过低统计人工介入率将人工介入标记为任务失败或单独字段全局 CPS 指标平稳但某类任务异常被高量任务拉平按 task_type 分组查看对每个任务类型独立监控成本这里要说一个很有意思的点不少团队在做 LLM 路由时把“省钱”作为唯一的 KPI却忘了省钱的最终目的是把预算用在刀刃上而不是盲目降低每一次调用的单价。如果把 cost-per-success 当作衡量标准很多原本看起来合理的决策会产生完全不同的结论。9. 最佳实践建议9.1 优先完善成功判定函数对于程序化的 LLM 任务建议先写清楚“什么样叫成功”再考虑路由。成功判定函数建议直接放在服务代码里而不是人工主观判断。它可以是 Pydantic 校验、JSON Schema 校验、正则匹配、单元测试或一个简单的规则引擎。9.2 在路由层保留策略影子模式变更 LLM 路由策略时不要直接切全量流量。可以先开影子运行模式将实时请求复制一份到新策略上做离线评估对比新旧策略的 cost-per-success。如果没有影子模式也可以做小流量灰度至少观察一个完整业务周期。9.3 为回退链路设置上限建议给每个任务设置最多尝试次数和最大回退成本。例如一个任务最多尝试 3 次回退成本不能超过直接使用旗舰模型成本的 1.5 倍。超过阈值时直接转发到人工队列或默认高质量模型。这里的“阈值”应该由 cost-per-success 这个指标反推出来。9.4 不要把成本指标独立看待单独看 cost-per-success 也有盲区。即使成本降低如果用户满意度下降、任务完成质量下滑长期同样不可持续。建议同时监控成功率、延迟、用户反馈和产出质量评分。9.5 定期复盘成功/失败样本每两周抽一批 cost-per-success 异常高的任务样本人工查看失败原因。你会发现很多失败不是模型能力问题而是提示词让模型难以理解或是路由判级把简单任务分到了不合适的模型上。这种分析对“到底什么时候该用小模型”的直觉培养非常有帮助。10. 总结LLM 路由优化到了今天已经不能只盯 cost-per-call 这个表面数字。真正值得团队建立的是一套以“任务成功”为分母、以“全链路真实成本”为分子的核算体系。Cost-per-success 本质上是把模型调用成本、失败成本、回退成本和人工成本全部打通让每一次路由决策都回到业务目标本身。一开始建议从一个小范围做起选一种任务类型实现成功判定函数把任务日志串起来跑一段时间的 cost-per-success。只要第一步做出来后面扩展监控维度、优化路由回退阈值、引入更多模型策略就都有了判断依据。如果你正在做 LLM 路由、模型网关或者 AI Agent 应用可以先回答一个问题你的日志里能不能查出一个相似任务的首次调用模型、重试模型、总成本和最终是否成功如果查不出来就说明系统还没有建立任务级的成本归因Cost-per-success 这个指标基本无从谈起。先补上这块数据再做成本优化效果会比拍脑袋调路由阈值靠谱得多。