1. 课程导论：为什么模型发布需要限流与熔断？

1.1 高并发场景下的模型服务风险

当大语言模型（LLM）或深度学习模型从实验环境迁移到生产环境时，API 网关将面临突发流量、资源争抢和下游依赖抖动等多重挑战。模型推理通常比普通 Web 请求消耗更多 CPU/GPU 资源，且推理延迟波动大，一旦流量超过系统承载阈值，可能引发级联故障。

1.2 限流与熔断的核心作用

限流（Rate Limiting）和熔断（Circuit Breaking）是保障模型服务稳定性的两大支柱。限流控制请求进入速率，熔断在依赖故障时快速切断调用链路，两者配合形成“入口控制 + 出口保护”的双层防线。

• 限流： 基于令牌桶、漏桶或滑动窗口算法，限制每秒请求数（RPS）或并发数。例如：单模型实例最大 50 QPS，超出则返回 429 Too Many Requests。
• 熔断： 监控错误率或延迟，当连续失败数超过阈值（如 5 秒内错误率 > 50%）时，断路器打开，后续请求直接返回降级响应，避免资源浪费。
• 降级： 熔断后的兜底策略，返回缓存结果、默认回复或友好提示，保证用户体验不中断。

1.3 模型发布特有的挑战

与普通 API 不同，模型推理服务具有以下特殊属性，使得限流熔断设计更加复杂：

1. 推理延迟非恒定： 输入长度、模型参数量、批处理策略都会导致延迟从 100ms 到 10s 不等，固定超时策略容易误判。
2. GPU 资源稀缺： 显存是硬约束，并发请求数超过显存容量直接导致 OOM，限流必须考虑显存水位。
3. 冷启动与预热： 新发布的模型需要预热（warm-up）才能达到稳定性能，预热期间限流阈值应动态调整。
4. 多模型混合部署： 同一 GPU 上部署多个模型时，限流策略需按模型优先级和资源配额分别配置。

1.4 一个典型的高并发故障案例

假设某 LLM 问答服务上线后遭遇营销活动流量高峰：

• 正常状态： 单实例 4 张 A100 GPU，支持 32 并发请求，平均延迟 800ms。
• 突发流量： 瞬间涌入 200 个并发请求，超过 GPU 显存容量（80GB）。
• 连锁反应： 显存溢出 → 容器 OOMKilled → Kubernetes 重启 Pod → 重启期间所有请求超时 → 客户端重试 → 新 Pod 再次被冲垮。
• 恢复时间： 无限流熔断时，故障持续 15 分钟，影响数万用户。

如果配置了限流（最大 40 并发）和熔断（错误率 > 30% 时断开 30 秒），系统会在 3 秒内进入降级模式，返回“服务繁忙”提示，保护 GPU 集群不被摧毁，流量高峰过后自动恢复。

1.5 课程目标与学习路径

本课程将带你从零构建一套适用于模型发布场景的限流熔断系统。你将掌握：

• 算法原理： 令牌桶、漏桶、滑动窗口、自适应限流、熔断状态机。
• 工程实现： 基于 Python 和 FastAPI 的中间件开发，集成 Redis 分布式限流。
• 云原生部署： 在 Kubernetes 上使用 Istio 和 Envoy 实现服务网格级别的限流熔断。
• 模型发布实战： 针对 LLM 推理服务的预热、显存感知限流、动态阈值调整。
• 监控与告警： 使用 Prometheus + Grafana 可视化限流熔断指标。