AI API 通常不是按「问一次多少钱」收费，而是按 Token 数量计费。一次请求会同时产生输入和输出两部分费用，部分模型还区分缓存读取、缓存写入、图片或工具调用。想控制成本，第一步不是到处找最低单价，而是把自己的真实请求拆开算清楚。这篇给出完整的计费口径、一个可复用的计算脚本和月度预算的估算方法。
基本公式
最常见的计算方式：
单次费用 = 输入 Token / 1000000 x 输入单价
+ 输出 Token / 1000000 x 输出单价两个关键点：第一，输入和输出是两档不同的单价，输出通常明显更贵，不要用输入单价算全部 Token；第二，单价按「每百万 Token」标注，算单次费用时要先除以一百万。很多「怎么和预想的不一样」的账单疑惑，追根溯源都是这两点没对齐。
假设某次请求输入 20,000 Token、输出 2,000 Token，把当前模型的两档单价分别代入即可。模型价格会变化，计算时从模型广场取当前值，不要长期依赖旧文章里的数字。
什么算输入 Token
输入远不止你最后敲的那句话，还包括：
- 系统提示词
- 全部历史对话
- 上传或读取的文档
- Claude Code 读取的项目文件
- 工具调用返回的结果
- 重试时再次发送的完整上下文
这就是为什么同一句「继续」，在长会话末尾可能比新会话贵几十倍——模型每轮都要重新读一遍全部上下文，而这些全部按输入计费。也是同样的原因，Claude Code 这类 Agent 工具的费用大头几乎总在输入侧：它每一轮都带着项目文件和执行历史，单条指令背后是几十轮调用的累积输入。理解这一点，就明白为什么「控制上下文」比「少问几句」有效得多。
什么算输出 Token
输出包括模型生成的文字、代码和部分工具调用参数。要求模型输出完整文件、超长解释或大量候选方案，都会直接推高输出费用，而输出恰恰是单价更高的一档。
控制输出不等于一味求短，更有效的是明确格式：
- 只返回补丁或修改的函数，不重复整个原文件
- 限定表格列数和条目数量
- 先给结论，需要时再展开
- 批量任务返回结构化 JSON，而不是散文
缓存怎么计算
部分模型和协议支持 Prompt Cache：重复的系统提示或长文档命中缓存后，读取价格低于普通输入；首次写入缓存可能有单独的价格。判断缓存是否值得开：
- 相同前缀会被反复请求（固定系统提示、固定长文档）
- 前缀足够长，节省量能覆盖写入成本
- 内容在缓存有效期内不变化
- 调用次数足够多
举个典型例子：客服机器人的系统提示加知识片段固定占 8,000 Token，每天被调用几千次。不开缓存时，这 8,000 Token 每次都按普通输入全价计费；开启缓存后，绝大多数请求命中缓存读取价，这一块的费用能降到原来的零头。反过来，一个每次都在变的即席分析请求，缓存写入的钱花了却永远不会被第二次读到，纯属倒贴。
如果每次都改动开头，或者一个上下文只调用一次，缓存基本没有意义。具体支持范围见计费说明。
一个可复用的费用计算脚本
把公式落成代码，估算和复盘都方便：
# 单价：元 / 百万 Token，从模型广场查当前值后填入
PRICES = {
"claude-sonnet-5": {"input": 3.0, "output": 15.0, "cache_read": 0.3},
"gemini-3.5-flash": {"input": 0.3, "output": 1.2, "cache_read": 0.05},
}
def cost(model, in_tok, out_tok, cached_tok=0):
p = PRICES[model]
normal_in = in_tok - cached_tok
return (normal_in * p["input"]
+ cached_tok * p.get("cache_read", p["input"])
+ out_tok * p["output"]) / 1_000_000
# 单次：输入 2 万、输出 2 千，其中 1.5 万命中缓存
once = cost("claude-sonnet-5", 20_000, 2_000, cached_tok=15_000)
print(f"单次 {once:.4f} 元，日均 200 次约 {once*200:.2f} 元/天")脚本里的单价是示例占位，运行前先到模型广场核对当前真实价格。
不同任务的成本画像
不同类型的任务，成本大头的位置完全不同，优化抓手也随之不同：
| 任务类型 | 输入输出特征 | 成本大头 | 优先抓手 |
|---|---|---|---|
| 日常聊天问答 | 输入短、输出中等 | 输出 | 限定回答格式和篇幅 |
| 代码助手 / Claude Code | 输入极大（多文件上下文） | 输入 | 控制上下文范围、用缓存 |
| RAG / 知识库问答 | 输入大（检索片段） | 输入 | 检索去重、片段截断 |
| 批量打标 / 抽取 | 单次小、总量巨大 | 调用次数 | 换轻量模型、走批量 |
| 长文写作生成 | 输入小、输出大 | 输出 | 分段生成、砍冗余展开 |
先判断自己属于哪一类，再决定把力气花在哪。给「输入大户」压输出格式、给「输出大户」做输入缓存，都是方向搞反的无用功。
长上下文为什么容易超预算
长上下文模型允许一次放入大量内容，但「能放进去」不等于「每次都该全放」。常见浪费：
| 浪费模式 | 后果 | 替代做法 |
|---|---|---|
| 每次请求重发整个仓库 | 输入费用线性爆炸 | 只发相关文件和片段 |
| 对话历史从不裁剪 | 越聊越贵 | 定期开新会话或做摘要压缩 |
| 检索结果不去重 | 重复内容重复计费 | 检索后去重、截断再拼接 |
| 日志文档不筛选 | 大量无效 Token | 先用便宜模型摘要再交给主力模型 |
可以先用 gemini-3.5-flash 这类低价模型做分类和摘要，再把浓缩后的片段交给目标模型。Gemini 长上下文场景的细节见长上下文成本控制。
从单次费用估算月度预算
用四步从真实数据推预算，比拍脑袋可靠：
- 从用量记录取 20 至 50 次真实请求
- 分别算出平均输入和平均输出 Token
- 乘以每天预计请求次数，得到日成本
- 乘以每月使用天数，再上浮 20~30% 留给重试和增长
月费用 ≈ 单次平均费用 x 每日请求数 x 每月使用天数 x 1.3套一个具体的数字：假设平均单次输入 8,000、输出 1,000 Token，按当前主力模型单价算出单次约几分钱；日均 300 次请求、每月 22 个工作日，乘出来再上浮三成，就是一个有依据的月度预算数字。整个过程十分钟，比「大概每月几百块吧」的拍脑袋强得多，也方便预算超了之后回头对账，看究竟是单次变贵了还是次数变多了。
团队不要只盯总预算，还要按成员、项目和 Key 拆开设上限。测试脚本失控是真实世界里最常见的「账单事故」，独立 Key 的额度上限能保证它最多烧掉自己的配额，而不是整个团队的余额——这正是 Zivv 团队模式里成员级 Key 与预算的用途。
用量记录比估算更重要
上线前的估算只能给量级，运行后要定期看真实分布：
- 哪个模型消耗最多，是否有高价模型在做简单任务
- 输入与输出的比例是否异常（输入畸高通常是上下文失控）
- 哪个 Key 或成员增长最快
- 是否存在异常重试
先优化占比最大的一项，通常比全面压缩 Prompt 更有效：大头来自重复长上下文，就优先做检索和缓存；来自超长输出，就先收紧返回格式。给自己定一个简单的节奏：每周固定看一次用量分布，任何单项占比突然跳变（某个 Key 翻倍、输入输出比异常）都值得当天查明原因，因为异常拖到月底，账单已经把代价结清了。
常见问题 FAQ
Q：中文和英文的 Token 数一样吗？ A：不一样。同样含义的内容，中文消耗的 Token 通常多于英文，且不同模型的分词器不同，估算时以各模型实际计数为准。
Q：请求失败或报错会计费吗？ A：鉴权失败（401）、路径错误（404）这类没到模型的请求不计费；模型已开始生成后中断的请求，已产生的 Token 会计费。
Q：怎么知道一次请求用了多少 Token？ A：API 响应里带有用量字段（输入、输出 Token 数），控制台的用量记录也按请求维度展示，不需要自己数。
Q：充值的钱怎么换算成 Token？ A：Zivv 按 ¥1 = $1 充值，调用时按各模型单价从余额扣费，同样的钱在低价模型上能跑多几倍的量。
Q：输出为什么比输入贵？差多少？ A：生成 Token 的计算成本高于读取 Token，所以各家模型的输出单价普遍是输入的数倍，具体倍数因模型而异，以模型广场标注的两档单价为准。这也是「控制输出格式」性价比很高的原因。
一个可执行的成本控制顺序
- 从模型广场确认当前单价
- 用真实用量算平均单次成本
- 按任务选模型，别让顶配模型做简单分类
- 控制重复上下文和无效输出
- 为每个 Key 设可承受的上限
- 每周看一次用量变化，而不是月底才看账单
前两条是算账，中间两条是省钱，后两条是防失控。三组动作对应三种能力，缺一组都会在某个月的账单上补回来。
Token 成本没有一个适用于所有人的固定答案，可靠的做法永远是「当前价格 + 真实用量」算出来，再用模型选择、上下文管理和预算上限持续校正。想边算边试，注册 Zivv 充 ¥10 就能用真实请求跑通本文的整套方法，完整计费口径以计费文档为准。