计费口径一变，模型就失效
成本模型建立在「计量单位 × 单价 × 用量」之上，任何一项变化都会让它失真。调价只是其中一种触发：计量单位从按次改为按 token、缓存命中单独计价、批处理通道有独立口径、图像与音频按不同单位折算，都会让原有的估算公式不再成立。重算的目标不是记住新数字，而是重建一套能随口径变化快速更新的结构。
基本信息
| 触发条件 | 价格调整、计量单位变化、缓存或批处理口径变化、套餐与配额调整 |
|---|---|
| 需要的数据 | 输入与输出 token 分布、缓存命中比例、重试次数、并发形态 |
| 关键口径 | 是否区分缓存读写、输出 token 是否含推理过程、是否有最低计费量 |
| 产出物 | 更新后的单位成本、预算预测与告警阈值 |
| 复核节奏 | 调价后立即重算，之后按固定周期回归 |
| 注意事项 | 具体单价与计费规则以厂商官方计费文档为准 |
典型使用场景
- 收到调价通知：先把新口径落到公式，再评估对预算的影响
- 新增缓存策略：命中率提升后重算实际单位成本，验证收益是否成立
- 切换到批处理通道：延迟换成本，需要按业务容忍度重新权衡
- 容量规划：按新口径预测下一个量级的支出，避免预算超支
- 功能定价：对外报价前确认成本基线，避免毛利被口径变化侵蚀
- 异常排查：账单增幅与业务增长不匹配时，重算定位是哪一项口径变化
成本项与易错点
| 成本项 | 计量单位 | 易错点 |
|---|---|---|
| 输入 token | 按 token 计量 | 长上下文与检索拼接会显著抬高输入侧 |
| 输出 token | 按 token 计量，口径各家不同 | 是否含推理过程需要核实 |
| 缓存读 | 低于常规输入计价 | 命中率下降时成本回升，需单独监控 |
| 缓存写 | 按写入量计价 | 首次写入成本增加，短期账单会上升 |
| 批处理 | 独立通道口径 | 只能用于可延迟任务，不能用于实时链路 |
| 图像与音频 | 按分辨率或时长折算 | 折算规则变化会让多模态成本波动 |
| 重试与失败 | 按实际调用计费 | 超时后重试在部分通道同样计费 |
| 最低计费量 | 按请求下限计量 | 短请求被按最低值计费，短文本成本被低估 |
重算模板
重算模板
# 用公式与占比表达，不写死单价
period: 月度
numerator:
billable_input_tokens: 输入 token 总量
billable_output_tokens: 输出 token 总量
cache_read_tokens: 缓存命中读取量
cache_write_tokens: 缓存写入量
image_units: 图像折算单位数
request_minimums: 触及最低计费量的请求数
unit_costs:
input: 相对权重 1.0
output: 相对权重（通常高于输入）
cache_read: 相对权重（通常低于输入）
cache_write: 相对权重
assumptions:
cache_hit_rate: 命中率实测值，不用估计
retry_rate: 重试率实测值
burst_margin: 峰值冗余比例
outputs:
cost_per_1k_requests: 折算结果
monthly_forecast: 按业务增长曲线外推
alert_threshold: 偏离基线触发阈值重算时先核对口径而不是先算数：把「按什么单位计费、哪些用量单独计价、最低计费量与推理内容如何计入」写清楚，再代入数据。口径不清时算出的精度是假象，方向可能是错的。
缓存与批处理的收益要用命中率与任务容忍度验证：命中率依赖提示词前缀的稳定性，批处理依赖任务可延迟。只看单价差额会高估收益，实际节省取决于你的流量结构。
不要依赖记忆中的价格做预算，也不要把它写进文档。计费规则、单位与折扣随时可能调整，一切以对应厂商的官方计费文档为准；成本模型应保存公式与用量数据，单价作为可替换的参数。