限流基础概念
限流（Rate Limiting / Throttling）是模型服务治理中最基础、最前置的防御手段。它的核心思想是：在单位时间内，只允许系统处理预定数量的请求，超出部分的请求直接拒绝、排队或降级，从而保护后端资源不被突发流量冲垮。
什么是限流
限流是一种主动的流量控制策略。它不关心请求是否合法、是否重要，只关心“当前时刻的请求量是否超过了系统预设的阈值”。一旦超过阈值，限流器就会按照既定规则（直接拒绝、等待排队、丢弃等）处理多余的请求。
关键理解：限流不是“系统扛不住才触发”，而是“在系统还能正常处理时，主动限制入口流量”，确保系统始终运行在安全水位内。
限流的目的与作用
限流不是为了让系统“变慢”，而是为了让系统“更稳定”。在模型服务场景中，限流承担着以下核心作用：
| 目的 | 具体作用 | 典型场景 |
|---|---|---|
| 保护后端资源 | 防止突发流量打满 GPU/CPU 算力，避免 OOM 或长时间阻塞 | 大模型推理服务、批量推理任务 |
| 保障服务质量 | 控制并发数，确保每个请求都能获得合理的响应时间 | 在线 API 服务、实时对话系统 |
| 公平分配资源 | 防止某个客户端或用户独占服务资源 | 多租户模型平台、API 网关 |
| 成本控制 | 避免因流量激增导致云资源费用失控 | 按量计费的推理服务、Serverless 部署 |
| 防止级联故障 | 在依赖的下游服务变慢时，主动限流避免自身被拖垮 | 模型服务调用外部 API、数据库查询 |
实践要点：限流阈值不是拍脑袋定的。通常需要结合压测数据、历史流量峰值、SLA 要求来综合设定。建议设置“安全阈值”和“告警阈值”两层，安全阈值用于限流，告警阈值用于提前预警。
常见限流场景
在模型服务体系中，限流几乎无处不在。以下三个场景是最典型、最需要关注的限流切入点：
1. API 调用限流
这是最外层的限流防线，通常部署在 API 网关或反向代理层。针对每个 API 端点、每个用户、每个 IP 或每个 API Key 设置独立的调用频率限制。
- 粒度：按用户/应用/API Key 分别计数
- 典型阈值：1000 次/分钟、100 次/秒
- 响应方式：返回 HTTP 429 Too Many Requests，附带 Retry-After 头部
- 模型服务特例：大模型 API 通常按 Token 消耗量限流，而非仅按请求次数
2. 推理请求限流
这是模型服务内部的核心限流点。推理请求往往消耗大量 GPU 算力和显存，一旦并发过高，轻则推理延迟飙升，重则显存溢出导致进程崩溃。
- 粒度：按模型实例、按 GPU 卡、按推理引擎进程
- 典型阈值：最大并发推理数（如 8 个并发）、最大排队长度（如 64 个请求）
- 响应方式：请求排队等待、返回 503 Service Unavailable、丢弃请求
- 模型服务特例：动态批处理（Dynamic Batching）场景下，限流需与批处理策略协同
3. 资源争抢限流
当多个模型服务或推理任务共享同一组硬件资源（GPU、CPU 内存、网络带宽）时，需要限流来防止某个任务“饿死”其他任务。
- 粒度：按模型优先级、按任务类型、按资源池
- 典型阈值：GPU 显存使用率 > 90% 时触发限流、CPU 负载 > 80% 时降级
- 响应方式：低优先级请求排队、高优请求优先通过、非核心任务降级
- 模型服务特例：多模型混合部署时，需为每个模型分配最小资源保障
常见误区：不要认为“限流就是拒绝请求”。在模型服务中，合理的限流策略应该配合排队机制和降级策略。例如，当推理请求超过并发上限时，可以让请求进入等待队列，而不是直接丢弃。只有当队列也满了，才触发拒绝。这样既能保护系统，又能最大化吞吐量。
限流与模型服务的特殊关系
相比传统 Web 服务，模型服务的限流有以下几个显著特点：
| 维度 | 传统 Web 服务 | 模型服务 |
|---|---|---|
| 资源消耗 | CPU 密集型或 IO 密集型，资源消耗相对可预测 | GPU 算力 + 显存，资源消耗与输入输出长度强相关 |
| 限流指标 | QPS（每秒请求数）、并发连接数 | QPS + 输入 Token 数 + 输出 Token 数 + 显存占用 |
| 响应时间 | 通常毫秒级，波动较小 | 可能从毫秒到分钟级，波动极大（受模型大小、输入长度影响） |
| 排队策略 | 简单 FIFO 队列即可 | 需考虑优先级、批处理窗口、超时时间等复杂策略 |
| 降级方案 | 返回缓存结果、静态页面 | 返回简化模型结果、降级为小模型、返回默认回复 |