算力成本翻倍不止翻倍：从链路优化到业务问责

刚把我们团队的 AI 小助手从十几个人的内部试点，推到全公司十几个部门使用时，我才真切感受到“算力成本翻倍不止翻倍”。试点时一次调用几百毫秒、费用几块钱，大家都觉得还能接受；但并发请求上千、业务链路出现多轮推理、失败后要重试甚至人工复核时，实际支出已经远远超出原来的两倍。

更糟的是，模型并没有突然坏掉，而是慢慢偏离业务需求。试点时我们挑了干净的数据、明确的任务边界，结果上线后用户提问方式多了、上下游系统返回的字段结构也变了，答案开始出现前后不一致、细节缺失的情况。这类错误不像系统报错那样触发告警，却悄悄增加了人工复核量，侵蚀了用户信任。

面对这种“静默失败”，我学到的第一条经验是把验证做成常态。高影响的请求要保留完整的输入、输出和人工处理记录；业务规则一旦变动，就必须有人负责及时更新知识库并复核效果；对于无法确定答案的请求，系统应直接转人工或降级到确定性流程，而不是硬塞一段看似通顺却缺乏依据的文字。

成本失控的根源往往藏在链路的每一个环节。一次业务请求可能触发三次模型调用：一次用大模型理解意图，一次用中等模型生成草稿，最后一次用小模型做格式化。如果把所有环节都塞进高价模型，算力费用自然会翻倍。我的做法是先画出完整的调用链，把高价值、低价值的节点分别匹配不同能力的模型，同时对重试、日志保存等隐形消耗做好预估。这样即使使用频率提升，整体花费也能保持在可接受范围。

扩展前的检查清单

• 模型输出是否有明确的业务验收标准，哪些错误可容忍，哪些必须人工介入。




• 知识库更新由谁负责、多久一次，是否有业务确认流程。




• 是否已经埋点监控人工改写率、转人工比例等“表面正常”的质量信号。




• 完整链路的算力、并发、重试和人工成本是否已计入预算。




• 高峰期没有资源时是否有降级方案，能够限制功能或转入人工流程。




• 出现异常时谁有权暂停或回滚系统，决策流程是否已书面化。

把这些问题写进文档并签字确认后，才敢把 AI 推向全公司。只有把试点的“有人盯着”变成可持续治理的业务能力，算力成本才不会像雪球一样失控。