扣减费用 token 消耗量 × 模型单价

很多人第一次看账单会懵：明明只跑了几十条请求，钱怎么扣这么多。其实背后的算式很朴素——用量乘单价。麻烦的是用量口径和单价口径各自都有分支，对不上就会算错。这篇把「消耗量 × 单价」这条主线拆开，给你一套从用量记录推到扣减金额的顺序，以及算不准时该回头查哪几项。

很多人第一次看账单都会懵：明明只跑了几十条请求，钱怎么扣这么多。其实背后的算式很朴素——用量乘单价。麻烦的是用量口径和单价口径各自都有分支，对不上就会算错。这篇把「消耗量 × 单价」这条主线拆开，给你一套从用量记录推到扣减金额的顺序。

先说结论：扣减费用不是平台随手定的一个数，而是每个计价项各算一次再相加。你要做的不是背公式，而是把「数了哪些量」和「用了哪个价」这两件事分别对齐。任何一边对不上，结果就会偏。

一条主线：消耗量 × 单价 = 扣减金额

最容易被忽略的一点：一次调用里往往不止一个计价项。输入、输出、缓存读写，有时还有工具调用，每一项都是「这一项的数量 × 这一项的单价」，最后求和才是这次调用真正扣掉的钱。拿总 token 数去乘一个单价，几乎必然对不上。

计价项

账单里单独算钱的一类用量，比如输入、输出、缓存命中、工具调用

用量记录

接口返回或后台导出的数字，告诉你有多少量被计了费

最小可算模型

把用量按计价项拆成几列，每列配一个单价，最后求和

为什么不建议拿总数乘一个价：输入和输出单价通常不同，缓存命中的那部分往往又是另一个价。混在一起乘，误差会随用量放大，量越大偏得越多。正确做法是把用量记录按计价项拆开，逐项对齐单价。

消耗量那一侧：先确认你数的是什么

常见坑是把「提示词里写了几百字」当成 token 数。字符数、词数、token 数是三个不同的东西，中英文比例也不一样，手估基本没用。要算钱，就用平台实际记的那份用量，不要自己按字数推。

拿到用量数据，先看字段名再决定能不能直接乘。有些平台返回的是输入加输出的合计，有些把两者分开给，还有些把缓存命中的部分单列出来。字段口径没看清就乘，后面全是白算。

• 多轮对话不是只算最后一轮：历史上下文每轮都会重新计入输入，轮次越多，输入侧增长越快
• 失败或被拦截的请求有的计费有的不计费，导出用量时要确认这些算不算在内
• 缓存命中的部分可能按另一套规则计量，别和普通输入混在一列
• 自己算不准时，以实际账单和后台用量页为准，别拿接口返回字段硬推

1. 导出当天的用量记录从后台把明细导出来，至少要有计价项、数量、时间三个字段；导出后先看总行数和请求次数对不对得上
2. 按计价项分组把输入、输出、缓存、工具调用分别汇总，形成几列数字；如果某列是空的，先确认是真的没有还是字段没导出来
3. 和请求日志对齐抽几条具体请求，看用量记录里的数量能不能和日志对上，对不上说明口径还有一层没看到

单价那一侧：同一个模型可能有好几个价

同一个模型，走官方直连、云厂商托管、中转站，单价往往不是一回事。先把你实际用的那条路的单价口径定下来，再去乘用量，否则算出来的金额没有可比性，也没法判断贵还是便宜。

阶梯价和批量折扣会让挂牌价和实际执行价分开，结算时按哪一档走，要看当时生效的那一档。单价本身也会调整，所以这里不写具体数字：需要时到站内价格页核对当时的数字，再回到你的用量记录上乘。

拿一个具体场景走一遍，看钱花在哪

设定一个通用场景：一家 5 人小团队把一批文档丢给模型做摘要，每天几十次调用，每次都会把之前的内容带上去，历史上下文比较长，也没开缓存。这种情况下的费用结构，和很多人想的不一样。

1. 先统计当天各类用量把输入、输出各自的总量拉出来，缓存那列如果是空的就写零
2. 逐项乘当期单价用你在站内价格页核对到的当期单价，分别乘输入量和输出量，不要合并成一个总数
3. 求和并与账单对照算出总额后和账单比，看差额主要落在哪一项；差额集中在输入侧，说明上下文带太多了

这类场景的典型结果是：输出往往不是大头，反复带上去的长输入才是。所以「少带一点历史」通常比「换个更便宜的模型」见效更快。反过来，如果是短提示、单轮、无缓存的批量任务，输入输出比例接近，这时候单价差异才是主要变量。

算出来和账单不一样，按这个顺序排查

对不上不用慌，绝大多数偏差来自四类原因。按下面的顺序查，基本能在几步内定位到问题出在哪一层，而不是反复重算。

• 第一看字段：你用的用量是不是包含缓存、工具调用、失败次数；失败请求有的计费有的不计费
• 第二看时间：用量和单价的统计窗口是否一致，跨结算点的那几个小时最容易出偏差
• 第三看币种与折算：单价是外币、结算是人民币时，中间还隔着一层汇率与手续费
• 第四看口径归属：账单里可能混了别的项目或别的账号，先确认这笔扣减属于谁