核心要点
记牢公式：单次成本 = 输入 token×输入单价 + 输出 token×输出单价；总成本再×调用量
估 token：中文约 1 字≈1~2 token，别忘 system prompt、few-shot 示例、RAG 检索片段、历史对话都算输入
估调用量：QPS 或 DAU × 人均轮次 × 每轮上下文长度，按峰值算容量
降本四招：换小模型、缓存、缩短 prompt、限制输出长度（max_tokens）
标准回答
第一步：算单次成本
单次成本 = 输入 token 数 × 输入单价 + 输出 token 数 × 输出单价。注意输出单价通常比输入贵几倍，输出长的功能要重点关注。
第二步：估 token 数
输入不止用户那句话，还包括 system prompt、few-shot 示例、RAG 检索拼进来的片段、多轮对话历史——这些往往是大头。中文粗估 1 字≈1~2 token，英文 1 词≈1.3 token，要精确就用官方 tokenizer 跑一遍真实样本。
第三步：乘上量级
总成本 = 单次成本 × 调用量。调用量 = DAU × 人均使用次数 × 每次轮数（多轮要累加滚雪球的历史上下文）。按峰值 QPS 估容量和限流，别只算日均。
第四步：降本
- 简单任务换小模型，难任务才上大模型（路由分流）。
- 对重复/相似请求做缓存，命中就不花钱。
- 精简 prompt、裁剪检索片段数量和长度。
- 用 max_tokens 限制输出，避免模型啰嗦烧钱。
举例：输入约 1000 token、输出约 500 token，日调用 10 万次，就先算单次再 ×10 万估月成本，对比不同模型选性价比最优的。
常见误区
⚠️ 常见踩坑
只数用户输入的几个字，忽略 system prompt、few-shot、RAG 片段和多轮历史——这些隐藏上下文常占输入 token 的大头，导致成本估算严重偏低。
追问
追问 1：多轮对话的成本为什么会越聊越贵？
每轮请求都要把之前的对话历史一起作为输入发给模型，上下文像滚雪球一样越来越长，输入 token 逐轮累加。控制方法：限制保留轮数、对早期历史做摘要压缩、或只带与当前问题相关的片段，而不是无脑全量塞历史。
追问 2：上线前怎么压测验证成本？
用一批真实/仿真请求样本跑一遍，记录每次实际的输入输出 token（API 返回的 usage 字段最准），算出真实人均成本，再乘预估量级。比拍脑袋估 token 准得多，还能顺便发现 prompt 是不是太长、输出是不是超预期。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。