比较 API 成本时，不要只看标价
Claude、GPT、Gemini 的价格页很重要，但纸面上最便宜的模型，不一定就是你的产品中最便宜的方案。真实 API 成本取决于输入 token、输出 token、上下文长度、重试、缓存命中率，以及请求是否经常 fallback 到更强模型。比较不同工作负载前，可以先从 AI 模型价格表 建立统一基准，再用 2025 模型成本对比 继续比较不同供应商和模型档位。
如果你正在上线 AI 功能前比较模型供应商，可以用下面这套流程。
1. 先定义同一个任务
不要拿模糊 prompt 比较不同模型。先确定一个真实工作负载：
| 项目 | 示例 |
|---|---|
| 产品功能 | 客服助手、代码助手、文档总结 |
| 平均输入 | 用户问题加检索上下文 |
| 平均输出 | 简短回答、长报告、结构化 JSON |
| 调用量 | 每日或每月请求数 |
| 质量目标 | 草稿、正式回答、专家复核 |
只有任务相同，供应商成本比较才有意义。
2. 拆开输入和输出 token
大多数模型 API 的输入和输出价格不同。短 prompt 加长回答，可能比长 prompt 加短回答更贵。
可以用 文本模型计算器 至少测试三组场景：
- 基准请求。
- 长上下文请求。
- 高输出请求。
如果功能会用推理模型，也应结合 推理模型成本规划 比较成本结构。
3. 比较每个供应商内部的模型档位
Claude、GPT、Gemini 都有不同强度和价格的模型档位。公平比较时，不应只拿一个模型对一个模型，而要记录：
- 默认低成本模型。
- 复杂任务使用的高质量模型。
- fallback 模型。
- 批处理或后台任务模型。
- 最大上下文需求。
有时最佳方案不是所有请求都用同一个供应商。你可以用低成本模型做日常分类，再用强模型生成最终回答。
4. 把上下文长度算进预算
上下文长度会快速改变成本。每次请求 2,000 输入 token 的聊天助手，和每次附带 80,000 token 文档的研究助手，账单完全不同。
需要确认工作负载是否包含：
- 短 prompt。
- 检索片段。
- 完整文档上下文。
- 多轮对话历史。
- 工具定义或 function schema。
如果你在做 RAG 或长上下文功能，可以参考 RAG 聊天机器人成本估算 和 长上下文 API 成本规划。
5. 加入缓存和复用假设
提示词缓存可能改变比较结果。某个供应商的输入标价更高，但如果大段固定 prompt 或工具定义缓存效果好，真实成本可能更有竞争力。
计入缓存节省前，需要确认：
- 哪些 prompt 内容保持固定。
- 工具定义是否稳定。
- 动态变量是否破坏缓存前缀。
- 预期缓存命中率是多少。
- 缓存输入是否有不同价格。
可以配合 缓存命中率成本规划 做检查。
6. 计入重试和 fallback
忽略重试的成本比较通常过于乐观。预算中应加入这些倍数：
- SDK 自动重试。
- 队列任务重试。
- 用户刷新导致重复提交。
- 超时后重新执行。
- fallback 到更强模型。
当输出很长时，即使很小的重试比例也会影响总账单。
7. 建立供应商对比表
有用的表格不只记录价格，还要记录假设：
| 字段 | 记录内容 |
|---|---|
| provider | Claude、GPT、Gemini 或其他模型 API |
| 模型档位 | 低成本、均衡、高质量 |
| 输入 token | 基准值和 P90 |
| 输出 token | 基准值和 P90 |
| 请求量 | 每日或每月调用量 |
| 缓存命中率 | 预期值和实测值 |
| 重试率 | 预期倍数 |
| fallback 比例 | 升级到强模型的百分比 |
这张表能让你在选择供应商前看清成本和质量取舍。
总结
比较 Claude、GPT、Gemini API 成本时，先定义相同工作负载，再拆分输入和输出 token，比较各供应商内部模型档位，计入上下文长度、缓存、重试和 fallback。真正合适的方案，是能达到质量目标、成本可解释，并且上线后能持续监控的模型组合。