什么是单位有效任务总成本

聊到模型降价，最常听到的一句话是“单价便宜了三成，换过去肯定省钱”。但如果把账本摊开看，单价只是账面上的一个变量。真正决定钱包厚度的，是另一个不太上口的东西：单位有效任务总成本。

它的意思其实很朴素——完成一件真正有业务价值的任务，前后一共花了多少钱。分母不是请求数，而是"有效任务数"：用户的问题被解决了，结构化字段被下游系统正常接收了，工具链路走到了预期的结果。那些失败重试、格式解析不了、被迫转人工的请求，消耗了资源却没有产出，只能进分子，不能进分母。

分子往往比人们以为的更宽。除了接口本身的计费，还有输出不稳定带来的重试、兜底时对另一个模型的回退调用、工具的实际执行开销、人工审核的时间，以及输出变长之后连带的后续资源消耗。如果新模型让用户多追问两轮、让运营多修正一批结果，这些都算在同一件事的成本里。于是就会出现那种略显尴尬的局面：单价降了，单位有效任务总成本反而没动，甚至上升。

为什么单价这个指标容易骗人

因为单价衡量的是"一次调用"，而业务关心的是"一件事办成"。这两者之间隔着质量、稳定性和人工兜底三道门。模型替换会同时改变输出质量、工具调用路径、失败重试和用户行为，单价的下降只发生在其中最容易观测的那一层。

这也是为什么离线回放和线上灰度得分两轮做。离线回放回答的是"它能不能替代"——在不影响用户的前提下，看关键任务是否退化、结构化输出是否还能被解析、工具调用是否真的可执行。灰度回答的是"它值不值得替代"——并发波动、缓存命中变化、用户连续追问、真实的重试行为，这些历史数据复现不出来，只能在生产里长出来。单位有效任务总成本本质上是个线上概念，它需要真实流量才能算准。

怎么让这个数算得可比

想算得准，前提是让新旧两条路面对相似的请求。如果候选模型只分到简单任务，再拿它跟旧模型处理的全部任务比，结论一定好看，也一定不可信。同理，提示词版本、工具可用性、路由规则、缓存策略和兜底逻辑最好固定或至少记录下来，否则成本变化到底来自模型还是来自应用层同时改动的配置，事后谁也说不清。

另一个容易忽略的点是请求分布。真实系统里，少量复杂长文本、模糊指令、多轮上下文和边缘输入，可能贡献了大部分失败重试和人工介入。这类请求恰恰是单位有效任务总成本的主要来源。只看典型样例，算出来的往往是一个偏乐观的假账。

值得聊一聊的是，这个指标该不该成为唯一的判断依据？也未必。它是经营视角的汇总数，压缩掉了很多结构信息——同样的总成本，可能是各类任务都小幅变差，也可能是某一类关键任务明显退化而被其他部分平摊掉了。所以它更适合和任务结果、服务稳定性、用户与运营反馈一起看，而不是单独拎出来当结论。

比较务实的做法，是在测试开始前就把门槛说清楚：哪些任务必须维持既有质量，哪些工具调用不得失败，成本要降到什么程度才算真正值得迁移。门槛来自业务风险和服务承诺，而不是照着某个模型的表现临时挪动。如果收益只在部分请求类型上成立，分层路由也是一种答案，不必执着于一次性全量替换。毕竟迁移要证明的不是价格更低，而是更低的价格没有把风险和隐性成本悄悄搬到业务链路里。