openai 的 api 收费 标准

很多人搜「openai 的 api 收费 标准」，结果拿到的是别人截图里的单价，过两周就对不上。卡住的地方通常不是数字本身，而是口径：API 按 token 双向计费，ChatGPT 订阅按月打包，两者根本不是一套账。这篇把两套口径拆开讲，给出查价、换算、核对的固定动作，具体数字一律去站内页面看当时的版本。

搜「openai 的 api 收费 标准」的人，十有八九拿到的是一张别人截图里的单价表。问题不在于数字对不对，而在于你根本不知道那张表是什么时候截的、算的是哪一档、走的是哪条通道。过两周再去看官方页，可能已经对不上了。

真正卡住人的其实是口径：OpenAI 的 API 按 token 双向计费，用多少算多少；ChatGPT 是订阅制，按月打包给额度，两者不是同一套账本。这篇不讲单一结论，只讲怎么分清这两套账、怎么查当期数字、怎么把单价换算成你自己一个月大概要花多少。所有具体数字，一律到站内页面看当时的版本。

先分清：API 按量和 ChatGPT 订阅不是一套账

很多人把 ChatGPT 的月费和 API 的单价放一起比，得出「订阅更划算」或「API 更便宜」的结论，这个比较本身就不成立。API 是计费接口，你发一次请求就产生一次消耗；ChatGPT 是产品订阅，你付的是使用权限和额度，额度内怎么用都不再单独扣钱。

判断标准很简单：如果你要把模型接进自己的程序、每天调用量不固定，那就看 API 口径；如果你只是想有个能对话的助手，订阅制才是你要看的。什么情况下不适用：如果你用的是第三方中转或云厂商托管，计价口径还要再叠一层，得单独看那家的规则。

API 收费的核心口径：输入和输出分开计价

同一个模型，输入和输出通常不是一个价，输出一般更贵。所以算一次请求的成本，不能只乘一个单价，得把两段拆开：输入 token 数乘输入单价，加上输出 token 数乘输出单价。只按总量乘一个数，估算会偏。

1. 拆出输入段把系统提示、历史对话、用户这一轮的问题、工具返回结果全算进输入。很多人的输入 token 是输出的好几倍，却只盯着输出价格看。
2. 拆出输出段模型生成的内容、结构化输出的字段、工具调用的参数，都算输出。让模型返回长 JSON 的场景，输出占比会明显上去。
3. 分别乘单价再相加到 /official-api/providers/openai 核对当期输入、输出两档单价，分别乘完再相加，别图省事合成一个数。
4. 验证一次拿一笔真实请求的响应里的用量字段，自己算一遍，和平台账单对一下，差得多说明你漏了某段。

哪些东西会被算进 token：一份自查清单

不少人以为只有自己打的那几个字才算钱，其实一轮对话里被计费的内容比想象的多。下面这份清单可以照着自查，看看自己的消耗到底出在哪。

• 系统提示与角色设定：每一轮都要重新发一遍，设定写得越长，等于每一轮都在为它付费
• 多轮对话历史：轮次越多，累积的输入越大，长会话的后期每问一句都比开头贵
• 长文档、代码上下文、检索回来的片段：这些塞进上下文就按输入计费
• 工具调用与结构化输出的额外字段：函数参数、返回结果也算 token
• 重试与失败请求：生成到一半失败重发的部分，通常也计费

不确定自己用量构成的话，先用 /tools/model-cost-calculator 粗算一遍，把输入输出比例拉出来看。如果发现输入占比远超预期，多半是系统提示或历史堆积的问题，而不是模型选贵了。

ChatGPT 这边怎么算：看额度而不是看单价

订阅制没有 token 单价这个概念，你付的是周期内的使用权和额度上限。所以拿「订阅费除以 token 数」去算单价，是没有意义的，因为订阅本身不按 token 结算。

判断一个订阅档值不值，看的不是单价，而是额度够不够你用、功能范围对不对得上需求。这些额度口径和刷新周期随时可能调整，别背数字，到 /plans/chatgpt-plus 和 /resets 看当期规则。

额度

周期内能用多少，用完可能降级或等待刷新

刷新周期

额度按什么节奏重置，规则以站内当期页面为准

功能范围

不同档能用的能力不一样，这部分比价格更影响体验

按人头

团队共用时看清是整组一份额度还是每人一份

什么情况下不适用：如果团队里好几个人共用一个账号，讨论额度和价格就先讨论清楚按人头怎么分，不然账算不明白。

查价固定动作：三步拿到可信数字

网上流传的价目表最大的问题是不可追溯。想拿到能用的数字，按下面三步走，每一步都能回去复核。

1. 找官方价格表去 /official-api 看官方 API 价格页，任何二手表格都只能当参考，最终以官方页为准。
2. 看厂商模型规格到 /official-api/providers/openai 看该厂商的模型清单与规格说明，确认你要用的那一档到底是哪一个。
3. 查价格变动记录到 /price-watch 看这档价格近期有没有变动痕迹，如果有，就说明你手上那张旧表已经过期了。

把单价换算成「我一个月要花多少」

单价本身不解决任何问题，你要的是自己一个月大概花多少。换算逻辑不复杂：先估日均请求数和平均 token 数，再乘单价，别直接抄别人的月账单，因为用量结构完全不同。

把输入和输出分开估，输出占比高的场景特别容易低估，因为输出单价通常更高。重试和失败请求也要算进去，这部分属于隐性增量。换算工具可以用 /tools/token-price-calculator，测算方法也可以参考本分区已有的预算类文章，别重复造轮子。

三个常见误判，以及怎么避免

大部分算错账的情况，不是数学问题，是口径没对齐。下面三个误判出现频率最高。

• 把官方标价当成最终账单：中转站、云厂商托管、批量通道都可能改变实际单价，官方价只是基准
• 拿某一档的单价去套全部模型：同一家不同模型档次差很大，混着算会得出错误结论
• 用旧截图当依据：价格会动，写死的数字最不靠谱，看当期页面才算数

排查顺序建议固定下来：先确认你走的是哪条通道，再确认用的是哪一个模型档，最后才去看单价。顺序反了，前面两步的变量会把你后面的计算全部带偏。

什么情况下这套口径不适用

这套算法只对「官方 API 直连」成立，下面几种情况要换一套判断方式，硬套会算错。

• 第三方中转站：计价里多了倍率和折算，得另看中转站的计费规则，判断方法可以看本分区关于中转计费的文章
• 云厂商托管：可能按资源占用和按调用量混合计费，不能只按 token 单价乘
• 订阅制用户：订阅本身不按 token 结算，硬算 token 单价没有意义
• 批量或异步通道：结算方式和实时调用不一样，价格结构要单独看说明

如果你不确定自己属于哪种，先回到 /official-api 看官方口径，再去你实际用的那个服务商页面看它自己的说明，两边对齐了再算。