4. 流量控制原理：令牌桶算法、漏桶算法、滑动窗口算法原理与对比
在模型风险管理API的流量控制场景中，核心目标是防止突发流量冲垮推理服务、保障高优先级请求的响应时间，并公平分配模型推理资源。三种经典算法——令牌桶、漏桶、滑动窗口——各自适用于不同的流量特征与风险容忍度。
4.1 令牌桶算法（Token Bucket）
令牌桶算法通过一个“桶”以恒定速率生成令牌，请求必须获取令牌才能被处理。桶内可累积一定数量的令牌，允许短时突发流量。
- 核心参数：桶容量（burst capacity）、令牌生成速率（rate）。
- 工作流程：令牌以固定速率注入桶中，桶满则丢弃多余令牌；每个请求消耗一个或多个令牌；桶内令牌不足时请求被拒绝或排队。
- 适用场景：允许突发但限制平均速率，如模型批量推理、短时高并发预测请求。
模型风险提示：令牌桶的突发能力可能导致模型服务在短时间内承受峰值负载，若模型推理延迟与并发量呈非线性增长，需配合熔断机制使用。
4.2 漏桶算法（Leaky Bucket）
漏桶算法将请求视为水滴，以恒定速率从桶底“漏出”处理，桶满则溢出丢弃。该算法强制输出速率完全平滑，不允许任何突发。
- 核心参数：桶容量（queue depth）、漏出速率（drain rate）。
- 工作流程：请求进入桶中排队；桶底以固定速率漏出请求进行处理；桶满时新请求被直接丢弃。
- 适用场景：需要严格平滑输出流量的场景，如数据库写入、下游处理能力固定的模型推理管道。
风险权衡：漏桶算法消除了突发，但可能导致请求排队延迟增加。在模型风险评分场景中，若请求超时容忍度低，需谨慎设置桶容量。
4.3 滑动窗口算法（Sliding Window）
滑动窗口算法将时间划分为多个小窗口，统计当前窗口及历史窗口的请求总量，当总量超过阈值时拒绝新请求。它通过时间粒度细分实现更精确的限流。
- 核心参数：窗口大小（window size）、窗口数量（number of sub-windows）、请求阈值（threshold）。
- 工作流程：维护一个时间窗口队列，每个子窗口记录请求计数；滑动时移除过期窗口数据，累加当前窗口总计数；总计数超过阈值则拒绝请求。
- 适用场景：需要精确控制时间窗口内请求总量的场景，如API调用频率限制、模型推理配额管理。
模型风险最佳实践：滑动窗口算法在模型风险管理中常用于“每分钟推理次数”配额控制，配合令牌桶可实现“配额+突发”双层限流。
4.4 三种算法对比
| 对比维度 | 令牌桶算法 | 漏桶算法 | 滑动窗口算法 |
|---|---|---|---|
| 输出速率 | 允许突发，平均速率受限 | 严格恒定，完全平滑 | 窗口内总量受限，允许窗口内波动 |
| 突发处理 | 支持短时突发（桶容量内） | 不支持突发 | 窗口内可突发，但受总量限制 |
| 请求丢弃策略 | 令牌不足时丢弃或排队 | 桶满时丢弃 | 窗口超限时丢弃 |
| 实现复杂度 | 中等 | 低 | 较高（需维护时间窗口队列） |
| 内存开销 | 低（仅维护计数器） | 低（仅维护队列长度） | 中等（需存储子窗口计数） |
| 适用场景 | 允许突发流量的API、模型批量推理 | 需要严格平滑输出的下游系统 | 精确时间窗口配额控制、API频率限制 |
| 模型风险适配 | 配合熔断应对突发过载 | 适合固定吞吐的推理管道 | 适合按分钟/小时计费的模型服务 |
4.5 算法选择决策流程
- 是否需要支持突发流量？
- 是 → 考虑令牌桶或滑动窗口
- 否 → 考虑漏桶
- 是否需要严格平滑输出？
- 是 → 选择漏桶
- 否 → 继续下一步
- 是否需要精确时间窗口配额控制？
- 是 → 选择滑动窗口
- 否 → 选择令牌桶（实现简单、性能好）
- 模型风险等级评估
- 高风险模型（如信用评分）→ 推荐滑动窗口 + 令牌桶双层限流
- 中低风险模型（如推荐系统）→ 令牌桶即可满足需求
生产环境建议：在模型风险管理API网关中，通常组合使用令牌桶（允许突发）与滑动窗口（配额控制），形成“速率+配额”双层限流策略，兼顾用户体验与系统稳定性。