先明确每个套餐的目的
免费限额应让真实开发者完成有效试用，同时避免成为自动化滥用的低成本目标；付费限额应在可持续利润下支持承诺的工作负载；企业限额还应反映治理与服务支持。
选择数字前先定义新用户必须完成什么才能理解产品。如果一次真实测试需要 200 次请求，50 次免费配额就无法完成试用。
把成本预算转化为配额
估算每次成功请求或任务的平均成本，包括重试和辅助调用。用套餐成本预算除以这个数，再扣除波动缓冲。
免费用量本质上是获客成本。除了每账户配额，还应为整个免费层设置月度总预算。
初始套餐配额 = 套餐用量成本预算 / 每个成功单位的预计成本 ×（1 - 波动缓冲）
叠加多种限制，而不是只依赖一个数字
月配额无法阻止客户在几秒内全部用完。应结合周期配额、RPM、TPM、并发、最大载荷和输出上限。
| 套餐 | 配额行为 | 吞吐行为 |
|---|---|---|
| 免费 | 月度硬上限 | 低 RPM、低并发、严格风控 |
| 入门 | 包含配额并提示升级 | 可用于基础生产 |
| 成长 | 更高配额或可选超额 | 更高持续和突发容量 |
| 企业 | 合同用量与告警 | 协商或专属容量 |
让用量耗尽可以预测
在面板中显示用量，并在达到限制前发送通知。错误响应应包含重置时间和升级路径；后台任务可以暂停，而不是持续重试不可能成功的请求。
- 在多个阈值通知账户管理员。
- 允许设置低于账户上限的项目和 Key 限额。
- 测试环境使用独立且较低的限制。
- 开启付费超额前取得明确同意。
根据真实分布复查限额
上线后比较每个套餐的中位数、高分位和极端用量。平均值可能掩盖少数占用大部分容量的用户。调整前应区分高价值重度用户、程序死循环、Key 泄露和账号滥用。