Token费用和API调用费的区别

第一次拿到账单时最容易犯迷糊：明明这几天只是调了几百次接口，钱却花在看不见的 token 上；反过来，有时候调用次数堆得很多，token 却没涨多少。这两笔钱是两套口径，混在一起估预算必然估歪。这篇把 token 费用和调用费各自的计费单位、触发条件、怎么分别核对讲清楚，最后给一套按天拆账的动作清单。

第一次拿到账单时最容易犯迷糊：明明这几天只是调了几百次接口，钱却花在看不见的 token 上；反过来，有时候调用次数堆得很多，token 却没涨多少。这两笔钱是两套口径，混在一起估预算必然估歪。这篇把 token 费用和调用费各自的计费单位、触发条件、怎么分别核对讲清楚，最后给一套按天拆账的动作清单。

先把结论摆前面：token 费是「你喂了多少内容、模型吐了多少字」的钱，调用费是「你敲了几次门」的钱。大部分按量接口把两者合在一起，只在 token 上加价，所以你感觉不到调用费存在；但图像、语音、嵌入、部分工具接口是按次、按秒或按字符单独收，这时候两笔账就分家了。

一笔请求为什么会拆成两笔账

• token 费用按输入输出字数算，是「用了多少内容」的钱；调用费按请求次数或订阅额度算，是「敲了几次门」的钱
• 大多数按量接口把两者合一，只在 token 上加价，所以你会觉得没有调用费；但图片、语音、嵌入、部分工具接口往往按次或按秒单独计价
• 订阅制套餐是第三种口径：固定月费买的是额度，超额才回到按量；判断时要先分清自己在按量还是套餐里
• 哪家什么口径，去 /official-api 看对应厂商页当期的说明，别拿别人家的规则套

token 这一侧：什么在涨，什么不涨

涨的永远是输入加输出的总量，而输入不只是你打的那句话。系统提示、历史对话、文档切片、工具返回的结构化结果，全都算输入。很多团队月底发现 token 费爆表，问题不在用户问得多，而在每次请求都顺手塞了一整段检索结果进去。

会涨的部分

系统提示、多轮历史、文档切片、工具返回值、模型输出正文

通常不涨的部分

请求失败被拒、鉴权不过、被自己的网关或限流挡下

能降单价的三类开关

缓存命中、批处理通道、小模型分流

去哪核数字

到 /tools/token-price-calculator 换算，到 /price-watch 看变动

判断标准很简单：一条稳定运行的请求，它的输入长度应该是可预测的。如果同一类请求的 token 波动超过预期，先查是不是把上下文越堆越长，而不是先怀疑单价变了。单价确实会变，但那个数字要到站内页面看当时的，不要凭记忆估。

调用费这一侧：次数、时长、并发怎么算

• 按次计价的接口（图像生成、语音合成、部分检索与嵌入）看的是请求条数，长文本被切成多段就是多笔，切分策略直接决定花多少钱
• 按时长或字符计价的（转写、配音）看的是音频长度，跟 token 无关，压缩码率不省钱，缩短时长才省
• 有些平台对并发和速率另设档位费用，等于为「同时能开几条」付钱，而不是为内容付钱，团队规模一大这笔就显出来
• 要确认自己踩的是哪种，去 /ai-nav/category/ai-model-platform 按平台翻计费与限制那一栏

把两笔钱分开核对的顺序

1. 第一步：找次数栏先看总账里有没有独立的「调用次数」这一栏。没有，就说明这家是按量合并计价，你只需要盯 token，不用去算调用费。
2. 第二步：按请求类型分堆把生成类、转写类、嵌入类请求分开统计。它们大概率不共享同一套单位，混在一起算平均成本没有意义。
3. 第三步：算两条单位成本拿当天总费用除以有效请求数，再除以总 token 数。两条曲线走势不一致的那几天，就是费用波动的来源。
4. 第四步：做一次对照实验同一提示词，跑短问短答和长上下文各一轮。看费用差落在哪一侧，比逐页读计费文档快得多。
5. 第五步：把日志字段补齐至少记下模型名、输入输出 token、请求次数和状态码。字段清单可参考 /tools 里本地工具的导出格式，方便后续自动对账。

这套顺序的适用边界要说清：它适合请求结构相对稳定、按量计费的团队。如果你在订阅套餐里，或者业务量小到每月只有几百次调用，拆账的收益不如直接把额度用完再评估；这时候重点应该放在套餐额度是否够用，而不是逐日拆 token。

还有一个提醒：两笔钱分开估之后，不要立刻拿估算值去卡预算上限。估算的意义是让你知道钱花在哪一侧、哪一天开始偏离，而不是给业务设死线。真正要盯的是趋势，不是某一天的绝对值。

账单上分不清的两笔钱，到业务上就是分不清的两个问题：内容变多了，还是动作变多了。