1. 限流熔断概述
1.1 为什么模型API需要限流与熔断
大语言模型（LLM）与推理类模型API具有显著的计算密集性和响应不确定性。单次推理可能消耗数十至数百毫秒的GPU时间，且请求量突发时，后端资源极易被击穿。缺乏限流与熔断机制时，系统会面临以下风险：
- 资源耗尽：无限制的并发请求占满GPU显存与计算槽位，导致新请求排队超时或OOM崩溃。
- 级联雪崩：上游服务因下游模型API超时而重试，重试流量进一步压垮后端，最终整个调用链瘫痪。
- 成本失控：按token或按调用次数计费的模型API，突发流量直接转化为高昂账单。
- SLA违约：高延迟或错误率超过客户容忍阈值，导致业务流失与赔偿。
核心洞察：模型API的限流熔断不是“可选项”，而是保障系统稳定性与成本效益的强制性基础设施。
1.2 核心概念与目标
| 概念 | 定义 | 低延迟场景下的关键目标 |
|---|---|---|
| 限流（Rate Limiting） | 控制单位时间内允许通过的请求数量或并发数，防止系统过载。 | 将P99延迟控制在模型推理时间+合理排队时间以内（通常<500ms）。 |
| 熔断（Circuit Breaking） | 当错误率或延迟超过阈值时，快速拒绝请求，给下游恢复时间。 | 熔断响应时间<10ms，避免调用方线程阻塞等待超时。 |
| 降级（Degradation） | 在过载时返回降级结果（如缓存、默认回复），而非直接报错。 | 降级路径延迟必须低于正常推理路径，通常<50ms。 |
| 预热（Warm-up） | 服务启动或扩容后，逐步提升流量，避免冷启动导致超时。 | 预热期内允许的请求量平滑增长，不触发熔断误判。 |
限流与熔断的最终目标可归纳为：
- 保护后端：确保模型服务不会因过载而崩溃。
- 保障公平：在多个租户或业务线之间合理分配推理资源。
- 快速失败：在无法处理时立即返回明确错误，而非让调用方长时间等待。
- 自动恢复：后端恢复后，流量自动回切，无需人工介入。
1.3 低延迟场景下的挑战
模型API的限流熔断与传统的微服务限流有显著差异，主要体现在以下挑战：
| 挑战维度 | 传统API限流 | 模型API限流 |
|---|---|---|
| 响应时间分布 | 相对稳定（通常<50ms） | 高度可变（50ms~10s+），受输入长度、模型大小影响 |
| 资源消耗 | CPU/内存，可预测 | GPU显存+算力，并发数受显存容量严格限制 |
| 限流粒度 | QPS或并发数 | 需同时考虑QPS、并发数、输入token数、输出token数 |
| 熔断敏感性 | 错误率>50%时触发 | 延迟轻微升高（如P99从200ms升至400ms）即需干预 |
| 预热需求 | 通常不需要 | GPU算子编译、显存分配需要预热，否则前几次请求极慢 |
低延迟场景的特殊约束：模型API的限流熔断决策必须在微秒到毫秒级完成。如果限流器本身引入超过5ms的延迟，就违背了低延迟的初衷。因此，算法选择（如令牌桶 vs 滑动窗口）和数据存储（本地内存 vs 分布式Redis）需要精心权衡。
下图展示了模型API在无保护、仅限流、限流+熔断三种状态下的延迟表现对比：
实践要点：在低延迟模型API场景中，限流与熔断必须协同工作。仅限流无法应对后端偶发变慢导致的延迟抖动；仅熔断无法防止持续过载。两者结合才能实现P99延迟稳定在200ms以内的目标。