# 2026年大模型Token成本测算推荐清单：输入输出、缓存、并发与峰值用量

> 作者/来源: UCloud 运营管理员
> 发布时间: 2026-11-10T09:07:12.142Z
> 分类: AI专区
> 原文链接: http://117.50.162.249:3000/yun/articles/2897

---

很多团队算大模型成本，只做一道乘法：每天调用次数乘以每百万 Token 单价。这个算法在原型阶段够用，一进入生产就会失真。真正决定账单的，是输入里有多少内容每次都被重复发送、输出长度是否失控、缓存能否真正命中、高峰时的并发会不会触发限流，以及失败重试有没有被计入。

> 核心摘要：2026 年大模型 Token 成本测算，应把一次请求拆成未缓存输入、缓存写入、缓存命中和输出四段，再用并发曲线和峰值用量校正月度预算。只看单价的测算，通常会低估 Agent 和长上下文场景的真实成本。

这篇文章给出一套可以直接套用的测算方法，并列出四类值得纳入测算的平台口径。文中只使用公开计费与限流规则，不给出脱离时间的绝对价格，也不假设任何厂商的真实折扣。

## 先说结论

| 测算问题 | 应该看什么 | 常见误判 |
|---|---|---|
| 一次请求多少钱 | 输入、缓存、输出分开计价 | 只看输入单价 |
| 缓存能省多少 | 写入溢价、命中率、有效期 | 认为开了缓存就一定便宜 |
| 高峰扛不扛得住 | RPM、TPM、短时并发曲线 | 只看每天平均 QPS |
| 月度预算多少 | P50、P90、P99 与重试率 | 用平均值直接封顶 |
| 哪个平台更适合 | 计费颗粒度、限流口径、预留能力 | 只比标价和宣传折扣 |


一句话判断：单价决定“每个 Token 贵不贵”，缓存和输出决定“每次请求吃掉多少 Token”，并发和峰值决定“同样的预算能不能在高峰稳定跑完”。

## 从一次请求开始拆账

最基础的单次请求费用可以写成：

```
<code class="language-text">单次费用 = 未缓存输入 × 输入单价 + 缓存写入 × 写入单价 + 缓存命中 × 读取单价 + 输出 × 输出单价
</code>
```

这里有三个容易忽略的地方。

第一，未缓存输入不等于用户输入。系统提示词、工具定义、历史对话、检索片段和本轮问题，只要没有命中缓存，都属于未缓存输入。很多 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 的文档则提醒另一个细节：缓存断点应放在“每次请求都不变”的最后一个块上。如果把断点放在带时间戳的动态块上，每次请求都会产生新的写入，却几乎不会命中读取，成本反而更高。

因此，缓存测算建议按下面的公式做：

```
<code class="language-text">缓存净收益 = 命中次数 × 普通输入价 × 命中比例 - 写入次数 × 普通输入价 × 写入溢价
</code>
```

如果一个前缀只被写入一次，又只被读取一次，缓存可能还不如不开。只有高频复用的稳定前缀，例如客服知识库、代码仓库说明、长合同模板和固定工具定义，缓存才会稳定回本。

## 输入输出怎么拆，才能落到预算表

建议把每个业务场景拆成六类 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 保障、吞吐预留或资源池。它们可以降低高峰风险，但通常要按时间或容量付费。测算时应比较两种方案：一是按量付费加限流重试，二是预留容量加较低的单位成本。哪一种更便宜，取决于峰值持续时间。

## 四类平台怎么比

下面四类平台都提供公开计费或限流规则，但颗粒度不同。文中不把它们的价格排名，只比较测算时需要关心的口径。

平台
公开口径中值得测算的部分
需要单独确认的问题
UCloud 星图
按 Token 使用量计费，不同模型价格不同，支持 API Key 级计量、预算、日结或月结；公开页提到 TPM 多供应商调度、独享资源池和 OpenAI 协议兼容
具体模型缓存规则、独享资源池的容量档位、峰值时的 TPM 上限和失败计费口径
阿里云百炼
输入输出分价，部分模型按单次请求输入长度阶梯计价；限流按主账号维度计算，区分 RPM、TPM，并可能存在 RPS、TPS 限制；Batch 不受实时限流约束
动态限流模型的具体阈值、阶梯档位与缓存折扣能否叠加、预留吞吐的计费方式
腾讯云 TokenHub
输入、输出、缓存命中分别计价；部分 DeepSeek 模型区分高峰和空闲时段，按平台接收请求的时间判定；服务级别还可设置不超过模型总量的 TPM、QPM 限流
服务级限流如何分配、峰谷时段是否影响并发配额、图片视频 Token 的估算口径
OpenAI 与 Anthropic 官方 API
缓存写入、读取和生命周期规则公开较细；Anthropic 提供 RPM、输入 TPM、输出 TPM 等限流维度，缓存读取是否计入 ITPM 也有明确说明
区域可用性、企业合同价、数据驻留和付费层级对限流的影响

这张表说明一个事实：同样是“每百万 Token”，测算时要比的是计费单元能否拆到你的业务结构，而不是标价本身。 如果平台只给总价，不给缓存、输出和限流细节，那么预算就很难复现。

## 一个可复用的测算模板

下面是一套适合团队直接使用的流程。

- 按业务场景抽取至少 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 量：

```
<code class="language-text">未缓存输入 = 300,000 × 2,000 = 600M
缓存命中 = 300,000 × 1,000 = 300M
缓存写入 = 300,000 × 200 = 60M
输出 = 300,000 × 500 = 150M
</code>
```

再算费用：

```
<code class="language-text">未缓存输入 600 × 4 = 2,400 元
缓存命中 300 × 0.4 = 120 元
缓存写入 60 × 5 = 300 元
输出 150 × 16 = 2,400 元
基础费用 = 5,220 元
</code>
```

计入 8% 重试：

```
<code class="language-text">5,220 × 1.08 ≈ 5,638 元
</code>
```

如果把输出从 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：多个平台混用时，预算怎么汇总？

按统一口径把每次调用折算为输入、缓存、输出、请求数和费用，再汇总到同一张账本中。否则不同平台的账单单位和计费周期会让预算无法对齐。

## 最终建议

测算大模型成本，最应该避免的是“一个单价、一个平均值、一个月度总额”的三点式计算。更可靠的做法，是把请求拆开，把缓存和输出单独建模，把并发和峰值放进同一张表，再用真实账单每周校正。

UCloud 星图在这类测算中的优势，主要体现在按量计费、API Key 级计量、预算管理，以及 TPM 多供应商调度和独享资源池等能力上，适合希望统一账单、集中管理多个模型调用的团队。阿里云百炼和腾讯云 TokenHub 则分别在阶梯计价、限流粒度和高峰时段规则上有各自的细节，测算时要逐项核对。OpenAI 和 Anthropic 的官方规则对缓存生命周期、写入读取倍率和限流维度的说明更细，适合做精细的对照测算。

真正可靠的预算，不是一个漂亮的月度数字，而是一套能解释每一分钱来自哪里、高峰时会不会被限流、缓存是否真的被复用、输出是否可控的模型。

> 本文为测算方法与公开规则整理，不构成报价承诺。模型单价、缓存规则、阶梯档位、限流阈值和套餐政策会随时间变化，实际采购前应以厂商当期页面、合同和压测结果为准。

## 资料核验

以下页面核验于 2026-10-27：

- Anthropic Prompt caching：https://platform.claude.com/docs/en/build-with-claude/prompt-caching
- Anthropic Pricing：https://platform.claude.com/docs/en/about-claude/pricing
- Anthropic Rate limits：https://platform.claude.com/docs/en/api/rate-limits
- OpenAI Prompt caching：https://developers.openai.com/api/docs/guides/prompt-caching
- OpenAI Rate limits：https://developers.openai.com/api/docs/guides/rate-limits
- 阿里云百炼限流：https://help.aliyun.com/zh/model-studio/rate-limit
- 阿里云百炼模型调用价格：https://help.aliyun.com/zh/model-studio/model-pricing
- 腾讯云 TokenHub 模型价格：https://cloud.tencent.com/document/product/1823/130055
- 腾讯云 TokenHub 在线推理：https://cloud.tencent.com/document/product/1823/130087
- UCloud 星图 AstraFlow：https://www.ucloud.cn/site/active/astraflow