Appearance
2.8 成本估算实操
"这个 AI 功能上线后每月要花多少钱？"——这是产品决策必答题。这一节用一个完整算例教你估算，避免上线后账单吓一跳。
成本由什么决定
一次调用的费用 = 输入 Token × 输入单价 + 输出 Token × 输出单价。
放大到一个功能的月成本，关键是四个量：
月成本 ≈ 日请求数 × 30
× (单次输入 Token × 输入单价 + 单次输出 Token × 输出单价)记住两个事实：
- 输出比输入贵（通常 3-5 倍）
- System Prompt 每次请求都计费——它是隐性大头
完整算例：一个客服问答功能
假设：
| 量 | 估值 |
|---|---|
| 日请求数 | 5,000 次 |
| System Prompt（固定） | 800 Token |
| RAG 检索拼进去的文档 | 1,200 Token |
| 用户问题 | 平均 100 Token |
| AI 回答 | 平均 400 Token |
单次输入 = 800 + 1200 + 100 = 2,100 Token单次输出 = 400 Token
假设单价（便宜的国产模型量级，仅示意）：输入 ¥0.001/千 Token，输出 ¥0.002/千 Token。
单次输入费 = 2100 / 1000 × 0.001 = ¥0.0021
单次输出费 = 400 / 1000 × 0.002 = ¥0.0008
单次合计 ≈ ¥0.0029
日成本 = 5000 × 0.0029 ≈ ¥14.5
月成本 = 14.5 × 30 ≈ ¥435💡 注意：输入占了大头（¥0.0021 vs ¥0.0008），而输入里 System Prompt + RAG 文档 = 2000 Token，用户问题才 100。优化空间在固定输入，不在用户问题。
看清楚钱花在哪，再优化
把同一个算例换算成"钱花在哪"：
System Prompt (800) ┐
RAG 文档 (1200) ├─ 占输入的 95%，是优化重点
用户问题 (100) ┘
AI 回答 (400) ── 输出，按需控制长度对应的优化手段：
| 优化 | 怎么做 | 效果 |
|---|---|---|
| 精简 System Prompt | 去废话，只留必要规则 | 直接降固定输入 |
| 利用上下文缓存 | 固定内容放最前，命中缓存按低价计费 | System Prompt 部分大幅降价 |
| 控制 RAG 注入量 | 只拼最相关的 2-3 段，别全塞 | 降输入，还提质量 |
| 限制输出长度 | "200 字内回答" | 降最贵的输出 |
| 分档用模型 | 简单问题用小模型 | 降单价 |
| 批处理非实时任务 | 用 Batch API | 约省 50% |
套用 上下文缓存：上面那 800 Token 的 System Prompt 每次都一样，命中缓存后这部分可能只按几分之一计费——5000 次/天的量级，省下来很可观。
🛠️ 实战练习：估算你自己的功能
按下面模板，估一个你真实（或设想）的 AI 功能：
日请求数：____
单次输入 = System Prompt(__) + 注入内容(__) + 用户输入(__) = ____ Token
单次输出 = ____ Token
查到你用的模型输入/输出单价：____ / ____
月成本 ≈ 日请求 × 30 × (输入Token×输入单价 + 输出Token×输出单价)做完后回答：
- 钱主要花在输入还是输出？输入里哪部分最大？
- 如果请求量涨 10 倍，月成本是多少？还能承受吗？
- 三个最该优化的点是什么？
进阶挑战：在代码里用 response.usage（prompt_tokens / completion_tokens）真实统计 100 次调用的平均 token，和你的估算对比，校准你的估算模型。
📌 关键结论
- 月成本 ≈ 请求量 × 30 ×（输入 Token×输入单价 + 输出 Token×输出单价）
- 输出比输入贵，但输入里的 System Prompt + 注入内容往往才是大头
- 优化顺序：精简固定输入 → 用缓存 → 控制 RAG 注入与输出长度 → 分档用模型
- 上线前先估，并设每日告警；用
response.usage持续校准估算