先解决一件事：单位
AI 调用的价格标签上同时存在四种单位，它们互相之间没有换算提示：
- 元/千 tokens（国内厂商早期常用）
- 元/百万 tokens（现在的主流口径）
- 美元/百万 tokens（海外厂商）
- 万字（中文语境下的直觉单位，比如"20 万字上下文"）
先把前两种钉死，这是最容易看错的一格：
| 标价写法 | 换算成元/百万 tokens |
|---|---|
| 0.0008 元/千 tokens | 0.8 元 |
| 0.0005 元/千 tokens | 0.5 元 |
| 0.02 元/千 tokens | 20 元 |
| 输入 1 元/百万、输出 2 元 | 1 元 / 2 元 |
这不是虚构数字，都是历史公开定价：2024 年 5 月 7 日 DeepSeek-V2 开源时 API 是输入 1 元、输出 2 元（每百万 tokens）；同月中旬火山引擎把豆包主力模型报到 0.0008 元/千 tokens；5 月 21 日阿里云把 Qwen-Long 从 0.02 元/千 tokens 降到 0.0005 元（官方口径最高降幅 97%）。注意这些都是当年的价格，不是今天的报价——今天各家普遍更低。用它们只是为了演示算法。
看懂单位之后，真正的成本估算只有三步：标定 → 算单次 → 核账单。
第一步：标定你自己的"字/token 比"
几乎所有估算失败都源于用了一个别人给的固定比例。中文、英文、代码、JSON 的 token 密度差得很远：同样 1000 字，中文正文、英文正文和缩进密集的 JSON 能差出接近一倍的 token 数。
正确做法是拿你自己的数据标定一次，只要五分钟：
- 挑三份真实素材：一份典型输入（比如你要塞给模型的整份合同）、一份典型输出（模型该回给你的那段结果）、一份系统提示词。
- 用官方 tokenizer 数一遍，或者直接发一次真实请求，读返回里的 usage 字段。
- 记下三个比值：输入字数÷输入 tokens、输出字数÷输出 tokens、系统提示 tokens 的固定值。
之后所有估算都用你自己这三个系数。这一步的产出是一张便签，比如"我的中文输入约 1.5 字/token，输出约 1.2 字/token，系统提示固定 400 tokens"——别人的比例对你毫无意义。
还有一个必须单独标定的东西：思考过程的 token。 带推理模式的模型会把中间推理也算进输出计费，这部分经常是最终答案长度的几倍到几十倍。如果你的模型有"思考预算"开关，那它其实是个价格旋钮，不是效果开关。
第二步：算一次调用
公式很短，但每一项都要单独数：
一次调用的成本 = 输入 tokens ÷ 1,000,000 × 输入单价 + 输出 tokens ÷ 1,000,000 × 输出单价
输入侧要加总这四块，很多人只算第一块：
- 系统提示词（固定，每轮都重发）
- 本轮的用户内容或文档
- 历史对话轮次（Agent 场景下这是大头）
- 工具定义（挂 MCP 或 function calling 时，每个工具的 name、description、JSON Schema 都要占输入 token，工具一多就是几千）
拿一个具体例子走一遍。假设你做的是"读一份 3 万字文档、回 500 字结论"，标定结果 1.5 字/token，系统提示固定 400 tokens，按 DeepSeek-V2 当时的 1 元/百万输入、2 元/百万输出算：
- 输入：30,000 ÷ 1.5 = 20,000 tokens，加系统提示 400，约 20,400 tokens
- 输出：500 ÷ 1.2 ≈ 420 tokens
- 成本：20,400 ÷ 1,000,000 × 1 + 420 ÷ 1,000,000 × 2 ≈ 0.0204 + 0.00084 ≈ 0.021 元
一次两分钱，一百万次两万元。这里的关键结论不是绝对值，而是结构：输入占了 96% 的成本。 因为文档很长而回答很短。反过来做代码生成（进 2 千字、出 2 千字）时，输出占比会翻过来——输出单价通常是输入的 2 到 4 倍。 所以"输入输出比"决定了你该关心哪一侧，这是选型和优化的第一个分岔口。
Agent 场景：成本不是线性涨，是平方涨
单轮任务上面这个公式够用。Agent 不一样，因为它每一轮都要把完整历史重新发一遍。
假设每轮新增 1 份上下文，跑 4 轮：
- 第 1 轮发 1 份，第 2 轮发 2 份，第 3 轮发 3 份，第 4 轮发 4 份
- 累计输入 1+2+3+4 = 10 份，而不是 4 份
轮数 n 的累计量是 n(n+1)/2，也就是任务轮数翻倍，输入成本大约翻四倍。这就是为什么"我一次问答才两分钱，为什么月底账单三千块"——你算的是单轮，跑的是三十轮，而且工具定义和系统提示在这三十轮里被重发了三十遍。
三条直接可动的推论：
- 控制轮数比控制单轮长度更有效。 12 轮累计 78 份上下文，压到 6 轮只剩 21 份——省的是七成，不是一半。
- 工具按需加载。 常驻 20 个工具定义，等于每轮多付 20 份 schema。让智能体只在需要时挂载，是纯收益。
- 稳定前缀放最前面。 系统提示和长文档放在输入开头、可变内容放后面，才可能被缓存命中——下一节讲这个。
第三步：核对账单，而不是猜
估算只能用来做决策，真实成本必须从账单里读。三件事：
一、把 usage 字段存下来。 每次调用至少记 prompt tokens、completion tokens、以及（如果有）cached tokens 和推理 tokens。没有这张表，任何优化都是盲的。
二、按模型和按场景分列。 月账单除以调用次数得到"单次平均成本"这个数字几乎没有意义，因为它被两类任务混在一起了。要拆到"每个业务场景 × 每个模型"的粒度，看中位数和 P95，不是平均值——一个失控的长任务能把平均值抬到失真。
三、算到业务单位上。 把成本挂到"每份文档""每个活跃用户""每篇生成内容"上，而不是"每月 API 费用"。前者能回答"这个功能该不该做"，后者只能让你焦虑。
一个实用的换算：如果某个功能的单次成本是 0.02 元、每用户每天用 20 次，那每个活跃用户每天 0.4 元、每月约 12 元。这个数字一旦落到"每人每月"，就能直接跟客单价、留存价值放在同一张表上比较了。 这也是唯一能让非技术同事参与决策的表达方式。
反过来推：账单比预期高时，按这个顺序查
前面是正着算，这里是倒着查。假设你原本按单次两分钱估算，月底却跑了三千块——差了一万倍，说明估算模型漏了东西，而不是单价涨了。 按这个顺序查，通常三步内能定位：
第一查：调用次数是不是被放大了。 把总成本除以"你认为的业务次数"，得到每次业务实际花了几毛钱还是几块钱。如果是几块钱，说明一次业务背后跑了远不止一次调用。这一步暴露的通常是重试和轮次：失败重试有没有上限、Agent 有没有在同一个错误上反复兜圈。这是最常见的成本泄漏源，而且它不体现在任何一份报价单上。
第二查：输入侧哪一块在膨胀。 把某一轮请求的输入原样打出来数一遍，看四块各占多少。经验上最容易被忽略的是工具定义和历史轮次：前者是"挂了就一直在"，后者是"聊得越久越贵"。如果系统提示加工具定义就有 8000 tokens，那每次调用的起步价就已经定了，跟用户问什么无关。
第三查：输出侧有没有算上推理。 如果你用了带思考模式的模型，而估算时只按答案长度算，输出会整段低估。把 usage 里的推理 tokens 单独拉出来看占比，很多任务的推理量是答案的 5 到 20 倍。
查完这三步，绝大多数"账单失控"会落到两个结论之一：要么轮次失控，要么固定前缀太大。 前者用轮数上限和早停解决，后者用缓存和按需加载解决——两者的做法完全不同，所以先分清是哪一种，比急着换便宜模型有用得多。
缓存价为什么会改变架构
多数厂商对命中缓存的输入 token 单独定价，通常远低于标准输入价。这条规则的实际含义是：同样的内容，放的位置决定它按哪个价计费。
于是有三条工程习惯，它们不是"省钱技巧"，而是接口设计约束：
- 前缀要稳定。 系统提示、工具定义、长文档放前面，且不要在里面塞时间戳、随机 request id 这类会破坏前缀一致性的字段——一个字符的差别就可能导致整段前缀不命中。
- 别把动态内容插到中间。 把当前时间、用户名这类变量放到输入的末尾。
- 多轮任务优先复用同一会话前缀。 这也是 Agent 框架里"会话保持"的真实价值之一。
这套机制在商业层面的影响比在单个账单上更大，可以看 长上下文经济学：Prompt Caching 如何改变大模型商业变现与应用形态。工程侧的裁剪做法在 上下文工程与 Token 预算管理。
三条省法，各自的边界
算清成本之后才谈优化。三条路的适用条件完全不同，用错方向会白花力气：
换更便宜的模型。 前提是任务本身简单。判断方法：拿 50 条真实样本做小评测，看质量掉多少。如果 90% 的任务用轻量模型就够了，正确做法是分流而不是整体替换——这条路的系统做法在 降低企业 LLM 调用成本 70%：Prompt Caching、智能分流与小模型蒸馏。
缩短上下文。 前提是里面有冗余。典型冗余：把整个仓库塞进去只为改一个函数、历史轮次无限累积不清理、工具定义全量常驻。如果信息本来就必要，硬压缩只会把成本从输入侧搬到"任务失败重跑"上，后者贵得多。
减少调用次数。 前提是存在重复计算。同一份文档被问 10 次，正确做法是缓存中间结果或换成语义检索，而不是换个便宜模型再算 10 遍。自建 + 免费开源工作流的整套路子见 把 AI 账单砍掉 90%：本地部署 DeepSeek + 免费开源 Agent 工作流实战。
还有一种情况不该省：成本结构本身不是瓶颈时。 如果单次两分钱、每月一共三百块，那花在优化上的工时早就超过账单了。这三年价格一路向下——2025 年 4 月 24 日智谱把 GLM-4-Plus 从 50 元/百万 tokens 降到 5 元，2026 年 9 月 22 日深夜 OpenAI 与 Anthropic 在 90 分钟内先后把 API 价格永久下调（过程见 凌晨 90 分钟的价格战）——在一个持续下跌的成本曲线上做精细优化，回报周期通常比你想的短。 该做的是把量跑起来，把估算方法留下来。
一份可以直接抄走的清单
开始之前
- 用我自己的三份素材标定了字/token 比，而不是用别人的固定比例？
- 我知道这个模型是否单独计费的推理 token 吗？
- 我知道输入价和输出价分别是多少吗（统一到元/百万 tokens）？
算单次 4. 输入侧四块都加了吗：系统提示、本轮内容、历史轮次、工具定义？ 5. 这个任务是输入重（长文进短出）还是输出重（短进长出）？ 6. 如果是多轮，我算的是累计量而不是单轮量吗？
核账单 7. usage 字段落库了吗？ 8. 拆到"场景 × 模型"粒度了吗？看的是中位数和 P95 还是平均？ 9. 换算成"每业务单位多少钱"了吗？
决定要不要优化 10. 缓存命中条件满足吗（前缀稳定、动态内容在后）？ 11. 我要省的是单价、上下文长度还是调用次数——三者对应不同做法？ 12. 省下来的钱，值不值我花在这些清单上的时间？
第 12 问是真正的止损线。这三年最常见的错误不是算错，而是在成本根本不是瓶颈的地方精算，在该算清楚的地方直接签年约。
接着看什么
这套算法是"读模型发布稿"的下半篇——那篇讲怎么判断数字可不可信（怎么读一份大模型发布稿：六个数分三组看），这篇讲怎么把其中的价格栏变成你自己的预算。想理解为什么价格会在 2024 年 5 月集中跳水、又为什么 2026 年轮到大厂永久降价，历史脉络在 中国大模型三年：从 8 款备案到 1112 款。真要按成本做选型，两张对照表可以直接用：国产大模型横评 和 海外大模型横评。企业侧还要考虑统一路由和计费管控，看 企业级 AI Gateway 架构设计。
一句话版本
AI 调用的钱不是按"字"算的，是按 token 算的，而 token 要用你自己的素材标定；单次成本用公式算，多轮成本按平方算，最后一定换算成"每业务单位多少钱"——如果这笔账算下来还不到三百块，就别再优化了。