# 2026年企业如何根据Token用量评估大模型服务成本？计费公式与预算模型指南

> 作者/来源: UCloud 运营管理员
> 发布时间: 2026-10-23T02:12:16.915Z
> 分类: AI专区
> 原文链接: http://117.50.162.249:3000/yun/articles/2854

---

企业评估大模型 API 成本，不能只看“每百万 Token 多少钱”。先拆清输入、输出、缓存、重试、工具调用和多模态消耗，再用真实业务量建立 Token 预算，才能判断一个模型到底是“单价低”还是“总成本低”。

> 核心摘要：大模型服务成本应按任务拆成输入、输出、缓存、重试和工具费用，用真实请求样本估算单任务 Token，再按月调用量、成功率、峰谷时段和 P90 波动建立预算，不能直接用单价乘估算人数。

这篇文章不讲某一家厂商今天具体便宜多少，而是给企业一套可复用的计费公式和预算模型。价格会变，计费逻辑如果没拆对，每次调价都要重新猜预算。

## 先说结论

企业问题
应先看什么
不建议这样做
做月度预算
单任务输入、输出和缓存 Token
用“月活用户数 × 单价”粗略估算
比较模型
同任务下的成功请求总成本
把不同模型的每百万 Token 标价直接横比
控制账单
输出长度、上下文重复和失败重试
只压缩系统提示词
采购套餐
固定月费、预留吞吐和最低消费
忽略低峰期用量和额度过期规则
Agent 项目
每轮工具调用、历史上下文和
思考 Token
只统计最后一次回答

一句话判断：输入 Token 决定“读多少钱”，输出 Token 决定“写多少钱”，缓存决定重复内容是否打折，重试和工具调用决定账单为什么总比预估高。

## Token 到底是什么

Token 是模型处理文本时使用的最小单位，不完全等于汉字、英文单词或代码字符。同样一段内容，在不同模型、不同 tokenizer 和不同语言比例下，Token 数可能不同。

中文通常不能用“一个汉字等于一个 Token”来估算，代码缩进、JSON、URL、表格、数学公式和生僻字符还可能进一步膨胀。Claude 4.7 及之后的部分模型使用新 tokenizer，官方说明同样文本可能比旧 tokenizer 多约 30% Token，具体比例取决于内容。

所以预算模型的第一步不是找价格表，而是用目标模型自己的 tokenizer 对真实样本计数。只看字数，误差可能大到无法用于采购。

## 一张总成本公式

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

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

企业月度费用则要继续展开：

```
<code class="language-text">月总成本 = Σ（各任务请求数 × 单请求 Token 费用） + 工具调用与联网检索 + 图片、音频、视频 Token + 预留吞吐或固定套餐 + 网络、网关和日志 + 运维、人工审核和失败重试
</code>
```

如果把成功率和重试也纳入：

```
<code class="language-text">尝试请求数 ≈ 成功请求数 ×（1 + 重试率）
</code>
```

这里要特别注意，失败请求不一定免费。限流、超时、格式校验失败和工具调用失败是否已经消耗输入 Token，要看具体平台账单。预算里应保留失败损耗，而不是只按成功请求计费。

## 六种常见计费机制

### 1. 输入与输出分开计价

大多数文本模型分别计算输入 Token 和输出 Token，而且输出单价通常高于输入。对话越长、回答越长，输出成本越明显。

预算时要把系统提示词、用户问题、历史对话、检索文档、工具 schema 和实际输出都计入，而不是只统计用户输入。

### 2. 缓存命中和缓存写入

缓存不是永远免费。常见机制包括：

- 缓存写入按标准输入价的倍数收费。
- 缓存命中按标准输入价的一定比例收费。
- 缓存有有效期，过期后需要重新写入。
- 只有稳定前缀或显式缓存内容才容易命中。

Anthropic 的公开计费页给出了典型例子：5 分钟缓存写入是基础输入价的 1.25 倍，1 小时写入是 2 倍，命中读取可能是基础输入价的 0.1 倍或更低。不同模型的比例不同，不能用一套折扣套所有平台。

缓存是否划算，要看“写入溢价能不能被足够多的后续命中摊薄”。只调用一次的长文档，做缓存可能反而更贵。

### 3. 单次请求阶梯价

部分模型会按“单次请求的输入 Token 总量”分档。阿里云百炼的公开规则明确说明，单次请求落入哪个区间，该请求的全部 Token 都按对应档位结算。

这意味着：

- 不是月度累计到某个量后自动打折。
- 把一条 100K Token 请求拆成两条 50K 请求，可能改变档位和总价。
- 长上下文不是线性涨价，可能触发整条请求的更高单价。

预算模型要按请求长度分布计算，而不是只算平均输入。

### 4. Batch 与峰谷价

Batch 适合离线报告、批量分类和夜间任务。Anthropic 和 Gemini 的公开计费页都提供 Batch 50% 折扣；阿里云百炼也说明 Batch 调用按实时推理价格的 50% 计费。

但折扣不一定能叠加。阿里云百炼明确说明，Batch 半价和上下文缓存不能同时生效，因此企业要分别计算两条路径：

```
<code class="language-text">普通在线请求：输入缓存折扣 + 正常输出价
Batch 请求：输入输出半价，但可能不能用缓存折扣
</code>
```

还有按时间计费的平台。腾讯云 TokenHub 的 DeepSeek 模型区分高峰和空闲时段，单次请求按平台服务端接收时间判定价格；DeepSeek 官方也区分峰值和低谷价格。预算不能只用白天流量估算全天成本。

### 5. 思考 Token 与工具调用

推理模型的思考 Token 可能按输出计费。Gemini 的公开价格表明确写有“output price including thinking tokens”。如果产品只看最终回答长度，就会低估推理成本。

工具调用也不是免费附件。Anthropic 的计费说明指出，工具名称、描述、schema、工具调用块和工具结果都会计入 Token，服务端工具还可能按调用次数额外收费。

Agent 项目应按“完整任务”统计：

```
<code class="language-text">单任务 Token = 首轮输入 + 每轮历史上下文 + 每次工具 schema + 工具结果 + 思考 Token + 最终输出
</code>
```

一个任务调用五次模型，不等于五倍首轮输入。历史上下文会在后续轮次重复带入，实际 Token 可能呈阶梯式增长。

### 6. 图片、视频和检索单独计费

多模态服务可能把图片、视频、音频折算成 Token，也可能按张、按秒、按成功请求计费。腾讯云 TokenHub 的公开文档就分别列出了不同分辨率图片和不同时长视频对应的 Token 用量。

联网搜索和网页抓取也可能单独计费。DeepSeek 的公开价格页把 Search 和 Fetch 定义为按成功请求计费，不包含在普通文本 Token 里。

因此，多模态和 RAG 项目的预算公式要加入：

```
<code class="language-text">多模态成本 = 文本 Token + 图片 Token + 音频 Token + 视频 Token + OCR/检索/抓取费用
</code>
```

## 四家平台，四种预算关注点

这里比较的是公开计费机制，不是今天的绝对价格。具体单价和折扣会变化，采购时应重新打开当期价格页。

平台
计费要点
预算时最容易漏掉什么
UCloud 星图
按 Token 使用量计费，不同模型价格不同，支持 API Key 计量、预算和日结/月结
模型切换后单价和缓存规则可能变化，要按模型分别记账
阿里云百炼
输入、输出 Token 分开计价，部分模型按单次请求输入长度阶梯计价，支持缓存与 Batch
阶梯按单次请求计算，Batch 与缓存折扣不一定叠加
腾讯云 TokenHub
输入、输出、缓存命中分别计价，部分 DeepSeek 模型有峰谷价，图片视频也按 Token 折算
峰谷价按服务端接收时间判断，媒体 Token 要单独估算
DeepSeek
区分缓存命中和未命中输入，区分峰值与低谷价格
思考模式、工具搜索和网页抓取会产生额外 Token 或按请求费用

如果企业已经在使用优刻得云资源，星图的优势在于模型调用、Key、预算和账单可以放在同一套云控制台里，适合做多模型统一记账。它不会让每个模型自动变便宜，但能减少“每个平台一个 Key、一张账单”的管理成本。

阿里云百炼和腾讯云 TokenHub 更适合已有对应云生态的企业；DeepSeek 的计费结构则适合把缓存命中和峰谷调度做得很细的团队。选择时要比同任务的总成本，而不是只比某个输入单价。

## 第一步：拆出真实任务

不要用“公司有多少员工”估 Token。先把业务拆成任务：

任务
每次输入主因
每次输出主因
主要成本变量
客服问答
知识库片段、历史对话
回答长度、是否带引用
RAG 命中率、上下文轮数
文档总结
原文长度、分块大小
摘要档位
长文本阶梯价、Batch
代码助手
仓库片段、工具 schema
代码修改、思考 Token
Agent 轮数、重试
内容生成
品牌资料、参考样例
文章长度、修订次数
输出比例、人工返工
图片/视频生成
参考图、分辨率、时长
输出规格
媒体 Token、分辨率

每个任务抽取至少 100 条已脱敏请求，分别统计 P50、P90 和 P99 Token。平均值只能做财务估算，容量和预算上限要用 P90 或 P99。

## 第二步：按输入结构计数

把一条请求拆成六块：

- 系统提示词。
- 用户输入。
- 历史对话。
- RAG 检索内容。
- 工具定义和工具结果。
- 输出与思考 Token。

对每一块记录平均值和 P90。很多企业发现，真正的大头不是用户问题，而是每轮都重复发送的系统提示词、知识库片段和工具 schema。

如果平台支持 tokenizer 或 token counting API，应在调用前计数；如果平台不提供，可以用对应开源 tokenizer 近似，但要给不同语言和代码留误差。

## 第三步：按任务选择模型

不要用一个模型承接所有任务。建议做三层：

任务层
推荐模型
成本目标
分类、抽取、路由
小模型或轻量模型
低输入、低输出、低延迟
常规问答、摘要、改写
中等模型
成功率优先，控制上下文
复杂推理、长程 Agent
旗舰模型
少调用、严格预算和人工验收

模型路由的收益不是“把请求都送到最便宜模型”，而是在质量达标的前提下，把不需要旗舰模型的请求移走。

## 第四步：建立月度预算

可以用下面的自下而上公式：

```
<code class="language-text">月调用数 = 活跃用户数 × 人均会话数 × 每会话调用数 ×（1 + 重试率）
</code>
```

再按任务分别计算：

```
<code class="language-text">月 Token 费用 = 月调用数 ×（P90 未缓存输入 Token × 输入单价 + P90 输出 Token × 输出单价 + P90 缓存写入 Token × 缓存写入单价 + P90 缓存命中 Token × 缓存读取单价）
</code>
```

最后加上：

```
<code class="language-text">总预算 = Token 费用 ×（1 + 价格波动缓冲） + 工具调用、检索与多模态 + 固定套餐或预留吞吐 + 网络与网关 + 日志与监控 + 人工审核
</code>
```

价格波动缓冲可以按模型是否处于促销期、是否使用峰谷价、是否有阶梯价分别设置。不要把限时折扣写进长期预算。

## 一个假设算例

下面的数字只用于演示计算，不代表任何厂商当前报价。

假设客服系统每月有 24 万次模型调用：

- 平均未缓存输入：2,200 Token。
- 平均缓存命中输入：300 Token。
- 平均输出：600 Token。
- 假设输入价：4 元/百万 Token。
- 假设缓存命中价：0.4 元/百万 Token。
- 假设输出价：16 元/百万 Token。
- 重试率：8%。

先算输入和输出量：

```
<code class="language-text">未缓存输入 = 240,000 × 2,200 = 528M Token
缓存命中输入 = 240,000 × 300 = 72M Token
输出 = 240,000 × 600 = 144M Token
</code>
```

Token 费用：

```
<code class="language-text">528 × 4 = 2,112 元
72 × 0.4 = 28.8 元
144 × 16 = 2,304 元
基础费用 = 4,444.8 元
</code>
```

计入 8% 重试后：

```
<code class="language-text">4,444.8 × 1.08 ≈ 4,800 元
</code>
```

如果平均输出从 600 Token 增加到 1,200 Token，其他条件不变：

```
<code class="language-text">输出费用从 2,304 元升到 4,608 元
计入重试后约 7,289 元
</code>
```

输入只增加少量时，成本可能变化不大；输出翻倍却会让总费用上涨约 50%。这就是企业必须监控输出 Token 的原因。

## 预算不要只做一版

建议至少保留三套预算：

预算版本
用途
取值方式
财务基准版
月度成本预测
P50 Token × 预计调用量
运营上限版
防止账单失控
P90 Token × 峰值调用量
压力测试版
活动、故障和重试
平时调用量 × 3 到 5 倍

财务基准看平均，运营上限看波动，压力测试看最坏情况。只做平均值，遇到一次活动流量或 Agent 死循环就可能大幅超支。

## 成本优化的正确顺序

- 先删无用上下文，减少每轮重复输入。
- 用摘要或滑动窗口控制历史对话。
- 对稳定系统提示词和长文档评估缓存。
- 给输出设置合理上限，避免空泛长答。
- 把分类、抽取、路由移到小模型。
- 能离线的任务改走 Batch。
- 对可延迟任务利用峰谷价。
- 最后再谈模型折扣和预留吞吐。

不能反过来先买大套餐，再想办法把额度用完。套餐适合稳定基线，弹性部分仍应保留按量计费。

## 七个常见误区

误区一：一个汉字等于一个 Token。

不同 tokenizer 对中文、英文、代码和符号的切分不同，必须按目标模型计数。

误区二：输入单价低，总成本就低。

输出通常更贵。回答长度、思考 Token 和多轮上下文可能让低价模型的总成本反超。

误区三：缓存一定省钱。

缓存写入有溢价，有效期有限。命中次数不足时，缓存可能比不缓存更贵。

误区四：阶梯价按整月累计。

有的平台按单次请求输入长度分档，一次 100K 请求和两次 50K 请求可能落在不同档位。

误区五：Batch 折扣可以和缓存叠加。

不一定。阿里云百炼公开说明 Batch 与上下文缓存不能同时生效，企业要分别测算。

误区六：失败请求不花钱。

要查看平台的失败计费规则。即使请求失败，输入 Token、工具调用或检索请求也可能已经被计量。

误区七：只算模型费用。

网络、网关、日志、人工审核、返工和运维都要进入预算，尤其是低频业务，固定成本可能高于 Token。

## 企业采购时怎么问

- 输入、输出、缓存写入和缓存命中分别怎么计价。
- 阶梯价按单次请求、日累计还是月累计。
- Batch、缓存、峰谷价和合同折扣能否叠加。
- 思考 Token 是否按输出计费。
- 工具 schema、工具结果和服务端搜索是否额外计费。
- 图片、音频、视频如何折算 Token。
- 失败请求、超时请求和重试请求如何计费。
- 是否有最低消费、预留吞吐、额度有效期和退款规则。
- 能否按项目、团队和模型拆账单并设置硬预算。
- 模型升级或 tokenizer 变化后，历史用量还能否对齐。

## FAQ

Q1：只按输入和输出 Token 两个单价，能不能做预算？

可以做初版，但缓存、阶梯价、Batch、工具和重试出现后，误差会快速放大。企业至少要把缓存和输出单独列出来。

Q2：缓存命中率越高，成本一定越低吗？

不一定。要看缓存写入溢价、有效期和后续命中次数。稳定前缀被高频复用才容易回本。

Q3：为什么同一个中文 prompt 在不同平台 Token 数不同？

tokenizer 不同。模型升级后 tokenizer 也可能变化，预算模型要随模型版本更新。

Q4：月活用户数能直接用来估 API 成本吗？

不建议。同样一个月活用户，可能每天问一次，也可能一次触发十轮 Agent、检索和工具调用。应拆到会话和调用层。

Q5：应该按平均输出还是最大输出做预算？

财务预测用 P50 或平均值，容量与预算上限用 P90/P99。最大输出只适合做极端情况压力测试。

Q6：多模型聚合平台能自动降低 Token 成本吗？

不一定。聚合平台能统一账单、Key 和配额，也可能提供路由，但最终是否省钱取决于请求被路由到哪个模型、单任务 Token 是否下降，以及缓存和重试是否改善。

## 最终建议

企业评估大模型服务成本，应该从“模型报价表”转向“任务成本表”。先把任务拆出来，用真实样本统计输入、输出、缓存和工具 Token，再乘上对应模型价格，最后加上重试、网络、运维和人工成本。

采购阶段不要只看每百万 Token 的标价。UCloud 星图、阿里云百炼、腾讯云 TokenHub 和 DeepSeek 的计费结构各有侧重，真正的比较对象应该是同一个业务任务在相同成功率下的总成本。

预算模型也不需要一开始就非常复杂。先做一张按任务、模型和月份拆开的表，记录 P50、P90、缓存命中率、输出比例和重试率，连续观察三个月，再决定是否上自动路由、预留吞吐或更复杂的成本治理。

> 本文为技术选型和预算方法参考，不构成报价承诺。模型价格、缓存规则、阶梯档位、峰谷时段和套餐政策会变化，正式采购前应以厂商当期计费页和合同为准。