📚 课程目录第3章 API熔断在MRM中的必要性

3、API熔断在MRM中的必要性：模型推理API的不稳定性来源、熔断如何保护模型服务、避免级联故障的案例

3.1 模型推理API的不稳定性来源

在MRM（模型风险监控）体系中，模型推理API并非运行在理想环境中。实际生产中的推理API面临多种不稳定性来源，这些来源可归纳为以下四类：

不稳定来源	典型表现	影响等级	发生频率
上游数据波动	特征缺失、数据延迟、分布偏移	高	频繁
模型计算瓶颈	GPU显存溢出、推理超时、OOM	高	中等
下游依赖故障	特征存储不可用、结果回写失败	中	偶发
流量突发冲击	秒级QPS飙升、连接池耗尽	高	周期性

  关键洞察： 模型推理API的故障往往不是单一原因导致，而是多个不稳定因素叠加后的“雪崩效应”。熔断机制正是为了在雪崩发生前切断故障传播路径。

3.2 熔断如何保护模型服务

API熔断机制在MRM中的核心价值在于：将局部故障隔离在有限范围内，防止故障向整个模型服务体系扩散。其保护原理基于三个状态转换：

关闭状态（Closed）： 正常调用，统计错误率。当错误率超过阈值（如5%）且持续窗口期（如10秒），触发熔断。
打开状态（Open）： 直接拒绝请求，快速返回降级响应。给模型服务恢复时间，避免无效重试。
半开状态（Half-Open）： 允许少量探测请求通过。若成功则关闭熔断器，若失败则重新打开。

最佳实践： 在MRM中，熔断阈值不应是静态的。建议结合模型PSI（群体稳定性指标）和推理延迟的滑动窗口动态调整阈值，使熔断器对数据漂移和计算瓶颈都有响应能力。

3.3 避免级联故障的案例

以下是一个真实场景的对比案例，展示熔断机制如何阻止级联故障：

案例背景：信贷风控模型推理链路

某金融机构的信贷审批系统依赖三个模型推理API：反欺诈模型（A）、信用评分模型（B）、额度定价模型（C）。其中模型B依赖模型A的输出，模型C依赖模型A和B的输出。

教训： 无熔断时，模型A的一次超时（如因上游特征延迟）会引发B和C的连锁超时，最终导致整个信贷审批链路瘫痪。有熔断时，A的故障被快速隔离，B和C通过降级策略（使用缓存特征、默认额度）继续提供服务，保障了核心业务的连续性。

熔断参数配置示例

# MRM熔断器配置示例（YAML格式）
circuit_breaker:
  model_a:
    enabled: true
    failure_threshold: 5          # 5次失败触发熔断
    success_threshold: 3          # 半开状态3次成功恢复
    timeout_window: 10s           # 统计窗口10秒
    open_state_duration: 30s      # 熔断持续时间30秒
    half_open_max_requests: 2     # 半开状态最大探测请求数
    fallback_strategy: "cache"    # 降级策略：cache / default / reject
    monitored_metrics:
      - error_rate
      - p99_latency
      - memory_usage

3.4 熔断与MRM的协同工作流

在MRM体系中，熔断机制不是孤立存在的，而是与模型监控、告警、自动恢复形成闭环：

监控采集： MRM Agent实时采集推理API的错误率、延迟、吞吐量等指标。
阈值评估： 将采集指标与动态基线对比，判断是否达到熔断触发条件。
熔断执行： API网关执行熔断策略，返回降级响应，同时上报熔断事件。
根因分析： MRM平台关联熔断事件与模型版本、数据分布、资源水位，定位根因。
自动恢复： 根因修复后，熔断器自动进入半开状态，验证模型服务是否恢复。

  MRM熔断的核心价值： 将模型推理API的不可靠性从“业务中断”降级为“局部降级”，为模型修复争取时间，同时保障整体系统的可用性。在模型风险监控中，熔断是最后一道防线，也是最重要的防线之一。