误区一：只比 token 单价
为什么单价低反而更贵？单价只是账单的一部分。提示长度、上下文轮数、重试与失败调用都会放大实际消耗，只比单价容易选出账面便宜、实际更贵的方案。用真实调用日志测算单位成本才有可比性。
误区二：按峰值买满
按业务峰值预留全年容量，闲时资源闲置。更合理的是保底加弹性：保底覆盖日常负载，峰值用按量补充。怎么设？按近三个月用量定保底，把容量成本与波动成本分开，避免长期为闲置付费。
误区三：忽略输出与重试
输出 token 通常单价更高，长回答与结构化输出会显著增加成本；失败重试与多轮上下文叠加同样计费。怎么发现？做调用日志分析，按接口统计输入输出比例与重试率，账单看起来正常时也要查。
误区四：漏算存储与出网
向量库、对象存储、日志留存与跨区传输按容量和流量计费，随数据积累持续增长。预算只列推理费用时，第二年往往出现意料之外的支出。怎么预算？把存储与出网按增长曲线单独估算并复核。
误区五：拿试点当生产
试点用户少、调用集中，单位成本看起来很低。生产环境并发高、问题分布更杂，缓存命中率下降，实际成本可能成倍上升。怎么避免？用生产前三个月的真实数据复核，而不是拿试点数字外推。
适用与不适用
适合谁
- AI 应用上线后成本上升的团队
- 正在做算力预算的技术与财务人员
- 需要评估自建与云服务成本的管理者
不适合谁
- 尚未进入生产、只做原型验证的项目
- 完全使用免费额度或内部闲置资源的场景
典型场景
某团队在试点阶段测得的单位成本很低，上线后账单却远超预算。排查发现多轮对话使输入长度翻倍，失败重试占比不低，且向量库容量按全量文档计费。补齐这三项后，重新做了预算模型，并设了季度复核。
可执行步骤
- 统计提示长度与上下文轮数的分布，找出长尾调用与异常请求类型与来源
- 记录失败重试与超时调用的占比，纳入成本测算与优化清单中跟踪与结果
- 把存储、日志与出网纳入月度预算，按数据增长趋势估算上限与复核
- 按保底加弹性设计容量方案，并定期复核实际利用率与偏差来源，及时修正
- 用生产前三个月的真实调用数据，复核试点估算与单价假设是否成立
常见坑
- 用试点单位成本推算全年预算，上线后超支，只能临时压缩其他项目，年度复盘也交代不过去
- 只比单价而忽略调用结构差异，选出的方案实际更贵，复盘时才发现，比价基础已不存在，只能重新招标
- 容量按峰值买满，闲时资源浪费，财务质疑利用率却无从解释，议价也缺依据，很难自证，只能接受
- 不记录失败调用与重试，浪费长期隐形，账单无法归因到具体场景，优化没有抓手与依据，季度复盘流于形式
自检与验收清单
- 是否统计上下文长度、轮数分布与长尾调用占比
- 失败重试与超时调用是否单独计量并归因到场景
- 存储、日志与出网是否纳入月度预算与对账口径
- 容量方案是否采用保底加弹性的混合结构并复核
常见问题
怎么降低推理成本？
常见做法是压缩提示、缓存高频问题、按任务选择合适规模的模型、限制上下文轮数。每项都要用调用日志验证效果，避免影响回答质量，否则省下的成本会以投诉形式还回来。
包年套餐一定更便宜吗？
要看利用率。用量稳定且接近套餐额度时更划算；用量波动大时，包年可能造成闲置。签约前用近三个月实际用量测算，并留出业务增长的弹性空间，不要一次签满。
算力成本会随模型升级变化吗？
会。模型版本、定价与计费口径都可能调整，预算应保留弹性，并在合同中约定价格变动通知期。把成本模型做成可调参数，比写死在预算表里更实用，也便于逐月校准。