很多人第一次接 OpenAI，预充了一笔钱，跑两天发现余额掉得比想象快，回头翻账单又对不上——不是模型贵，是没搞清它到底按什么口径扣。这篇把 OpenAI 的 token 计费拆成几块讲：哪些 token 计入、哪些模型分开计价、缓存和推理类 token 排在哪一栏，以及单价该去站内哪个页面核对当时的数字。
很多人第一次接 OpenAI，预充一笔钱跑两天，回头翻账单对不上，第一反应是「模型太贵」。其实多数时候不是贵，是没搞清它按什么口径扣钱。同一段中文和英文，切出来的 token 数不一样；同一个请求，输入和输出分开算；用了缓存、开了推理，又是另一套算法。搞不清这些，看账单就只能瞎猜。
这篇不给你背单价，单价是会变的，背下来没意义。下面把 OpenAI 的 token 计费拆成四块讲：按什么单位扣、输入输出为什么差那么多、缓存和推理这类 token 排在哪一栏、以及要核对数字时该走站内哪几个页面。最后给一套自己估算成本的顺序，照着走就行。
先搞清它按什么单位扣钱
OpenAI 基本是按 token 计费，不是按请求次数，也不是按字数。字数和 token 不是一一对应，中文、英文、代码、标点的切法都不同，所以只看字数估成本一定不准。想心里有数，最靠谱的是从接口返回的 usage 字段里拿真实 token 数，而不是自己数汉字。
还有一点容易踩：不同模型是各算各的价目表，不存在「同一个单价乘个系数」。你从便宜模型换到贵模型，等于换了一张表，之前的成本印象直接作废。单价本身也会随时间调整，具体数字到 /official-api/providers/openai 看当时的价目，别记在脑子里。
- 按 token 计，不是按请求次数，也不是按字数；中英文切分不同，字数估不准
- 一次调用拆成输入和输出两段分别计，各自单价不同
- 输入包含系统提示、历史消息、工具定义，不只是你这次敲的那句话
- 不同模型是不同价目表，换模型等于换表，旧印象不能套
- 单价会调，核对当时的数字去 /official-api/providers/openai
输入和输出为什么差那么多
输出单价通常明显高于输入，因为生成比读取更吃算力。这解释了一个常见现象：你把提示词删掉一半，省下的钱远不如让模型少写一大段废话。想控成本，先管输出长度，往往比抠输入更见效。
输入这边也有几笔容易漏的账。多轮对话每一轮都要把之前的聊天记录重新发一遍，轮次越多输入越长，成本是往上叠的，不是每轮固定。另外系统提示、少样本示例、工具/函数定义，每次请求都会跟着走，哪怕这一轮你根本没调用工具。
| 成本项 | 什么时候会产生 | 排查动作 |
|---|---|---|
| 输出长度 | 模型生成的每一段文字 | 限制 max tokens、要求简洁回复 |
| 多轮历史 | 每次请求重发全部上下文 | 看轮次长度，长对话及时截断或总结 |
| 系统提示与示例 | 每次请求都带 | 定期精简固定提示，删掉没用上的示例 |
| 工具/函数定义 | 只要定义了就跟着走 | 不用的工具定义及时摘掉 |
什么情况不适用：如果你的调用都是短提示、单轮、不带工具，输入输出的差距没那么明显，这时候重点应该放在模型选型上，而不是抠上下文。选错模型的浪费，比上下文几个 token 大得多。
缓存和推理类 token 排在哪一栏
命中提示缓存的部分和没命中的部分，计价口径不一样。缓存读取通常比正常输入便宜，但首次写入可能有它自己的算法，不是白送。所以别默认「开了缓存就一定省」，得先看你重复发送的内容占比高不高。
推理类模型还有个坑：思考过程也可能作为 token 计费。这部分到底算输入还是输出、算不算在你看到的回复里，各家定义不同，只能看官方说明。光看账单是看不出来的，得对着计费口径去核。
- 提示缓存写入
- 第一次把内容存进缓存，可能有独立算法，不等于免费
- 提示缓存读取
- 命中缓存后的复用部分，口径通常比正常输入低
- 推理 token
- 模型内部思考产生的 token，是否计入、记在哪一栏要看官方说明
- 图片与音频折算
- 多模态输入会按规则折成 token，折算方式另算
这些名词的定义和对照在 /ai-dict/category/basics，看账单时对着查比猜快。什么情况不适用：如果你的请求都是短、独立、无缓存的，这几项基本用不上，不必为它花时间。
要核对单价，走这几条路
单价别去别处搜，站内就有对应页面。想知道官方各模型的输入输出档位，去 /official-api/providers/openai。想直接把单价换算成「一次对话多少钱」，用 /tools/token-price-calculator 或 /tools/model-cost-calculator，把你的用量填进去。
想知道自己真实跑了多少 token，看 /usage 的用量口径，再和账单对。价格有没有动，看 /price-watch。经第三方渠道调用的，单价未必等于官方，先到 /sites 和中转站目录确认它标的计费口径，再决定要不要比价——口径不一致，比出来的价没意义。
| 你想知道的事 | 去哪看 |
|---|---|
| 官方各模型输入输出单价 | /official-api/providers/openai |
| 一次对话大概多少钱 | /tools/token-price-calculator |
| 按用量算总成本 | /tools/model-cost-calculator |
| 自己实际用了多少 token | /usage |
| 单价是否变动 | /price-watch |
| 第三方渠道计费口径 | /sites 与中转站目录 |
估自己花的钱，按这个顺序走
- 取一次典型调用的 token 数从接口返回的 usage 字段里拿真实的输入、输出 token 数，不要自己数汉字估。
- 算月度 token 量输入、输出分开算：各自乘每天调用次数，再乘 30。别混在一起乘一个均价。
- 对齐当时单价拿月度 token 量去 /official-api/providers/openai 对当时的输入输出单价，得到粗估。这一步只是量级，不是精确账单。
- 用真实账单校准跑一周后拿实际账单回来对偏差。偏大就优先查缓存命中、多轮历史长度、以及是不是混用了不同模型。
这套顺序给的是量级判断，不是精确预测。真实成本受缓存命中率、对话轮次、模型混用影响很大，所以第三步之后一定要有第四步校准，否则估出来的数只会让你更困惑。
下一步想先确认自己经手的渠道有没有按官方口径计费，去 /sites 看它的标价和说明，再拿上面的步骤估一遍，心里就有数了。→常见问题
为什么我看到的单价和账单扣的对不上？
多半是三个原因：一是输入输出分开计价，你只记住了其中一个；二是多轮对话里历史消息每次重发，实际输入比你预想的长；三是走了中转或云厂商渠道，单价口径本身就不同。先确认渠道，再按输入/输出两笔分别对。
中文和英文的 token 数差多少，会影响预算吗？
会。同一段意思，中文和英文切出来的 token 数不一样，比例随内容和切分方式变化，没有固定倍数。做预算时别用字数除以固定值，最好直接取平台返回的 usage 值来估算，尤其是中英混排的提示词。
缓存开着是不是一定省钱？
不一定。只有重复出现的前缀被命中才有意义，命中部分才可能便宜；如果每次请求内容都不一样，缓存写进去又没被读，等于白搭。判断标准是看你的请求有没有稳定不变的前缀，比如固定的系统提示或长文档。
