算清一次请求的成本

三个变量

1. 输入单价：按每百万输入 token 计。
2. 输出单价：按每百万输出 token 计，多数服务高于输入，因为输出要逐个生成。
3. 用量：一次请求实际用了多少输入、多少输出。

算式

成本 = 输入 token × 输入单价 + 输出 token × 输出单价

举例（单价是示例，不是任何厂商的报价，以你所用服务公示为准）：

• 输入 2,000 token，单价 $0.15 / 百万
• 输出 500 token，单价 $0.60 / 百万

计算：2,000 ÷ 1,000,000 × 0.15 = $0.0003；500 ÷ 1,000,000 × 0.60 = $0.0003。 合计约 $0.0006，不到一分钱。

单次很便宜，所以真正的成本问题从来不是「一次多少钱」，而是「一天多少次」。

三笔容易被忽略的开销

• 重试：失败重发，输入 token 要再算一次。客户端自动重试时，你往往完全无感。
• 多轮对话：每一轮都要把历史重新发一遍。第 N 轮的输入约等于前 N−1 轮的全部内容，累计成本随轮数快速上涨。
• 长上下文：每次带 5 万字，就是每次都按 5 万字计费，哪怕问题只有一个。

余额掉得比预期快，通常就是这三件事之一，排查顺序见余额掉得特别快。

设三道上限

1. 单次：给 max_tokens 设上限，堵住失控的长输出。
2. 每天：按 key 或按用户设配额，避免一个脚本跑飞。
3. 告警：用量到 70% 时通知，而不是等到欠费。

自测

1. 一段 1,000 token 的对话连续追问 10 轮，累计输入 token 大约是多少？为什么不是 1 万？
2. 为什么给 max_tokens 设上限能省钱？
3. 你的场景一天 1 万次请求，单次成本 $0.0006，一个月大约多少？