一次模型路由误触发引发的成本雪崩：从额度超限到动态降级的工程复盘

问题现象：用户无感知，账单先报警

2026年4月中旬，我们收到云厂商的用量告警：某AI服务的月度Token消耗在3天内超出预算300%，且主要流量集中在高成本大模型上。此时业务侧无任何异常反馈，用户请求成功率、响应延迟均正常。初步排查发现，超过60%的请求被错误路由到高成本模型，而原本应走低成本模型的场景未被正确识别。

更严重的是，由于额度治理模块未及时干预，系统持续向高成本模型发送请求，导致当日额度耗尽，后续请求全部被限流，形成“成本雪崩 → 服务降级”的连锁反应。

排查顺序：从现象到链路的逐层下钻

我们按以下顺序展开排查：

1. 确认现象范围：通过日志抽样发现，错误路由集中在特定业务场景（如客服意图分类），且多发生在非高峰时段。
2. 检查路由策略配置：发现路由规则中“意图置信度阈值”被误设为0.3（正常应为0.7），导致大量低置信度请求被强制升级。
3. 验证额度治理逻辑：额度模块依赖“当前用量/月度预算”比值做限流，但未考虑“单位请求成本差异”，对高成本模型缺乏独立额度控制。
4. 追踪状态流转：发现路由决策与额度检查之间存在时序漏洞——路由先执行，额度后校验，导致高成本请求已发出才触发限流。

关键证据：日志中的决策断层

通过分析请求链路日志，我们提取到三类关键证据：

• 证据1：路由决策日志显示，同一批请求中，意图置信度为0.4~0.6的样本被标记为“需升级处理”，但业务定义中此类场景应由轻量模型处理。
• 证据2：额度模块日志显示，在额度耗尽前5分钟，系统已连续发出12万次高成本模型请求，而额度告警阈值设置为80%，未及时阻断。
• 证据3：状态机流转记录显示，路由模块输出“model_type: high”后，额度模块仅检查“total_usage < budget”，未校验“high_cost_usage < high_budget”。

这三条证据共同指向一个核心问题：路由策略与额度治理之间缺乏协同设计，导致局部决策失控引发全局成本风险。

根因：策略解耦与状态机缺陷

根本原因可归结为两点：

1. 路由策略与成本感知脱节

路由模块仅基于“意图置信度”做决策，未接入“模型单位成本”和“当前额度水位”信息。当置信度阈值设置偏低时，系统倾向于“宁可错杀不可放过”，将所有边缘case推向高成本模型。

2. 额度治理缺乏分层控制

现有额度模块采用“总量控制”模式，未区分模型层级。高成本模型（如GPT-4级别）与低成本模型（如轻量LLM）共享同一额度池，导致低成本请求被高成本流量挤占，形成“公地悲剧”。

此外，路由与额度模块之间存在状态机断层：路由决策后直接调用模型API，额度检查作为后置步骤，无法阻止已发出的请求。这种“先执行后校验”的设计违背了稳定性优先原则。

实现方案：分层额度 + 前置拦截 + 动态降级

我们提出三项工程改进：

1. 引入分层额度池

为不同成本层级的模型设立独立额度池，并设置动态分配策略：

• 高成本模型：独立额度池，默认占比≤20%总预算
• 中成本模型：共享池A，占比30%
• 低成本模型：共享池B，占比50% 额度分配支持按小时动态调整，高峰时段可临时借用其他池额度，但需记录并后续归还。

2. 路由决策前置额度检查

重构请求链路，将额度检查提前至路由决策前：

请求 → 额度检查（按预估成本） → 路由决策 → 模型调用

额度检查阶段需预估本次请求的Token消耗（基于历史均值或Prompt长度），若高成本池额度不足，则强制路由至低成本模型，避免“先斩后奏”。

3. 动态降级策略

当高成本模型额度耗尽或响应超时，系统自动触发降级：

• 一级降级：切换至同功能低成本模型（如GPT-4 → Claude 3 Haiku）
• 二级降级：启用缓存结果或简化Prompt（如移除非关键上下文）
• 三级降级：返回兜底响应（如“请稍后再试”） 降级策略需记录降级原因与影响范围，供后续优化参考。

风险与边界：避免过度治理

风险1：降级影响用户体验

低成本模型效果可能下降，需通过A/B测试验证降级阈值合理性。建议在非核心场景（如FAQ检索）优先试点。

风险2：额度分配僵化

固定比例分配可能导致资源浪费。解决方案是引入“弹性额度借用”机制，允许低成本池在空闲时向高成本池出借额度，但需设置借用上限与归还期限。

边界条件：

• 仅适用于多模型并存的AI系统，单模型场景无需分层额度
• 要求模型间具备功能兼容性（如均支持意图分类）
• 需具备Token消耗预估能力，否则前置检查无法实施

最后总结

本次故障暴露了AI工程中一个典型盲区：局部优化可能引发全局风险。路由策略追求“效果最优”，额度治理关注“总量可控”，但两者缺乏协同导致成本雪崩。

工程落地需坚持三点原则：

1. 决策前置：关键控制点（如额度检查）必须前置，避免后置校验失效
2. 分层治理：按风险等级划分控制粒度，高成本操作需独立管控
3. 状态闭环：路由、额度、降级等模块需共享状态机，确保决策一致性

最终，我们通过分层额度池、前置拦截与动态降级策略，将高成本模型用量控制在预算内，同时保障了核心场景的服务稳定性。这一案例再次证明：AI系统的稳定性不仅依赖模型效果，更取决于后台链路的工程严谨性。

技术补丁包

1. 分层额度池设计 原理：按模型成本层级划分独立额度池，支持动态分配与弹性借用
   设计动机：避免高成本模型挤占全局额度，实现精细化成本治理
   边界条件：需模型具备功能兼容性，且系统支持Token消耗预估
   落地建议：在额度服务中新增cost_tier字段，路由模块调用前查询quota_service.check(cost_tier, estimated_tokens)

2. 路由前置额度检查机制 原理：将额度检查提前至路由决策前，基于预估Token消耗做拦截
   设计动机：防止“先执行后校验”导致不可逆成本支出
   边界条件：要求Prompt长度稳定或具备历史均值数据
   落地建议：在网关层插入PreRouteQuotaFilter，调用模型前执行if !quota.Check(model.Tier, len(prompt)*avgTokensPerChar) { return fallback }

3. 动态降级策略实现 原理：按额度水位与响应时间触发多级降级，保障服务可用性
   设计动机：在高成本模型不可用时提供无缝体验过渡
   边界条件：需定义降级映射表（如model_A → model_B）及兜底响应模板
   落地建议：在路由服务中实现DegradationPolicyEngine，根据quota_status和latency_p99选择降级路径

4. 额度弹性借用协议 原理：允许空闲额度池向高负载池临时出借额度，提升资源利用率
   设计动机：避免固定分配导致的资源浪费
   边界条件：需设置借用上限（如不超过池总量的30%）与自动归还机制
   落地建议：在额度服务中实现BorrowQuota(fromTier, toTier, amount, ttl)接口，定时任务自动回收过期借用

5. 路由-额度状态同步机制 原理：通过共享状态机确保路由决策与额度状态一致
   设计动机：解决模块间状态断层导致的决策冲突
   边界条件：需统一状态定义（如QUOTA_AVAILABLE,QUOTA_EXHAUSTED）
   落地建议：引入DecisionContext对象，在请求链路中传递quota_status，路由模块据此调整策略