速率限制与节流

在没有防护措施的情况下部署计算密集型服务（例如扩散模型推理端点），可能会导致性能下降、成本不可预测以及潜在的服务拒绝（无论是故意的还是无意的）。生成图像需要大量的GPU时间和内存。不受控制的访问会迅速耗尽这些资源，影响所有用户的可用性。速率限制和节流是保护您的服务、确保客户公平使用以及维持可预测运营成本的必要机制。

速率限制规定了客户端在特定时间窗内可以发出的请求数量，而节流通常通过排队或减慢响应速度来平滑处理突发请求，尽管这些术语有时可以互换使用。对于生成式API而言，速率限制主要目的是通过预先拒绝过量请求来预防系统过载。

为什么速率限制对扩散模型API很重要

1. 资源保护： GPU价格高昂。限制请求可以避免单个用户或故障脚本独占GPU资源，确保服务对其他用户保持可用。
2. 成本控制： 云资源使用，特别是GPU实例和数据传出，直接影响成本。速率限制通过限制最大工作负载，有助于将支出控制在预算内。
3. 公平使用： 在多租户系统或具有不同订阅级别的API中，速率限制强制执行使用配额并防止滥用。
4. 系统稳定性： 突然的请求高峰不仅会使GPU工作节点超负荷，还会使上游组件（如负载均衡器、数据库或日志系统）超负荷。速率限制提供了一个必要的缓冲。

常见的速率限制算法

可以采用多种算法来执行请求限制。选择适合的算法取决于期望的行为，特别是在处理突发请求和实施复杂性方面。

令牌桶

这是最常见且灵活的算法之一。设想一个具有固定容量的桶，以恒定速率补充令牌。

• 每个传入请求都需要一个令牌才能继续。
• 如果有可用令牌，它就会被消耗，并且请求被允许。
• 如果桶是空的，请求就会被拒绝（或者排队，取决于系统设计）。
• 令牌会定期添加到桶中（例如，每秒10个令牌），直到达到其最大容量。

这允许突发请求达到桶的容量，消耗现有令牌，而补充速率则决定了可持续的平均请求速率。

一张图表显示了令牌桶算法的流程。请求在有可用令牌时消耗令牌；否则它们会被拒绝。

• 优点： 允许突发请求，相对容易理解，广泛使用。
• 缺点： 需要为每个客户端跟踪令牌数量和上次补充时间。

漏桶

该算法侧重于确保稳定的流出速率，类似于一个以恒定速度漏水的桶。

• 传入请求被添加到队列中（即桶）。
• 系统以固定速率（漏出速率）从队列中处理请求。
• 如果请求在队列已满时到达，它就会被拒绝。

这平滑了流量，但对突发请求的容忍度比令牌桶低。

• 优点： 保证后端负载平滑且可预测。
• 缺点： 在正常的突发请求期间也可能拒绝请求，即使平均速率很低。与令牌桶相比，它较少用于纯粹的速率限制，但类似于固定大小的工作池如何从队列中处理任务。

固定窗口计数器

这种简单的算法在固定时间窗内（例如，每分钟、每小时）计算请求。

• 为每个客户端在当前窗口维护一个计数器。

• 每个请求使计数器递增。

• 如果在窗口内计数器超过限制，请求就会被拒绝。

• 计数器在每个新窗口开始时重置。

• 优点： 非常容易实施，资源使用率低。

• 缺点： 可能会允许在窗口边界出现双倍的速率限制（例如，在第1分钟结束前的一次突发和在第2分钟开始后的另一次突发）。

滑动窗口日志 / 计数器

这些算法通过考虑一个滚动时间窗口，比固定窗口提供更高的准确性。

• 滑动窗口日志： 请求的时间戳被存储。为了检查限制，会在最近窗口持续时间内的请求（例如，最近60秒）被计数。旧的时间戳会被丢弃。

• 滑动窗口计数器： 结合了固定窗口的效率和滑动窗口的准确性。它为当前和以前的固定窗口保留计数器，并使用基于请求在当前窗口中的位置的加权和，来近似计算真实滑动窗口内的计数。

• 优点： 精确的速率限制，避免了固定窗口的边缘情况突发。

• 缺点： 滑动窗口日志可能占用大量内存。滑动窗口计数器实施起来比固定窗口更复杂。

对于扩散模型API，当请求可能耗时且占用资源较多时，令牌桶或滑动窗口算法通常受到青睐。令牌桶为可能间歇性生成图像但偶尔需要小幅突发的用户提供了灵活性，而滑动窗口对持续速率提供更精确的控制。

实施策略

速率限制逻辑可以存在于您架构的不同部分：

1. API网关： 诸如AWS API Gateway、Google Cloud Endpoints/API Gateway或Azure API Management等服务提供内置的速率限制功能（通常基于令牌桶）。这通常是最简单的方法，可以将此问题从您的应用程序代码中移除。配置通过云提供商的控制台或基础设施即代码工具完成。
2. 应用程序中间件： 直接在您的API框架内实施速率限制（例如，为FastAPI使用fastapi-limiter库，为Node.js/Express使用express-rate-limit）。这提供了细粒度控制和对应用程序特有上下文的访问，但需要仔细实施，特别是在分布式环境中。
3. 专用服务/Sidecar： 对于复杂情况或微服务架构，专用速率限制服务（通常使用Redis进行分布式状态管理）可以集中逻辑。诸如Envoy的代理也提供速率限制能力。

使用API网关通常是典型部署中最实际的起始点，提供了功能和管理便利性之间的良好平衡。对于与特定应用程序状态或用户属性关联且不容易暴露给网关的更定制化逻辑，应用程序中间件变得必要。

配置与客户端识别

有效的速率限制需要识别谁在发出请求并应用正确的限制。

• 识别： 客户端可以通过以下方式识别：
  • API密钥： 对于服务器到服务器或第三方开发者访问是标准做法。
  • IP地址： 更简单但可靠性较低（共享IP、代理、潜在的欺骗）。适用于针对匿名滥用的基本保护。
  • 用户认证令牌（例如JWT）： 将使用情况直接与已认证用户关联。
  • OAuth客户端ID： 用于代表用户访问API的应用程序。
• 设置限制： 限制应基于：
  • 资源容量： 您的后端基础设施（GPU工作节点、队列）可以处理的最大可持续负载。
  • 用户层级： 为免费、基本和高级用户提供不同的限制。
  • 业务逻辑： 更严格地限制特定资源密集型操作。
• 粒度： 对每个用户、每个API密钥、每个端点或全局应用限制。例如，您可能对所有端点上的每个用户设置一个全局限制，加上对最耗资源的图像生成端点设置一个更严格的限制。

处理超出限制的情况

当客户端超出其速率限制时，API必须做出适当响应：

• HTTP状态码： 标准代码是429 Too Many Requests。
• 响应头： 包含信息性头以帮助客户端管理其请求速率：
  • Retry-After：指定客户端在发出另一个请求之前应等待多长时间（以秒为单位，或一个特定日期）。对于客户端回退策略非常重要。
  • X-RateLimit-Limit：窗口中允许的最大请求数量。
  • X-RateLimit-Remaining：当前窗口中剩余的请求数量。
  • X-RateLimit-Reset：限制重置的时间（UTC纪元秒或时间戳）。（注意：头名称可能因实施约定而略有不同）。
• 错误消息： 提供清晰的错误消息，解释速率限制已超出。

与您的API交互的客户端应设计成能够优雅地处理429响应，通常通过实施受到Retry-After头指导的指数退避策略。

柱状图显示了每秒传入请求在每秒10个请求的固定速率限制附近波动。超出限制的请求（比虚线高的柱子）将触发429响应。

分布式系统中的速率限制

当您的API在负载均衡器后运行在多个实例上时，实施速率限制需要仔细的状态管理。每个实例不能独立跟踪给定客户端的限制；它们需要一个共享的真实来源。常见的解决方案包括：

• 集中式数据存储： 使用像Redis这样的内存数据库非常有效。原子操作（例如，INCR，EXPIRE）允许多个实例安全地递增和检查特定客户端密钥的计数器。
• 粘性会话（不太理想）： 配置负载均衡器，使其始终将来自同一客户端的请求发送到同一API实例。这简化了每个实例的速率限制逻辑，但降低了容错性，并且可能导致负载分布不均。如果可能，通常应避免为此目的使用。
• 专用速率限制服务： 云提供商网关或专用速率限制服务在内部处理分布式状态。

实施速率限制和节流不仅仅是一个操作上的勾选框；它是构建稳定、可靠且成本效益高的API的一个根本方面，用于处理像扩散模型推理这样的高要求工作负载。通过仔细选择算法、实施策略和配置参数，您可以有效地管理访问并保护您的生成式AI服务。