很多人第一次看用量明细会愣住：明明只发了一段话，为什么输入比输出贵、为什么缓存那两项单独列出来、为什么同一个模型两段用量单价不一样。这篇不讲虚的，把 token 计费的几种模式逐项拆开对，告诉你在哪种用法下该盯哪一栏，以及怎么用这些口径去选模型、做预算。
很多人第一次翻用量明细会愣住：明明只发了一段话，账单上却给你拆成好几栏，输入一栏、输出一栏，中间还插着缓存相关的两栏，同一个模型前后两段用量单价还不一样。这不是平台在玩花样，而是 token 计费本来就有好几套口径叠在一起。搞不清这些口径，你连自己钱花在哪都不知道，更别说优化。
这篇不讲虚的，把输入输出、缓存命中、阶梯计费、批量错峰这几种模式逐项拆开对，告诉你哪种用法下该盯哪一栏，怎么用这些口径去选模型、做预算。看之前建议手边开着站点里的价格对照页，边看边核对自己常调的那几个模型。
先分清：输入和输出是两笔不同的账
token 计费最容易踩的坑，就是把输入和输出揉成一个均价来看。实际是两个独立单价：你写进提示词的部分按输入算，模型生成出来的部分按输出算，两边各自累计各自的量。同一个模型上，输出单价普遍高于输入单价，所以「回答写得长不长」对账单的影响，往往比「提示词写得多不多」更大。
- 写进提示词、上下文、示例的部分计入输入；模型吐出来的回答、补全、推理过程计入输出
- 有些模型把思考链、推理过程这类中间产物也算进输出，看明细前先确认这一项有没有单列
- 同一个模型两段用量单价不同，多半是命中了阶梯或缓存，不是记错账
- 自测方法：挑一次真实调用，把提示词和回答分别贴进站内的 token 换算工具算一遍，看两边各占多少
缓存命中与未命中：同一段前缀为什么两个价
带缓存的计费通常拆成写入和读取两步。第一次把一段长前缀送进去算写入，之后复用这段前缀算读取，读取单价一般低于写入，也低于普通输入。这就是为什么明细里会出现两栏跟缓存有关的用量——它们不是重复收费，而是同一段内容在不同时点的两种计价方式。命中不是自动的，得前缀完全一致才能复用，中间改一个字就可能整段重算。
所以缓存不是「用过就省」，而是「别乱改前缀才省」。超时也会失效，隔太久再调同一段前缀，可能要重新走一遍写入。批量任务和交互式任务在这点上表现完全不同：批量任务短时间内反复调，命中率高；交互式对话每次内容都在变，命中率往往很低。
| 场景 | 缓存有没有用 | 怎么判断 |
|---|---|---|
| 固定长系统提示 + 大量短问题 | 有用，前缀稳定 | 前缀基本不变，读取量应远大于写入量 |
| 每轮对话内容都不同 | 基本没用 | 前缀频繁变动，写入量居高不下 |
| 一次性长文档处理 | 看是否重复调用 | 同一份文档只调一次，缓存没机会复用 |
| 短提示词 | 收益有限 | 前缀本来就短，写入的绝对值很小 |
阶梯计费：用量越大单价越低，但门槛在哪
阶梯价一般按某个统计周期内的总用量分档，没跨过门槛就按上一档单价结算。关键分歧在于跨档之后怎么算：有的是整段用量都按新单价重算，有的是只有超出门槛的部分按新价算，这两种口径出来的结果差很多。选平台或谈价之前，先把这三件事问清楚。
- 确认统计周期是按自然月、按账期还是按滚动周期统计，周期不同，你落在哪一档就不同。
- 确认重算口径跨档后是整段重算还是超出部分重算，直接问对接人或翻价格说明里的细则。
- 确认生效时点跨档是立刻生效还是下个周期才生效，影响你这个月还能不能赶上新价。
- 对照实际用量把当前周期的真实用量记下来，到站点官方 API 价格页核对自己在哪一档，再决定要不要往上一档靠。
批量与错峰：同一种调用为什么能有两个价
批量通道把请求攒起来异步处理，用等待换折扣；实时通道要低延迟，单价更高。这两者不是同一件商品，别拿一个的价去要求另一个。适不适用只取决于一件事：这个任务的结果能不能等。能等的走批量，要立刻回给用户的走实时，不要一律图便宜。
- 错峰折扣和阶梯折扣可能叠加也可能互斥，规则要在具体平台的价格说明里逐条对，别按经验套
- 排查顺序：先确认任务是否可延迟，再看该模型是否提供批量通道，最后才比较两条通道的价差是否值得改造调用逻辑
- 需要立刻返回结果的场景，比如面向用户的实时问答，不要为了省钱硬塞进批量通道
- 结果可以等到下一批处理的场景，比如离线打标、批量摘要，优先看批量通道
别把按 token 的账和别的计费单位混着算
有些模型按次、按字符、按分钟、按张或按秒计费，和按 token 的账混在一张表里加总，结论一定是错的。同一条链路里不同环节的计费单位也常常不一样，比如检索阶段按次、生成阶段按 token，结算方式完全不同。对齐口径再比价，不然你比的是苹果和橘子。
| 计费单位 | 典型场景 | 比价时的坑 |
|---|---|---|
| 按 token | 文本生成、对话 | 输入输出要分开看，别合一个均价 |
| 按次 | 检索、分类、固定长度任务 | 单次价低不代表总量低，看调用次数 |
| 按分钟/秒 | 语音、音视频处理 | 和按 token 的账单不能直接加总 |
| 按张 | 图像生成、识别 | 分辨率、尺寸可能影响结算，要问清 |
从用量明细倒着看懂自己的账单
真正的动作是把明细按四项拉平：普通输入、缓存写入、缓存读取、输出。这四项的比例基本决定了你的成本结构长什么样，比盯着单价表空想有用得多。拿到比例之后，你才知道该往哪使劲——改提示词结构、压回答长度、换更便宜的模型，这三件事的收益完全不一样。
- 缓存写入远大于读取：说明前缀老在变，先检查系统提示词是不是每次都在改
- 输出占比极高：说明回答太长，或者任务本身就是生成型，重点压输出
- 普通输入占比居高不下：考虑把固定不变的部分前置，看能不能命中缓存
- 四项都很平均：没有明显短板，优化空间有限，优先看能不能换更合适的模型
每月做一次这个动作，配合站内用量页面里的真实数字对照，比空想强。不用追求一步到位，先把最大的那一项搞清楚就够了。
按任务类型选计费模式：一张对照清单
把前面的口径收拢成一张对照清单，按你的任务类型对号入座。这张表不是标准答案，只是把「什么情况适合什么模式」列出来，具体单价到站内价格对照页核对该模型当时的数字。
| 任务类型 | 优先看哪栏 | 建议模式 |
|---|---|---|
| 固定长系统提示 + 大量短问题 | 缓存读取 | 带缓存的模型，不变部分前置 |
| 一次性长文档、不着急 | 批量折扣 | 批量通道，能等就等 |
| 对话类产品 | 输出单价 | 重点控制回答长度和思考链 |
| 用量稳定且持续增长 | 阶梯门槛 | 到门槛附近再谈档位 |
| 用量忽高忽低 | 按量单价 | 老实按量结算，别提前锁档 |
这张清单用起来有个前提：你得先知道自己的用量结构长什么样。如果连输入输出各占多少都不清楚，先回去做前面那步「把明细按四项拉平」，再回来对这张表。
下一步拿你最近一个周期的用量明细，按输入、缓存写入、缓存读取、输出四项拉平，看看最大的一项是哪个，再去价格对照页核对对应的单价，你就知道该动哪里了。→常见问题
输入和输出为什么不能按一个平均价算？
因为两边单价不同，且比例随任务变。同一个模型，生成型任务输出占大头，分类或抽取型任务输入占大头，用平均价估预算，换一类任务就失准。要么分开记，要么按任务类型分别估。
缓存是不是开了就一定省钱？
不一定。缓存省的是重复前缀那部分输入。如果你的提示词很短、每次都不同、或者前缀老在改，缓存写入的钱花出去了却很少被读取，反而是净亏。先看明细里写入和读取的比例再决定要不要开。
阶梯价的门槛是按什么周期算的？
各平台不一致，常见是按自然月，也有按累计用量的。关键要问清是整段重算还是只对超出部分重算，以及跨档后生效时间。这三点不同，同样的用量最后账单能差出一截。
批量通道便宜，是不是所有任务都该走批量？
不是。批量是用等待时间换折扣，结果要几十分钟甚至更久才回来。凡是用户在前台等着、或者下游流程卡着这一步的任务，都不适合。判断标准只有一条：这个结果能不能等。
账单里的缓存那两项对不上，先查什么？
先确认前缀有没有被改动，包括时间戳、随机 ID、用户昵称这类每次都不一样的内容混在开头。再确认调用间隔是否超过了缓存有效期。这两条是失效最常见的原因，比查平台规则快得多。
