DevToken

LLM 429 速率限制与 Worker 并发计算器

针对 60 个实时 2026 模型计算所需 RPM、输入 TPM（ITPM）与输出 TPM（OTPM），在上线前识别配额瓶颈，并复制全抖动指数退避重试配置。

浏览器本地运行 — 0 字节上传
生产配额与并发容量测算工作台
安全（84% 峰值桶：ITPM）
所需 RPM
240
所需输入 TPM
840,000
所需输出 TPM
144,000
最大安全 Worker 并发数
16
建议队列深度
48

配额利用率与限流瓶颈诊断

每分钟请求数 (RPM) 240 / 2,000 (12%)
每分钟输入 Token 数 (ITPM) 840,000 / 1,000,000 (84%)
每分钟输出 Token 数 (OTPM) 144,000 / 200,000 (72%)
全抖动指数退避重试配置 
// Full-jitter exponential backoff + Retry-After guard (google/gemini-4-hydrogen)
export async function callWithRateLimitGuard<T>(
  fn: () => Promise<Response>,
  maxRetries = 5,
  baseDelayMs = 500,
  maxDelayMs = 30_000
): Promise<T> {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const res = await fn();
    if (res.status !== 429 && res.status < 500) {
      return (await res.json()) as T;
    }
    if (attempt === maxRetries) {
      throw new Error(`LLM quota exhausted (HTTP ${res.status}) after ${maxRetries} retries`);
    }
    const retryAfterSec = Number(res.headers.get('retry-after'));
    const ceiling = Math.min(maxDelayMs, baseDelayMs * 2 ** attempt);
    const sleepMs = Number.isFinite(retryAfterSec) && retryAfterSec > 0
      ? retryAfterSec * 1000
      : Math.floor(Math.random() * ceiling);
    await new Promise((r) => setTimeout(r, sleepMs));
  }
  throw new Error('Unreachable');
}
测算该负载的 30 天 API 支出 → 对比不同模型等级 → 模型定价 →

LLM 429 速率限制瓶颈是如何触发的

企业级 LLM API 网关同时执行三个令牌桶上限：RPM（每分钟请求数）、ITPM（包含 RAG 切片在内的每分钟输入 Token 数）以及 OTPM（每分钟输出补全 Token 数）。即使另外两个桶利用率低于 20%，只要任一令牌桶超限就会立即返回 HTTP 429。建议将配额测算与30 天 API 成本计算结合使用，并在 LLMEOL 上核查模型退役（EOL）排期。

生产队列控制与重试防护准则

常见问题

为什么请求量远低于 RPM 上限时仍然频繁收到 HTTP 429 错误？

长篇幅 RAG 提示词与多轮 Agent 历史记录会在达到每分钟请求数（RPM）上限之前，提前耗尽输入 TPM（ITPM）或输出 TPM（OTPM）令牌桶。

启用提示词缓存会提高我的输入 TPM 速率上限吗？

提示词缓存可将输入 Token 计费降低 90% 至 95%，且多家提供商会将命中的缓存前缀不计入未缓存 ITPM 配额——可在 LLM 成本计算器中精确测算节省金额。

为什么要用全抖动指数退避而不是固定等待时间重试？

固定重试间隔会导致同一秒被限流的并发 Worker 在完全相同的时刻成批重试；全随机抖动可在 TypeScript 和 Python SDK 中将重试请求均匀打散到整个恢复窗口。