ChatGPT的api价格

准备接 ChatGPT API 的时候，最容易卡在同一个地方：官方页面上列了一堆模型和单价，但你不知道自己的场景该看哪一栏，也算不出一个月大概要掏多少。这篇不背任何数字，只讲清计费口径怎么读、不同档位分别适合什么活，再给一条从查价到核算的完整动作路径，让你自己能把数字查出来、算出来。

先看懂价目页在说什么：输入、输出和它们的单价关系

打开任何一家官方价目页，别急着找「多少钱」这个数字。它不是一个数，而是一张表：一边是输入单价，一边是输出单价，通常还会按模型分成好几档。先把这张表的结构看懂，再去套你的业务，否则很容易拿一个数当全部，最后预算对不上。

输入和输出是两笔账，而且方向不一样。你贴进去的文档、历史对话、系统提示算输入；模型吐出来的回答、代码、结构化结果算输出。很多场景里输出反而更贵，如果你的业务是大段生成、长文改写，成本重心就在输出侧；如果是把长文档做分类、抽取，重心可能落在输入侧。只看输入单价做估算，方向就会偏。

• 先分清你的业务是「输入重」还是「输出重」，再决定盯哪个单价
• 把输入单价和输出单价分别乘以各自的 token 量，再相加，别拿单一单价乘总量
• 单价的计量单位是每百万 token，不是每次请求、也不是每个字，先换算再谈钱
• 同一档模型按上下文长度可能分不同单价，长输入落在哪一档要对着页面确认
• 把每百万 token 换算成你的单次请求平均 token，才看得出单次成本
• 如果估算结果和预期差得远，先回头查是不是把输入输出混在一起算了

1. 确认当期口径到 /official-api/providers/openai 看这家供应商目前的价目页入口和计费口径，价格和分档会变，以页面当期数字为准。
2. 抄下两个数针对你打算用的那一档模型，分别记下输入单价和输出单价，别只记一个。
3. 确认上下文档位看页面是否按输入长度分了不同单价，估一下你典型请求的输入大概在哪个区间，落在哪档就按哪档算。
4. 换算成 token用你业务里的真实样本，估算平均每次请求的输入 token 和输出 token，注意这里说的是 token 不是字数。
5. 分别计价再相加输入量乘输入单价、输出量乘输出单价，两者相加，才是你这次业务量对应的量级。

不同档位分别适合什么活：别拿顶配干所有事

同一家厂商的 API 通常按能力分成几层，习惯上叫旗舰档、均衡档、轻量档。注意分层依据是「任务对推理深度的要求」，不是参数量越大越好。参数量大的模型在简单活上不但更贵，还可能更慢、更容易过度发挥，比如把一句分类标签写成一段解释。

旗舰档

适合需要多步推理、长链条决策、跨段落上下文的任务，比如复杂代码生成与重构、多条件约束下的方案对比、需要先想再答的分析题。

均衡档

适合多数日常问答、中等长度文本改写、常见代码补全，能力够用且延迟与成本更可控，是很多业务的默认档。

轻量档

适合确定性高、答案空间小的任务，比如分类打标、格式转换、字段抽取、短文本摘要、关键词归并。

最常见的浪费不是选错模型，而是把两类活塞进同一个请求。比如让旗舰档顺手做一遍字段清洗和格式转换，这部分其实轻量档就能稳定完成，却按高成本结算。反过来，把复杂推理压给轻量档，输出看着像对但细节站不住，返工和人工校验的代价往往更高。

1. 先列任务清单把你业务里实际会发出的请求逐条写下来，一句话描述每条要模型干什么，别写「智能问答」这种模糊描述。
2. 再按确定性分组答案可枚举、有标准答案的归一组；需要读多段材料再判断的归一组；需要多步串联的归一组。
3. 最后逐组试档同一组任务先用轻量档跑，结果不达标再往上升一档，升档要有具体失败样例支撑，别凭感觉直接上顶配。
4. 到模型库对一遍拿分组结果去 /models 按任务类型比一遍能力与限制，比只盯价格排序更快，也更不容易选偏。

这套分法不适用于两类情况：一是任务对延迟极度敏感、宁可多花钱也要一次答对，这时直接选能力更强的一档更划算；二是你还在验证业务可行性、请求量很小，此时统一用一个强档跑通流程，比提前做精细分档更省事，等量上来再拆。

按量计费怎么结算：预扣、结算与余额的关系

很多人第一次看官方控制台，会发现余额一会儿掉一截、过几分钟又回来一点，于是怀疑自己是不是被重复扣费了。这多半是按量计费的正常节奏：调用发起时先按一个预估量把余额冻住，请求彻底结束后再按实际消耗结算，多冻的部分会退回来。想知道具体口径，去站内 /official-api 相关页面核对当时的说明，那里写的是官方最新规则。

1. 先分清冻结和实扣调用成功发出后，余额可能瞬时下降，这一步是预授权；等响应结束、用量统计完成，才会按真实 token 数结算并把差额放回。判断方法：过几分钟刷新一次账户页，看最终稳定值，而不是盯着中间那一下。
2. 再对调用记录控制台一般有按请求维度的用量记录。出现异常时，先按时间找到那几条请求，看它们的输入、输出用量加起来是否等于被扣的总额，能对上就不是重复扣。
3. 最后查扣减顺序如果账户里同时有赠送额度和自充余额，要看清楚先扣哪一笔。顺序搞反了，很容易以为自己在花钱，其实花的是赠送部分，或者反过来。

• 把余额页和调用记录页并排看，用同一段时间范围对照
• 流式和断开的请求，重点看输出用量而不是看是否正常结束
• 给自动重试设次数上限，并对同一个请求做去重标识
• 赠送额度和自充余额的先后顺序，去官方计费说明里确认一次
• 发现对不上时，先截图保存记录再联系支持，别只描述现象
• 要横向比价或看别人踩过的坑，到站内 /official-api 相关页面看当时的数字

余额跳动是结算过程，不是扣费结果；能对得上调用记录，就说明账没问题。

一张可执行清单：接入前、上线后

这一节不讲哪家贵哪家便宜，只给一张能照着做的清单。价格随时会动，所以清单里没有任何一个具体数字，所有数字都去站内当期页面拿。

1. 第一步：确认模型档位先想清楚这个功能到底需要哪一档能力。把需求写下来：是短问答、长文摘要，还是要读图片、要走工具调用。档位定高了，成本按倍数往上走；定低了，返工重跑更亏。定完去 /official-api 对一遍当前在售档位，别凭印象选。
2. 第二步：量出单次 token找一条最典型的真实请求，把提示词、历史上下文、输出长度都算进去。注意上下文是每轮都重发的，多轮对话的输入会滚雪球。自己估不准就用官方 tokenizer 或先跑一小批真实样本，把输入输出分别记下来。
3. 第三步：乘调用量拿单次 token 乘以日活乘人均次数，再乘一个月天数。这一步最容易漏掉峰值：白天高峰和月底结算前的量通常比平均值高不少。建议同时算平均和峰值两版，按峰值做预算。
4. 第四步：对上预算把第三步的结果换成钱，再留一段缓冲给重试、失败重发和缓存没命中的部分。四步里任何一步拍脑袋，最后都会和账单对不上。

• 调用次数：和预估差多少，是接口重试多还是真的业务涨了
• 输入输出比例：输出突然变长，通常是提示词或上下文没控制住
• 模型占比：是不是有小流量悄悄走了更贵的档位
• 额度顺序：免费额度、赠送额度、付费额度的扣减顺序对不对
• 失败率：报错重发会重复计费，这块很容易被忽略

最后一句提醒：不要把任何数字背下来，也不要把本文档当成价格表。价格会调整，档位会增减，唯一作数的是站内当期页面。要报预算或者做对比，去 /official-api 看官方档位和计费口径，去 /price-watch 看价格追踪的当期数字。