05. 限流、熔断、降级在大模型系统里分别起什么作用？
整理限流、熔断、降级在大模型系统中的稳定性设计。
简单回答
限流是控制请求流入速率，保护 GPU 资源不被打爆。熔断是在下游服务（如模型 API）持续异常时快速失败，避免级联故障。降级是在资源不足时提供有损但可用的兜底方案（如用小模型替代大模型、返回缓存回答）。三者共同保障系统在高负载和异常情况下不崩溃。
详细解释
限流（Rate Limiting）
在大模型系统中，限流的对象和粒度比传统系统更复杂。传统系统通常按 QPS 限流——每秒允许多少个请求。大模型系统还需要按 token 限流——因为不同请求的 token 消耗差异巨大，一个 1000 token 的请求和一个 50000 token 的请求对 GPU 的压力完全不同。
常见的限流维度包括：全局 QPS 限制（防止系统整体过载）、每用户 QPS 或 TPM（Tokens Per Minute）限制（防止单个用户占用过多资源）、按 API Key / 租户限流（多租户场景）、按模型限流（不同模型的 GPU 容量不同）。
如果是调用外部 API，还要注意 API 提供方本身的限流。OpenAI 的 API 有 RPM（Requests Per Minute）和 TPM 限制，超过后会返回 429。所以客户端也需要做限流和排队，避免被上游拒绝。
实现上，轻量方案用 Redis 做计数器（令牌桶或滑动窗口），复杂方案用 API Gateway 的限流插件。
熔断（Circuit Breaker）
熔断的场景是：调用的下游服务（模型推理、外部 API、向量数据库等）持续返回错误或超时。如果不熔断，每个请求都去调一次注定失败的服务，浪费时间和资源，还可能因为超时堆积导致级联故障。
熔断器的三个状态：关闭（正常通过）→ 打开（快速失败，不再调用下游）→ 半开（定期尝试一个请求，成功则恢复关闭，失败则继续打开）。
在大模型系统中，熔断特别重要的场景有：外部 API 宕机（OpenAI 偶尔会出问题）、自建推理服务 GPU OOM、向量数据库查询超时。熔断后的行为需要配合降级策略。
降级（Degradation / Fallback）
降级是在服务能力不足时主动牺牲部分功能或质量来保证可用性。大模型系统常见的降级策略有：
模型降级：大模型不可用时切换到小模型（GPT-4 → GPT-3.5，70B → 7B）。效果有损但速度更快、成本更低。缓存兜底：如果请求和之前的某个请求高度相似，直接返回缓存的回答。功能降级：关闭 RAG 检索（直接用模型自身知识回答）、关闭 Agent 工具调用（只做纯对话）、关闭流式输出（改成一次性返回）。排队等待：告诉用户"当前排队中"而不是直接报错。固定话术兜底：最极端的情况下，返回一个预设的兜底话术，比如"系统繁忙，请稍后再试"。
三者的关系
限流是"防"——控制流入量，不让系统过载。熔断是"断"——下游出问题时快速止损。降级是"退"——能力不足时提供有损但可用的服务。三者通常配合使用：限流削掉过量请求 → 如果还是撑不住，熔断保护关键链路 → 熔断后的请求走降级逻辑。
面试时可以这样答
这三者在大模型系统中比传统系统更重要，因为推理成本高、延迟长、依赖多。
限流在大模型场景有个特殊点——不能只按 QPS 限，还要按 token 限。因为不同请求的 token 消耗差异很大，一个长请求可能顶十个短请求。通常要在用户维度和全局维度分别做限制。
熔断主要防级联故障。比如外部 API 宕机了，如果不熔断，所有请求都去等超时然后失败，连接堆积很快就把整个系统打挂。熔断器打开后快速失败，把请求导到降级逻辑。
降级在大模型系统中有很多玩法。最常见的是模型降级——大模型不可用时切到小模型，效果有损但起码能用。也可以用缓存兜底、关闭 RAG、返回预设话术等。具体策略取决于业务对可用性和质量的优先级。
三者的配合是：限流在前面挡住过量流量，熔断在中间保护关键链路，降级在后面提供兜底方案。
常见追问
- 按 token 限流怎么实现？请求来的时候 output token 数还不知道怎么办？
- 模型降级后用户体验怎么保证？需要告知用户当前用的是小模型吗？
- 降级策略应该是自动触发还是人工干预？