Token 怎么计费：输入输出分开算、缓存命中另算，先把账单口径看明白

先分清三笔账：输入、输出、缓存

在按量计费的模型 API 里，「token」既是模型理解文本的最小单位，也是计费单位。DeepSeek 的 Models & Pricing 文档写的是「We will bill based on the total number of input and output tokens by the model」，同一页的价目表把输入拆成命中缓存与未命中缓存两个档位，输出单独成列。Anthropic 的价目页同样把 Input、Output、Prompt caching Read、Prompt caching Write 分列成四个不同单价。也就是说，一次调用在账面上不是「一共多少 token 乘一个价」，而是至少分成输入一笔、输出一笔，输入里命中缓存的部分再走另一档。

为什么会这样分？因为输入和输出在推理过程里是两件事：输入是模型一次读进来的上下文，输出是模型逐字生成的结果，两者的计价口径本来就各自独立。缓存则是另一回事：阿里云百炼的上下文缓存文档写明，上下文缓存技术可以缓存请求的公共前缀，减少推理时的重复计算；命中缓存的输入 token 与未命中的输入 token 分属不同计费档。所以如果同一个长前缀被反复使用，账面上会出现「命中部分按缓存档、未命中部分按普通输入档」的拆分。

本站「API 成本估算工作台」就是把这三笔账拆开填的。它有八个输入框：输入 token（默认 12000）、缓存 token（默认 6000）、输出 token（默认 1800）、每月调用（默认 1000）、输入价 / 1M（默认 1.00）、缓存价 / 1M（默认 0.50）、输出价 / 1M（默认 4.00）、重试率 %（默认 5）。页面原话是：「缓存 token 应包含在输入 token 内；重试率按额外调用成本估算。」这一句是填表时最容易出错的地方——缓存 token 不是另加在输入之外，而是输入的一部分。

「每百万 token」怎么换算成单次请求

价目表上的单价单位是「每 1M token」。要把单价变成单次请求的钱，先算这次实际用了多少 token，再按各自档位乘单价，最后按算式中的分母换算。本站工具的算式与页面脚本一致：

((输入 - 缓存) × 输入价 + 缓存 × 缓存价 + 输出 × 输出价) / 1e6 × (1 + 重试率 / 100)

这里每一项对应的意思是：输入减缓存，是没命中缓存的那部分输入，乘普通输入价；缓存那部分乘缓存价；输出乘输出价。三项相加除以 1e6，是因为单价都按每百万 token 标；再乘上重试系数，把额外调用算进去。算出来的单位是 USD。

用本站默认值代入一次：输入 12000、缓存 6000、输出 1800、每月调用 1000、输入价 1.00、缓存价 0.50、输出价 4.00、重试率 5%。先算未命中缓存的那部分输入：12000 减 6000 得 6000，乘输入价 1.00 得 6000；缓存那部分 6000 乘缓存价 0.50 得 3000；输出 1800 乘输出价 4.00 得 7200。三项相加为 16200，除以 1e6 得 0.0162，再乘重试系数 1.05，单次约 $0.0170；乘每月调用 1000 次，月度约 $17.01。读者可以按这几步脱离本站，用自己的数字手算一遍，再与工具结果对照。

为了不依赖工具也能复核，按同一算式把本站三个单价字段分别对应到算式中的项：

• 未命中缓存的输入：输入 token 减缓存 token，再乘输入价 / 1M。
• 缓存输入：缓存 token 乘缓存价 / 1M。
• 输出：输出 token 乘输出价 / 1M。
• 重试：在单次结果上乘 (1 + 重试率 / 100)。

这几项对应两件事，但它们都只是算式结构，不是建议：一是缓存 token 占比越高，输入那一笔的单价结构就越偏向缓存档；二是输出 token 的权重和它的单价直接相关。至于某个具体供应商的缓存价是普通输入价的百分之几、缓存写入是否另计、缓存有效期多长，各家文档写法不同，必须回到官方价目页确认，本文不引用任何供应商的具体单价或倍率。

填表时四个容易搞错的点

第一，缓存 token 要含在输入 token 里。 这是本站页面的硬口径。如果你把「输入」填成未命中部分，又把缓存另填一遍，工具会按「未命中 + 缓存」重复计算，结果偏高。正确做法是：输入填这次请求的全部输入 token，缓存填其中命中缓存的那部分。

第二，实际 token 数以用量返回为准。 DeepSeek 的 Token & Token Usage 文档写明，每次实际处理的 token 数要以模型返回的 usage 为准，并说明其换算说明只是估算，应以 API 返回的用量作为事实来源。所以填表前最好先用实际请求跑一遍，拿到 usage 里的输入、缓存、输出数字，再回填到工具里，而不是凭字数拍脑袋。该文档也给出了粗算参考：1 个英文字符约 0.3 token，1 个中文字符约 0.6 token；Cohere 的 tokenizer 文档则提到一个词通常是 2–3 个 token 左右，一段话约 128 个 token。这些只能当量级参考。

第三，重试率是「额外调用成本」。 页面写的是「重试率按额外调用成本估算」，所以它是乘在单次成本之外的系数，而不是从单次成本里扣。填 5% 表示假设有 5% 的调用会额外发生一次。这个数字应当来自你自己观测到的失败与重试情况，而不是默认值照抄。

第四，别把未知费用默认为零。 页面原话是「输入、缓存、输出、重试分别展示，不把未知费用默认为零」。如果某次调用存在你还没纳入的项目——比如缓存写入是否单独计费、某些供应商是否对特定档位另算——在估算里应当标成未知，而不是当成 0 让它悄悄消失。

口径落点与复核顺序

把这篇文章的口径收成一句话：输入与输出分别计价，输入里命中缓存的部分走更低的缓存档，未命中的部分走普通输入档；缓存 token 包含在输入 token 内；每百万 token 的单价要除以 1e6 再乘用量，重试另乘系数；实际 token 数以 API 返回的用量为准。供应商价格、模型别名和缓存规则会变，购买前请回到官方价目页。

复核顺序建议固定成三步：先拿一次真实调用的 usage 确认输入、缓存、输出三个数；再用上面的算式手算一遍单次成本；最后乘每月调用次数。本站是独立的计算工作台，不代表任何模型供应商；具体价格与口径以各供应商最新官方文档为准，本站只做估算，不构成报价、采购或财务建议。