AI 网关的降级策略：不是所有任务都配得上一个便宜模型

AI 网关在 2026 年的产品形态已经比较清晰：统一接入多个模型供应商，做鉴权、路由、限流、重试、熔断、降级、成本统计和审计。但降级这个动作，比大多数网关配置界面暗示的要微妙得多。

一个来自企业多模型网关设计的实操规则是：超时、限流、5xx 触发 fallback 是合理的，但高风险任务禁止自动降级到能力不足的模型。合同审阅、财务分析、客户正式回复这类任务，即使主模型不可用，也应该进入人工审核或延迟队列，而不是盲目换一个便宜模型。原因不在于便宜模型“不够聪明”，而在于降级之后错误更难被发现：低质量输出披着正常响应的外衣流入下游，比一个明确的 503 更有害。

另一个容易被低估的设计点是缓存和降级的交互。缓存能省钱的前提是提示词结构稳定，动态内容不要放在可缓存前缀里乱动。如果降级后的模型和主模型共享缓存 key，但生成风格和格式约定不同，缓存命中反而会造成输出不一致。比较稳的做法是让缓存 key 带上模型标识和 prompt 版本，降级路径使用独立的缓存命名空间。

从成本治理角度看，网关需要记录的字段远不止 input/output token：cached_tokens、model_price_version、business_unit、route_reason、request_id，这些字段决定了你能不能回答“这次降级到底省了多少钱、多花了多少人工”。没有 route_reason 的成本报表，只是一张账单，不是治理工具。

AI 网关的价值不是把架构画复杂，而是让企业在模型快速变化时保有选择权。但选择权的前提是降级边界清晰：哪些任务可以自动降，哪些必须停住、等人。