OpenAI API 想省钱?先解决的是账单设计,不是比价

"哪家 OpenAI API 最便宜?"这个问题本身就问错了方向,照着它去选也大概率选错。单价只是账单里的一行,你能不能控制住总账,取决于另外三件事是否成立:是不是只为真实发生的用量付费、请求失败会不会白扣钱、事后能不能查清楚每一分钱去了哪。这三条都成立,单价高低反而没那么重要;这三条有一条不成立,报价单再漂亮,账单也照样能让你意外。

这篇文章讲的就是第二件事——那些能把一个按量计费的 API,从"每月都要提心吊胆"变成"能提前算清楚"的计费机制。

为什么最低标价不等于最低账单

单价是个费率,不是总账。真正花掉的钱 = 费率 × 一堆你在价目表上根本看不到的因素:

• 已经扣了钱,请求却失败了。 如果计费是在请求发起时就扣,而不是等请求完成才结算,那超时、限流、上游故障都可能照样收你的钱,哪怕你什么都没拿到。
• 估算用量 ≠ 真实用量。 有些接入方式按每次调用给一个固定估算值收费,而不是对照供应商实际返回的 token 数结算。估算天然偏保守,意味着天然偏向多收。
• 会过期的余额。 计费周期结束就作废的预付额度,哪怕账单上没单独列出来,本质上也是一笔成本——那是你已经花出去、却没能用上的钱。
• 没法核对发生了什么。 如果拉不出一份逐条记录每次调用、每次重试、每笔扣费的明细,你只能凭信任接受一个总数。总数看着没问题时这没关系,一旦总数看着不对,你也没办法自己查。

这些因素在价目表上两个数字一比就完事的对比里统统看不见,它们会在几周后的账单里冒出来,变成一个和你自己估算对不上号的总数。

真正决定成本的三个机制

一个真正在意成本控制的网关,要把三件事做对,而且这三件事是叠加生效的——每一件都堵住了账单跑偏的一条具体路径。

1. 先预扣,再按真实用量结算

一套既不会多收也不会少收的计费流程应该长这样:请求发起时,网关按一个保守估算先做一次预扣;等上游返回结果后,再按上游实际报告的真实 token 用量结算——也就是响应里那两个数字,prompt_tokens 和 completion_tokens,你自己也能从返回结果里读到。你付的钱从来不是那个估算值,而是真实发生的用量,精确到每一个 token。

这一点的意义在于,它直接消灭了"账单为什么比我预期高"这类问题的一整条来源——答案永远不会是"估算值被垫高了",因为估算值从一开始就不是最终结算的数字。

2. 上游调用失败,自动退款

上面这套流程的另一半:如果上游调用失败——供应商返回 5xx、连接中断,或任何导致你没拿到可用结果的情况——预扣的那笔钱会被自动退回,这次请求不计费。你不需要提工单,不需要等人工审核,甚至都不用自己发现这次失败,退款就已经发生了。正是这个机制,让"自动重试""失败后跨渠道转移"这类能力才敢真正拿来用——一个会自动跨渠道重试失败请求的网关,只有在"失败的那几次真的一分钱不收"的前提下,才谈得上可信。

3. 一份真能拿去核对的用量日志

前两条机制起作用的前提,是你能验证它们确实在起作用。这就需要一份细到能还原任意一笔扣费的用量日志:模型、prompt 和 completion 的 token 数、耗时、是否走了流式、以及实际扣费金额,支持按时间范围筛选,并能导出成 CSV,拿去和你自己的请求日志对账,而不是只能信一个仪表盘上的总数。能导出的日志,也就能丢进表格里按模型、按天、按项目汇总,清楚看到钱花在了哪,而不是只能盯着页面顶上那一个数字猜。

这三个机制合在一起,把"信任总账"变成了"核实总账"——一份能核实的账单,才是一份能真正拿来做预算规划的账单。

一个不会过期的余额

成本控制的另一半,和某一次具体的请求无关,而是关于那些你已经充值进去的钱后来怎么样了。计费周期一到就作废的余额,会逼着你要么硬着头皮多花钱把它用掉,要么干脆用不完看着它作废——不管哪种结果,都算不上"便宜",哪怕当初看的价目表很有竞争力。

一个可以无限期结转的余额彻底移除了这种压力:今天充的钱,不管你是明天用还是六个月后用,都还在,而且能用在目录里的任何一个模型上,不局限于某一个产品入口。"一个余额、不过期、跨模型通用"这一条属性,就是让你能一次性大额充值、而不用围着一个截止日期算计自己该怎么用的关键。

从 API 返回结果里读回真实用量

如果你不想只是听信这套说法,想自己验证一下,最直接的办法是显式请求用量数据,并从响应里把它读出来。开启流式返回时,加上 stream_options.include_usage,最后一个 chunk 就会带上计费用的真实 token 数:

curl {GATEWAY_BASE_URL}/chat/completions \
  -H "Authorization: Bearer $APIKO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o-mini",
    "messages": [{"role": "user", "content": "Summarize this in two sentences: ..."}],
    "stream": true,
    "stream_options": {"include_usage": true}
  }'

把 {GATEWAY_BASE_URL} 换成你部署环境的网关地址,model 换成你实际在调用的模型 id——具体清单以模型目录当下显示的为准。所有 OpenAI 兼容的客户端库都暴露同一个 usage 对象;重点不在这条具体请求本身,而在于养成"回读 prompt_tokens、completion_tokens,而不是凭感觉估算"这个习惯。如果你已经在通过网关调用,不妨从导出的用量 CSV 里拉一周流量,和自己预期的数字对一下——这个对账动作,才是检验一个"便宜"的 API 是不是真便宜的实际测试。

一份成本控制清单,而不是一次价格比较

在只看单价评估一个 OpenAI 兼容 API 之前,先确认以下几点:

• 计费是按真实 token 用量结算,还是按每次调用的固定估算值?
• 上游调用失败会自动退款,还是要你自己发现并申诉?
• 能不能导出带有单笔成本的用量日志、按时间筛选,拿去和自己的记录核对?
• 余额会过期,还是未用完的额度可以结转?
• 价目表上看到的价格,和账单实际扣的钱是同一套数字,还是两套可能会脱节的系统?

这五条都做到位的报价,哪怕标价不是市面上绝对最低,也能出一份可预期的账单。这五条有任何一条没做到,标价再低,账单也可能让人意外。

用真实请求验证,而不是靠估算

检验一个网关的计费机制是否靠谱,最快的办法就是真的跑一批请求,自己把数字读回来核对。新账户注册即自动获得试用额度,无需绑卡——你可以直接发一批真实请求、导出用量日志,在投入正式预算之前,先确认预扣、结算、失败退款这几件事是不是真如上文所说在运作。注册试用,或直接看价格页获取目录里全部模型的实时单价。