TCO（Total Cost of Ownership）最常见的坑是：只看“每百万 tokens 单价”，忽略了缓存/批量/长上下文分段/工具按次收费/托管渠道差异。
先定义“计费对象”：请求、会话、还是任务
建议以“任务”为主（对齐业务价值），辅以“请求/会话”：
- 任务：一次“完成某件事”（例如：生成一份报价单、完成一次工单分类）
- 会话：多轮对话累计的 tokens（长上下文的主要成本来源）
- 请求：底层调用粒度（用于限流与计费核对）
成本构成清单（选型时必须逐项核对）
- 输入/输出 tokens
- 长上下文分段计价（例如 0-32K、32K-128K、128K+）
- 上下文缓存
- 命中 tokens 的折扣价格
- 缓存存储（按小时/按量）费用
- 批量推理（batch）：价格折扣、任务排队与失败重试机制
- 工具按次收费：联网搜索、插件、OCR、图片/视频生成等
- 托管渠道溢价：Azure/Bedrock/Vertex 的价差与配额差异
- 工程侧开销：重试导致的重复计费、回放/评测导致的额外 tokens
一个可直接复用的 TCO 估算模板
你可以先用“保守估算”（把不确定项按最坏情况算），再用 POC 数据校正。
TCO = Σ(任务数 * 任务成功率修正 * 单任务成本)
单任务成本 =
输入tokens * 输入单价(分段) +
输出tokens * 输出单价(分段) +
命中tokens * 命中单价 +
缓存存储(小时) * 存储单价 +
工具调用次数 * 工具单价 +
批量/折扣修正 +
重试/失败修正
POC 后一定要补的 3 个真实参数：
- 平均输入/输出 tokens（按场景分桶）
- 缓存命中率（按会话/按任务）
- 重试与失败率（按失败类型）
常见“成本陷阱”清单
- 长对话越用越贵：上下文不断变长，成本呈线性甚至“分段跳变”增长
- 缓存省钱但也可能烧钱：命中率低时，反而多了缓存存储费用与复杂度
- 工具调用是另一条账：联网搜索/OCR/多模态经常按次收费，容易被忽略
- 重试会重复计费：没有幂等与去重的重试，会把成本放大
你应该如何用“成本”做决策
- 用“单位产出成本”比较（每个成功任务多少钱），而不是只比 token 单价
- 先做“成本门禁”：
- 单任务成本上限
- 单会话成本上限
- 预算日上限（超过就降级/停机）