很多人第一次查 OpenAI token 价格，看到输入、输出、缓存几栏数字就懵了：同样的调用量，为什么不同模型差好几倍，为什么账单和单价乘出来的对不上。这篇不背具体数字，只讲清 token 计价由哪几项拼成、不同模型差异出在哪，以及去哪一页核对当时的实时价格。
很多人第一次查 OpenAI token 价格，看到输入、输出、缓存几栏数字就懵了：同样的调用量，为什么换成另一个模型账单翻好几倍，为什么自己拿单价乘 token 数，跟月度账单总对不上。问题多半不在算术，而在于计价口径被拆成了好几条线，你只乘了其中一条。
这篇不背任何具体数字，价格随时在变，写死的数只会误导人。只讲清 token 计价由哪几项拼成、不同模型档位差异出在哪，以及动手估算前该按什么顺序自查，具体数额一律到站内对应页面看当时的挂牌。
一条请求的钱由哪几个口袋分走
一次普通调用，账单上通常拆成输入 token 和输出 token 两栏费率。这两栏不是同一个数，输出那栏普遍更贵，所以同一段提示词，答案写得越长，成本涨得越快。估成本时如果把输入输出混成一个总数去乘，基本一定会偏。判断方法很简单：翻一次自己的日志，把入参和出参的 token 数分别记一栏，你会发现它俩的比例经常差好几倍。
- 输入 token
- 你发给模型的内容，含系统提示、历史对话、检索回来的资料，都算在这一栏
- 输出 token
- 模型生成的内容，通常费率高一些，长回答、长代码尤其吃这一项
- 提示缓存
- 重复出现的提示前缀可能走另一套费率，命中与未命中不是一个价
- 批量通道
- 把请求攒起来异步提交，费率口径和标准实时调用不同，别混着乘
还有一类容易被漏掉：图片、音频、工具调用这些模态，未必按 token 数计费，可能按张数、秒数或调用次数走另一套单位。如果你的业务里这类请求占比不高，可以忽略；但如果是图文混合或语音场景，它很可能才是账单大头，得单独拎出来算一遍，别塞进 token 总账里。
不同模型档位差在哪，怎么按活挑
同一家厂商的模型一般分成轻量、主力、旗舰几档。档位越高，单 token 越贵，但贵不等于亏——复杂任务上，贵模型一次跑对，便宜模型可能要跑三遍加人工兜底，总账未必更省。所以挑模型的正确姿势不是看单价排行榜，而是看这个任务失败一次的返工成本有多高。
| 任务类型 | 建议档位 | 判断依据 |
|---|---|---|
| 分类、打标、格式转换 | 轻量档优先 | 输出短、判断简单，错一次重试也便宜 |
| 摘要、改写、抽取字段 | 轻量到主力之间试 | 先跑小样本对比合格率，再决定要不要升级 |
| 多步推理、长文分析 | 主力及以上 | 链路长，一步错会拖垮整条结果，重试成本高 |
| 代码生成、结构化输出 | 主力档起步 | 格式错、逻辑错的修复成本远高于 token 差价 |
什么情况下这套分档不适用？如果你的调用量极小，比如一天几十次内部试用，那单价差异对总支出几乎没影响，此时优先选能力够用的档位，别为了省钱把开发时间耗在调提示上。反过来，量大到单月账单会进财务审批的，档位选择就值得认真做一轮小样本对比。
- 先按任务定档，再按档位查价，不要反过来先看便宜的就往上套
- 用一个真实样本各跑一遍，记录合格率和平均重试次数，而不是只记单价
- 把重试、人工复核、下游返工的成本一并算进去，这才是真实总账
- 留出一档升级空间：轻量档跑不动的任务，别硬调提示词硬撑
查实时价格该看哪几页
价格会变，截图和记忆都不可靠。要动手估算前，先去站内把当时的口径对齐。官方挂牌价到 /official-api/providers/openai 核对，注意那一页通常会把标准按量、缓存、批量几条线分开列，别只看第一行就下结论。跨平台接入的，再到 /openrouter 和 /price-watch 看当时的实际挂牌与变动记录，两边对不上的地方，往往就是你在别处没注意到的通道差异。
- 对官方挂牌口径打开 /official-api/providers/openai，确认你用的模型和通道对应哪一栏费率，把输入、输出分开记下来。
- 查实际挂牌与变动到 /price-watch 看该模型近期的价格变动记录，避免拿一份旧表当依据。
- 换算成单次成本用 /tools/token-price-calculator 把每百万 token 的单价，换算成你一次任务的实际用量，得到一个能直接进预算的数。
动手前按这个顺序自查
估算不是拍脑袋乘一个数，而是一个可以迭代的流程。顺序错了，后面全歪。建议固定成四步：先估用量，再认通道，然后留余量，最后拿真实账单回头修正。这套顺序对任何一家厂商都通用，换模型、换通道都只要重跑一遍，不用重新想。
- 分开估输入输出拿一条真实请求，数清楚入参和出参大概各多少 token，分别记两栏，别合成一个总数。
- 确认走哪条通道标准、缓存、批量，三者费率不同。先确定你的请求实际落在哪条线上。
- 留出余量给重试、超长提示、上下文累积留一栏余量，一般不要按理论最小值做预算。
- 看真实用量回头修跑一周后到 /usage 看真实消耗，用它反推估算系数，比一开始就精算更靠谱。
这套自查什么时候不适用？如果你还在选型阶段，连用哪家都还没定，那就别花时间精算某一家的 token 单价，先跑通一个能出结果的最小流程更有价值。等业务稳定、量起来了，再回来把这套顺序认真走一遍。
token 价格从来不是一个数字，而是输入、输出、通道、重试四件事乘出来的结果。下一步把你现在用的模型和通道对一遍当时的挂牌口径，再到 /price-watch 看有没有变动，顺手用计算器换算成单次任务成本，估算才算真正落地。→
常见问题
为什么我按单价乘出来的钱和账单对不上？
最常见的原因是输入输出费率不同却被当成一个价，其次是缓存命中、批量通道走了另一套费率，还有重试和失败请求也计入用量。建议把输入、输出、缓存读写分开统计，再按各自费率乘。口径细节可在 /official-api/providers/openai 对照当时说明。
便宜的档位能不能直接全换过去？
取决于任务类型。分类、信息抽取、格式改写这类判断边界清楚的活，轻量档通常够用；需要多步推理、长文理解或严格输出格式的，换错档位带来的返工和人工核对成本可能超过省下的钱。建议先拿一个真实任务做对照再决定。
价格变动频繁，怎么知道现在是多少？
官方挂牌价看 /official-api/providers/openai，变动记录和对比口径看 /price-watch，跨平台或中转接入的实际挂牌在 /openrouter 也能翻到。写进文档或预算表时建议标上核对来源和时点，别把某一次看到的数字当成长期依据。
