在接纳新租户之前构建 AI API 容量分类帐

不要等到实时流量才发现无法为新客户提供服务。运行时限制回答了一个狭隘的问题：这个请求现在应该运行吗？他们没有回答入职前重要的商业问题：此提供商帐户、项目、工作区、区域、型号系列和支出信封能否支持您即将出售的租户？

AI API 容量分类账为该问题提供了具体答案。当承诺的工作负载没有可靠的支持容量时，它将上游限制转换为内部供应、减去预留、应用预留空间并阻止计划创建或租户激活。

容量分类帐控制什么

容量分类账不能替代运行时速率限制、计费或事件响应。它位于生命周期的早期：销售、计划设计、租户配置、模型配置文件分配和升级。

读者问题是特定的：AI API 经销商和 SaaS 团队销售访问权限的速度比上游提供商批准、公开或维持配额的速度快。在任何人检查相关上游池是否存在之前，客户可能会购买承诺型号、区域、延迟层或每月数量的计划。结果是可以预见的：429 错误、升级受阻、紧急配额请求、强制回退模型以及尴尬的客户沟通。

分类账应该回答如下问题：

• 我们能否在不消耗预留企业容量的情况下在此型号系列上激活此租户？
• 经销商可以制定承诺在特定区域每月提供 2000 万个代币的计划吗？
• 该客户可以从突发访问升级到承诺容量吗？
• 哪个提供商池支持这一承诺？何时必须审核该假设？
• 如果最近未协调提供商限制会发生什么情况？

这对于 AI API 转销商平台尤其重要，其中下游门户可能向许多客户出售打包访问权限，而上游配额仍然集中在少数提供商帐户中。

要围绕的事实

以下内容是提供商文档中的事实约束，应塑造设计。

• OpenAI 记录了组织和项目级别的 API 速率限制。限制因模型而异，可能在模型系列之间共享，并且可以通过响应标头进行检查。
• OpenAI 将每月支出控制与费率限制分开记录。强制执行的硬支出限制可能会返回 429 错误，并且强制执行可能不会立即生效。
• OpenAI 管理 API 支持组织工作流程，例如项目管理、API 密钥管理、支出限制、提醒、审核日志和速率限制操作。
• Anthropic 记录管理员 API 速率限制 API，用于查询配置的组织和工作区限制。
• Anthropic API 响应包括显示强制限制、当前使用情况和重置时间的速率限制标头。
• Azure OpenAI 配额按订阅、区域、模型和部署类型以每分钟令牌为单位进行分配。部署消耗可用配额池。
• Azure 文档建议将认知服务使用读者角色作为查看订阅中可用配额的最低访问权限。
• Google 云配额限制项目可以使用的资源量，通常可以调整，并通过云配额进行监控。系统限制已修复。

这些事实暗示了一个设计要求：账本无法将容量建模为单个全局数字。它必须保留提供商特定的维度，同时向您自己的产品和合作伙伴公开标准化准入决策 API.

推荐的账本模型

将上游容量建模为一流的控制平面对象。有用的容量池记录通常需要以下字段：

• 提供商： openai、anthropic、azure_openai、gemini 或其他上游。
• provider_account_id:拥有配额的组织、订阅、结算帐户或租户。
• 范围：组织、项目、工作区、云项目、区域、部署或服务帐户。
• 区域： Azure 和驻留敏感工作负载所需；对于不受区域限制的提供商来说，可选或全局。
• model_family：规范化的内部系列，而不仅仅是确切的提供程序模型字符串。
• deployment_type：标准、配置、批量、优先级、实时或其他容量类别。
• rpm_limit： 每分钟请求数（如果有）。
• tpm_limit： 每分钟令牌或同等令牌率容量。
• batch_queue_limit: 排队作业、排队令牌、文件大小或特定于提供程序的异步容量。
• monthly_spend_cap:硬性或配置的上游预算边界。
• sellable_fraction:允许商业承诺的测量容量百分比。
• effective_from 和 effective_until:，因此临时配额增加不会成为永久假设。
• 来源： API、控制台证据、客户经理批准、手动覆盖或从标头推断。
• last_reconciled_at: 用于过时数据警告和审批门。

然后添加从这些池中使用的预订记录：

• tenant_id 或 reseller_customer_id: 客户或下游租户。
• reservation_class：已提交、可突发、内部、批量、free_trial或紧急。
• model_profile_id: 面向产品的模型和后备包。
• required_rpm 和 required_tpm： 入场费用估算。
• monthly_volume_commitment：预计每月代币数量或支出。
• region_policy： 必需、首选或无限制。
• 状态：待处理、有效、降级、过期、拒绝或awaiting_provider_quota.
• approved_by 和 approval_reason: 用于商业例外情况。
• review_at:何时必须再次检查容量。

重点不是要完美预测每个标记。关键是要让销售和入职决策足够明确，以便在客户依赖它们之前对其进行审核、质疑和更新。

准入控制不同于运行时限制

运行时限制是请求级保护。它估计或测量实时请求的压力，并决定是否分派、延迟、降级或拒绝。这是必要的，但它是被动的。

准入控制是供给侧规划。它决定是否允许租户、经销商计划、模型配置文件或升级存在。强大的实施将容量检查与合作伙伴API自动化、计划验证、客户引导和管理员审批联系起来。

例如，如果计划承诺：

，则计划创建应该会失败验证

• 没有映射的提供商池的模型系列；
• 不存在配额的区域；
• 仅由尽力容量支持的延迟层；
• 承诺的代币数量大于可售空间；
• 队列限制未知的批处理层；
• 将使提供商帐户接近其硬上限的支出承诺。

这不是面向客户的限制。这是产品的完整性。如果您的网关允许经销商宣传无法获得提供商配额支持的计划，则运行时代码将继承其无法兑现的承诺。

计算可用空间的可销售容量

不要出售 100% 的上游数量。提供商限制可能会发生变化，模型系列可以共享池，重试会消耗额外的配额，并且客户流量不会均匀到达。实用的政策仅将测量容量的一小部分公开为可销售。

一个简单的公式就足以开始：

sellable_tpm = provider_tpm_limit * sellable_fraction
available_tpm = sellable_tpm - active_reserved_tpm - pending_reserved_tpm

如果提供商池公开 1,000,000 TPM，而您的政策销售了 70%，则只有 700,000 TPM 可用于承诺。如果活跃租户预留 500,000 TPM，待批准交易预留 100,000 TPM，则剩余可用 TPM 为 100,000。

可销售比例应因池类型而异：

• 稳定的大容量池：对账成熟后，70-80%可能是合理的。
• 新提供商帐户：在实际流量确认行为之前，安全性为 50-60%。
• 共享模型系列池：减少可销售容量，因为不相关的模型别名可能会发生竞争。
• 手动或过时的证据：减少可销售产能或阻止新的承诺。
• 紧急后备池：不要将其作为正常容量出售。

支出上限需要类似的处理。提供商硬支出限制是预算支持，而不是产品容量计划。如果上游硬上限为每月 50,000 美元，则网关应为计划使用保留较低的内部阈值，并在硬限制中断生产流量之前发出警报。

使用预订舱位而不是按请求预订

不要尝试在准入期间为每个可能的请求预留提供商容量。这属于运行时节流。容量入场与预约课程配合效果更好。

忠诚的客户

忠诚的客户可以获得明确的容量预留。他们的计划应指定所需的模型系列、区域、服务等级、代币率假设和审核日期。空闲预留会降低利用率，但它们使承诺变得可信。

爆表客户

突发客户从共享池中提取资金。他们可以在可用时使用容量，但不应阻止承诺的入职。他们的计划语言、API状态和降级行为必须清晰。

内部工作负载

内部评估、支持工具、分析作业和管理自动化应该有自己的预留类。否则，内部流量可能会悄悄消耗销售人员认为可用的容量。

批量作业

批量容量需要单独建模，因为它可能受队列大小、作业计数、排队令牌、文件限制或周转承诺的控制，而不仅仅是 RPM 和 TPM。

免费试用

免费试用应使用有意限制的池。免费试用不应消耗稀缺的区域或优先容量，除非这是深思熟虑的上市决策的一部分。

按计划协调提供商容量

分类账仅在通过对账进行供给时才有用。提供商控制平面在网关之外发生变化：管理员调整项目、工作区、部署、支出上限、密钥、区域和模型可用性。在已知的管理员更改后构建计划的拉取和事件驱动的检查。

实际的协调循环如下所示：

1. 获取 API 存在的提供商可见的限制。
2. 将维度标准化为容量池记录。
3. 将新值与之前的账本快照进行比较。
4. 如果容量减少或消失，则将预留标记为面临风险。
5. 当证据窗口结束时，临时增加就会过期。
6. 当过时的池仍然支持有效承诺时发出警报。
7. 在审核日志中记录每项更改。

一些能力证据可能不完善。提供商可以通过 API、云配额控制台、响应标头或帐户代表工作流程公开限制。支持所有这些作为不同的证据类型。账本应表现出信心和新鲜感，而不是假装每个提供商都发出相同的控制平面数据。

这与更广泛的 AI API 配额管理重叠，但容量分类账有一个更狭窄的目的：决定在流量到达之前可以安全出售或激活哪些内容。

放入产品的准入检查

容量准入应该成为创建承诺的工作流程的一部分。最有用的检查通常是这些。

计划创建检查

当管理员创建转销商计划时，请验证宣传的型号系列、服务级别、区域承诺、每月销量、突发假设和后备政策。如果没有提供程序池可以支持具有空间的计划，则该计划应保持草稿状态或需要覆盖。

租户激活检查

配置客户后，预留相关的容量级别。激活响应应显示诸如活动、待定配额批准、降级为回退或已阻止等状态。

升级检查

在增加租户的计划之前，请针对目标预留运行相同的准入计算。如果容量不足，升级应成为与提供商配额工作流程相关的待处理请求。

模型资料检查

如果模型别名或配置文件发生变化，请重新计算预留。看似无害的别名促销可能会将租户从一个提供商池转移到另一个提供商池，并破坏供应模式。

区域政策检查

对于 Azure 和驻留敏感工作负载，显式验证区域。除非客户政策允许回退，否则其他地区的同等型号无法满足居住承诺。

实施细节：录取决策形式

保持录取结果机器可读。合作伙伴 API、经销商门户或内部管理 UI 不应解析人工注释。

{
  "decision": "approved",
  "tenant_id": "tenant_123",
  "model_profile_id": "profile_support_fast",
  "reservation_class": "committed",
  "backing_pool_id": "pool_azure_eastus_gpt4_standard",
  "required_tpm": 120000,
  "required_rpm": 600,
  "sellable_tpm_before": 700000,
  "reserved_tpm_before": 520000,
  "available_tpm_after": 60000,
  "headroom_policy": "standard_70_percent",
  "evidence_freshness": "fresh",
  "review_at": "2026-11-01T00:00:00Z"
}

对于拒绝，请返回产品工作流程可以采取行动的原因：

{
  "decision": "blocked",
  "reason_code": "insufficient_regional_tpm",
  "required_region": "eastus",
  "required_tpm": 300000,
  "available_tpm": 90000,
  "recommended_action": "request_provider_quota_increase",
  "fallback_options": [
    "standard_global_pool",
    "lower_volume_plan",
    "pending_activation"
  ]
}

避免仅返回“无容量”。调用者需要知道问题是否是区域配额、模型可用性、过时的证据、支出上限暴露、缺少部署或政策冲突。

审核商业决策

每个容量决策都应该是可审核的。记录：

• 谁请求了租户、计划或升级；
• 谁批准或推翻了该决定；
• 哪个提供商池支持了这一承诺；
• 应用了哪个净空政策；
• 使用了哪个证据来源；
• 当预订过期或必须审核时；
• 如果租户降级或移动到另一个池，会发生什么变化。

这在发生事故时很重要。如果池耗尽配额，团队需要知道问题是否来自意外流量、过时的提供商证据、覆盖、模型配置文件迁移或不应激活的销售计划。

权衡

容量分类账会增加运营开销。它还可以拒绝收入，直到上游配额得到确认。这确实令人沮丧，但总比出售在负载下失败的计划要好。

硬预订提高了高价值租户的可预测性，但会降低客户闲置时的利用率。软预留可提高利用率，但需要更强的运行时控制和更清晰的面向客户的降级规则。

区域建模对于 Azure 和驻留敏感工作负载来说是必要的，但它会使后备路由变得复杂。一个区域中可用的模型可能无法满足其数据必须保留在另一区域中的租户的要求。

手动证据有时是不可避免的。风险不在于存在手动证据，而在于存在。风险在于将其视为新鲜的 API 派生真理。使用过时数据警告、过期日期和批准要求。

提供商硬性支出限制是有用的保障，但它们可能会通过 429 中断生产流量。在上游硬上限成为执行机制之前，网关应在内部发出警报和预留。

什么是推荐，什么是预测？

建议：将容量建模为分类帐对象、协调提供商限制、应用空间、按租户类别预留、将准入检查连接到计划和租户工作流程，并审核每个决策。

预测：随着经销商门户、代理产品和 SaaS 租户加入变得更加自动化，容量准入将变得更加重要。客户将期望立即激活，而提供商配额批准和区域容量将仍然不平衡。与仅依赖运行时限制的团队相比，在控制平面中明确提供供应的团队遇到的紧急情况升级会更少。

事实： 上述特定于提供商的声明应视为当前公共文档中的事实，但提供商 API 和配额语义可能会发生变化。保持对帐代码和文档链接的审查。

可行的结论

从一个高价值工作流程开始：阻止承诺的租户激活，除非新的提供商池可以支持所请求的模型系列、区域、费率以及净空后的支出范围。然后添加计划验证、升级检查、陈旧证据警报和合作伙伴 API 状态字段。

最低有用版本很小：容量池表、预留表、协调作业、余量策略和准入决策API。这足以将容量从部落知识转移到产品控制平面，销售、支持、运营和下游经销商门户可以在其中查看承诺是否真正得到供应的支持。

相关阅读

• 实时 AI 流量的运行时速率限制调整API流量