ChatGPT一百万token多少钱

很多人第一次算ChatGPT的账，都是拿一个「每百万token多少钱」的数字乘上自己的调用量，算完发现跟实际账单对不上。这篇不背数字，而是带你把百万token的价格结构拆开：先分清输入和输出是两笔钱，再看缓存、批量、长上下文这些会把单价拉高拉低的条件，最后用你自己的用量记录反推一个可信的百万级预算。

很多人第一次算ChatGPT的账，都是拿一个「每百万token多少钱」的数字乘上自己的调用量，算完发现跟实际账单对不上。差在哪？差在你算的是单价，账单收的是结构。这篇不背数字，带你把百万token的价格结构拆开：先分清输入和输出是两笔钱，再看缓存、批量、长上下文这些会把单价拉高拉低的条件，最后用你自己的用量记录反推一个可信的百万级预算。

看这篇之前先记住一句话：任何写死的单价都只是某一刻的快照，缓存折扣、批量价、渠道倍率、汇率一变，那个数字就作废了。真正能长期用的是算法和口径。当期具体数字请到站内价格页核对，本文只给你判断标准和可执行的步骤。

为什么大家都按「百万token」来问价

单次调用往往只花几厘钱，小数点后几位，看不出任何差别；把量放大到百万级，差距才浮现出来，也才谈得上比较。所以「每百万token」本质是一个统计口径，方便你估算量级，而不是一个可以下单的商品。很多人误以为有一百万token的打包套餐，其实没有这回事。

• 单次调用金额太小，无法横向比较，百万级才是能看出差异的量级
• 各家报价单位不统一，有的按千、有的按百万，必须先换算成同一口径才能比
• 百万是统计单位不是套餐：没有「买一百万送多少」，只有单价乘以实际用量
• 算预算时真正要盯的是你自己的输入、输出token总量，而不是报价页上的那个数字

先分清：输入和输出是两笔不同的钱

输入token是你发过去的内容，包括提示词、上下文、历史对话和工具返回的结果；输出token是模型吐回来的内容。这两者单价不同，通常输出比输入贵，而且贵不少。所以一个任务如果回答很长，账单会比只按输入估算的高出一大截，这个偏差在长文生成、代码补全这类任务上特别明显。

压输出的办法比换模型更直接：在提示词里写死最大长度、要求只回结构化短内容、禁止模型自由发挥写解释。压输入的办法是控制上下文，只带真正需要的历史。这两件事做一次，长期省下来的量比挑渠道明显得多。

让单价变动的几个条件：缓存、批量与计费口径

官方页面上的单价不是唯一价格，实际结算有好几套口径。命中缓存的前缀内容可能按更低价算，但这有前提：你的调用结构里真的有一段高度重复的前缀，比如固定的系统提示或知识库开头。如果每次请求都完全不同，缓存对你没有任何意义。

前缀缓存

请求开头有一段原样重复的内容，这部分可能按更低价计费；前提是结构真的重复

批量提交

把不急的活攒起来异步提交，通常走另一套价，但要用等待时间换，实时交互不适用

中转倍率

经第三方渠道时，最终扣费会乘以一个倍率，比价前先确认这个倍率是多少

计费口径

含不含缓存、批量、税费、汇率，不同渠道口径不同，不拉齐就没法比

判断标准很简单：如果你的任务对延迟敏感、每次请求内容都不一样，那么缓存和批量这两条基本用不上，别拿它们的折扣价去估自己的预算。反过来，批量处理文档、离线跑数据这类场景，就值得专门排一条异步通道，把省下的钱和时间成本放在一起算。

上下文越堆越长，百万级的账会怎么变

这是最容易被低估的一块。同一轮对话里，历史越长，每次请求带上的输入token就越多。第N轮请求里塞的是前面所有轮次的内容，token量是往上叠的，不是每轮固定的。所以一个聊了很长的会话，后半段的单次成本可能是开头的很多倍。

判断标准：只有当任务真的需要跨轮记忆时，才有必要堆上下文。一问一答的活、每次都能独立完成的任务，堆着历史纯属浪费。常见做法是到一定轮次就做摘要，把旧内容压成一段短概述，或者干脆开新会话，只把必要的结论带过去。

1. 量一下当前上下文的平均长度从日志里抽一批请求，看输入token的分布，中位数和长尾差距大的话说明有失控的会话。
2. 设一条截断线超过多少轮或多少token就触发摘要，把旧内容压缩，别让它无限增长。
3. 验证压缩后效果用同一批测试任务对比压缩前后的输出质量，掉得太多说明摘要策略需要调。

从你的用量记录反推百万级花费：四步走

不要拿官方单价乘一个拍脑袋的调用量，那样算出来的数字没有参考价值。正确的方式是从你已有的用量记录反推。这四步每一步都能验证，缺一步结果都会偏。

1. 导出三项数据在后台或日志里导出调用条数、输入token总量、输出token总量。缺任何一项都算不准，尤其是输出量，很多人只看请求数不看输出长度。
2. 输入输出分开算输入乘输入单价，输出乘输出单价，两者相加。不要用一个混合平均价糊过去，长短回答的比例一变，平均价就失真。
3. 补上隐性消耗重试、失败请求、工具调用的返回内容、多轮对话的重复上下文，这些不产生有效结果但照样计费的量要单独加进去，通常占总量的一个不可忽略的比例。
4. 留一档余量按上面算出的数字再加一段余量，用来应对上下文自然增长、模型切换、用量爬坡。余量比例根据你项目的验证阶段定，早期留宽一点。

算完之后拿这个数字去站内价格页对一遍，看当期官方口径的数字和你自己的估算差多少，差得多说明某个假设错了，通常是输出长度或上下文重复被低估。

量大了单价会变吗：阶梯与承诺用量怎么看

量上去之后，部分渠道会提供阶梯价或承诺用量折扣，但这类优惠通常有前置条件：签一个周期、承诺一个最低消费、或者提前预付。它不是自动生效的，需要你去谈或者去开通。

什么情况下不适用：用量波动大、项目还在验证阶段、随时可能切模型的团队，锁量反而更亏。因为你把不确定性买成了确定性成本，一旦用量掉下来，承诺的那部分照样要付。稳妥的做法是先小批量跑一两个月，看用量曲线稳不稳，再决定要不要谈阶梯。

比价时的对照清单：别只比一个数字

不同渠道报出来的数字看起来差不多，实际到手成本可能差很远，因为口径不一样。下面这份清单是比价前必须逐项确认的，漏掉任何一项，比出来的结论都不可靠。

• 对齐口径：报的是输入价、输出价还是混合平均价，含不含缓存和批量折扣
• 对齐单位：每百万还是每千，换算错一位数就是十倍差距
• 对齐附加项：限速、并发上限、超量之后是降速还是拒绝，这些都会影响实际可用成本
• 对齐结算方式：预付还是后付，有没有最低消费，退改规则怎么算
• 把要接的模型和渠道全部拉齐之后，再去站内价格页核对当期数字

预算怎么守：给百万级用量装几道闸

算出预算只是第一步，真正难的是让它别失控。用量是渐进的，不会某天突然翻倍，所以等看到账单才发现超支，往往已经超了很久。给用量装几道闸，比事后复盘有用得多。

• 按月或按周设用量上限，超过阈值就告警，必要时直接熔断，别等账单来提醒你
• 给不同类型调用打标签：长上下文、批量任务、工具调用分开统计，出问题能立刻定位到是哪一类
• 定期复盘token去向，看哪几类任务吃掉了大部分量，评估有没有换成更小模型的余地
• 把重试和失败请求单独统计，这部分是纯损耗，控制住它对预算的贡献往往被低估

这几道闸不需要很复杂，多数后台和网关都支持按标签统计和阈值告警。关键是把它们当成日常配置，而不是出事之后才补的应急措施。用量管理和代码质量一样，是持续维护的事。