速率限制是你在扩展AI应用时遇到的无形天花板。它们解释了为什么批量处理很重要，为什么你需要重试逻辑，以及为什么一些提供商对更高的速率限制收取更多费用。
AI API 的限速机制同时涉及多个维度，理解每个维度可以避免很多困扰。大多数服务提供商至少实施两种限制：每分钟请求数（RPM）和每分钟令牌数（TPM）。RPM 限制了您无论请求大小如何，每分钟能发起的 API 调用次数——Anthropic 的免费层级可能允许 5 RPM，而付费层级则提供 1,000+ RPM。TPM 限制了每分钟通过的令牌总量（输入 + 输出）。您可能独立地触及任一限制。常见意外情况是：您远低于 RPM 限制，却因发送长提示且上下文窗口较大而触及 TPM 限制。一些提供商还实施每日请求数（RPD）和每日令牌数（TPD），在 UTC 时间午夜时重置每日上限。
服务提供商实施这些限制的机制遵循几种标准模式。最常见的方法是令牌桶算法（或其近亲滑动窗口算法）。想象一个能容纳 60 个令牌的桶，以每秒 1 个令牌的速度补充。每个请求会根据其令牌数量从桶中扣除相应数量的令牌。如果桶为空，您的请求将被拒绝并返回 HTTP 429（请求过多）。响应头会告诉您所需信息：x-ratelimit-limit-requests、x-ratelimit-remaining-requests、x-ratelimit-reset-requests，以及它们的令牌版本。智能客户端代码应主动读取这些头信息，而不是等待收到 429 错误。Anthropic、OpenAI 和大多数其他提供商会在每次响应中包含这些头信息。
当您遇到限速时，标准做法是使用指数退避加抖动。第一次 429 错误后等待 1 秒，然后 2 秒、4 秒、8 秒——并添加一个随机组件（抖动），这样如果您的 50 个并行工作线程同时收到 429 错误，它们不会在精确的同一时刻重试，从而避免立即再次收到 429 错误。大多数提供商的 SDK（如 Anthropic 的 Python SDK、OpenAI 的 SDK）会自动处理基本的重试逻辑，但生产系统通常需要更复杂的方案：具有优先级级别的请求队列、基于剩余配额主动限速的自适应限速，以及在提供商明显过载时快速失败的熔断器。
速率限制的战略影响决定了严肃应用的架构方式。如果您需要通过 Claude 处理 100,000 份文档，不能只是发起 100,000 个并发 API 调用。您需要管理并发性，可能运行 20-50 个并行请求并从队列中获取任务。Anthropic 提供了一个具有独立更高吞吐量速率限制的 Batch API，成本折扣 50%——专为此用例设计。OpenAI 也有类似的批量端点。对于需要保证容量的应用，企业层级和承诺使用协议提供专用吞吐量，与共享池隔离。未言明的现实是，速率限制不仅仅是关于公平性——它们关乎 GPU 资源分配。您发出的每个请求都需要 GPU 时间，而提供商只能处理与 GPU 数量相当的并发请求数量。速率限制是平衡供需的机制。