如何降低你的大模型 API 成本

如果你的模型账单涨得比用量还快，原因几乎从不神秘。真正决定账单的只有四件事：你发出多少输入 token、生成多少输出 token、输入里有多大比例在各次调用间重复、以及每百万 token 你付多少钱。下面每个杠杆都作用在这四项之一上。

本文是一组深入文章的枢纽。如果你已经知道自己要看哪一块，可以直接跳到两家厂商标价对比、两款前沿模型的正面对照、如何从真实用量估算月度账单，或者提示缓存到底值多少钱。

钱到底花在哪

token 定价是不对称的，而这个不对称是控制开销最有用的一条事实。在我们目录里的每一款模型上，输出 token 都比输入 token 贵好几倍；而厂商提供缓存费率的地方，缓存输入只是正常输入的一个零头。

所以「读一份长文档、返回一个短标签」和「读一句短提示、写一篇长文」这两种负载，即便总 token 数相同，成本结构也完全不同。在优化任何东西之前，先搞清楚你属于哪一种。估算方法那篇讲了怎么从日志里拿到这个数，而不是靠猜。

杠杆一：把模型选对档位

最大的模型是为最难的问题定价的。而生产流量里有相当一部分并不难：分类、抽取、路由、短摘要、格式转换。把这部分流量放到更小的模型上，通常是单项收益最大的改动，因为档位之间的价差是倍数级的，不是边际的。

可落地的做法是分级路由：先走便宜模型，遇到低置信度或明确的困难信号再升级。质量保留在真正需要的地方，同时不再为本来不需要的工作付高价。可以在完整价格表上比较各档位，或浏览模型目录来决定哪两款适合组成快通道与慢通道。

杠杆二：缓存提示里永远不变的那部分

多数生产提示里大部分是样板：系统提示、工具定义、少样本示例、政策文档。这段前缀每次调用都一模一样，而你每一次都在按全价为它付费。

两家厂商都把缓存读取定在正常输入价的一个很小的比例上。对于以稳定前缀为主的提示，这几乎等于给账单的输入侧直接打折。具体机制、让它生效的排序规则，以及哪些情况会悄悄失效，都在提示缓存拆解里。

杠杆三：别为没人看的输出付钱

输出是账单上贵的那一侧，也恰好是开发者最少去管的一侧。有三个习惯在持续浪费它：

• 没设最大 token 限制。80 个 token 能说清的事模型写了 900 个，多出来的 820 个你照付。
• 需要结构化数据却要了散文。改成要一个紧凑的 JSON 对象，输出量常常能降一个数量级。
• 改一个字段却重新生成整篇文档。让模型只返回差异，剩下的自己拼。

这三件事都不牺牲质量，它们砍掉的是根本没人读的 token。

杠杆四：先度量，再优化

团队常常优化错了接口，因为人对 token 用量的直觉极不可靠。一个每晚重新嵌入语料的后台任务，可能比全部交互流量加起来还贵。按路由分别记录输入 token、输出 token、缓存 token 和模型，然后按成本排序，而不是按调用次数排序。

拿到分路由的 token 用量之后，API 成本计算器能在几秒内把它换算成月度金额，并把同一负载在官方价和奥莱价下的结果并排给你。

杠杆五：单价本身

前四个杠杆减少的是你买多少 token，这一个改变的是每个 token 值多少钱——也是唯一一个无需任何工程改造就作用于你全部请求的杠杆。

corouter 以奥莱价转售这些模型的容量，按 token 计量，从预付余额扣费。你继续使用同样的模型 ID 和熟悉的 JSON 结构，所以这是一次路由决策，而不是重写应用逻辑。

几个杠杆叠起来值多少

取一个中等规模的负载：每月 5000 万输入 token、500 万输出 token。在完全不做任何工程改动的前提下，公开标价与奥莱价的对比是：

然后再把工程杠杆叠上去。把其中一半简单流量路由到更小的模型，输入那一行还会再降；把 2000 token 的稳定系统前缀做上缓存，剩下的输入成本又去掉大半。它们能叠加，因为作用在同一个等式的不同项上。

合理的执行顺序

1. 先埋点。一周的分路由 token 日志，胜过一个月的猜测。
2. 全局设置输出上限，把话痨接口改成结构化返回。
3. 给所有带稳定前缀的提示开启缓存。哪些能生效见缓存指南。
4. 把不难的流量下沉到更小档位。厂商价格对比里能看到档位差最大的地方。
5. 最后给整体重新定价。把你的真实数字放进成本计算器。