推理与调用
按 token 计费时输入长度往往占大头，长文档整篇投喂会让费用随篇幅线性上升。做法是先检索再截取、把固定说明放进系统提示、对高频问题加缓存，能在不降低质量的前提下压掉一部分支出，且改动范围可控，便于逐项验证。
失败与返工
超时重试、格式不合规重新生成、人工逐条纠错，都是账面之外的支出。统计每百次任务的失败次数与返工工时，往往比单价更能解释月度账单的波动，也更容易找到明确的优化入口，让改动有的放矢。
冗余容量
为峰值预留的算力在平时闲置，闲置率高的专属实例会推高单位任务成本。可以用按量资源补充峰值、把批处理任务挪到低谷时段、对非实时请求排队，降低为峰值付全价的比例，同时不牺牲白天的响应体验。
数据与人力
知识库清洗、评测集维护、提示词迭代与值班监控都是持续投入，且随场景数量增长。这部分不宜一刀切压缩，评测与知识维护缺失会以质量事故的方式反噬，处理成本通常高于省下的投入，还会影响业务方信心。
先测再改
先按场景、模型与输入长度给每次调用打标签，归集一个月账单，找出占比最高的两三项，再做单变量改动并复测。没有基线就做优化，通常只是把成本从一科目挪到另一科目，月底看不出变化，也无法向管理层说明成效。
适用与不适用
适合谁
- 月度模型账单波动大、说不清原因的团队
- 准备扩场景、需要预估边际成本的企业
- 要把 AI 支出纳入部门核算的财务与 IT 负责人
不适合谁
- 尚未上线、没有真实调用数据的项目
- 只接受一次性采购、不做月度复核的组织
典型场景
某零售企业的客服助手月账单持续上升，团队先按场景、模型与输入长度打标签，发现大部分费用来自把整份商品手册塞进上下文。改为检索片段加固定摘要后，再用同一评测集确认答案质量未降，才把改动推到全部入口，并把单位任务成本纳入月度汇报。
可执行步骤
- 给每次调用打上场景、模型、输入长度与输出长度标签，写入可查询的明细表并保留一个月以上
- 按月归集账单，列出占比最高的三项成本，并写明各自的主要成因与对应的责任方
- 对单项做改动，例如检索截取、缓存命中、批处理合并或把部分流量降到更小的模型
- 用固定评测集复测质量，确认成功率与人工接管率没有实质下降后再逐步推广到其他入口
- 记录改动前后的单位任务成本并归档，作为下一轮优化的基线与向管理层汇报的依据
常见坑
- 只看单价不看用量结构，优化方向选错，投入人力却收效有限，还会错失真正的成本大头，项目节奏也随之被打乱。
- 为省钱换小模型却不复测，错误率上升后人工返工成本更高，账面省下的钱又花在客服与补录上
- 没有评测集做对照，无法证明优化没有牺牲回答质量，业务方难以认可，推广阶段阻力很大，复盘时难以说明原因。
- 把评测与知识维护当成可削减项，半年后回答质量整体下滑，补救成本高于当初省下的全部投入
- 成本口径随汇报对象变化，前后数据不可比，优化成效无法验证，预算评审也缺少可信依据，责任与损失都难界定。
自检与验收清单
- 是否按场景与模型维度归集了月度成本并保留完整明细
- 是否统计失败重试次数与人工返工工时并形成月度记录
- 峰值预留容量的闲置率是否测算过并形成结论
- 每次优化是否有评测集对照记录与明确的推广范围
- 单位任务成本口径是否固定，并能在月度之间保持可比
常见问题
成本优化会不会影响回答质量？
会，所以每次改动都要用固定评测集做单变量对照，确认成功率与人工接管率没有实质变化。质量与成本的平衡点应由业务负责人确认，不能由工程侧单方面决定，也不能用平均值掩盖长尾失败。
换成小模型一定能省钱吗？
不一定。小模型单价低，但可能多次重试或大量转人工，综合成本反而上升。判断标准是单位任务完成成本，包含重试、返工与接管，而不是单次调用价格，测算口径要事先约定。
成本按部门还是按场景归集？
两者都要。按部门用于预算与考核，按场景用于优化。标签体系要能同时支撑两个维度，否则月底只能看到总数，无法定位到具体入口和责任人，优化也就无从下手，预算也很难谈得清楚，复盘时缺少依据。