AI API 速率限制会在规模化时节流你的移动应用
OpenAI、Anthropic 和 Google 的速率限制是为受控使用设计的,而非面向数千并发用户的移动应用。限制在哪里被触发以及触发后会发生什么。
你的应用登上了 App Store 推荐。下载量激增。5,000 个用户在同一小时内打开应用。每个人都触发了一个 AI 功能。你的后端向 OpenAI 发送 了 5,000 个 API 调用。
OpenAI 的 Tier 1 允许每分钟 500 个请求。你刚刚超出了 10 倍。API 返回 HTTP 429(请求过多)。你的用户看到错误消息或永远不会结束的加载动画。
这不是假设。这是将移动应用分发模式与为受控企业使用设计的 API 速率限制结合后的可预见结果。
各供应商的速率限制
OpenAI
| 层级 | 要求 | RPM | TPM |
|---|---|---|---|
| 免费 | API 密钥 | 3 | 40,000 |
| Tier 1 | $5 付款 | 500 | 30,000-200,000 |
| Tier 2 | $50+ 消费, 7+ 天 | 5,000 | 450,000-2,000,000 |
| Tier 3 | $100+ 消费, 7+ 天 | 5,000 | 800,000-4,000,000 |
| Tier 4 | $250+ 消费, 14+ 天 | 10,000 | 2,000,000-10,000,000 |
| Tier 5 | $1,000+ 消费, 30+ 天 | 30,000 | 10,000,000-150,000,000 |
你从 Tier 1(500 RPM)开始。要达到 Tier 5 需要 $1,000 的累计消费和 30 天的账户历史。没有办法跳级。
Anthropic
| 层级 | 要求 | RPM | TPM |
|---|---|---|---|
| Build | 默认 | 1,000 | 80,000 |
| Scale | 审核后 | 4,000 | 400,000 |
Anthropic 需要手动升级层级。你申请,他们审核,他们决定。没有自动扩展。
Google Gemini
| 层级 | RPM | TPM |
|---|---|---|
| 免费 | 15 | 1,000,000 |
| 按量付费 | 2,000 | 4,000,000 |
| 企业版 | 自定义 | 自定义 |
Gemini 的免费层极其有限(15 RPM)。按量付费更好但仍有硬上限。
移动应用如何触发速率限制
并发使用高峰
移动应用有突发性使用模式。App Store 推荐、社交媒体病毒式传播或产品发布可以在同一时间驱动数千新用户。不像 Web SaaS 使用量逐渐增长,移动应用下载量可以在一天内激增 10-100 倍。
高峰时段
移动端使用在当地时间晚上 7-9 点达到峰值。如果你的用户集中在一个时区, 60-70% 的日使用量压缩在 3 小时窗口内。你的日均可能完全在限制范围内,但高峰小时会超出限制。
功能探索爆发
当用户首次打开 AI 功能时,他们通常会快速发起 5-10 个请求来探索它。这种"探索爆发"意味着新用户产生的请求是稳定态用户的 3-5 倍。在下载高峰期间,这会叠加放大。
计算
1,000 MAU,每用户每天 3 个请求 = 每天 3,000 个请求 = 平均每小时约 125 个请求。
但将 60% 的使用量压缩到 3 个高峰小时: 3 小时内 1,800 个请求 = 每小时 600 个请求 = 10 RPM。在 Tier 1 下很舒适。
10,000 MAU 同样模式: 高峰期 100 RPM。在 Tier 1 下仍然没问题。
50,000 MAU: 高峰期 500 RPM。在 Tier 1 限制的边缘。任何突增都会超出。
现在加上一次 App Store 推荐,一小时内带来 5,000 次下载,每次 3 个探索请求: 一小时内额外 15,000 个请求 = 在你的基线之上额外 250 RPM。你至少需要 Tier 2,而这需要 $50 的先前消费和 7 天的账户历史。
触发限制后会发生什么
HTTP 429 响应
API 返回 429 状态码和 retry-after 头。你的应用没有收到 AI 响应。如果没有适当的错误处理,用户会看到崩溃、空白响应或无限加载状态。
指数退避
标准的重试策略是指数退避: 等待 1 秒,重试,等待 2 秒,重试,等待 4 秒,重试。这在本就缓慢的 API 调用之上增加了延迟。
对于等待 1-2 秒等 AI 响应的用户,加上 1-4 秒的退避重试意味着总共 3-6 秒。大多数用户会放弃。
队列拥堵
如果你为限速请求实现了服务端队列,队列在高峰期间会增长。以 2 倍速率限制持续 10 分钟的高峰会产生一个需要 10 分钟才能清除的积压。队列末端的用户等待 10+ 分钟才能得到响应。
所有用户的体验降级
速率限制是按组织的,而非按用户的。当一次使用高峰触发节流时,你应用的每个用户都受影响。使用该功能数月的老用户与刚下载的新用户得到相同的 429 错误。
缓解策略
请求节流
实现客户端速率限制。限制每用户每分钟请求数。这能防止个别滥用但不解决并发用户问题。
服务端队列
将所有 AI 请求通过你自己的服务器路由。服务器管理队列并在速率限制内分发给 AI API。这能平滑突增但增加延迟和服务器基础设施成本。
多个 API 密钥
将请求分布到多个 API 密钥或供应商账户。这会倍增你的有效速率限制,但如果被发现会违反大多数供应商的服务条款。
模型回退链
如果你的主供应商被限速,回退到次要供应商。OpenAI 被限速?路由到 Gemini。这增加了复杂性,需要维护多个集成。
缓存
对于相同或相似的请求,缓存响应。这减少了 API 调用,但只有在用户问的是类似问题时才有帮助。独特的用户输入(大部分聊天交互)无法被缓存。
结构性解决方案
速率限制存在是因为云供应商在所有客户之间共享有限的 GPU 容量。平台上的用户越多,每个人的限制就越紧。
端侧推理没有速率限制。"服务器"是用户的手机。每个用户有自己的推理容量。1,000 个并发用户意味着 1,000 个独立运行的并行推理实例。
| 因素 | 云 API | 端侧 |
|---|---|---|
| 速率限制 | 500-30,000 RPM(共享) | 无(每设备) |
| 并发用户 | 受供应商层级限制 | 无限 |
| 突增处理 | 被节流 | 无变化 |
| 所需基础设施 | 队列服务器 + 重试逻辑 | 无 |
| 可靠性 | 取决于供应商 | 取决于设备 |
扩展模型从根本上不同。云 API 共享一个池。端侧给每个用户自己的池。
为规模化做规划
如果你现在使用云 API 构建:
- 了解你的层级。 检查你当前的速率限制以及你距离限制有多远。
- 监控 429 率。 追踪你的用户多频繁地触发速率限制。如果超过 0.5%,你有问题了。
- 估算你的上限。 在多少 MAU 时你的高峰小时 RPM 会超出层级限制?那就是你的扩展悬崖。
- 构建回退。 队列、重试和优雅降级是生产应用的基本要求。
- 规划退出路径。 端侧推理是长期答案。在你的领域数据上用 Ertas 等平台微调模型,导出 GGUF,部署到用户设备。没有速率限制,没有共享基础设施,没有扩展悬崖。
Ship AI that runs on your users' devices.
Free plan with 30 credits/mo, no card required. Paid plans from $25/mo USD.
Ship AI that runs on your users' devices.
Free plan with 30 credits/mo, no card required. Paid plans from $25/mo USD.
Keep reading
当应用获得用户时，你的AI API账单将增长10倍
大多数AI教程跳过的成本计算。你的API账单随每个用户线性增长，真实的乘数效应比定价页面显示的更糟。以下是1K、10K和100K MAU时会发生什么。
移动端 AI API 定价: 每用户的真实成本
如何计算每个移动应用用户的真实 AI 成本。供应商对比、隐藏的成本倍增因素,以及决定你的 AI 功能是否可持续的单位经济学。
为什么你的 AI 应用感觉很慢: 网络延迟是瓶颈
AI API 调用为每次交互增加 500-3,000ms 的延迟。在移动端,这是用户喜爱和放弃一个功能之间的差距。时间花在哪里,以及如何解决。