计费说明

我们采用按实际用量计费——用多少算多少，不预扣、不设最低消费。

价格以合同为准

本站面向企业客户提供定向服务，具体单价与结算方式以双方签订的合约为准。 本文只说明计费机制，帮助你理解账单是怎么算出来的。 签约客户可在控制台查看自己的实际用量与账单明细。

计费单位

按 token 计费。token 是模型处理文本的基本单位：

• 中文约 1 个字 ≈ 1～2 个 token（不同模型的分词方式略有差异）
• 英文约 1 个单词 ≈ 1.3 个 token

每次请求的返回体里都带 usage 字段，明确告诉你这次用了多少：

"usage": {
  "prompt_tokens": 12,      // 输入 token
  "completion_tokens": 34,  // 输出 token
  "total_tokens": 46
}

输入与输出分别计价

输入（你发给模型的内容）和输出（模型生成的内容）单价不同，通常输出单价高于输入。 这与 OpenAI 的计费方式一致。

按上下文长度分段计价

部分模型（豆包 2.0 系列）采用分段计价：根据本次请求的输入长度落入的区间， 整个请求套用对应档位的单价。

输入长度区间	说明
0 ～ 32K	短上下文，单价最低
32K ～ 128K	中等上下文
128K ～ 256K	长上下文，单价最高

分段是按「整个请求」套用

举例：若某次请求输入 130K token，落入「128K～256K」区间， 则该请求的全部输入与输出 token 都按该档单价计算，而非分段累加。

建议：如果对成本敏感，尽量把单次请求的上下文控制在 32K 以内。

缓存命中更便宜

部分模型支持上下文缓存。当请求的前缀与之前请求重合时，命中的部分按更低的缓存单价计费， 可显著降低成本。

缓存是怎么算的

返回体的 usage 中会出现 cached_tokens，表示本次命中缓存的 token 数。 这部分计入 prompt_tokens，但按缓存单价（通常远低于正常输入价）结算。 多轮对话、固定系统提示词等场景容易命中缓存。

额度与余额

• 你的账户有余额，每次调用后按实际用量扣减。
• 控制台「钱包」可查看余额与变动记录；「使用日志」可查看每一笔调用的 模型、token 数与扣费金额。
• 余额低于阈值时，系统会自动发邮件提醒你（可在控制台设置提醒阈值）。

查看与对账

登录控制台可自助查询：

页面	用途
使用日志	逐笔调用明细：时间、模型、token、金额，可按时间筛选并导出
钱包	余额、充值记录、账单历史
数据看板	用量趋势统计，按模型/时间维度

对账建议

建议每月导出一次「使用日志」留存，与合约结算单核对。 所有金额均可追溯到具体调用记录。

费用会在什么时候产生

• 只在成功调用时计费。请求因参数错误、鉴权失败等原因被拒绝时不产生费用。
• 流式输出（stream: true）同样按实际生成的 token 计费，未生成完即断开时只计算已生成部分。

想控制成本

1. 选对模型 —— 简单任务用轻量模型（如 glm-5-3-flash-260828）成本可低数倍。
2. 控制上下文长度 —— 避免无意中把超长内容塞进请求，尤其是分段计价的模型。
3. 给密钥设额度上限 —— 防止单个应用异常导致超支。
4. 监控用量 —— 用数据看板观察趋势，额度预警邮件别忽略。

如有计费疑问，请联系平台商务。