📚 课程目录第1章限流熔断概述

1. 限流熔断概述：为什么模型Serving需要限流与熔断

与传统的Web服务或微服务不同，模型推理服务（Model Serving）对流量波动极为敏感。一个突发的推理请求激增，不仅会导致响应延迟飙升，更可能引发GPU显存溢出（OOM）、推理引擎崩溃，甚至拖垮下游的向量数据库或存储系统。限流与熔断是保障模型服务稳定性的第一道防线。

  核心痛点： 模型推理是计算密集型（尤其是LLM推理），单个请求的算力消耗远高于普通API调用。未经控制的突发流量会迅速耗尽GPU算力与显存，导致服务雪崩。

概念	定义	在模型Serving中的目标
限流（Rate Limiting）	控制单位时间内通过的请求数量或并发数，防止系统过载。	保护GPU算力与显存，确保推理延迟在SLA范围内（如P99 < 500ms）。
熔断（Circuit Breaking）	当错误率或延迟超过阈值时，快速切断对下游（或自身）的调用，避免级联故障。	防止推理引擎因OOM或死锁而持续失败，快速降级返回默认结果或错误码。
过载保护（Overload Protection）	综合限流与熔断，在系统接近容量极限时主动拒绝请求。	保持服务可用性，避免完全不可用（从“慢”变为“挂”）。

模型Serving的限流熔断策略继承自微服务架构，但存在显著差异。下表对比了关键区别：

对比维度	传统微服务限流	模型Serving限流
资源瓶颈	CPU、内存、网络IO、数据库连接池	GPU算力（TFLOPS）、显存（VRAM）、显存带宽
请求成本差异	请求成本相对均匀（如查询用户信息）	请求成本差异巨大（短文本 vs 长文本；简单分类 vs 大模型生成）
限流粒度	QPS（每秒请求数）、并发数	Token/s（输入+输出Token速率）、并发请求数、显存预留量
熔断触发条件	HTTP 5xx错误率、超时比例	推理错误率、GPU OOM事件、推理延迟（TTFT/TPOT）超阈值
降级策略	返回缓存数据、空结果、错误提示	返回默认推理结果、降级到小模型、排队等待、截断输入长度

关键认知： 模型Serving的限流不能只看QPS。一个请求的Token消耗量可能是另一个的100倍。因此，基于Token的限流（Token Bucket）比基于请求数的限流更精准。

下图展示了一个典型的模型Serving限流熔断分层架构。流量从网关进入，经过多层防护后到达推理引擎。

资源模型不同： 微服务限流通常基于CPU/内存使用率，而模型Serving必须考虑显存（VRAM）和算力（TFLOPS）。显存一旦耗尽，GPU进程会直接OOM被杀，无法像CPU那样通过swap缓解。
请求成本非线性： 在LLM推理中，输入长度和输出长度直接影响显存占用和计算量。一个1024 Token的请求与一个4096 Token的请求，成本相差4倍以上。简单的QPS限流无法覆盖这种差异。
熔断恢复更复杂： GPU OOM后，恢复通常需要重启推理容器或重新加载模型，耗时数秒到数分钟。微服务熔断的半开状态（Half-Open）试探策略，在模型Serving中需要更谨慎的恢复机制。
批处理（Batching）的影响： 模型Serving通常使用动态批处理（Dynamic Batching）来提高吞吐。限流策略需要与批处理调度器协同，避免在批处理队列中堆积过多请求导致延迟爆炸。

常见误区： 直接将微服务的“最大并发数”限流策略套用到模型Serving上。由于GPU显存限制，模型Serving的最大并发数通常远低于微服务，且与模型大小、输入长度强相关。建议从“最大显存占用”反推并发上限。