今天我们来聊一个实际场景：当主流大模型API突然中断服务时，你的Dify系统该如何实现自动容灾与自救？

无论是OpenAI、Anthropic，还是国内各大模型平台，难免会遇到维护升级、限流管控、网络波动等意外状况。倘若用户此时只看到白屏或HTTP 500错误，产品体验将大打折扣。

因此，提前构建降级能力至关重要。核心操作可归纳为四步：首先开启全局开关，接着配置主备模型自动切换，然后设定熔断阈值，最后添加友好的降级提示。下面逐一详解。

检查降级功能是否已启用

首先前往Dify管理后台：「设置」→「系统配置」→「容错策略」。确认【resilience.enabled: true】开关是否已开启。若仍为false，所有降级配置将无法生效，系统仍会返回原始错误信息。

开启方法很简单：点击右上角「编辑」按钮，将enabled字段改为true并保存。该操作会自动触发服务热重载，无需重启整个容器，即刻生效。

设置主备模型自动切换规则

接下来进入应用编辑页面，找到「模型配置」→「高级设置」，展开「降级模型」选项。此处提供两种实用的配置方案。

方法一：指定备用模型ID。简单说就是准备一个替代模型。填写一个已在Dify中配置好、且稳定性更强的模型。例如主模型使用gpt-4-turbo，降级模型可设为claude-3-haiku。前提是该备用模型的API Key已配置完善，且配额充足，否则替代方案形同虚设。

方法二：启用缓存回退。勾选「启用缓存降级」后，Dify会在首次成功响应时自动缓存结构化结果（例如JSON输出）。若主模型发生故障，系统将直接返回最近一次有效的缓存数据。但需注意——【该规则仅对inputs完全一致的请求生效】。换言之，只有完全相同的输入才能命中缓存；否则系统仍会尝试调用备用模型。

需特别警惕：若主模型与备用模型的输出格式差异较大（例如一个返回Markdown，另一个返回纯文本），前端解析时可能出现崩溃。因此建议在降级模型配置页底部点击「测试输出格式一致性」按钮进行验证，避免潜在问题。

配置熔断阈值及恢复策略

此步骤需要修改配置文件。打开dify-config.yaml，定位到resilience区块。

第一步：定义失败率触发条件。将failure_threshold_percent设置为60。即连续10个请求中有6个失败时，熔断器立即触发。该值可根据业务容忍度调整，但60%为合理起始值。

第二步：设定熔断持续时间。将open_state_duration_ms设为30000（30秒）。为何不设置更长？因为熔断旨在防止雪崩，而非让系统永久宕机。30秒后进入半开状态，仅允许1个试探请求通过。若该请求成功，熔断器将自动闭合，系统恢复正常模式。

第三步：绑定降级动作。在fallback_strategy下选择model_switch，而非cache_only。原因在于cache_only对于全新、从未缓存过的请求仍会失败。model_switch相当于双重保障：优先使用缓存，缓存不可用时自动切换到备用模型处理。

保存配置后，运行docker exec -it dify-api bash -c "kill -SIGUSR2 1"强制重载配置。请放心——【该信号仅重载resilience模块，不会影响正在处理的请求】。

添加降级响应提示模板

最后一步，也是许多团队容易忽略的环节。进入「工作流编排」，选择对应应用，然后点击「错误处理节点」。

拖入一个「文本响应」节点，配置一段友好的提示文案，例如："当前服务繁忙，我们正在全力恢复。请稍后重试，或查阅常见问题。"

该节点需连接到「熔断触发」出口，而非「超时」或「格式错误」出口。原因在于：只有熔断状态才代表整个模型层整体不可用；若为单个请求超时或格式错误，系统仍应尝试重试或解析。

此步骤不可或缺。否则降级发生时，Dify默认返回空JSON或HTTP 503，前端无法友好展示，用户直接困惑。费尽心思配置，最终让用户面对空白，实在可惜。

总而言之，大模型API不可用并非概率问题，而是时间问题。提前配置好这套降级机制，才能确保用户体验始终在线。