账单不是因为模型贵，而是因为请求长歪了：我怎么排查 token 成本

先说结论：如果你的 API 账单涨得很快，第一反应别急着换最便宜模型。很多时候，真正把钱吃掉的是上下文越堆越长、失败后整段重试、明明是轻任务却一直挂在高价模型上。

我是被一个批量摘要脚本教育的。那次我把 120 份会议纪要丢进去跑，原本以为主要成本会出在输出，结果拉 usage 明细一看，输入 token 占了大头，而且同一份系统提示词跟历史上下文被反复带上。更离谱的是，有 11 次因为返回格式不对触发重试，相当于同一段 token 又付了一遍。

后来我判断 token 成本，基本只看 4 个口径。

1. 输入 / 输出 token 比例：如果输入远高于输出，通常不是模型贵，是 prompt 和上下文太胖。

2. 重试次数：尤其是 JSON 结构化输出，一次解析失败就可能整段重跑。

3. 模型分层有没有做：分类、改写、摘要这种任务，没必要和复杂推理用同一档模型。

4. 日志能不能看清：如果 usage、错误码、模型路由都不透明，后面你根本不知道钱花去哪了。

我自己现在会把方案拆成三类。

第一类，官方直连。

优点是链路更短，规则更清楚，适合对合规、稳定性要求高的团队。缺点也明显：有些人会卡在访问、支付、接入管理上，测试门槛不算低。

第二类，中转入口。

这类方式对个人测试、小团队原型、需要多模型切换的人会友好一些，尤其是想先把模型列表、价格口径、日志习惯看明白的时候。缺点是你要多看一层：模型覆盖是否真实、账单是否透明、出错时有没有足够日志。

第三类，本地模型配云端模型。

如果你的任务里有很多草稿生成、分类、清洗、提取，本地或便宜模型先做第一层，复杂推理再交给高价模型，通常比“一把梭”更省。但这个方案维护成本更高，不适合完全不想折腾的人。

我现在的做法比较土，但有效。先把请求按任务拆层：

- 分类、改写、摘要初稿走低成本模型；

- 需要长链推理、代码修正、最终定稿再切高价模型；

- 相同系统提示词做缓存；

- 对结构化输出单独限重试次数，比如最多 2 次，不让它无限回环。

一个很直观的变化是：我把批量摘要那条链路改完后，单份文档平均输入 token 从 6200 左右降到 2800 左右，重试率也从接近 9% 压到了 2% 左右。这里不是说所有人都能拿到这个幅度，只是说明方向往往比单价更重要。

我会怎么选？

如果你是个人自用，或者在做原型验证，我更建议先选一个日志和模型口径相对清楚的入口，小额度把几条真实任务跑一遍，别先被宣传词带着走。我自己会顺手拿 AI驿站 https://apivibe.cn/h5 做模型和接入口径对比，先测输入输出、重试、可用模型，再决定要不要长期放进流程。

边界也得说清楚。生产高并发别只看便宜；有敏感数据的任务别随便丢到不清楚日志策略的链路里；如果你连 usage 明细都不看，换多少渠道都只是盲调。

我的经验就一句话：先把 token 账算清楚，再谈怎么买更便宜。