大模型接口变慢或超时，系统应该如何降级？
这道题考的是大模型服务的高可用设计。当 LLM 接口响应变慢或超时时，你的系统不能傻等着，更不能直接崩溃——需要一套完整的降级方案来保证服务可用性。
板块1：为什么需要降级——大模型服务的脆弱性
大模型服务天然是脆弱的，因为它有几个特点：
推理慢——单个请求可能需要几秒甚至几十秒；资源重——GPU 显存被占满后新请求进不来；依赖多——上游网络抖动、下游模型服务崩溃都会影响它。
最可怕的是级联故障。想象一下：100 个请求同时发过来，模型响应慢，前 50 个占满了 GPU，后面的只能排队等着。等的时间越长，堆积的请求越多，GPU 越转不动，最后整个服务彻底卡死。
这就像餐厅爆满时，服务员不是让顾客等位，而是让所有人堵在门口——最后谁也吃不上饭。
降级的本质是什么？是承认模型不可靠，然后用更可控的资源来兜底。降级不是放弃，是"打不过就跑，找个备选方案先顶着"。
板块2：四级降级策略——从缓存到轻量化的递进方案
降级不是一步到位的，而是分层的。就像节假日出行：
- 能走高速（一级）就走高速
- 高速堵车走省道（二级）
- 省道也堵走县道（三级）
- 县道也满了就步行（四级）
核心思想：能快就快，快不了就用备选，备选也不行了还有更轻量的方案兜底。
一级：缓存兜底
把用户问过的问题和答案存起来，下次同样的问题直接返回缓存结果。命中缓存的响应时间是毫秒级，比调用模型快 100 倍。
适用场景：高频重复问题、FAQ 类场景。
二级：静态答案
缓存没命中？但问题是可以归类的。比如用户问"怎么退款"，这类问题有标准答案，直接返回预设内容就行。
适用场景：标准化业务流程、常见问题解答。
三级：轻量化模型
前面都没命中？那就换一个更快的模型。比如从 GPT-4 降级到 GPT-3.5-turbo，或者换成开源的 Qwen、ChatGLM。虽然能力弱了点，但能返回一个基本可用的结果。
适用场景：非核心功能、用户可以接受回答质量下降的场景。
四级：向量检索降级
连轻量化模型也超时了？最后一道防线是向量数据库。根据用户问题检索相似问答，直接返回已有的优质答案。
适用场景：知识库完备、用户问题可以匹配到已有答案的场景。
板块3：按错误类型匹配降级策略——对症下药
降级不是一遇到问题就全部降级，而是要根据不同的错误类型选择不同的策略。
就像医生看病，不同症状开不同药。
| 错误类型 | 表现 | 降级策略 |
|---|---|---|
| 网络瞬断 | Connection timeout | 重试 2-3 次，间隔指数退避 |
| 限流 429 | Rate limit exceeded | 进入队列等待，或者降级 |
| 上下文超限 | Max tokens exceeded | 压缩历史对话，摘要后继续 |
| 安全拒答 | Content policy violation | 走人工客服或返回兜底话术 |
| 模型崩溃 | Service unavailable | 切换备用模型或降级链路 |
| 响应超时 | Timeout | 按四级策略逐级降级 |
| 质量不达标 | 低分回复 | 返回置信度高的备选答案 |
关键点：不是所有错误都要降级，有些是瞬时的（比如网络抖动），重试就能恢复；有些是持续性的（比如模型服务挂了），才需要真正降级。
板块4：LLM Gateway 降级架构——统一封装、自动恢复
前面说的都是策略，怎么落地？靠 LLM Gateway。
Gateway 是整个降级系统的中枢，它做三件事：
1. 统一封装
把所有模型调用封装在一个 SDK 里，对业务代码屏蔽细节。业务方只管调用 llm.ask(question)，Gateway 内部处理重试、降级、熔断。
2. 熔断器保护
熔断器有三个状态：
- 关闭状态：正常请求，流量直接打到模型
- 打开状态：检测到故障，立即阻断请求，走降级逻辑
- 半开状态：放少量请求试试水，确认恢复了就关闭熔断器
就像家庭的漏电保护器——检测到异常自动跳闸，修复后自动合闸。
3. 监控指标
降级策略需要数据支撑。Gateway 要记录：
- 请求成功率
- 平均响应时间
- 降级触发次数
- 各模型 QPS
通过这些指标判断什么时候该降级、降级后效果如何。
面试怎么答
基础版（150字）：
当 LLM 接口变慢或超时时，我会采用四级降级策略：一级缓存兜底，命中历史结果；二级返回静态答案，覆盖标准化问题；三级切换轻量化模型，如从 GPT-4 降级到 GPT-3.5；四级走向量检索，返回相似问答。对于不同的错误类型也要对症下药：网络瞬断要重试，限流要排队，超上下文要压缩。降级后要记录日志，便于后续优化。
加分版（200字）：
我会通过 LLM Gateway 统一封装降级逻辑，配合熔断器实现自动触发和恢复。熔断器监控请求成功率，当故障窗口内的失败率超过阈值（比如 50%），自动打开熔断器阻断请求，走降级链路。恢复阶段进入半开状态，放少量请求验证，确认稳定后关闭熔断器。核心用户可以设置更高配额，非核心功能优先降级。同时要有配套监控，实时看降级触发次数和影响面。
一句话总结
大模型降级的核心是分层降级 + 错误分类 + 自动熔断，让系统在模型不可靠时依然能提供基本服务。