一次大模型调用的成本怎么估算？
一句话回答
大模型按 token 计费：费用 = 输入 token × 输入单价 + 输出 token × 输出单价，输出的单价通常比输入高。估算时最容易漏的是输入：系统提示、工具定义、历史消息、检索到的资料每次请求都要重新发送；一次工具调用就多一次完整的往返；推理模型的思考过程通常也按输出计费。先算出单次请求的 token 数，再乘以请求量推到月成本，上线后用真实的用量校正。缓存命中的输入部分可能有折扣。
详细解析
输入里有什么
| 组成 | 说明 |
|---|---|
| 系统提示 | 每次请求都带 |
| 工具定义 | 每个工具的名称、描述、参数 Schema 都计入输入 |
| 历史消息 | 多轮对话中，每一轮都要把之前的对话再发一遍 |
| 检索内容 | RAG 拼进去的文档片段，往往是输入的大头 |
| 用户问题 | 通常只占一小部分 |
让成本成倍增长的地方
- 多轮对话：第 k 轮的输入包含前面所有轮次。假设每轮问答约 m 个 token，第 k 轮的输入约为 k × m，n 轮下来总输入约为 m × n² / 2，随轮数平方增长。所以要做历史截断和摘要（见多轮对话的上下文怎么管理）
- 工具调用：模型返回工具调用，应用执行后带着结果再请求一次。每多一轮，整个上下文就再发一遍，工具结果也计入输入
- Agent：一个任务可能循环十几步，每一步都是一次完整的调用，成本要按任务而不是按请求估算
- 推理模型：回答之前生成的思考内容，通常按输出 token 计费，即使不展示给用户
- 重试：超时重试、格式校验失败后重新生成，都会重复计费
为什么输出更贵
输入的所有 token 可以一次并行计算（prefill），GPU 的利用率高；输出只能一个一个地生成（decode），每一步都要把模型权重从显存里读一遍，却只为每个请求产出一个 token。所以每个输出 token 占用的 GPU 时间更多，定价也更高（prefill 和 decode 见 KV Cache 是什么）。
举例估算
下面的单价都是假设值，只用来演示计算方法，实际以供应商的官方价格为准：
假设单价：输入 2 元 / 百万 token，输出 8 元 / 百万 token
一次 RAG 问答：
输入 = 系统提示 1000 + 检索片段 3000 + 历史消息 2000 + 问题 100 = 6100 token
输出 = 500 token
费用 = 6100 × 2 / 1,000,000 + 500 × 8 / 1,000,000 = 0.0122 + 0.004 = 0.0162 元
按日活估算月成本：
日活 1 万，每人每天提问 10 次，每月 30 天 → 300 万次请求
月成本 ≈ 300 万 × 0.0162 元 ≈ 4.9 万元可以看到：输出单价是输入的 4 倍，但在这个场景里，输入的费用占了七成以上，压缩上下文比限制输出更有效。
实际估算还要考虑：用量的分布（少数重度用户可能占大头）；Embedding、重排等附属调用；开发调试和评测的消耗；再留出一定的余量。
用真实数据校正
- 每次调用都记录接口返回的 usage（输入、输出、缓存命中的 token 数），按用户、功能、模型汇总（见 LLM 应用的可观测性）
- 上线前用对应模型的分词器统计样本的 token 数，不要用固定的"一个汉字等于几个 token"去换算（见 Token 是什么）
代码示例
// 单价单位：元 / 百万 token。都是假设值，实际做成配置，以供应商价格为准
const PRICE = { input: 2, cachedInput: 0.5, output: 8 }
function estimateCost({ inputTokens, cachedTokens = 0, outputTokens }) {
// inputTokens 是包含命中部分的总输入；各家 usage 的统计口径不同，换算时要注意
const uncached = inputTokens - cachedTokens // 缓存命中的部分按折扣价计算
return (uncached * PRICE.input + cachedTokens * PRICE.cachedInput + outputTokens * PRICE.output) / 1e6
}
estimateCost({ inputTokens: 6100, outputTokens: 500 }) // 0.0162
estimateCost({ inputTokens: 6100, cachedTokens: 1000, outputTokens: 500 }) // 假设其中 1000 个 token 命中缓存：0.0147面试官可能追问
怎么在上线前把成本估得更准？
用真实或模拟的对话样本跑一遍，统计每次请求的输入、输出 token 的分布，看 P50 和 P95，不只看平均值，再乘以预估的请求量。多轮对话越往后越贵，要按平均的对话轮数估算整段会话的成本。上线后按真实的 usage 校正，并设置用量告警。
中文和英文的 token 数一样吗？
不一样，而且不同模型之间差别很大：分词器的词表不同，同一段中文在不同模型里切出的 token 数可能相差明显。估算时用对应模型的分词器实际统计，或者直接看接口返回的 usage。
估出来成本太高，从哪里下手？
先看钱花在哪：按输入的各个组成部分、按功能、按用户统计。常见的大头是历史消息和检索内容，再就是不必要的大模型调用。具体手段见降低大模型调用成本有哪些办法，其中提示缓存见 Prompt Caching。
易错点
- 只按"问题 + 回答"的长度估算，漏掉系统提示、历史消息和检索内容
- 用单次请求的成本乘以请求量，忽略了多轮对话的成本随轮数平方增长
- 把某个时间点的价格写死在代码里，价格调整后估算就失真了
- 忘了推理模型的思考 token 和工具调用带来的额外往返
AI 模拟面试官
用自己的话回答，AI 对照参考答案打分、指出遗漏，再追问，最多 3 轮
这道题你掌握了吗？
选一个最接近的状态，没掌握的题会出现在"我的进度 · 待复习"里。
学习记录暂存在本机浏览器。登录后自动同步到账号，换设备也能看到。