GPT20亿Token价格表

当调用量涨到几十亿 Token 这个级别，单价表本身已经不够用了——你会发现同一份用量，按不同口径算出来能差出一大截。这篇不给你写死的数字，而是给一套搭「二十亿 Token 量级价格表」的方法：先把计价口径对齐，再把用量折算成可比单位，然后到站内对应页面核对当期单价，最后用账单和用量记录做交叉验证。适合正在做年度预算、或要向上汇报成本的团队。

把调用量做到几十亿 Token 这个量级，你会发现普通单价表已经不够用了。同一份用量，按不同口径算出来能差出一大截，年度预算表和实际账单对不上，往往不是算错乘法，而是口径从一开始就没对齐。

这篇不讲写死的数字，而是给一套搭「二十亿 Token 量级价格表」的方法：先把计价口径拆开对齐，再把业务用量折算成可比的 Token 单位，然后到站内对应页面核对当期单价，最后拿真实账单反推验证。适合正在做年度预算、或者要向上汇报成本的团队；如果你还在百万级用量、模型随时换，这张表可以先不做。

量级一上来，价格表为什么就不准了

小量测试时按一次对话估个大概，放到几十亿 Token 会被放大成完全不同的账单。误差不只来自单价本身，还来自输入输出比例、缓存命中率、重试和失败请求这些在小量下被忽略的项。量级越大，这些「零头」越会变成主要偏差。

• 输入和输出的比例会随业务漂移，早期估的比例拿到大批量场景里往往不成立
• 缓存命中和不命中的单价口径不同，混在一起加总等于算错
• 重试、超时重发、失败请求都会真实计费的一部分，估的时候容易漏
• 不同渠道（官方直连、云厂商托管、中转站）计价口径不一样，跨渠道加总前必须分开

第一步：把计价口径对齐，再谈单价

对齐口径的核心动作是「拆」。一份报价至少要拆成输入价、输出价、缓存写、缓存读四类，它们从来不是同一个数。拆完之后再确认这份报价含不含税、含不含平台服务费、有没有走阶梯或折扣，这些在站内页面通常按分栏列出。

把「每百万 Token 单价」统一成同一货币、同一单位之后再乘用量。口径不一致的两张表不要放在一起比，否则比出来的差额没有意义。当期数字到站内的官方 API 价格页核对，各家供应商顺着厂商目录能找到对应条目。

第二步：把用量折算成可比单位

业务侧给你的通常是请求数、字数、文档数、会话数，这些不能直接乘单价。先折成 Token 总量，再按输入输出比例拆成两列，这一步是整张表里最容易出错的地方，建议用站内换算工具做口径转换，别手工按小数点挪。

1. 折算总量按业务量乘平均单次 Token 数得到月总量，平均单次值用真实日志抽样，别用拍脑袋的数。
2. 拆分输入输出把总量按输入输出比例拆两列，比例同样从日志来；两个比例加起来要能对上总量。
3. 加余量在总量上留三类余量：重试、长上下文膨胀、上线初期预估偏差。余量比例按自己业务定，写进表格备注。
4. 换算验证用站内换算工具跑一遍，和手工结果对一下，对不上先查单位而不是查公式。

余量别一刀切。核心链路的重试率通常更低，批处理任务的重试和失败占比更高，两类分开设余量，最后加总出来的总量才接近真实账单。

第三步：一张能拿去汇报的价格表长什么样

汇报用的价格表要满足两个条件：调价之后不用重做，别人拿着能自己更新。做法是把单价列写成「见站内某页当期数字」，小计列只放公式不放死数，这样表格不会随调价过期。

固定列

模型或渠道、输入单价、输出单价、缓存口径、用量假设、小计、备注（来源与查询时间）

分组方式

按场景分组而不是按模型分组，同一场景里放候选模型，方便看替换后的差额

小计

只写公式和引用单元格，不写算好的数字，避免调价后整表失效

备注列

记录单价来自站内哪个页面、什么时候查的，下次复盘知道该重查哪几页

按场景分组的好处是，当你只想回答「换掉某个模型能差多少」，直接看该场景那一行就够了，不用在几十行模型里翻。表里别放跑分和名次，那些去站内排行榜页看，和成本表是两回事。

认单价的地方：别背数字，去这几页看

价格会调，背下来的数字没有任何意义。做表的时候记录查询时间和页面路径，下次复盘时知道该重查哪几页，这比记住某个数有用得多。

• 官方按量价格到官方 API 价格页核对，各家供应商在厂商目录里顺着找对应条目
• 订阅制、编程套餐这类包干的额度，到编程套餐目录看包含多少量、超了怎么算
• 地区价差看官方订阅地区价页，同一家不同地区可能不一样
• 价格变动趋势看价格追踪页，比单点数字更能说明该不该现在锁渠道
• 把每次查到的页面链接和查询时间填进备注列，形成自己的价格档案

中转站渠道的价格不要直接当成官方价来用，它的报价里通常含渠道加价和服务费。拿它做预算时，先到站内的中转站目录核对它的计价方式，再决定要不要放进同一张表。

第四步：拿真实账单反向验这张表

表搭完不算完，按月拿用量记录的 Token 量和账单金额做对照。差得多先查口径（缓存、倍率、重试），再查用量假设，顺序别反，否则容易在假设上白改半天。

差异记录别只写一句「对不上」。写清是哪个环节、哪一类请求导致的，下次估得更准。如果账单里混着多条业务线或多人共用额度，先把账户拆开再核对，否则永远找不到原因，这种情况不适合直接按总额反推。

从价格表到预算：怎么控制不要跑飞

价格表本身不省钱，配套的预算和告警才省钱。按用量设预算上限和告警线，把「一晚跑飞」挡在结算之前，这是大批量调用方最该先做的一件事。

1. 设上限按月度预算折算成 Token 上限，落在账户或项目维度，超了先降速而不是直接停业务。
2. 加告警在用量跑到上限的某个比例时触发提醒，比例自己定，重点是留出处理时间。
3. 分层路由核心链路用稳定渠道，可等待的批处理走更便宜的路子，别把全部量压在一个渠道上。
4. 定期复盘看单价和用量哪一头在涨。单价涨要换渠道或换模型，用量涨要先看业务是不是真增长了。

二十亿 Token 的价格表，比的不是谁记得住数字，而是谁的口径能一直对得上账单。