企业级 AI API 容量规划 2026：burstable quota、峰值压测与月度容量预算建模

TL;DR — 企业 AI API 的容量规划不是”算一下 RPM 够不够”。它由三块构成：burstable quota 的两参数建模（稳态速率 + 桶深）、能持续 10 分钟以上的真实压测、以及一份能跟着流量曲线滚动更新的月度容量预算。三块缺一块都会在线上炸：要么是 429 比例失控，要么是月底预算撞线服务降级，要么是评审会上拿不出”我们能扛多少”的具体数字。

去年还在讨论”先把模型用起来再说”，今年财务和 SRE 都开始追问硬指标了。一次产品发布会，或者一篇客户成功故事被转发到 Hacker News，AI API 调用量翻 5 倍是常见事。麻烦的是大多数团队既不知道上游能撑到第几倍，也算不清楚翻完之后这个月还剩多少预算。下面把容量规划拆成三个能落地的模块，每块都给出可以照搬的方法和数字。

为什么 AI API 的容量规划是个独立问题

云容量规划那套工具（AWS Compute Optimizer、k8s HPA、Prometheus 的 capacity dashboard）在 AI API 这里只能做参考，不能直接照搬。差异有三个层面。

第一，离散 token 计费 vs 连续资源占用。一台 EC2 启动了不论跑没跑都计费，但 AI API 一次调用几十毫秒就结算，token 数还和 prompt 内容强相关。规划”我下个月需要多少 EC2 实例”是个静态题，规划”我下个月需要多少 token”是个动态题，需要把请求频率和单次 token 数同时建模。

第二，双约束：RPM 和 TPM 同时卡。OpenAI 顶级 tier 4 的 GPT-5.4 是 10000 RPM + 30M input TPM，Anthropic 顶级 tier 4 的 Sonnet 4.x（含 4.6）是 4000 RPM + 2M input TPM + 400K output TPM。这两组数完全不对称：OpenAI 的 RPM 留得宽，TPM 留得更宽；Anthropic 把 OTPM 单独拎出来限制，意味着 1000 个轻量 chatbot 调用和 50 个 long-context agent 调用会撞到完全不同的瓶颈。容量规划不能只看一个 RPM 数字。

第三，acceleration limit 是个隐藏维度。Anthropic 官方支持文档说得很清楚：即使你的瞬时 RPM/TPM 没超，只要”短时间内组织用量出现剧烈爬升”也可能被拒。这不是 bug，而是 token bucket 模型本身允许的反爬保护。规划时如果只看绝对峰值，发布日早上 9 点流量平台一拉就会被狠狠教育。

所以企业级容量规划至少要回答三个问题：稳态能扛多少、瞬时能 burst 多少、月底预算花完之后还能撑几天。下面三章对应这三个问题。

模块一：burstable quota 的两参数建模

不要把 burstable quota 当成”比 RPM 大一点的瞬时上限”。它得拆成两个独立参数才用得起来。Anthropic 文档里描述的 token bucket 是这么工作的：

• 一个桶，桶的最大容量叫 burst capacity（桶深）
• token 以恒定速率注入，这个速率叫 sustained rate（稳态速率）
• 每次请求按消耗的 token 数从桶里扣
• 桶空了就 429

闲置一段时间之后桶会重新装满，所以”突然来一波”短时间内能跑到桶的总容量。但一旦稳态超过注入速率，桶很快就空，后面所有请求都被限流。

给业务侧的两条规则

第一条：SLO 必须按 sustained rate 算，不能按 burst capacity 算。 见过太多团队拿”我压测能跑到 6000 RPM”去承诺业务方，结果跑了 3 分钟之后就开始 429。压测时看到的高峰是桶里存货被吃掉的瞬时结果，不是稳态能力。给业务承诺的容量上限应该贴着上游披露的 sustained rate 再向下打 70-80% 安全垫。

第二条：前端 timeout 必须按 burst capacity 触发的最坏延迟算。 即使常规情况下 P99 是 800ms，如果业务允许 burst，那 burst 用完之后的尾部请求会触发服务端 retry，端到端延迟可能拉到 8-10 秒。前端如果按 P99 设 2 秒 timeout，burst 一来就会出现大批”请求中断但实际成功”的诡异 case。

配置参考表

把不同模型的 sustained / burst 拆开记录，规划时直接查表。以下是 2026 年 5 月主流模型在顶级 tier 的公开参数，实际值以你账号的 dashboard 为准：

几个容易踩的点：Anthropic Sonnet 系列把 OTPM 单独限制在 400K，远低于 ITPM；Opus 4.x 整个家族共享同一池 quota（4.8/4.7/4.6/4.5 加起来不分开计算），Sonnet 同理（Sonnet 4.6/4.5/4 共享）。如果你 workflow 高度依赖长上下文（200K input），先撞 ITPM 而不是 RPM；如果是高吞吐 streaming output，OTPM 才是真正瓶颈。Anthropic 还有一个杠杆：cache read 不计入 ITPM，配合 prompt caching 实际吞吐可以放大 5-10 倍。

在 LLM 网关里把规则编码

光是在 wiki 文档里写”前端 timeout 设 10 秒”没用，必须在网关层落地。LiteLLM 的 tpm/rpm 配置可以分 model + key 双维度：

model_list:
  - model_name: claude-sonnet-4-6
    litellm_params:
      model: anthropic/claude-sonnet-4-6
      api_key: "os.environ/ANTHROPIC_API_KEY"
      timeout: 10     # 按 burst 最坏延迟算
      max_retries: 2
    tpm: 1750000     # sustained 2M ITPM 的 87%，留安全垫
    rpm: 3500        # 4K RPM 的 87%

注意 LiteLLM 的 tpm / rpm 是 model 条目级配置，必须和 litellm_params: 同级，不是放进它里面（放错位置会被解析器忽略，限流不会生效）。

ofox 的 dashboard 里则可以直接对单 key 设 RPM/TPM 限流，超过就在网关侧直接 429，不打到上游。这样既保护上游配额，又让你在自己的可观测体系里看清楚”哪些请求是被自己拦下来的”。

模块二：能跑出真实数字的峰值压测

压测是容量规划里最被低估的一环。常见的反模式是 wrk 跑 30 秒看个 RPM 就交差，这种压测除了让自己心安以外没有任何信息量。要压出有用的数字，至少得满足下面三个条件。

压测三条件

条件一：持续时间 ≥ 10 分钟。 这是触发上游 acceleration limit 的最小窗口。3 分钟以内的压测只能看到 token bucket 桶深，看不出真正的稳态。Anthropic 的限流响应通常在 5-8 分钟才开始变化。

条件二：阶梯式加压，不要直接顶峰。 从预期稳态的 50% 起步，每 2 分钟加压 20%，一直加到 1.5 倍。这样能把 429 第一次出现的拐点压出来，那个拐点就是上游实际能给你的 sustained rate。

条件三：用真实 prompt，不要用 “hello world”。 token 数和 prompt 内容强相关，10 字 prompt 压出来的 RPM 数字在 long-context 业务上完全不可用。从生产环境采样最近 1000 条请求，去除 PII 后作为压测语料。

三个必看指标

压测过程中最少要采集这三组数据：

1. P50/P95/P99 延迟分布。 不是平均延迟。P99 才是用户实际感受到的延迟。
2. 429 比例 + retry-after 分布。 429 多不可怕，可怕的是 retry-after 突然从 1 秒跳到 60 秒——意味着你触发了 acceleration limit，上游开始主动降速。
3. 桶恢复时间。 压到 429 之后停手，记录多久之后 RPM 能恢复到正常水位。这个数字直接决定你的 failover 触发时机。

压测脚本骨架

用 k6 或者 vegeta 都行。下面是 k6 的最小可用骨架，跑完会输出 P99 和 429 比例：

import http from 'k6/http';
import { Rate, Trend } from 'k6/metrics';

const errorRate = new Rate('errors');
const latency = new Trend('latency_ms');

export const options = {
  stages: [
    { duration: '2m', target: 50 },   // 起步 50% sustained
    { duration: '2m', target: 80 },
    { duration: '2m', target: 100 },  // 稳态
    { duration: '2m', target: 130 },
    { duration: '2m', target: 150 },  // 1.5x 顶峰
  ],
  thresholds: {
    'errors': ['rate<0.05'],
    'latency_ms': ['p(99)<10000'],
  },
};

export default function () {
  const res = http.post(__ENV.GATEWAY_URL, JSON.stringify({
    model: 'claude-sonnet-4-6',
    messages: [{ role: 'user', content: __ENV.SAMPLE_PROMPT }],
  }), { headers: { 'Authorization': `Bearer ${__ENV.KEY}` } });
  errorRate.add(res.status === 429);
  latency.add(res.timings.duration);
}

跑完看 summary，三件事：errors 比例、latency_ms P99、以及 429 第一次出现在哪一阶段。把这三个数填进容量表，业务对接时直接用。

压测频率

新模型上线、新场景上线，加上每月一次的常规复盘，三个时点各跑一次就够。压测有成本，每次按当时模型价格算大约消耗 100-300 美元的 token，一年下来 5000 美元上下，比一次线上事故便宜得多。压测结果整理成 capacity_report_YYYY_MM.md 归档，下次规划时拿来对比。

模块三：月度容量预算建模

到这里有了稳态能力和瞬时能力，最后一块是把这两个数和钱挂上钩。月度预算建模要回答的核心问题是：给定一笔预算和一份流量曲线，钱什么时候花完？

基础公式

最基本的公式：

月度成本 = Σ(场景 i 的日请求数 × 平均 input token × input 单价 / 1M
           + 场景 i 的日请求数 × 平均 output token × output 单价 / 1M) × 30

但这个公式有两个坑要补丁。

补丁一：prompt 迭代浪费。 模型开发期间 prompt 会不断改，每改一次跑回归测试就烧一遍 token。Featherless 的 2026 报告建议预留 2-3 倍 buffer。我们的实际数据是开发期 2.5x、成熟期 1.3x，按这两个系数分别算”开发预算”和”运行预算”两本账。

补丁二：agentic 工作流的乘数效应。 一次 Cursor Composer 任务是 chatbot 单次调用的 10-20 倍 token。如果你的业务里有 agent，agent 流量必须单独拆一列，不能和 chatbot 混在一起估。我们的实测乘数：

建模 Spreadsheet 骨架

把上面拆解放到一张表里跑：

A: 场景名
B: 日均请求数
C: 平均 input token
D: 平均 output token
E: input 单价 / 1M（按模型查表）
F: output 单价 / 1M
G: 日成本 = B*C*E/1e6 + B*D*F/1e6
H: 月成本 = G * 30
I: 开发期 buffer 系数（2.5 / 1.3）
J: 实际月预算 = H * I

最后把所有场景的 J 加起来就是月度容量预算。这张表至少每月初更新一次，理想情况是跟着 dashboard 的真实数据自动同步。

预算曲线 vs 实际花销

光算总预算不够，还要监控”花得快不快”。一个 30 天预算到第 10 天烧掉 50% 不一定有问题，但到第 5 天就烧掉 50% 一定要查。在 dashboard 里画一条线性参考线，把实际累计支出叠上去，凡是连续 2 天斜率高于参考线 50% 的，触发告警人工介入。这套机制接 cost governance 里的双层告警体系做：详见企业级 AI API 成本治理实战。

实际案例：从 7K 美元降到 4.5K

一家做合同审查 SaaS 的团队，原始月费 7000 美元。第一轮建模发现两个问题：

第一，audit log 的总结环节用 Claude Opus 4.6（Anthropic 官方价 25 美元 / 1M 输出），但 80% 的总结任务用 Sonnet 4.6（15 美元 / 1M 输出）质量没差异。改 routing 之后省 1000 美元/月。

第二，prompt 里有一段 1.5K token 的 system instruction 每次都重复发送，但 Anthropic 已经有 prompt caching：cache read 按 base input 的 10% 收费，Sonnet 4.6 的 base input 是 3 美元 / 1M，所以 cache hit 降到 0.3 美元 / 1M。开 cache 之后月省 1000 美元。

总共省 2000 美元，相当于月费降 29%，没有任何业务功能改动。规划是抓杠杆，不是缩开支。

这三块怎么和 SLO / Observability / Failover 串起来

容量规划不是孤立模块，它的输入和输出都和别的工程实践挂钩。

• 容量规划 ↔ SLO 设计：sustained rate 决定 SLO 上限，burst capacity 决定 SLO 的尾部延迟承诺。详见企业级 AI API 可观测性与 SLO 落地。
• 容量规划 ↔ Failover 演练：压测压出的 429 拐点是 failover 触发线。撞到这条线就要切到次级模型或次级供应商。详见企业级 AI API 故障演练。
• 容量规划 ↔ Cost Governance：月度预算建模的输出直接是 cost governance 的硬上限输入。两套表格应该共用一个 source of truth。

如果你只想跑通这套规划的最小路径，建议是这个顺序：先按本文模块三建出月度预算表 → 再按模块二压一次主流场景拿到 sustained 数字 → 最后用模块一在网关里编码限流。三件事一周做完。

ofox 平台层面能省什么事

聚合平台的价值在容量规划这一层尤其明显，可以从几个具体角度看。

跨厂商统一限流是最直接的省心。在 ofox 上配一套 RPM/TPM 规则，背后挂 Claude、GPT、Gemini 三家上游，不用分别和三家谈三套配额。一旦某家上游报 429，gateway 内部 fail-over 到次级供应商，业务侧无感知。

ofox 的 Enterprise 方案承诺 99.99% SLA，签约时可以提前申请 burst 余量，发布日不用临时去和上游加 ticket。这种”预付 burst”通常比临时找客服快 2-3 天。

最后是返点。按月消费阶梯返点 3-7%，这个数字在月度预算建模时直接进 J 列，能立刻降一个台阶。

具体配置可以对比下企业级 LLM Gateway 横评看哪种方案更适合自己团队的运维能力。

常见踩坑

最后列几个高频反模式，规划评审时拿这张表问一遍能筛掉一半隐患：

接下来更细的话题包括：怎么对一个具体业务做容量规划（推荐配合AI API 调用避坑指南和AI API 报错排查手册看），以及高级一点的”按用户 tier 拆 quota”做法，那是单独一篇文章的体量了。

容量规划本质上是把”我们能扛多少”和”我们要花多少”这两个无形问题，变成可以写进合同、压进预算、放进监控大盘的具体数字。前期多花一个下午建模，后面少跑一晚上 oncall。