openai 官方 api 价格

准备接 OpenAI 官方 API 的时候，最容易被两件事卡住：一是官网上几十个模型名字并排，不知道该看哪一列；二是跑完测试发现账单和心里的估算差了一截，却说不清差在哪。这篇不背数字，只给一套「先对齐口径、再按用量换算、最后逐条排查」的做法，价格随版本变动，落笔前到站内官方 API 价格页核对当时的数字。

准备接 OpenAI 官方 API 的时候，最容易被两件事卡住：一是官网上几十个模型名字并排摆着，不知道该看哪一列；二是跑完测试发现账单和心里的估算差了一截，却说不清差在哪。这篇不背数字，只给一套做法：先对齐口径，再按用量换算，最后逐条排查。价格随版本滚动，落笔前到站内官方 API 价格页核对当时的数字。

对开发者来说，所谓「OpenAI 官方 API 价格」其实不是一个数字，而是一张二维表：横向是模型档位，纵向是计费口径。你真正要回答的问题是「我这个业务跑一个月大概花多少」，而不是「哪个模型最便宜」。所以下面每一节都只讲怎么判断、怎么动手，不给结论式报价。

先把官方价目表读成一张能用的表

价目页上并排的几列，含义完全不同：输入价对应你发过去的提示和上下文，输出价对应模型生成的内容，缓存读价只对命中缓存的那部分前缀生效。只盯一个「起价」是最常见的误读，因为它往往对应最省的调用方式，跟你的真实请求结构未必沾边。

1. 先锁模型族，再看价到站内模型资料库按用途筛（分类、摘要、代码、多模态），拿到候选模型标识，再回价格页找对应行。顺序反过来容易为了省钱选一个干不了活的模型。
2. 把三列抄进自己的估算表输入单价、输出单价、缓存读单价各占一行，后面留出「预估用量」和「月成本」两列。抄的时候记下核对时点，写进方案备注。
3. 标注数据来源文档或方案里出现价格，一律写成「以站内官方 API 价格页为准」，现场数字到站内官方 API 价格页核对，别把某个时间点的数字写死进代码注释。

文本、图片、语音的计价单位根本不是一回事

文本按 token 计，图片按张或按分辨率折算，语音按时长或字符计。这三类用量在日志里长得完全不一样，硬加总出一张「总花费」的表，到了核对环节必然对不上。

做预算时按模态分开建账，最后再加总。哪些模态归哪类计费、走哪条计价逻辑，到站内 AI 词典的基础分类页和站内官方 API 页对照确认，别凭印象套。

把每百万 token 的单价换成「一次任务要多少钱」

单价是给采购看的，开发者真正需要的是「一次典型任务花多少」。做法很简单：量出一次请求的输入长度、输出长度和调用次数，再乘单价。量之前别猜，拿真实样本跑十几次，取中位数比取平均值稳。

• 输入里占大头的是系统提示、历史对话还是检索内容，决定了你能不能靠裁剪省钱；先定位大头，再谈优化。
• 输出长度往往比输入更贵，控制输出长度的收益通常比压缩提示更明显。
• 用站内 token 价格换算工具和模型成本换算工具把单位换成「每次」和「每天」，直觉才对得上。
• 换算口径没对齐之前不要下结论，尤其是跨模型比价，输入输出比例不同的模型没法直接比单价。

上下文、缓存和多轮对话怎么把花费顶上去

多轮对话每轮都要重发历史，输入 token 随轮次线性堆高，这是最容易失控的一项。一个看起来「只多说了几句」的会话，到第十轮时输入长度可能是第一轮的好几倍，而每次都要按输入价再算一遍。

缓存命中部分通常单独计价，前提是你的前缀能稳定复用。请求里每次微调一句系统提示、插入一个时间戳，前缀就变了，缓存直接失效，你以为是省钱的优化反而没生效。

前缀复用

把不变的部分放最前面，变化的部分尽量往后放，命中率才稳

命中率

看命中 token 占输入 token 的比例，不看命中次数

失效判断

换了模型、改了提示开头、加了动态字段，都会让缓存不生效

缓存到底省了多少、什么条件下不省，参照站内提示缓存成本判断路径那一页，那里给了完整的判断分支，比凭经验猜靠谱。

重试、超时和被限速之后，哪些调用照样要付钱

服务端已经返回内容、但客户端超时重发的请求，很可能被算两次。这类重复计费最隐蔽，因为你本地只看到一次失败、一次成功，账单上却是两条。

1. 先判断是不是幂等生成类请求重试一次就是两次不同结果，天然不幂等；查询类通常幂等，重试代价小。不幂等的请求要么加去重键，要么接受重复成本。
2. 区分被拒和已受理被限速拒绝的请求一般不计费，但「已受理却没收到响应」是另一回事。日志里要能分辨这两种状态，否则排查方向会跑偏。
3. 按顺序排查异常先看单位时间内的请求量与失败量是否同步上升，再看重试逻辑的触发条件，最后才查具体请求。排查顺序和常见坑见站内重试计费与限流那一页，以及重试成本排查清单。

批处理和阶梯价：什么时候便宜，什么时候不适用

批处理类接口通常按更低单价结算，代价是交付时间。赶工期、要即时响应的场景直接不适用，别为了单价便宜把体验拖垮。判断标准很简单：这个任务能不能等，等多久业务方接受。

阶梯或承诺量折扣要先看清是按自然月还是按合同周期统计，跨期用量可能掉出折扣区间。月底冲量、月初结算这类节奏，很容易踩到统计窗口的边界。

• 能等且量大的离线任务，优先考虑批处理口径。
• 实时交互、客服、生成式前端，不要为了折扣硬排队。
• 折扣与赠送额度的叠加顺序别自己猜，先按站内计价口径对齐那一页确认规则。
• 跨期统计的折扣，要在预算表里标出统计周期，避免月底估算失真。

让每一笔花费可追溯：日志里至少要留哪些字段

排查账单靠的不是聪明，是日志字段够不够。每次请求至少记下模型标识、输入 token 数、输出 token 数、是否命中缓存、请求 ID 和时间戳，缺任何一项，后面都可能查不动。

按项目或按功能打标签同样关键，否则月底只能看到一笔总数，分不清是谁烧的。字段清单直接照站内用量日志字段模板来，站内用量页可以对照自己的消耗水平，看是否偏离同类业务。

账单对不上时的排查顺序

对账不要一上来翻明细，那样只会越翻越乱。正确的顺序是：先对总量（调用条数、token 总数），再对结构（哪类调用占比异常），最后才逐条查异常记录。总量对上了，问题多半在结构；总量就对不上，才值得翻明细。

1. 对总量把本地日志的调用条数和 token 总数与平台用量页对比。差异在百分比以内通常正常，差出量级多半是漏记或重复记。
2. 对结构按模型、按模态、按项目分组对比占比。某一类突然偏高，往往是缓存失效或误用了高价模型。
3. 查异常记录锁定可疑时间段，按请求 ID 逐条看。重点看失败重试、超时重发、跨期边界这几类。
4. 记下结论把本次差异的原因写进排查记录，下次同类问题直接查记录，不用重跑一遍流程。

常见差异来源集中在几处：重试重复计费、缓存未命中、模态混算、时区导致的跨期。每月固定花十分钟做一次核对，流程参考站内月度账单核对那一页，形成习惯比临时救火省事得多。