账单是怎么算的：输入与输出

你在一段长对话里只问了「那第二项呢」，账单却可能比第一轮更高。原因是模型要理解「第二项」指什么，本轮推理通常还会纳入前面的指令、资料和对话。界面上新增了六个字，不代表这次请求只处理六个字；API 用量要看本轮实际计入的输入、输出、缓存及其他类别。

先给答案

一次调用通常分别统计输入和输出。多轮对话若把历史再次纳入本轮上下文，历史会再次成为输入并参与计量；是否由应用重发、服务端引用，是否命中缓存，以及推理 token 如何计入，要以具体 API 的用量字段和文档为准。

输入、输出和上下文是三件事

Token 是模型处理文本等内容时使用的离散单位，不等同于稳定的「一个汉字」或「一个单词」。同一句话换模型、分词器或语言，token 数都可能变化；图片、音频等输入也可能按各自规则换算。因此，估算可以用厂商的计数工具，结算应以响应中的 usage 或账单记录为准。

输入与输出 token 是一次调用的两个主要方向。输入可能包括系统指令、用户问题、检索到的资料、工具定义、图片，以及为延续对话而提供的历史；输出是模型本轮生成并由接口计量的内容。部分推理模型还会报告推理或思考相关用量，其可见性和计费归类因产品而异，不能假定响应里看不到就没有消耗。

还要区分上下文窗口：它是模型一次推理能处理的上下文容量约束，不是免费额度。不同 API 对输入与最大输出如何共享窗口、超限时返回错误还是截断历史，做法并不相同。应用若自动裁掉最早消息，用户可能没有看到报错，却会发现模型「忘了」开头；应用若不截断，请求可能直接失败。上线前必须实际测试目标接口。

多轮对话为什么会重复处理历史

多轮对话是应用让当前请求带上先前交流，使模型能继续理解上下文。传统无状态接口通常由应用把需要的历史消息重新提交；有些新接口允许用会话或响应标识引用服务端保存的状态。后者简化了代码，但不代表历史不再进入模型，也不自动代表这部分免费。厂商通常仍按本轮实际输入、缓存输入或其他用量类别报告。

用一个简化例子看增长。第一轮输入为 800 token，输出 200；第二轮若带上第一轮输入和输出，再加 50 token 新问题，本轮可见输入约为 1,050 token，然后再生成新输出。第三轮继续保留前两轮，输入还会增长。这里的数字只用于展示结构，实际还会有系统指令、消息格式和工具定义等开销。

所以历史的「重复计费」更准确的说法是：只要旧内容再次成为本轮计量的输入，就会再次产生输入用量；命中提示词缓存时，重复前缀可能进入单独的缓存输入类别并采用不同费率。它不是把过去账单原样收第二次，也不是所有聊天产品都按 API 单次向用户展示费用。企业核算应看自身购买产品的计费说明。

从 usage 字段还原真实成本

不要拿聊天框里看到的字符数推账单。应为每次请求保存：模型与版本、请求时间、业务场景、输入 token、输出 token、缓存读取或写入 token、推理相关 token、错误与重试次数。日志里不要保存不必要的原始敏感内容，可以保存请求标识、分类和聚合用量。

成本优化也应先找结构，不先压缩每句话。固定系统指令是否过长？整本手册是否每轮都发送？工具定义是否包含未使用接口？历史是否可以摘要？检索是否只返回相关片段？输出是否设置了合理上限？例如一个客服流程只需要订单状态，却每轮附上完整产品目录，删掉无关资料往往比要求模型「回答短一点」节省更多输入。

摘要历史有代价：它可能遗漏承诺、数字和否定条件。更稳妥的做法是把订单号、用户选择、审批状态等关键事实存入结构化字段，把闲聊压缩成摘要，并在需要时允许回看原始记录。这样既控制窗口增长，也不会把业务状态完全寄托在一段模型摘要上。

自己试一下

如果你有能返回 usage 的 API 控制台，可在 2026 年 8 月 27 日之后用同一模型做三次测试。第一轮发送一段约千字的虚构公司制度并问「列出三条规则」；第二轮连同历史问「把第二条改成一句话」；第三轮新开会话，只粘贴第二条并提出同样要求。记录每轮的输入、输出和缓存相关字段。

通常第二轮输入会包含可见历史，明显高于那句新问题本身；第三轮因为只提供必要片段，输入下降。若第二轮命中缓存，标准输入与缓存输入的拆分可能不同。没有 API 时，也可以让厂商官方 token 计数器分别计算三份请求，但这只能估算，不能替代账单。模型和接口会更新，你试的时候结果可能不同，重点是比较「新消息长度」与「本轮实际输入」的差别。

常见误解

「上下文窗口越大，聊天就越省钱。」 大窗口只是允许一次放入更多内容，不会自动减少用量。把无关历史塞满大窗口，仍可能增加延迟和成本，还会干扰回答。

「服务端替我保存会话，旧消息就不计输入。」 状态管理和模型计量是两层事情。引用会话标识可能免去客户端重发文本，但历史仍可能被取回并参与本轮推理；应看响应的官方用量字段，而不是根据请求体大小推断。

三句话总结

文本模型 API 通常分别记录输入与输出用量，具体费率和细分项仍以产品文档为准。
历史只要再次进入本轮上下文，就可能再次形成输入用量，缓存命中则另按产品规则统计。
每次请求都记录 usage，才能发现长指令、整份资料、工具定义和历史增长造成的真实开销。

如果你要做决定

要求供应商提供一份真实多轮请求的 usage 样例，标清标准输入、缓存输入、输出、推理用量与重试如何计费。再用你自己的长对话样本跑十轮，不能只用单轮演示估算月度成本。