缩短提示词后,应根据每个响应的 usage 和整项任务的成本来检查节省效果。简短的回答也可能伴随大量推理开销,而继续对话时,历史内容可能再次计入用量。为了控制预算,请分别核算 Token 数量、计费类别,以及完成任务所需的调用次数。

四种计数器及其包含关系
在 usage 对象示例中,OpenAI 展示了输入、输出及这两类计数器的详细信息。可按以下方式理解:
input_tokens— 本次调用的输入 Token 总量,包括用于延续对话的上下文。input_tokens_details.cached_tokens— 从缓存中读取的输入部分,已计入input_tokens。output_tokens— 生成的 Token 总量,包括推理过程。output_tokens_details.reasoning_tokens— 用于推理的输出部分。
推理 Token 已包含在 output_tokens 中;不能再将其加到输出总量里。 OpenAI 按照输出 Token 费率对其计费。同样,把 cached_tokens 再加到输入中,也会重复计算同一部分请求。要获取总量,请使用 total_tokens,或将 input_tokens + output_tokens 相加。
成本核算:按类别拆分输入
当前定价页面分别列出了普通输入、缓存输入、缓存写入和输出的费率。请选择与实际模型、处理模式及适用上下文长度相符的费率。请将精确数值保存在可版本管理的计算配置中。
当前缓存文档中有一项重要细节:对于 GPT-5.6 及更新的模型,会计入 input_tokens_details.cache_write_tokens。如果你的计费方案将缓存写入单独计费,请从普通输入中扣除这一类别,并应用其对应费率。
I = input_tokens
C = input_tokens_details.cached_tokens
W = input_tokens_details.cache_write_tokens
O = output_tokens
ordinary_input = I - C - W
cost = ((I - C - W) * P_input
+ C * P_cached
+ W * P_write
+ O * P_output) / 1_000_000
此处的价格以每百万 Token 为单位;对于没有单独写入类别的计费方案,请设置 W = 0。该公式涵盖了上述 Token 计费类别。付费工具应根据其定价条款另行列项。
示例:输入为 4000,其中缓存输入为 3000、缓存写入为 500;输出为 1000,其中推理 Token 为 600。由此得到 500 个普通输入 Token,总计 5000 个 Token。输出按 1000 个 Token 计费;保留 600 这一数值用于诊断。
继续对话时,输入用量会再次产生
手动管理历史记录时,应用会将之前的消息一并传入,再附上新的输入。包含在下一个请求中的消息会再次成为输入上下文。因此,只测量用户最新一条消息会漏算历史记录的用量。
使用 previous_response_id 时,应用会传入上一条响应的引用,由 API 关联上下文。根据延续对话的计费规则,对话链中先前的输入 Token 会再次作为输入计费。缓存可能改变这部分输入适用的费率类别;请查看每条响应中的 cached_tokens,确认实际缓存命中情况。
如何验证优化效果
- 保存基准样本。比较相同类型的任务、模型、成功标准,以及长度相近的对话。
- 记录每次调用。记录响应和任务 ID、模型、推理设置、状态、延迟和完整的
usage。同时保存提示词版本和定价配置版本。 - 汇总每项任务的成本。纳入该任务的所有调用,以及重试所产生的响应。主要指标应为成功完成任务的成本。
- 区分变化原因。分别跟踪普通输入、缓存读取与写入、输出以及推理占比。计算总体缓存占比时,用
C的总和除以I的总和。 - 检查质量和分布尾部。除平均成本外,还应比较 p95、尝试次数和任务成功率。
max_output_tokens 参数会限制生成内容和推理过程。达到上限时,响应状态可能变为 incomplete;即使没有可见文本,也可能已经消耗 Token。评估节省效果时,请将这类响应纳入统计:只有在可比任务成功完成且总成本更低时,才算达到优化目标。