先统一口径：成本到底算什么
推理成本通常包含：算力（GPU/TPU）、网络、存储、以及人力运维。文章级别的粗算往往只关注算力，但上线后你会发现缓存与重试会显著改变成本曲线。
粗算公式（直觉版）
把单次请求成本近似为：单次请求成本 ≈（输入 tokens + 输出 tokens）÷ 有效吞吐（tokens/s）× 资源单价。其中「有效吞吐」会被批处理、量化、KV cache、以及并发排队影响。若你只按峰值 FLOPS 估算，通常会低估延迟与排队带来的浪费。
并发与 SLA：别用单请求代表一切
线上成本由 P95/P99 延迟与并发共同决定。为了 SLA，你可能需要更多冗余副本；这部分成本要计入预算，而不是仅按平均 QPS 计算。
缓存：命中率的杠杆
对重复问题、稳定提示模板、以及 RAG 检索结果做缓存，常常比换更大模型更划算。缓存命中率应作为一级指标监控，而不是事后优化。
模型切换的隐性成本
更换模型不仅是单价变化，还可能触发：提示重写、评测回归、工具链兼容、以及客服与文档更新。把这些成本纳入决策，而不是只看 API 报价。
预算要分层：实验、灰度、全量
建议把预算拆成三层：实验预算（验证可行性）、灰度预算（验证稳定性）、全量预算（验证商业可持续性）。实验阶段允许较高单次成本，但要控制总量；灰度阶段重点看失败重试与峰值排队；全量阶段必须建立成本预警阈值。这样能避免“实验成功但上线亏损”的常见问题。
你可以每周追踪的三个数字
如果只追踪三个指标，优先选：单次请求平均成本、缓存命中率、P95 延迟。三者结合能快速判断问题是模型太重、缓存策略太弱，还是容量规划不足。指标的价值不在于漂亮，而在于能指导你下一步该优化哪里。
结算视角：别忽略失败请求
实际账单里，失败请求和超时重试也会产生成本。建议把“成功调用成本”和“总调用成本”分开统计，这样才能看清系统质量问题带来的额外支出。很多团队优化模型单价后，月账单却没有下降，原因往往就在重试链路和错误处理策略上。
结语
成本估算的目的不是得到精确数字，而是避免数量级错误。把 token、吞吐、并发与 SLA 写在同一页，你才能做出可执行的决策。