2026 年 10 月 15 日 8:11---13:04，DeepSeek 服务中断近 5 小时，网页、App 与 V4.1 Flash API 部分不可用。10 月 12 日另有一次对话服务中断。
对开发者而言，这是一个典型的外部依赖故障问题。本文不从新闻角度讲，而是从工程角度，把"如何降低大模型依赖带来的系统性风险"拆成可落地的三层设计。
直接答案
大模型是外部依赖，外部依赖必须假设它会消失。 治理分三层：容量层（降低峰值依赖）、路由层（多模型可切换）、降级层（不可用时业务仍可运行）。判据只有一句：模型不可用时，核心链路有没有一条"降级但可用"的路径。
一、问题定义：三个不可控维度
| 维度 | 表现 | 工程后果 |
|------|------|---------|
| 可用性 | 服务中断，无预警 | 核心链路 5xx |
| 稳定性 | 响应质量/延迟波动 | 结果不可复现，难验收 |
| 策略性 | 接口变更、限流、调价 | 架构与成本被动调整 |
2026 年以来该平台至少 18 次大面积异常。把这类风险当作"低概率事件"来做架构，是把工程判断让位给了运气。
二、第一层：容量层------降低峰值依赖
工程上的第一步是调用分级，而不是急着换供应商：
-
强依赖：开放生成、复杂语义推理、多轮规划 → 保留大模型。
-
弱依赖：分类、抽取、意图识别、格式校验 → 优先本地小模型（如量化后的 7B/3B）或规则引擎。
-
伪依赖 ：规则能判、字典能查、模板能套 → 应从模型调用中移除。
这一步的收益是双重的：既降低故障面，也直接降低单位任务成本。
三、第二层：路由层------多模型可切换
在业务与模型之间引入模型路由网关，实现多模型负载均衡与故障切换。
工程落地的两个硬约束：
① 统一输出契约。 业务层只依赖结构化契约（固定字段与格式），不依赖任何模型的原始输出。否则每接一个模型就要写一套适配层，"可切换"就是伪命题。
② 路由可配置化。 模型选择、权重、超时、重试策略应作为配置项，而非硬编码。故障时改配置即可切换，而不是重新发版。
一个常见的工程细节：重试必须带退避与熔断。 上游不可用时盲目重试，只会把故障放大成雪崩。
四、第三层：降级层------不可用时业务仍可运行
这是最容易被跳过、也最能体现工程成熟度的一层。
降级设计的核心是"分级可用"：明确核心链路在失去模型能力后，能退到哪个功能级别。
- 缓存降级：重复或近似请求命中缓存，短时间内不依赖上游。
- 规则降级：用确定性规则替代概率性生成，输出质量下降但流程不断。
- 离线降级：现场作业本地缓存、本地计算，恢复后异步补传。
第三点有真实案例。一套服务一百四十多所学校的本地部署系统运行了十年，断网、断电、重启都遇到过。它能持续可用的原因是设计阶段就确定了降级路径：网络中断时，本地继续记账与凭证输出；网络恢复后数据自动补传，保证最终一致。
在分布式系统里，"最终一致 + 本地可用"往往比"强依赖上游"更可靠。
五、6 项降级自查
| # | 自查项 | 工程判据 |
|---|--------|---------|
| 1 | 峰值依赖可降 | 已完成调用分级，伪依赖已移除 |
| 2 | 模型可切换 | 存在路由网关，输出契约统一 |
| 3 | 结果可缓存 | 缓存命中率与 TTL 已定义 |
| 4 | 规则可兜底 | 核心链路有确定性降级分支 |
| 5 | 离线可作业 | 支持本地作业 + 恢复后补传 |
| 6 | 故障可观测 | 有错误率/超时/延迟告警 |
第 6 条是治理是否成立的判据：如果故障是靠用户投诉发现的，说明可观测性建设落后于依赖引入。
六、结论
大模型带来的能力提升是真实的，但它引入的是一种不可控的外部依赖。工程上的应对不是"不用"，而是"用好 + 留后路"：
- 容量层降低依赖强度；
- 路由层消除单点；
- 降级层保证可用性下限。
模型崩不崩你说了不算，崩了以后业务能不能活，你说了算。
降级不是技术退步，而是给业务留的一条命。
算力是别人的，降级预案才是自己的。