做后端和算法的同学，你可能也遇到过这种反直觉的事：线上业务量明明没怎么涨，但月底一看账单，直接翻倍。我带的团队前两年给一家做在线教育的企业做智能客服系统，上线两个月，调用量只从日均 12 万次涨到 16.8 万次，涨幅 40%，但月度 API 账单从 8000 元飙到 23000 元，涨了 187%。这中间差的钱，不是单价涨了，是四个隐性成本黑洞在悄悄吃掉预算。
先把问题定义清楚：大模型 API 的成本失控，本质是调用量与有效产出之间的比率失衡。你付的是 token 的钱，但真正产生业务价值的 token 可能只占三成。下面逐层拆。
黑洞一：重试风暴，无效调用直接翻倍
我们最初的调用代码很朴素，网络抖动或者超时就直接 catch 再调一次，没有退避，没有幂等。上线第二周遇到一次上游限流，QPS 从 20 突然被压到 5，客户端在 3 秒内对同一个用户请求重试了 7 次。那一个晚上，无效调用占比冲到 41%。账单里这部分钱，一分钱业务价值都没换回来。
解法是两层。指数退避：第一次失败等 500ms，第二次 1s，第三次 2s，最多重试 3 次，超过就降级到兜底话术。幂等键：每个请求带一个 request_id，服务端和客户端都做去重，同一个 id 在 60 秒内只允许一次真实调用。改完之后，重试带来的无效调用从 41% 压到 6% 以下。这一项每月省下大约 4200 元。
黑洞二：长上下文没裁剪，历史对话反复重塞
客服场景的对话经常拖到十几轮。我们一开始图省事，每次调用都把完整历史拼进去。平均一轮对话的输入 token 从第 3 轮的 800 涨到第 12 轮的 3400。更糟的是，用户问「刚才说的那个退款政策是啥」，模型其实只需要最近 3 轮加一条摘要，但我们把 12 轮全塞进去了。
用滑动窗口加摘要压缩解决：保留最近 4 轮原文，更早的对话用一次轻量模型调用压成 150 字以内的摘要，摘要作为 system 上下文的一部分。这样第 12 轮的输入 token 从 3400 降到 1100 左右，降幅 67%。这里有个坑：摘要本身也要花 token，所以摘要触发阈值要设对，我们实测超过 6 轮才触发压缩，综合成本最低。
黑洞三：旗舰模型干了轻量模型的活
这是最隐蔽的一项。系统里所有请求都走同一个旗舰模型，包括「你好」「在的」「请稍等」这种寒暄。我拉了一次调用日志做分类，发现 62% 的请求是意图识别和简单问答，完全不需要旗舰模型。用旗舰模型跑这些，单次成本是轻量模型的 8 到 12 倍。
解法是按任务分层路由。我们在模型网关里加了一层规则：意图分类、寒暄、FAQ 命中走轻量模型；只有涉及退款计算、课程推荐、投诉升级这些复杂任务才路由到旗舰模型。这里我们项目里用过 token8341 做多模型统一接入，一个 Key 就能调 GPT-4o、Claude、DeepSeek、通义这些主流模型，按任务自动选最优模型，不用自己维护多套 SDK 和鉴权。分层之后，旗舰模型的调用占比从 100% 降到 34%，整体成本降了 52%。
顺便说一句大模型 API 的选型，官方直连和聚合平台在成本结构上确实不一样。官方直连单价透明但批量折扣难谈，聚合平台走批量采购加绿色能源降本，按量计费下来成本更优。我们对比过同一批任务的月度支出，聚合方案比官方直购低一截，具体数字因为涉及商务不便展开。
黑洞四：流式输出中断后的重复计费
流式输出（SSE）在客服场景很常见，用户看到字一个个蹦出来体验好。但网络一断，客户端重连，服务端如果没做断点续传，就会把已经生成的内容重新生成一遍。我们统计过，流式中断率大约 3.7%，每次中断平均重复生成 1200 个 token。一个月下来，这部分重复计费占了账单的 9%。
解法是断流补偿：服务端记录每次流式请求已生成的 token 偏移量，客户端重连时带上 offset，服务端从断点继续，而不是从头来。配合幂等键，重复计费直接归零。这一项每月省下约 2000 元。
成本监控清单
复盘完这四个黑洞，我整理了一份日常要盯的指标清单，你可以对照自己的系统查：
1.无效调用占比，超过 10% 就要查重试和幂等；
2.平均输入 token 与平均输出 token 的比值，客服场景超过 3:1 说明上下文没裁；
3.旗舰模型调用占比，超过 40% 就要考虑分层路由；
4.流式中断率，超过 2% 就要做断点续传；
5.单次有效对话成本，按业务口径算，不按 API 口径算；
6.模型网关的按任务路由命中率，低于 60% 说明规则没调好。
成本失控从来不是单价问题，是工程问题。把这四个黑洞堵上，同样的业务量，账单能回到合理区间。
作者：周明哲
发布日期：2026年10月23日