最容易做的 AI 预算，也最容易错：请求数乘以输入 token，再乘以模型单价。真实系统不是这样花钱的。一次产品调用可能包含长 system prompt、检索材料、工具 schema、输出 token、失败重试、安全检查、日志、存储，有时还包括一个真人在答案发给客户前复核。
对小团队来说，正确产物不是一张写满猜测的表，而是一份成本账本：每条成本有名字，尽早用真实调用轨迹替换估算，并在模型、价格、保留条款或工作流变化时更新。
成本账本怎么拆
| 成本项 | 估算方法 | 常见漏项 |
|---|---|---|
| 在线 API 调用 | 请求数 x（输入 token x 输入单价 + 输出 token x 输出单价 + reasoning/cache/tool/search/retry 成本） | 输出 token 和 reasoning/thinking token 可能才是主要开销。 |
| 上下文 | 静态 prompt + 对话历史 + 工具定义 + 检索文档 | 大上下文会被计费，即使真正有用的只有一小段。 |
| 缓存 | cache write、cache read、命中率、TTL、prompt 前缀稳定性 | prompt 顶部一个小变化，就可能让缓存命中率归零。 |
| 批处理 | 可等待的离线请求量和 provider batch 窗口 | 用户正在等待时不适合 batch；评测、富化、分类和 embedding 很适合。 |
| RAG | embedding/indexing + vector search + 回填上下文 token + rerank | 检索出来再塞回模型的文本，仍然按上下文 token 花钱。 |
| 向量数据库 | 向量数量、维度、查询量、metadata、备份、区域和最低套餐 | 有的按维度计费，有的有套餐最低消费，有的是托管 file-search 调用费。 |
| 评测 | 测试集规模 x 候选模型 x judge 模型 x 人工标注 | 评测是持续产品成本，不是上线前一次性任务。 |
| 人审 | 复核分钟数 x 综合时薪 x 升级处理比例 | 真正贵的通常是处理不确定、高风险或客户可见结果。 |
| 日志与观测 | token 日志、trace、错误事件、保留周期、查询量 | 详细 trace 有利于排障，也会带来存储、隐私和脱敏成本。 |
| 基础设施 | 模型网关、队列、worker、数据库、对象存储、密钥、监控和 fallback | 模型账单有时小于外围工程成本。 |
一个简单公式
先用这个月度公式估算：在线推理 + 离线 batch + embeddings + 检索/存储 + 评测 + 人审 + 日志/基础设施 + 20% 波动缓冲。缓冲不是悲观，而是给重试、prompt 改动、流量波动、provider 路由变化和新发现边界情况留空间。
到 2026 年 7 月已经变化的地方
- OpenAI、Anthropic 和 Gemini 都把 batch 做成正式路径，适合非实时任务；具体折扣、过期窗口和支持端点要以上线前最新文档为准。
- prompt/context caching 已经不是实现细节，而是预算杠杆。不同 provider 对 cache write、cache read、TTL 和 prompt 前缀稳定性的规则不同。
- 托管检索降低了搭建成本，但改变了账单形状。存储、工具调用、索引 embedding 和检索出的文档 token 可能分属不同成本线。
- 向量库没有统一价格模型。Cloudflare Vectorize、Pinecone 和数据库自建 pgvector，会在供应商费用、最低套餐和运维工作之间转移成本。
- 评测工具会变，真正应该沉淀的是数据集、评分规则和调用轨迹，而不是某个 dashboard。
按模型能力分流
| 工作负载 | 模型通道 | 成本规则 |
|---|---|---|
| 路由、打标、抽取、短分类 | 低成本快速模型 | prompt 保持短，输出强制结构化，能 batch 就 batch。 |
| 面向客户的 RAG 回答 | 标准模型 + 引用 + 检索评测 | 先把来源质量和评测做好，再考虑升级模型。 |
| 代码审查、复杂政策分析、高价值综合 | 前沿推理模型 | 只有任务价值能覆盖延迟、输出成本和人审时间时才使用。 |
| 工具调用 agent | 模型 + 产品控制 | 要预算重试、权限、审计日志和不可逆动作的人审确认。 |
RAG 成本不只是向量数据库
RAG 在第一个用户提问前就已经开始花钱：清洗文档、切块、embedding、建索引、metadata 设计和删除流程。查询时还会继续花在 embedding 或搜索、向量读取、可能的 rerank，以及回填给模型的上下文文本。如果答案必须引用来源，还要评测召回率、精确率、引用准确性和冲突处理。
最省钱的 RAG 往往不是检索最多，而是检索更准。更小的 top-k、更干净的 chunk、metadata 过滤，以及在证据不足时拒答的路径，既能降低幻觉风险，也能减少上下文成本。
预算可信度得分
| 得分 | 含义 |
|---|---|
| 0 | 没有 token 日志，没有估算，没有负责人。 |
| 1 | 有基于公开价格的表格，但没有真实调用轨迹。 |
| 2 | 小规模 pilot 已记录真实 token 使用，能看到输出 token 和重试。 |
| 3 | 缓存、batch、RAG、向量存储和人审已经拆成独立成本线。 |
| 4 | 有任务级评测、失败分类和每条工作流的单位经济账。 |
| 5 | 生产中有成本监控、异常告警、毛利测算、provider fallback，并每月复核动态价格和条款。 |
上线前该做什么
- 至少采集一个代表性周，或一组刻意覆盖边界的 pilot 调用轨迹。
- 把用户可见同步调用和可离线 batch 的任务分开。
- 实测缓存命中率，不要直接套用供应商最佳情况节省比例。
- 把 RAG 检索质量和模型质量放在同一张评审表里。
- 为低置信、受监管或不可逆输出写清楚人审策略。
- 在邀请真实用户前设置 spend limit、异常告警、日志保留和删除流程。
- 保留可迁移的评测数据、prompt 和 provider adapter，方便价格或条款变化时重新比较。