账单报警通常不会告诉你哪一行代码出了问题。它只告诉你，这个月模型调用费用比预期高了一截。很多人会把原因归到“模型太贵”，然后开始讨论要不要换便宜模型。可真实项目里，单价只是其中一个变量，更多成本被藏在请求链路里：上下文越塞越长、失败后自动重试、用户取消后流式输出还在跑、相似问题没有命中缓存。
这类问题很适合出现在 AI 后端面试里，因为它不只考会不会调模型接口，也考你有没有把大模型当成一个需要预算、观测和退路的线上依赖。
先把账单拆回一次请求
成本治理不能只看总金额。一次请求的成本大致来自输入 token、输出 token、调用次数、模型单价和额外链路成本。输入 token 往往被低估：系统提示词、历史对话、检索资料、工具说明、格式约束，全都会进入上下文。一个回答看起来只生成了几百字，实际输入可能已经塞了几千甚至上万 token。
如果面试官追问“怎么定位费用上涨”，比较稳的说法是：我会按接口、场景、用户、模型和时间窗口拆账，看平均输入长度、输出长度、重试次数、失败率和缓存命中率。只看调用次数不够，因为一次调用的上下文长度差异可能很大。
重试会把小问题放大成账单问题
大模型调用失败后重试是常见做法，但重试不是免费的。超时、限流、网络抖动都可能触发重试；如果没有退避和上限，一次用户请求背后可能打出多次模型调用。更麻烦的是，用户看到的只是“等了一会儿”，账单里留下的是多轮输入和输出。
重试要有边界：只对临时错误重试；限制次数；给整次请求设置总预算；重试前判断是否已经超过用户可接受等待时间。对非核心生成任务，可以直接降级或排队，而不是让所有请求同步等待模型恢复。
长上下文是最隐蔽的成本入口
很多团队为了让模型答得更准，会不断往提示词里加说明，往上下文里塞历史消息，往 RAG 结果里多放几段资料。短期看效果可能变好，长期看成本和延迟都会上去，而且质量不一定稳定。
更好的做法是给上下文设预算。历史对话要摘要或裁剪，检索资料要重排和去重，工具说明只放当前任务需要的部分。不要把“资料越多越安全”当默认策略。模型看见更多文本，不等于会用对更多信息。
流式输出也要处理取消
流式输出常被当成用户体验优化，但它也会带来成本问题。用户关闭页面、切换问题或网络断开后，如果后端没有把取消信号传到模型调用，模型可能继续生成完整答案。用户没看到，账单照样产生。
所以 AI 后端要记录取消率、平均已生成长度和取消后的后台运行时间。流式接口不仅要推 token，还要能感知客户端断开，及时停止下游调用，并释放连接和线程。
面试里可以这样收束
如果被问到大模型成本治理，我不会只说“换小模型”或“做缓存”。我会先拆成本来源：输入、输出、调用次数、重试和模型单价。然后看哪些场景成本异常，比如长上下文、多轮重试、低缓存命中、用户取消后仍生成。治理动作也要分层：上下文预算、缓存策略、重试上限、模型分级和账单监控。
成本不是财务同学月末才看的数字。对 AI 应用来说，它是系统设计的一部分。能把成本拆到请求级别，才有资格谈模型选择和商业化。
还有一个容易被忽略的细节：成本治理不能只靠事后统计。上线时就要埋好调用链路里的字段，比如业务场景、模型名、输入长度、输出长度、是否重试、是否命中缓存、是否被用户取消。没有这些字段，账单涨了以后只能猜；有了这些字段，才能把费用上涨定位到某个功能、某类用户或某次发布。