AI 后端项目面试里，很多候选人会重点讲模型效果，却很少主动讲稳定性。可真实上线后，模型接口会超时、限流、返回格式异常，调用成本也会随着用户增长快速上升。面试官如果追问“线上怎么兜底”，就是在看你有没有把大模型当成生产系统的一部分。
模型调用和普通 HTTP 调用类似，但它更贵、更慢、更不稳定，输出还可能不完全符合格式。因此 AI 后端必须同时设计超时、重试、降级、缓存、限额和观测。
超时不能只调大
模型慢时，最直觉的做法是把超时时间调长。但超时越长，用户等待越久，服务端资源占用越久，排队也可能更严重。更合理的做法是按场景分层：实时对话要短超时，后台总结可以长一些；核心回答失败要给可理解的提示，非核心润色失败可以直接跳过。
重试也要谨慎。模型服务如果已经抖动，大量立即重试会放大流量。可以使用有限次数、退避、只对可重试错误重试，并且给每个用户或请求设置总预算。
降级不是失败，而是产品设计
AI 功能失败时，系统可以有不同降级方式：返回基于规则的结果、只展示检索资料、不生成总结、转人工、提示稍后重试。选择哪种方式，取决于业务场景。
面试题解析：可接受的降级是展示结构化要点，稍后补充生成，不建议是长时间空白等待。客服问答：可接受的降级是给知识库依据片段或转人工，不建议是编造确定答案。
- 文案润色：可接受的降级是返回输入内容和基础建议，不建议是阻塞主流程。
- 工具执行 Agent：可接受的降级是停止执行并要求确认，不建议是失败后继续猜参数。
成本要从第一天观测
大模型成本不是上线后才看的问题。一次请求用了多少 token、调用了几次模型、是否命中缓存、是否因为失败重试增加成本，都应该记录。否则用户量上来后，很难判断钱花在哪里。
可以按功能、用户、模型、场景统计成本。低价值场景用小模型或规则，高价值复杂场景再用强模型。重复问题可以缓存，长上下文可以摘要，历史消息不能无限带上。
面试里更成熟的表达
可以这样总结：AI 后端不只是调模型接口。我会给模型调用设置场景化超时和重试上限，按错误类型决定降级；对高风险输出做格式校验和安全边界；同时记录 token、耗时、失败率、缓存命中和用户维度成本。这样系统即使在模型抖动或流量上涨时，也能保持可控。
还有一个面试里很加分的点：把成本治理和用户价值绑定。不是所有请求都值得调用最强模型，也不是所有用户都需要同样长的上下文。可以按场景分层：简单分类用规则或小模型，复杂推理再走强模型；高频重复问题优先缓存；低置信度回答再升级处理。
这样设计不是为了省钱而牺牲体验，而是把有限预算花在真正影响结果的地方。面试官听到这里，会更容易判断你考虑过上线后的可持续运营。