很多团队算大模型成本，只做一道乘法：每天调用次数乘以每百万 Token 单价。这个算法在原型阶段够用，一进入生产就会失真。真正决定账单的，是输入里有多少内容每次都被重复发送、输出长度是否失控、缓存能否真正命中、高峰时的并发会不会触发限流，以及失败重试有没有被计入。
核心摘要：2026 年大模型 Token 成本测算，应把一次请求拆成未缓存输入、缓存写入、缓存命中和输出四段，再用并发曲线和峰值用量校正月度预算。只看单价的测算，通常会低估 Agent 和长上下文场景的真实成本。
这篇文章给出一套可以直接套用的测算方法，并列出四类值得纳入测算的平台口径。文中只使用公开计费与限流规则，不给出脱离时间的绝对价格，也不假设任何厂商的真实折扣。
先说结论
| 测算问题 | 应该看什么 | 常见误判 |
|---|---|---|
| 一次请求多少钱 | 输入、缓存、输出分开计价 | 只看输入单价 |
| 缓存能省多少 | 写入溢价、命中率、有效期 | 认为开了缓存就一定便宜 |
| 高峰扛不扛得住 | RPM、TPM、短时并发曲线 | 只看每天平均 QPS |
| 月度预算多少 | P50、P90、P99 与重试率 | 用平均值直接封顶 |
| 哪个平台更适合 | 计费颗粒度、限流口径、预留能力 | 只比标价和宣传折扣 |
一句话判断：单价决定"每个 Token 贵不贵"，缓存和输出决定"每次请求吃掉多少 Token"，并发和峰值决定"同样的预算能不能在高峰稳定跑完"。
从一次请求开始拆账
最基础的单次请求费用可以写成：
text
单次费用 =
未缓存输入 × 输入单价
+ 缓存写入 × 写入单价
+ 缓存命中 × 读取单价
+ 输出 × 输出单价这里有三个容易忽略的地方。
第一，未缓存输入不等于用户输入。系统提示词、工具定义、历史对话、检索片段和本轮问题，只要没有命中缓存，都属于未缓存输入。很多 Agent 项目的大头不是用户那一句话，而是每轮都重复发送的工具 schema 和历史上下文。
第二，缓存写入通常比普通输入更贵。以 Anthropic 的公开规则为例，5 分钟缓存写入是基础输入价的 1.25 倍，1 小时写入为 2 倍；命中读取则只有基础输入价的 0.1 倍左右，部分新模型更低。OpenAI 对 GPT-5.6 及之后的模型，默认 30 分钟生命周期的写入也按标准输入价的 1.25 倍计，读取为 0.1 倍，部分型号为 0.05 倍。
第三，输出 Token 往往是最容易放大的一项。输出单价通常高于输入单价，而且输出长度受模型风格、提示词要求和思考模式影响。一个把 600 Token 回答放大到 1200 Token 的改动，可能比压缩一半系统提示词影响更大。
缓存怎么测，才不会高估收益
缓存是最容易被夸大的成本项。它真正省钱，需要同时满足三个条件：前缀足够长、前缀足够稳定、后续请求足够频繁。
以 OpenAI 的公开说明为例，缓存只对超过最小长度的前缀生效，GPT-5.6 及之后的模型最小可缓存长度为 1024 Token，且要求整段前缀完全一致。只要前面某个系统消息、工具定义或历史内容变了，后面的缓存都无法复用。
Anthropic 的文档则提醒另一个细节：缓存断点应放在"每次请求都不变"的最后一个块上。如果把断点放在带时间戳的动态块上，每次请求都会产生新的写入，却几乎不会命中读取，成本反而更高。
因此，缓存测算建议按下面的公式做：
text
缓存净收益 =
命中次数 × 普通输入价 × 命中比例
- 写入次数 × 普通输入价 × 写入溢价如果一个前缀只被写入一次，又只被读取一次，缓存可能还不如不开。只有高频复用的稳定前缀，例如客服知识库、代码仓库说明、长合同模板和固定工具定义，缓存才会稳定回本。
输入输出怎么拆，才能落到预算表
建议把每个业务场景拆成六类 Token：
- 系统提示词。
- 工具定义与工具结果。
- 历史对话。
- 检索片段或文档原文。
- 本轮用户输入。
- 输出与思考 Token。
每一类都记录 P50、P90 和 P99。平均值适合做财务基准，P90 适合做预算上限，P99 适合做容量和异常排查。只用平均值，常见后果是月底账单比预算高出一截，而业务团队找不到原因。
输出测算要多做一步：区分"正常回答""长回答"和"失败后重试的回答"。如果某个 Agent 在工具调用失败时反复重写计划，输出 Token 可能在几分钟内就超过全天预算。
并发与峰值：同样的月预算，也可能跑不完
很多预算模型到这里就结束了，但生产系统真正的风险在峰值。以阿里云百炼的公开限流规则为例，限流按主账号维度计算，同时存在每分钟请求数和每分钟 Token 数限制；文档还说明，除 RPM 和 TPM 外，系统可能按每秒 RPS 与每秒 TPS 执行，短时间爆发即使没有超过每分钟总量，也可能被拒绝。
这意味着峰值测算至少要看三条线：
| 指标 | 计算方法 | 用途 |
|---|---|---|
| 峰值 RPS | 高峰 1 分钟内请求数 ÷ 60，再取 P99 | 判断是否触发短时请求限制 |
| 峰值 TPS | 高峰 1 分钟内 Token 数 ÷ 60，再取 P99 | 判断输入输出吞吐是否够用 |
| 并发会话数 | 同时活跃的 Agent 或用户会话数 | 判断排队、重试和超时风险 |
峰值用量还要叠加重试。假设平时 429 比例是 1%，但在大促时上升到 10%，而客户端又采用立即重试，那么真实请求数可能在几秒内放大数倍。正确做法是给重试设置上限、退避和抖动，并把重试次数计入预算。
有些平台提供独享或预留能力，例如 TPM 保障、吞吐预留或资源池。它们可以降低高峰风险，但通常要按时间或容量付费。测算时应比较两种方案：一是按量付费加限流重试，二是预留容量加较低的单位成本。哪一种更便宜，取决于峰值持续时间。
一个可复用的测算模板
下面是一套适合团队直接使用的流程。
- 按业务场景抽取至少 100 条脱敏请求，统计六类 Token 的 P50、P90、P99。
- 用目标模型的 tokenizer 或 token counting 能力计数，不用字数估算。
- 标出每类内容的复用性：每次都变、偶尔变、长期不变。
- 把长期不变的前缀放入缓存，并记录写入次数与命中次数。
- 按平台规则计算单次请求费用，分别算普通模式和 Batch 模式。
- 用月调用量乘以单次费用，得到财务基准。
- 用 P90 Token 和峰值调用量得到运营上限。
- 用 RPS、TPS 和并发会话数检查限流，必要时测算预留容量。
- 加入重试率、失败率和人工审核成本，得到总预算。
- 每周用真实账单校正一次，连续三周误差超过 15% 时重新抽样。
其中第 8 步最容易被跳过。很多团队在财务预算里很满意，却在上线第一个高峰日遇到 429，只能临时扩容或降级模型。
一个假设算例
下面的数字只用于演示测算方法，不代表任何厂商当前报价。
假设一个客服 Agent 每月有 30 万次模型调用，平均每次：
- 未缓存输入 2,000 Token。
- 缓存命中 1,000 Token。
- 缓存写入 200 Token。
- 输出 500 Token。
- 假设输入价 4 元每百万 Token，缓存读取价 0.4 元每百万 Token，缓存写入价 5 元每百万 Token，输出价 16 元每百万 Token。
- 重试率 8%。
先算各部分的 Token 量：
text
未缓存输入 = 300,000 × 2,000 = 600M
缓存命中 = 300,000 × 1,000 = 300M
缓存写入 = 300,000 × 200 = 60M
输出 = 300,000 × 500 = 150M再算费用：
text
未缓存输入 600 × 4 = 2,400 元
缓存命中 300 × 0.4 = 120 元
缓存写入 60 × 5 = 300 元
输出 150 × 16 = 2,400 元
基础费用 = 5,220 元计入 8% 重试：
text
5,220 × 1.08 ≈ 5,638 元如果把输出从 500 Token 提高到 1000 Token，其他条件不变，输出费用从 2,400 元升到 4,800 元，加上输入、缓存写入和命中部分，基础费用约为 7,800 元，计入 8% 重试后约 8,400 元。这个例子说明，输出长度是需要被重点监控的变量，它的增幅会直接传导到总账单。
再看并发。假设高峰时段 10 分钟内有 3 万次请求，平均每次 3,500 Token 输入加输出，那么高峰平均请求数约为每秒 50 次，每秒 Token 约 17.5 万。如果平台某个模型的限流额度只有每秒 10 次请求，那么即使月预算足够，高峰仍会大量被拒绝。这时的解决方法不是只看预算，而是换更高配额的模型、拆分批次、增加备选模型或预留容量。
常见误区
误区一：Token 越便宜，总成本一定越低。
如果便宜模型需要更多轮次、更长输出或更多人工返工，总成本可能更高。
误区二：缓存命中率越高越好。
命中率只说明复用情况，还要看写入溢价、缓存有效期和写入次数。低频内容强行缓存，可能比不缓存更贵。
误区三：Batch 一定最便宜。
Batch 适合离线任务，但有队列和处理时长。客服、实时对话和交互式 Agent 不能用 Batch 替代在线调用。
误区四：平均 QPS 不高，就不会限流。
限流可能按分钟、秒级或突发模式执行。平均值再低，也挡不住几秒内集中爆发。
误区五：重试只是小成本。
重试会重复消耗输入，还会放大并发。没有退避和上限的重试，可能让高峰事故变成账单事故。
采购和评审时要问的问题
- 输入、缓存写入、缓存命中和输出是否分别计价。
- 缓存生命周期是多少，写入是否有额外溢价，命中后是否刷新有效期。
- 阶梯价按单次请求、日累计还是月累计。
- Batch、缓存、峰谷价和合同折扣能否叠加。
- 限流是按 RPM、TPM、RPS、TPS 还是账号、业务空间、API Key 计算。
- 限流被触发后，失败请求是否计费，是否可以切换备选模型。
- 独享资源池或预留容量的最小规格、计费周期和扩容时间。
- 峰谷时段按请求接收时间还是调用时间判定。
- 账单能否按项目、团队、模型和 API Key 拆分，能否设置硬预算。
- 模型升级或 tokenizer 变化后，历史用量能否对齐。
FAQ
Q1：没有真实业务数据，怎么做第一版测算？
先用典型业务样本做小规模压测，抽取 100 条以上请求，统计 Token 分布和并发曲线。宁可先给一个区间，也不要用拍脑袋的平均数直接签预算。
Q2：为什么输出比输入更难控制？
输出由模型生成，受提示词、思考模式、业务规则和用户追问影响。输入大多可以在系统层面裁剪，输出则需要通过最大长度、格式约束和评测来控制。
Q3：缓存应该按小时还是按天测算？
按业务访问节奏来定。客服知识库可能按小时复用，内部代码助手可能按工作日复用。缓存生命周期要和访问间隔匹配，否则写入后很快过期。
Q4：峰值时直接降级到小模型，是不是合理策略？
可以作为预案，但要先用评测集确认质量下降是否可接受。对金融、医疗、法律等高风险场景，降级应有人工审核或明确提示。
Q5：多个平台混用时，预算怎么汇总？
按统一口径把每次调用折算为输入、缓存、输出、请求数和费用，再汇总到同一张账本中。否则不同平台的账单单位和计费周期会让预算无法对齐。
最终建议
测算大模型成本，最应该避免的是"一个单价、一个平均值、一个月度总额"的三点式计算。更可靠的做法，是把请求拆开，把缓存和输出单独建模，把并发和峰值放进同一张表，再用真实账单每周校正。
真正可靠的预算，不是一个漂亮的月度数字，而是一套能解释每一分钱来自哪里、高峰时会不会被限流、缓存是否真的被复用、输出是否可控的模型。
本文为测算方法与公开规则整理，不构成报价承诺。模型单价、缓存规则、阶梯档位、限流阈值和套餐政策会随时间变化，实际采购前应以厂商当期页面、合同和压测结果为准。