作者注：拆解大模型 API 账单中的输入、输出、缓存、推理 Token 与多模态计费口径，给出按调用日志核对用量、识别“费用突变”和应对价格变化的实操方法。
月底打开账单，发现某个模型的费用比上月多出一截，但调用次数几乎没变。这是很多已经把大模型 API 用到生产环境的团队都遇到过的情况。本文介绍一套 按计费项拆解 + 按调用日志对账 的方法，帮你看懂并核对大模型 API 账单。
这不是一篇价格汇总。各厂商价格变动频繁，本文不列具体单价，只讲长期适用的计费口径和核对思路。
一个可以参考的行业信号是：2026 年 11 月，有 AI 基础设施公司在招聘大模型平台运营岗位。该岗位的职责中明确写着“成本与计费核验”，要求核验输入／输出 Token、缓存 Token、推理 Token 及图片、音视频等计费口径，并及时发现异常账单、价格变化和计费偏差。平台方需要专人做这件事，说明计费口径本身就足够复杂。作为调用方，你同样需要一套自己的对账习惯。
核心价值：读完本文，你能分清大模型 API 账单里每一类计费项的来源，知道如何用调用日志核对用量，并能快速定位“同一请求费用突变”的原因。
大模型 API 账单核心要点：5 类计费项
一次模型调用的费用，通常不是“调用次数 × 单价”这么简单。不同计费项单价不同，来源也不同。混在一起看，很容易误判成本结构。
| 计费项 | 来自哪里 | 常见计价特点 | 对账关注点 |
|---|---|---|---|
| 输入 Token | 系统提示词、历史对话、工具定义、检索文档、用户输入 | 按 Token 计，通常比输出便宜 | 上下文是否在悄悄变长 |
| 输出 Token | 模型生成的可见回复 | 按 Token 计，单价通常高于输入 | 回复长度、max_tokens 设置 |
| 缓存 Token | 被缓存命中的输入前缀 | 命中部分常有折扣，部分厂商对写入另行计价 | 命中率是否下降 |
| 推理 Token | 推理模型的内部思考过程 | 通常按输出计价，但不一定出现在回复里 | 推理长度是否增长 |
| 多模态计费 | 图片、音频、视频的输入或生成 | 按张、按秒、按分辨率或折算 Token | 规格参数是否改变 |
大模型 API 账单为什么容易“对不上”
第一个原因是看不见的 Token。你在代码里只写了一句用户提问，但实际发出的请求可能包含几千 Token 的系统提示词、多轮历史和工具 Schema。推理模型还会产生大量用户看不到的思考 Token。这些都会进入账单，却不会出现在界面上。
第二个原因是口径不统一。同样是“图片输入”，有的厂商按张计价，有的按分辨率折算成 Token。同样是“缓存”，有的厂商自动缓存，有的需要显式声明，有的只对读取打折，有的还对写入额外收费。跨模型、跨厂商对比时，必须先把口径对齐。
第三个原因是变量会漂移。模型别名可能指向了新版本，提示词前缀的一次小改动可能让缓存全部失效，推理模型面对更难的问题会思考得更久。单价没变，账单也可能变。
大模型 API 账单各计费项详解
输入 Token：最容易被低估的部分
输入 Token 是模型在本次请求中“读到”的全部内容，而不只是用户那句话。多轮对话场景下，每一轮都会把之前的历史重新发送一次。对话越长，单轮输入成本越高，总成本接近按轮数平方增长。
RAG 应用也是输入 Token 的大户。检索召回的文档片段数量、每段长度，都直接决定输入成本。Function Calling 场景下，工具定义的 JSON Schema 每次请求都会计入输入，工具越多，固定开销越大。
另外要注意，不同模型的分词器不同。同一段中文在不同模型下的 Token 数可能差别明显，不能用一个模型的 Token 数去估算另一个模型的费用。
输出 Token：单价更高，受参数直接控制
输出 Token 是模型生成的回复内容。多数厂商的输出单价明显高于输入单价，所以“让模型少说废话”往往比压缩输入更省钱。
max_tokens 是输出成本的上限，但不是保证。如果回复被截断，已经生成的部分仍然计费。流式输出中途断开时，各平台对已生成 Token 的处理方式也可能不同，需要以官方说明为准。
缓存 Token：命中才省钱
提示词缓存的原理是：当多个请求共享相同的前缀（比如同一份系统提示词或同一份长文档）时，厂商可以复用已经处理过的部分，并对这部分输入给予折扣。
缓存有几个常见规则需要逐一确认：
- 是否自动启用：有的厂商默认开启，有的需要在请求中显式标记缓存位置；
- 前缀匹配要求：通常要求从开头起逐字一致，前缀里任何一处变化都会导致后面全部失效；
- 最小长度与有效期：太短的前缀可能不缓存，缓存过期后需要重新写入；
- 写入是否收费：部分厂商对首次写入缓存按高于普通输入的价格计费，只有后续读取才便宜。
对账时，要把“缓存读取 Token”和“普通输入 Token”分开统计，否则会把命中率下降误判为调用量增长。
推理 Token：看不见但要付钱
推理模型在给出答案前会进行内部思考，这部分 Token 通常按输出单价计费。很多情况下，推理内容不会完整返回给你，你只能从用量字段中看到它的数量。
推理 Token 的数量随问题难度、推理强度参数而变化。同一个接口，用户提的问题变难了，账单就可能上涨。如果业务只需要简单分类或格式转换，用推理模型往往是在为不需要的思考买单。
多模态计费：先确认“按什么计”
多模态的计费口径差异最大，也最需要逐个模型查看官方定价页。下表是常见的计价方式，具体规则以各厂商当前公布为准。
| 类型 | 常见计价方式 | 影响费用的关键参数 | 核对建议 |
|---|---|---|---|
| 图片输入（理解） | 按分辨率折算 Token，或按张计价 | 图片尺寸、细节等级参数 | 记录上传前后的实际分辨率 |
| 图片生成 | 按张计价，或按输出 Token 计价 | 尺寸、质量档位、生成数量 | 记录每次请求的规格参数 |
| 音频输入／输出 | 按时长计价，或折算为音频 Token | 音频时长、采样处理方式 | 记录音频真实时长 |
| 语音合成 | 按字符数或按 Token 计价 | 文本长度、音色档位 | 记录合成文本长度 |
| 视频生成／理解 | 按秒、按帧或按分辨率档位计价 | 时长、分辨率、帧率 | 记录时长与分辨率组合 |
| Embedding | 按输入 Token 计价 | 文本长度、批量大小 | 与普通输入单价分开统计 |
🎯 技术建议：多模态场景最好统一走一个入口，便于把不同计费口径集中管理。API易 apiyi.com 的官方介绍中提到，平台上的模型使用统一余额，并提供用量统计和调用日志。你可以先在控制台确认日志里展示了哪些字段，再决定对账表需要补记哪些参数。
大模型 API 账单快速上手：4 步对账法
对账的核心思路是：用自己记录的用量 × 自己记录的单价快照，得到期望费用，再与平台账单对比。差异超出容忍范围，就逐项排查。
第 1 步：在每次调用后记录用量字段
OpenAI 兼容格式的接口通常会在响应中返回 usage 对象。常见字段及其含义如下，不同模型和平台的返回情况可能有差异，接入前需要实际请求一次确认。
| 字段（OpenAI 兼容格式常见写法） | 含义 | 对应计费项 |
|---|---|---|
prompt_tokens |
本次请求的输入 Token 总数 | 输入（含缓存部分） |
prompt_tokens_details.cached_tokens |
输入中命中缓存的部分 | 缓存读取 |
completion_tokens |
输出 Token 总数 | 输出（可能含推理部分） |
completion_tokens_details.reasoning_tokens |
输出中的推理部分 | 推理 |
model |
实际响应的模型名称 | 用于识别版本变化 |
建议每次调用至少落库以下信息：
- 请求时间、请求 ID、业务场景标识；
- 请求中指定的模型名 和 响应中返回的
model； - 上表中的全部用量字段，缺失的字段记为空而不是 0；
- 多模态请求的规格参数，如图片尺寸、音频时长、生成数量；
- 是否流式、是否重试、是否被截断（
finish_reason）。
注意 prompt_tokens 和 completion_tokens 往往是“总数”，缓存和推理是其中的明细。计算费用时要先把明细从总数里减出来，再分别乘以对应单价，否则会重复计费或漏算折扣。
第 2 步：维护带日期的价格快照
不要在代码里硬编码单价。建议维护一张价格快照表，每一行记录模型名、计费项、单价、币种、生效日期和来源（官方定价页或平台公告）。
价格调整时新增一行，而不是覆盖旧值。这样回溯任意一天的账单时，都能用当时的价格重新计算。如果你通过 API易 这类聚合平台调用，单价应以平台当前公布的价格为准，并同样标注查询日期。
第 3 步：计算期望费用
单次期望费用可以拆成几项相加：
- 未命中缓存的输入 Token × 输入单价；
- 缓存读取 Token × 缓存读取单价（如有缓存写入计费，另加写入部分）；
- 可见输出 Token × 输出单价；
- 推理 Token × 推理对应单价（多数情况下与输出相同，以官方说明为准）；
- 多模态部分按各自口径单独计算。
按天、按模型、按业务场景汇总后，就得到了一份“你认为应该花多少钱”的账本。
第 4 步：与平台日志和账单比对
把自己的账本和平台的用量统计、调用日志放在一起对比。先比总额，再比分模型金额，最后定位到具体请求。
建议设一个容忍阈值。由于汇率、计费精度、统计时区等原因，小幅差异很常见；超过阈值的部分才需要逐项排查。
🚀 快速开始：如果你已经在 API易 apiyi.com 上调用模型，可以先导出一段时间的调用日志，与自己记录的
usage字段逐条对齐。日志中是否单独区分缓存 Token 和推理 Token，以平台当前提供的字段为准；如果没有单独列出，就以你本地记录的响应字段作为明细依据。
大模型 API 账单异常信号：费用突变怎么查
同一类请求的费用突然变化，是最值得警惕的信号。下表列出了常见原因和排查方向。
| 异常现象 | 可能原因 | 排查方法 |
|---|---|---|
| 单次费用上涨，调用量不变 | 模型别名指向了新版本，单价或 Token 消耗不同 | 对比响应中的 model 字段前后变化 |
| 输入费用上涨，输入 Token 总数不变 | 缓存命中率下降 | 查看 cached_tokens 占比，检查提示词前缀是否被改动 |
| 输出费用上涨，可见回复长度不变 | 推理 Token 增长 | 查看 reasoning_tokens 趋势，检查推理强度参数 |
| 输入 Token 持续缓慢上升 | 对话历史未截断、检索片段变多、工具定义增加 | 抽样查看完整请求体 |
| 调用次数比业务量多 | 客户端重试、超时后重发 | 按请求 ID 和业务 ID 去重统计 |
| 图片或视频费用突增 | 分辨率、质量档位或生成数量被改大 | 对比请求中的规格参数 |
| 账单单价与快照不一致 | 官方或平台调价 | 查阅定价页和公告，更新价格快照 |
缓存失效：最隐蔽的成本上涨
缓存失效常常来自一次“看起来无害”的改动。比如在系统提示词开头加了当前日期，或者把用户 ID 插在了前缀里。这样每个请求的前缀都不同，缓存会全部失效，输入成本直接回到原价。
正确做法是把固定内容放在最前面，把变化的内容放在最后面。改动提示词模板后，第二天就去看缓存命中占比有没有变化。
推理长度漂移：难度变化也会影响账单
推理模型的费用和问题难度相关。如果某天用户突然集中提了一批复杂问题，推理 Token 会明显上升，这属于正常波动。但如果推理 Token 在请求类型不变的情况下持续增长，就要检查是否换了模型版本或推理参数。
大模型 API 账单应对价格变化的检查习惯
价格变化本身不可控，但发现得早晚可以控制。下面是一套可以长期坚持的检查习惯：
- 每周：看一次分模型的费用趋势和单次平均成本，关注突变点；
- 每月：完整对账一次，差异超过阈值的逐项定位原因；
- 每次改提示词模板后：观察 1-2 天的缓存命中占比；
- 每次切换或升级模型前：用小流量对比新旧模型的 Token 消耗和费用；
- 关注公告：订阅所用厂商或平台的价格与模型更新公告，收到后立即更新价格快照；
- 锁定版本：生产环境尽量使用带具体版本号的模型名，避免别名自动升级带来意外。
💡 选择建议：如果业务同时用到多个厂商的模型，分散在多个账户里对账会非常耗时。通过 API易 apiyi.com 统一接入，可以在同一个余额、同一套日志里查看不同模型的用量，方便横向对比单次成本。具体能看到的明细维度，建议先在控制台核实。
常见问题 FAQ
Q1：什么是大模型 API 账单里的 Token？
Token 是模型处理文本的基本单位，可以理解为分词后的片段。一个中文字可能对应一个或多个 Token，具体取决于模型的分词器。账单通常按输入、输出、缓存、推理等不同类别的 Token 数量分别计价。
Q2：缓存 Token 和普通输入 Token 有什么区别？
两者都属于输入，但缓存 Token 是命中了已缓存前缀的部分，通常享受折扣。普通输入 Token 按原价计费。部分厂商还对首次写入缓存单独收费，因此对账时三者要分开统计。
Q3：推理 Token 为什么在回复里看不到？
推理 Token 是模型内部思考产生的，很多模型不会把完整推理过程返回给调用方，只在用量字段中给出数量。它通常按输出单价计费，所以即使回复很短，费用也可能不低。
Q4：同一个请求的费用为什么会突然变化？
最常见的原因有三个：模型别名指向了新版本、提示词前缀变化导致缓存失效、推理长度增加。其次是重试导致的重复计费，以及多模态规格参数被调大。按本文的异常信号表逐项检查即可定位。
Q5：如何借助平台日志核对自己的大模型 API 账单？
先在自己的系统里记录每次响应的 `usage` 字段和请求 ID，再导出平台的调用日志按请求逐条对齐。以 API易 apiyi.com 为例，可以在控制台查看用量统计和调用日志，先确认日志中包含哪些字段，再与本地记录合并对账。
Q6：多模态模型的费用应该怎么估算？
先查官方定价页确认计价方式：按张、按秒，还是按分辨率折算 Token。然后在请求日志中记录对应的规格参数，例如图片尺寸、音频时长、视频分辨率和时长，用这些参数乘以单价估算。
Q7：对账发现差异时，先查哪里？
先确认价格快照是否最新，排除调价因素。再比对调用次数，排除重试和重复请求。最后按模型、按计费项拆分差异，找出是输入、缓存、推理还是多模态部分出了偏差。
Q8：这套对账方法有哪些局限？
它依赖响应中返回的用量字段，如果某些模型或接口不返回缓存、推理明细，就只能依赖平台账单。另外汇率、计费精度和统计时区会造成小幅差异，需要设置合理阈值，而不是追求分毫不差。
大模型 API 账单核心要点 Key Takeaways
- 费用由多类计费项构成：输入、输出、缓存、推理和多模态单价各不相同，需分开统计。
- 输入 Token 远不止用户提问：系统提示词、历史、检索文档、工具定义都计入输入。
- 缓存命中靠前缀一致：固定内容放前面，变量放后面，改模板后检查命中率。
- 推理 Token 看不见但收费：简单任务避免用推理模型，关注推理长度趋势。
- 多模态先问“按什么计”：按张、按秒或按分辨率折算，以官方定价页为准。
- 对账四步走：记录用量、维护价格快照、计算期望费用、与日志账单比对。
- 统一入口便于对账：可借助 API易 apiyi.com 的统一余额与调用日志集中核对多模型用量。
总结
看懂并核对大模型 API 账单的关键在于三点：
- 拆开看：把一次调用的费用拆成输入、缓存、输出、推理、多模态几部分，分别对应来源；
- 自己记：每次调用落库用量字段和规格参数，维护带日期的价格快照；
- 定期比：每周看趋势，每月对总账，费用突变时按模型版本、缓存命中、推理长度、重试、规格参数逐项排查。
平台运营方会专门核验这些计费口径，作为调用方，建立自己的对账习惯同样必要。如果你的业务需要同时调用多家模型，推荐通过 API易 apiyi.com 统一接入，在一个控制台里查看用量与调用日志，再结合本文方法完成核对。
📚 参考资料
- V2EX 招聘帖：AI Agent 基础设施公司大模型平台运营岗位：岗位职责中列出“成本与计费核验”
- 链接：
v2ex.com/t/1254263 -
说明：2026-11-03 发布，描述了平台侧需核验输入／输出 Token、缓存 Token、推理 Token 及图片、音视频等计费口径，并发现异常账单、价格变化和计费偏差
-
各模型厂商官方定价页：具体单价与计费规则的唯一权威来源
- 链接：请在所用厂商官网的定价或文档栏目中查询
- 说明：价格变动频繁，引用时务必记录查询日期
作者：APIYI 技术团队
技术交流：对大模型 API 账单核对有疑问，欢迎通过 API易 apiyi.com 首页联系我们，更多接入资料可查阅 docs.apiyi.com 文档中心
