计量方式决定可比性
按 token 计费随请求长度波动，按实例时长计费与实际负载无关，自建则是折旧加运维。为什么必须先换算：直接比单价会把空闲成本藏起来，用量低时按量显得贵，用量高时自建显得省，结论随假设翻转。
缓存改变账本
前缀缓存通常按读写分别计价，写入一次、读取多次才划算。怎么判断：看同一段系统提示被复用的次数与间隔，复用少或间隔太长时，缓存未必省钱；边界是缓存有容量与过期限制，不能无限堆积。
批处理换价格
可延迟的任务走批处理，单价通常更低，代价是排队与更长的完成时间。为什么值得算：报表、归档与批量文案占比不小，挪到批处理能直接降低这部分支出；边界是业务时效要求必须先确认，不能事后补救。
限流与配额影响实际成本
配额不足会触发重试与排队，实际支出可能高于预期；配额过高则容易闲置。做法是按峰值请求速率申请配额，并留出重试余量；边界是配额调整往往需要提前申请，临时扩容不一定能批下来。
适用与不适用
适合谁
- 正在比较按量与预留方案、准备签年度协议的企业
- 有批处理与实时两类负载、时效要求不同的业务
- 需要向财务解释计价口径的成本团队
不适合谁
- 只有单一场景、用量很小、无承诺需求的团队
- 无法区分实时与离线任务的业务系统
典型场景
一家招聘平台的简历解析与职位推荐共用一套接口。团队把解析类任务改到夜间批处理，推荐保持实时，并把系统提示改为可缓存的前缀。换算到每任务成本后，两条链路的账第一次能放在一起比较，续约谈判也有了依据。
可执行步骤
- 把按 token、按实例时长与自建三种口径，统一换算成每任务成本
- 统计同一段系统提示的复用次数与间隔，判断缓存能否收回成本，再决定开关
- 区分实时与可延迟任务，评估批处理带来的延迟是否可以接受，再决定是否采用
- 按峰值请求速率申请配额，并预留重试所需余量，避免峰值时限流
- 签约前确认调价、超量与配额调整条款，写进合同附件并留书面记录
常见坑
- 拿按量单价与自建折旧直接对比，忽略空闲与运维人力，结论完全不可靠，容易做错决策。
- 为了省 token 把系统提示拆得很碎，缓存频繁失效，每次都要重新写入，反而更贵。
- 把有时效要求的任务放进批处理，第二天才出结果，业务方直接弃用，改回实时又来不及。
- 配额按均值申请，峰值时被限流，重试把实际支出推得更高，用户体验同时受损，还影响口碑。
自检与验收清单
- 三种计费口径是否都换算到每任务成本
- 缓存复用次数与间隔是否统计过并算过净收益
- 批处理任务是否确认可接受延迟与失败代价
- 配额是否按峰值速率并留足重试余量
- 调价与超量条款是否写进合同并经法务审阅
常见问题
批处理一定更便宜吗
单价通常更低，但要看任务是否能等待，以及失败重跑的成本。适合报表、归档、批量生成这类可延迟任务；客服与审批类不适合。判断方法是比较延迟带来的业务损失与节省的支出，而不是只看单价。
缓存要不要一直开着
看复用频率。同一段前缀在短时间内被多次使用时收益明显；复用很少或间隔很长，写入成本可能收不回来。建议按接口统计命中与写入比例，定期关掉低效缓存，避免账面上有缓存、实际没省。
实例计费适合什么场景
适合负载稳定、需要可预期延迟的场景，例如固定的实时推理服务。用量波动大时，实例在低谷期仍要付费，单位成本会被闲置摊高。选择前先看用量曲线的平稳程度，而不只是看标价。