先说结论：客服机器人烧钱，八成不是模型单价贵，而是调用方式出了问题。我们内部一个日活几千的售后问答机器人，上线头一个月账单直接冲到预算的三倍。排查下来，模型单价一分没变，全是调用结构上的隐形开销。这篇把复盘过程写出来，涉及大模型API成本优化的，可以对着自己的账单核一遍。
账单异常长什么样
异常的特征不是"总额高"，而是"结构怪"。我们拉了按天的调用明细，发现三个不对劲的地方：调用量最高的那几天，单次请求的平均token数在往上走；重试次数占比接近两成；同一个用户问题，短则几百token，长则上万token，方差极大。这三条凑在一起，基本就能定位到问题不在模型侧，而在我们自己的调用链上。
四个隐形开销，一个比一个隐蔽
第一，旗舰模型干粗活。我们最初图省事，所有请求统一走旗舰模型。但客服场景里，七成以上是"订单到哪了""怎么退货"这类意图识别和固定话术回复，这类任务用小模型完全够用，成本差一个量级。让旗舰模型去回答"营业时间几点"，等于开卡车送外卖。
第二，上下文无节制膨胀。多轮对话里我们把历史消息全量塞回去，用户聊到第十轮，光历史就占了大部分token。更麻烦的是，很多历史跟当前问题毫无关系，纯属陪跑。上下文不是越长越聪明，超过一定长度后，准确率提升有限，成本却是线性上涨。
第三，重试风暴。我们设了个简单的失败重试，但没做退避和熔断。上游偶发超时的时候，同一批请求会被反复打上去，失败一次重试一次，重试又失败又重试。账单上这部分调用全是白花的，用户那边看到的还是报错。
第四，流式和非流式重复计费。这个最容易被忽略。我们有的链路为了拿完整结果做后处理，非流式调一遍；前端又要打字机效果，流式再调一遍。同一个问题，两笔钱。后来统一成流式接收、本地拼装，这笔重复开销才消掉。
分层路由怎么落地
思路不复杂：按任务难度分流。意图识别、槽位抽取、固定话术这类，走轻量模型；真正需要推理、多步判断、情绪安抚的复杂会话，才交给旗舰模型。中间加一层模型网关做判断，请求进来先过分类器，打上任务标签再决定路由到哪个模型。
我们用的是按任务自动选最优模型这套逻辑，在硅碳相变的多模型路由上跑过一轮对比，简单任务切到轻量模型后，整体成本明显往下走，响应也更快。这里的关键不是"用哪个模型"，而是"什么任务配什么模型"这个映射表要持续调。上线初期我们按经验配，跑两周后按实际命中率重新校准了一遍，效果比拍脑袋配好得多。多模型统一接入的好处也在这时候体现出来，换路由策略不用改业务代码，网关层调一下就行。
优化前后的账单对比
不报具体数字，报比例。总调用量没变，因为用户量没变。总成本降了大约六成，其中旗舰模型调用占比从接近百分之百降到三成左右，剩下的分流到了轻量模型。重试相关调用从接近两成压到个位数百分比。单次请求的平均token数降了约四成，主要来自上下文裁剪。流式重复计费那块直接归零。整体算下来，从超预算三倍回到预算内还有余量。
监控和告警怎么配
省下来的钱要守住，靠的是监控，不是靠自觉。我们配了四条告警：单次请求token数超过阈值触发，防上下文失控；重试率超过设定比例触发，防重试风暴；旗舰模型调用占比异常升高触发，说明路由可能失效；单日成本环比涨幅超过阈值触发。这四条不用做得很复杂，按天聚合、超线告警就够用。Token计费模式下，成本是实时累积的，等到月底看账单再优化，钱已经花出去了。
一句话概括：客服机器人的成本大头在调用结构，不在模型单价。把分层路由、上下文裁剪、重试控制、流式统一这四件事做扎实，账单自然下来。延伸一步，如果你的场景里还有RAG检索，向量库的召回条数同样值得按这个思路核一遍。