接入豆包API之后，经常有人发现结算金额跟自己的估算对不上：明明只跑了几轮对话，账却比预期高；或者同一份用量，两个入口给出的数字不一样。问题多数不在价格本身，而在计费口径没说清——哪些token计入、按什么单位收费、免费额度和付费额度怎么衔接。这篇不报数字，只讲口径和动作：把豆包API的收费结构拆成几块，教你到站内哪几页核对当期价格，以及怎么用自己的用量日志反推真实花费。
接入豆包API之后，经常有人发现结算金额跟自己的估算对不上：明明只跑了几轮对话，账却比预期高；或者同一份用量，两个入口给出的数字不一样。问题多数不在价格本身，而在计费口径没说清。这篇不报数字，只讲口径和动作，帮你把收费结构拆开，再到站内把当期数字核对上。
先明确一件事：下面讲的都是「怎么算、去哪看」，不是「多少钱」。任何具体单价都会变，也会随活动和套餐调整，凡是涉及数字的地方，一律以站内页面当页展示的内容为准，别拿别人截图里的旧值去套自己的项目。
先搞清豆包API收费收的是哪几块
不管哪家厂商，API账单基本都由输入token和输出token两块组成，个别能力还会按次或按秒另计。第一步不是去查单价，而是先把自己的调用分类：哪些是纯文本对话，哪些带函数调用，哪些走结构化输出。同一个模型用不同能力，结算方式可能不一样，别用单一单价去乘全部调用量。
- 输入token
- 你发给模型的提示词、上下文、历史消息所占的计量单位，通常计入输入侧
- 输出token
- 模型生成并返回给你的内容所占的计量单位，通常计入输出侧，单价口径常与输入不同
- 按次计费
- 与token量无关、按调用次数结算的能力项，量小但单价固定，容易被漏算
- 按秒计费
- 部分实时类能力按占用时长结算，和文本token是两套账，要单独看
核对当期数字时，别绕到各种按量计费的中间页面对照，直接去站内的官方API资料库按厂商翻，豆包相关的单价和计费单位以那个页面当页展示为准。中途任何跳转页都可能不是最新口径。
- 把你的调用按「纯token」「按次」「按秒」分成三类，分别记账
- 每一类只认一个价格来源：站内官方API资料库对应厂商页
- 发现某类调用量小但账单占比高，优先怀疑它属于按次或按秒项
- 换模型或换能力前，重新确认一次计费单位，别默认沿用旧口径
免费额度与付费额度怎么衔接
免费额度通常有独立的重置周期和适用范围，用完之后是直接停掉，还是自动转成按量扣费，取决于你账号当时的开关状态。很多人算不准账，就是没先确认自己处在哪一档：以为还在免费段，其实已经在扣付费额度。
| 账号状态 | 用量页看到的现象 | 成本怎么算 |
|---|---|---|
| 纯免费段 | 剩余额度按周期在减少 | 只记用量，不折算金额 |
| 免费转付费 | 剩余额度不再按周期重置 | 按付费口径折算，别混用免费单价 |
| 全程付费 | 无免费额度条目 | 用量乘当期单价即为理论成本 |
| 含套餐/包量 | 存在单独的包量余额项 | 先扣包量再扣按量，两段口径不同 |
免费额度和付费额度混用时，账单上的「用量」和「实付」不是一回事。成本分摊要按实际扣费口径算，不能拿总token量直接乘一个单价。判断自己是不是已经进入付费段，看用量页的剩余额度变化比翻账单更快；同类调用量的普遍水平，可以到站内用量页面做横向对照。
用自己的用量日志反推豆包API花费
想搞清楚钱花在哪，最靠谱的方式不是看账单汇总，而是用自己的调用日志反推。只要你把每次调用的关键字段记下来，输入输出分开统计，再乘当期单价相加，得到的理论成本就能和实际账单对照。差额就是还没对齐的口径。
- 记四个字段每次调用记录：调用时间、模型名、输入token数、输出token数。字段维度可参考站内用量页展示的项，别自己发明一套对不上的口径
- 分类汇总按模型名分组，分别汇总输入和输出token总量。带函数调用或结构化输出的，单独拉一组
- 代入当期单价到站内官方API资料库找对应厂商当页单价，输入输出分别乘，再相加，得到理论成本
- 和账单比差额理论成本和实际扣费差异明显，说明有缓存、重试或长上下文导致的重复计入；若差额稳定，多半只是免费额度抵扣，属于正常
- 换算单次对话把平均输入输出token数代入站内token价格计算工具，就能估算一次典型对话大概落在什么区间
这里要提醒一点：差额长期偏大，八成不是价格算错，而是你的调用里混进了重复计入的部分，比如失败重试、长上下文重复携带、缓存没命中。这类口径问题的排查方法，站内另一篇讲token成本的稿子里已经写透了，这里不重复，只提醒你把它单独拎出来看，别混进单价乘算里。
接入前后各做一遍的核对清单
下面这张清单分三个阶段，接入前、接入后第一周、跑量阶段各做一遍。它不是一次性的，换模型、换能力、换渠道都要重跑一遍，因为每一环都可能改变计费口径。
- 接入前：确认要用的模型和能力分别属于哪种计费单位，是纯按token还是含按次项；单价来源固定在站内官方API资料库，不要凭记忆或截图
- 接入后：第一周每天对一次用量和余额，把异常增长的调用挑出来，先查是不是长上下文或失败重试导致
- 跑量阶段：给账号设预算告警，阈值按你能接受的一晚跑飞上限来定，别等月底看账单才发现
- 走中转渠道时：倍率和折算规则另算，要以站内中转站目录里对应站点的说明为准，别直接套官方单价
| 阶段 | 动作 | 判断标准 |
|---|---|---|
| 接入前 | 固化单价来源、区分计费单位 | 同一模型只认一个页面口径 |
| 接入后一周 | 每日对账、挑异常调用 | 用量增长是否和业务量同步 |
| 跑量阶段 | 设预算告警、定期复核 | 告警触发时先查重试和长上下文 |
| 用中转渠道 | 读该站点说明、单独核算 | 实际扣费是否吻合站点折算规则 |
需要补充一句适用范围：如果你的调用量本身很小，比如每天就几十次，那上面这套逐条对账的收益有限，按周看一次余额就够了，不必每天折腾。反过来，只要你的应用出现长上下文、批量并发或自动重试，这套核对动作就不能省。
下一步把当期的模型单价、计费单位和免费额度规则核对清楚，再决定你的成本模型怎么搭；这些数字一直在动，别用旧截图。→常见问题
豆包API的单价在哪里看，会不会经常变？
单价属于会调整的信息，写死在文章里没有意义。正确做法是每次测算前打开站内 /official-api ，找到对应厂商和模型，以当页当前展示为准。如果你用中转渠道，还要再看 /sites 里该站点的倍率说明，两个口径不能混着乘。
免费额度没用完，会先扣哪一部分？
一般会优先消耗免费额度，用尽后再走付费。但具体顺序和是否自动续扣，跟账号设置有关，不能想当然。稳妥的做法是在接入初期每天看一眼用量页的剩余变化，确认扣减顺序跟你预期一致，再放开调用量。
为什么我按单价算出来的钱，和账单差挺多？
常见原因是漏算了输出token、重试产生的重复调用，或者长上下文把输入量抬高了好几倍。先把用量日志里的输入输出分别累加，再乘当期单价对比一次；如果还对不上，去 token-cost 那篇按缓存和口径逐项排查，多半能定位到。
