chatGPT每百万token价格

你拿到一个按百万 token 报价的价目表，想把它换算成自己项目一个月要花多少，结果发现对不上：有的入口按输入输出两档算，有的免费额度只抵一部分，最后预算做出来差一截。这篇不讲单价数字本身，只讲「按百万 token 计价」这件事该怎么读、该按什么顺序把它变成自己项目里的成本模型，以及哪些情况下这套算法不适用。

你拿到一张按百万 token 报价的价目表，想把它换算成自己项目一个月要花多少，结果发现对不上：有的入口按输入输出两档算，有的免费额度只抵一部分，最后预算做出来差一截。问题通常不在数字本身，而在你把「报价单位」直接当成了「结算单位」。

这篇不列任何单价，只讲按百万 token 计价这件事该怎么读、按什么顺序变成自己项目里的成本模型，以及哪些情况下这套算法根本不适用。想核对某家当时的档位，到 /price-watch 看当天记录即可。

「每百万 token」到底是个什么计价单位

先记住一句话：百万只是把很小的单价放大到好读的数，它不是一次结算的门槛，也不是打包价。你实际扣费永远按真实消耗折算，用几十个 token 也是按比例算。把它当成「每公里油耗」，而不是「起步价」。

输入档

你发过去的内容，包括系统提示、历史对话、检索回来的文档

输出档

模型生成的内容，通常和输入不是同一口径，长回答要单独算

同一张表

同一家旗下不同型号往往各有各的价目表，跨型号比价前先确认是不是一张表

• 别把输入和输出混成一个均值：两者的比例在不同任务里差别极大，一个聊天机器人和一个批量摘要任务几乎不是一个模型
• 别拿字符数估 token：中文、代码、空格的换算比都不一样，硬估出来的偏差会在月底放大
• 跨型号比价先确认价目表归属：不在同一张表里的两个数字没有可比性
• 判断口径是否适用：如果账单按「次」「分钟」「张」结算，这套按 token 的算法就不适用，别硬套

把单价换成自己项目的成本：四步估算顺序

1. 第一步：量真实用量从调用日志里统计每次请求的输入、输出 token 数，按天汇总。不要用字符数或「大概几百字」来估，验证方式是拿一周日志跑一遍，看总数是否稳定。
2. 第二步：按任务分类把调用拆成对话、摘要、批处理、检索增强几类，各自记一份输入输出比例。验证方式是看每类的输出/输入比值是否长期稳定，波动大的单独再拆。
3. 第三步：分别套档位再加总输入量乘输入档、输出量乘输出档，再把各类相加。不要用单一均值一口价，验证方式是拿一个已知的完整调用反算，看能否对上。
4. 第四步：留缓冲重试、超长上下文、失败重发都会让实际消耗高于估算。缓冲比例按业务容忍度定，验证方式是回看历史账单，看实际是否经常超出预估。

免费额度在成本模型里怎么摆

免费额度要分两类看：一类是有效期内的赠送余额，用完就没了；一类是每日或每月重置的固定额度，会持续回来。这两类对预算的影响完全不同，混在一起会让你的成本曲线看起来很奇怪。

• 把免费额度当「抵减项」而不是「零成本」，否则额度用尽后的账单落差会很难解释
• 长期项目同时算两个数：含免费额度和不含免费额度，后者才是可持续的基准
• 免费额度有并发、限速或模型范围限制时，不能当成等额现金来冲抵成本
• 额度重置周期要写进预算表，按日重置和按月重置在月初月末的账单结构不一样

估算落地：预算表与告警该设什么

估算做完要能落地成一张表，否则下个月你还是不知道钱花在哪。预算表至少三列：预估消耗、单价口径来源、实际账单。缺任何一列，偏差出现时都没法复盘。单价口径来源写清是从哪个站内页面看的，方便下次核对。

• 按调用入口分账：官方直连和中转渠道的折算规则不一样，混在一个池子里看不出问题出在哪
• 设两级告警：日消耗软阈值先响，月度硬上限兜底，先软后硬给排查留时间
• 每月固定做一次预估 vs 账单对账，把偏差归因到用量变化还是口径变化
• 对账发现持续的固定偏差，优先怀疑单价口径或免费额度规则变了，而不是先怀疑用量