企业评估大模型 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 对真实样本计数。只看字数，误差可能大到无法用于采购。
一张总成本公式
最基础的单请求费用可以写成：
text
单请求 Token 费用 =
未缓存输入 Token × 输入单价
+ 缓存写入 Token × 缓存写入单价
+ 缓存命中 Token × 缓存读取单价
+ 输出 Token × 输出单价企业月度费用则要继续展开：
text
月总成本 =
Σ（各任务请求数 × 单请求 Token 费用）
+ 工具调用与联网检索
+ 图片、音频、视频 Token
+ 预留吞吐或固定套餐
+ 网络、网关和日志
+ 运维、人工审核和失败重试如果把成功率和重试也纳入：
text
尝试请求数 ≈ 成功请求数 ×（1 + 重试率）这里要特别注意，失败请求不一定免费。限流、超时、格式校验失败和工具调用失败是否已经消耗输入 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 半价和上下文缓存不能同时生效，因此企业要分别计算两条路径：
text
普通在线请求：输入缓存折扣 + 正常输出价
Batch 请求：输入输出半价，但可能不能用缓存折扣还有按时间计费的平台。腾讯云 TokenHub 的 DeepSeek 模型区分高峰和空闲时段，单次请求按平台服务端接收时间判定价格；DeepSeek 官方也区分峰值和低谷价格。预算不能只用白天流量估算全天成本。
5. 思考 Token 与工具调用
推理模型的思考 Token 可能按输出计费。Gemini 的公开价格表明确写有"output price including thinking tokens"。如果产品只看最终回答长度，就会低估推理成本。
工具调用也不是免费附件。Anthropic 的计费说明指出，工具名称、描述、schema、工具调用块和工具结果都会计入 Token，服务端工具还可能按调用次数额外收费。
Agent 项目应按"完整任务"统计：
text
单任务 Token =
首轮输入
+ 每轮历史上下文
+ 每次工具 schema
+ 工具结果
+ 思考 Token
+ 最终输出一个任务调用五次模型，不等于五倍首轮输入。历史上下文会在后续轮次重复带入，实际 Token 可能呈阶梯式增长。
6. 图片、视频和检索单独计费
多模态服务可能把图片、视频、音频折算成 Token，也可能按张、按秒、按成功请求计费。腾讯云 TokenHub 的公开文档就分别列出了不同分辨率图片和不同时长视频对应的 Token 用量。
联网搜索和网页抓取也可能单独计费。DeepSeek 的公开价格页把 Search 和 Fetch 定义为按成功请求计费，不包含在普通文本 Token 里。
因此，多模态和 RAG 项目的预算公式要加入：
text
多模态成本 =
文本 Token
+ 图片 Token
+ 音频 Token
+ 视频 Token
+ OCR/检索/抓取费用第一步：拆出真实任务
不要用"公司有多少员工"估 Token。先把业务拆成任务：
| 任务 | 每次输入主因 | 每次输出主因 | 主要成本变量 |
|---|---|---|---|
| 客服问答 | 知识库片段、历史对话 | 回答长度、是否带引用 | RAG 命中率、上下文轮数 |
| 文档总结 | 原文长度、分块大小 | 摘要档位 | 长文本阶梯价、Batch |
| 代码助手 | 仓库片段、工具 schema | 代码修改、思考 Token | Agent 轮数、重试 |
| 内容生成 | 品牌资料、参考样例 | 文章长度、修订次数 | 输出比例、人工返工 |
| 图片/视频生成 | 参考图、分辨率、时长 | 输出规格 | 媒体 Token、分辨率 |
每个任务抽取至少 100 条已脱敏请求，分别统计 P50、P90 和 P99 Token。平均值只能做财务估算，容量和预算上限要用 P90 或 P99。
第二步：按输入结构计数
把一条请求拆成六块：
- 系统提示词。
- 用户输入。
- 历史对话。
- RAG 检索内容。
- 工具定义和工具结果。
- 输出与思考 Token。
对每一块记录平均值和 P90。很多企业发现，真正的大头不是用户问题，而是每轮都重复发送的系统提示词、知识库片段和工具 schema。
如果平台支持 tokenizer 或 token counting API，应在调用前计数；如果平台不提供，可以用对应开源 tokenizer 近似，但要给不同语言和代码留误差。
第三步：按任务选择模型
不要用一个模型承接所有任务。建议做三层：
| 任务层 | 推荐模型 | 成本目标 |
|---|---|---|
| 分类、抽取、路由 | 小模型或轻量模型 | 低输入、低输出、低延迟 |
| 常规问答、摘要、改写 | 中等模型 | 成功率优先，控制上下文 |
| 复杂推理、长程 Agent | 旗舰模型 | 少调用、严格预算和人工验收 |
模型路由的收益不是"把请求都送到最便宜模型"，而是在质量达标的前提下，把不需要旗舰模型的请求移走。
第四步：建立月度预算
可以用下面的自下而上公式：
text
月调用数 =
活跃用户数
× 人均会话数
× 每会话调用数
×（1 + 重试率）再按任务分别计算：
text
月 Token 费用 =
月调用数
×（P90 未缓存输入 Token × 输入单价
+ P90 输出 Token × 输出单价
+ P90 缓存写入 Token × 缓存写入单价
+ P90 缓存命中 Token × 缓存读取单价）最后加上：
text
总预算 =
Token 费用
×（1 + 价格波动缓冲）
+ 工具调用、检索与多模态
+ 固定套餐或预留吞吐
+ 网络与网关
+ 日志与监控
+ 人工审核价格波动缓冲可以按模型是否处于促销期、是否使用峰谷价、是否有阶梯价分别设置。不要把限时折扣写进长期预算。
一个假设算例
下面的数字只用于演示计算，不代表任何厂商当前报价。
假设客服系统每月有 24 万次模型调用：
- 平均未缓存输入：2,200 Token。
- 平均缓存命中输入：300 Token。
- 平均输出：600 Token。
- 假设输入价：4 元/百万 Token。
- 假设缓存命中价：0.4 元/百万 Token。
- 假设输出价：16 元/百万 Token。
- 重试率：8%。
先算输入和输出量：
text
未缓存输入 = 240,000 × 2,200 = 528M Token
缓存命中输入 = 240,000 × 300 = 72M Token
输出 = 240,000 × 600 = 144M TokenToken 费用：
text
528 × 4 = 2,112 元
72 × 0.4 = 28.8 元
144 × 16 = 2,304 元
基础费用 = 4,444.8 元计入 8% 重试后：
text
4,444.8 × 1.08 ≈ 4,800 元如果平均输出从 600 Token 增加到 1,200 Token，其他条件不变：
text
输出费用从 2,304 元升到 4,608 元
计入重试后约 7,289 元输入只增加少量时，成本可能变化不大；输出翻倍却会让总费用上涨约 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，再乘上对应模型价格，最后加上重试、网络、运维和人工成本。
预算模型也不需要一开始就非常复杂。先做一张按任务、模型和月份拆开的表，记录 P50、P90、缓存命中率、输出比例和重试率，连续观察三个月，再决定是否上自动路由、预留吞吐或更复杂的成本治理。
本文为技术选型和预算方法参考，不构成报价承诺。模型价格、缓存规则、阶梯档位、峰谷时段和套餐政策会变化，正式采购前应以厂商当期计费页和合同为准。