AI API 网关中的服务层路由：快速、标准、预配置和批量，无需硬编码提供程序

服务层路由是决定 AI 请求是否值得优质低延迟容量、正常按需容量、预留吞吐量或折扣异步处理的策略层。如果没有该层，应用程序团队通常会直接在产品代码中对特定于提供商的标志、部署名称和批处理端点进行编码。这使得延迟、成本、配额和租户计费行为难以治理。

网关应该公开工作负载意图，而不是提供者机制。产品团队应该能够说“这是一个交互式支持回复”或“这是一项每晚的充实工作”，而网关则将该意图映射到正确的上游容量选项并记录实际发生的情况。

读者问题：容量类别正在成为应用程序逻辑

使用多个模型提供程序的团队通常从简单的模型路由开始：将此模型 ID 发送给该提供程序。当提供商公开不同的容量类别时，路由变得更加困难：

• 针对面向用户的路径提供优质的低延迟请求处理。
• 普通同步流量的标准共享容量。
• 专用或预置容量以实现可预测的吞吐量。
• 适用于延迟容忍工作负载的批量或异步 API。
• 预留容量耗尽时的溢出行为。

如果每个应用程序都自行处理这些选择，组织就会失去对四件事的控制：谁可以使用高级容量、成本是多少、容量不可用时会发生什么，以及所选层是否足以改进产品以证明支出是合理的。

实际模式是在 AI API 网关内放置一个与提供商无关的服务质量层。

基础事实

详细信息因提供商而异，但有几个可观察到的事实支持网关级设计。

• 事实：一些提供商公开每个请求的服务层以进行高级处理。 OpenAI 将快速模式描述为使用 service_tier 参数的每个请求选项，并表示相对于标准处理，其收费较高。 OpenAI 还表示，优先处理已于 2026 年 7 月 30 日更名为快速模式，同时 API 请求均接受 service_tier=priority 和 service_tier=fast。
• 事实：高级请求处理可能不是一个单独的配额范围。 OpenAI 指出，快速模式速率限制与其他服务层共享，并且流量的快速增加可能会触发斜坡速率行为，其中某些流量可能会被发送到标准处理。
• 事实：服务层可以是报告和计费维度。 OpenAI 表示，API 客户可以按服务级别和行项目对使用情况仪表板数据进行分组。 Anthropic 将标准、优先级 和批量记录为API 使用情况报告中的服务层值。
• 事实：批处理 API 可以显着降低异步工作的成本。 Anthropic 定价文档称，其 Batch API 支持异步大批量处理，输入和输出令牌可享受 50% 的折扣。 Google 的 Gemini Batch API 文档描述了以标准成本 50% 的成本处理大型异步工作负载，并进行了周转权衡，例如某些大批量作业的周转时间长达 24 小时。
• 事实：预置吞吐量是一个单独的容量模型。 Microsoft 将 Azure OpenAI 预配吞吐量记录为专用容量，这与容量共享且吞吐量可能随需求变化的标准部署形成鲜明对比。 Microsoft 还记录了同一 Azure OpenAI 资源中从预配部署到标准部署的溢出。

建议不要在应用程序代码中反映每个提供商术语。建议将这些机制标准化为面向业务的网关层。

定义提供商中立的网关层

首先根据工作负载行为命名层，而不是供应商术语。一个有用的第一个分类是：

<表> <标题> 网关层 典型工作负载 延迟预期 成本状况 默认降级行为 <正文> interactive_fast 语音循环、实时聊天、高价值用户操作 最低的实际延迟 允许溢价 按照标准继续或快速失败，具体取决于工作流程 interactive_standard 正常聊天，支持起草，内部副驾驶 同步 默认费用 重试、回退或返回受控错误 reserved_capacity 可预测的生产流量和稳定的利用率 可预测的吞吐量 预付费或承诺容量 仅在政策允许的情况下溢出 background_discount 评估、丰富、总结、嵌入、报告 异步 折扣优先 排队直到批处理路径可用 emergency_fallback 事件响应或临时客户升级 取决于政策 受控异常 批准窗口后自动过期

这个等级列表故意很小。如果您创建二十层，开发人员将绕过该系统。网关仍然可以在内部将一个中立层映射到多个特定于提供商的机制。

将请求的层与选定的层分开

调用者应发送请求的层，但网关应记录请求的层和实际选择的层。这些并不总是相同的。

请求元数据示例：

<前><代码>{ “型号”：“支持聊天默认”， “消息”：[...]， “元数据”：{ “工作流程”：“customer_support_reply”， “tenant_id”：“tenant_123”， "requested_gateway_tier": "interactive_fast", “end_user_id”：“u_789” } }

派送记录示例：

<前><代码>{ "request_id": "req_abc", “tenant_id”：“tenant_123”， "api_key_id": "key_live_456", “工作流程”：“customer_support_reply”， "model_alias": "支持聊天默认", "requested_gateway_tier": "interactive_fast", "selected_provider": "provider_a", "selected_provider_tier": "快", "tier_outcome": "select_as_requested", “降级原因”：空， “输入令牌”：1840， “输出令牌”：420， “延迟_毫秒”：1420， "estimated_cost_usd": "0.0312", "结算成本_美元": "0.0308" }

如果由于斜坡限制或租户预算规则而将溢价请求发送到标准处理，则该请求必须可见：

<前><代码>{ "requested_gateway_tier": "interactive_fast", "selected_provider_tier": "标准", "tier_outcome": "降级", “downgrade_reason”：“tenant_premium_budget_exhausted” }

这种区别可以防止分析产生误导。如果仪表板仅显示呼叫者请求的内容，财务部门将看到优质意图，但看不到优质执行。如果仪表板仅显示上游结果，产品团队将不知道他们的延迟敏感工作流程何时被拒绝高级容量。

在路由之前构建能力矩阵

服务层路由器需要一个功能矩阵。矩阵应该回答：对于给定的模型、区域、租户和工作流程，哪些容量机制可用？

最小字段：

• 提供商
• model_or_deployment
• 地区
• supports_sync
• supports_batch
• supports_premium_tier
• supports_provisioned_capacity
• supports_spillover
• provider_tier_values
• billing_line_items
• known_downgrade_behavior
• tenant_allowlist

一个简化的例子：

gateway_tier_map：
  交互式快速：
    首选：
      - 提供商：openai
        请求参数：
          服务层：快速
      - 提供者：人类
        请求参数：
          service_tier：优先级
    后备：
      - gateway_tier: 交互标准
        allowed_when：policy.allows_standard_downgrade
  背景折扣：
    首选：
      - 提供者：人类
        方式：批量
      - 提供者：双子座
        方式：批量
    后备：
      - 队列：延迟重试
        允许的时间：true
  保留容量：
    首选：
      - 提供商：azure_openai
        部署类：已配置
    后备：
      - 提供商：azure_openai
        部署类：标准
        allowed_when：policy.allows_spillover

这个矩阵应该是配置，而不是分散的代码。提供商命名变更、区域可用性和计费处理方式将随着时间的推移而变化。更新网关策略比重新部署每个调用 API 的应用程序更安全。

选择容量之前对工作负载进行分类

最难的部分不是提供者映射。它正在决定哪些请求值得哪个级别。

interactive_fast的良好候选者

• 语音助手会因延迟而中断对话。
• 与客户就高价值转化或保留路径进行聊天。
• 人工参与循环操作，其中客服人员正在积极等待。
• 延迟直接影响缓解的生产事件。

interactive_standard的良好候选者

• 内部副驾驶。
• 支持在人们可以容忍正常响应时间的范围内进行起草。
• 响应时间很重要但并不重要的产品功能。

background_discount的良好候选者

• 每晚总结。
• 大型文档丰富。
• 离线评估。
• 批量嵌入刷新。
• 分析标记和报告生成。

reserved_capacity的良好候选者

• 稳定的大批量生产工作负载。
• 合同客户工作负载以及可预测的吞吐量承诺。
• 流量无法容忍相邻噪音的变化，并且具有足够的利用率来证明专用容量的合理性。

一个简单的策略规则是：不允许呼叫者仅仅因为喜欢速度而选择优质容量。需要声明的工作流程、租户许可和预算范围。

强制租户和 API 密钥权限

每个租户和 API 密钥都应该有一个允许的层集。新密钥应默认为标准层和后台层，而不是高级层。

租户政策示例：

<前><代码>{ “tenant_id”：“tenant_123”， “允许的网关层”：[ “交互式标准”， “背景_折扣” ], “高级_等级”：{ “启用”：假， "monthly_budget_usd": "0.00", “approval_required”：正确 }, “保留容量”：{ “启用”：正确， "deployment_pool": "支持-prod-ptu", “allow_spillover_to_standard”：真， "spillover_monthly_budget_usd": "500.00" } }

键级覆盖示例：

<前><代码>{ "api_key_id": "key_voice_prod", “allowed_gateway_tiers”：[“interactive_fast”]， "workflow_allowlist": ["voice_control_loop"], "premium_daily_budget_usd": "75.00", “最大溢价流量百分比”：15 }

关键级别的策略可以防止意外扩展。开发人员无法获取用于语音流量的密钥并将其用于批量摘要脚本，除非工作流程也被允许。

明确设计降级和溢出行为

降级行为是产品决策，而不仅仅是基础设施决策。当高级或预配置容量不可用时，网关应选择以下四种路径之一：

• 遵循标准：当可用性比延迟一致性更重要时非常有用。
• 队列：对于后台作业和批量工作负载很有用。
• 快速失败：当缓慢响应比没有响应更糟糕时很有用，例如紧张的实时循环。
• 要求调用者重试：当客户端可以使用退避和保留的幂等密钥安全地重试时很有用。

政策示例：

downgrade_policy：
  语音控制循环：
    请求层：交互式快速
    if_fast_unavailable：fail_fast
    错误代码：tier_capacity_unavailable
  客户支持回复：
    请求层：交互式快速
    if_fast_unavailable：按照标准进行
    record_outcome：降级
  nightly_document_enrichment：
    request_tier：背景折扣
    if_batch_unavailable：队列
    最大队列延迟时间：24
  Contracted_api_customer：
    request_tier：reserved_capacity
    if_reserved_exhausted：溢出到标准
    require_spillover_budget：true

不要隐藏溢出效应。溢出可以提高可用性，但会改变成本和 SLO 解释。发票和分析应显示预留容量请求、溢出事件、实际使用的标准容量以及原因。

将服务层路由连接到计费

如果等级选择不是分类账的一部分，则网关无法控制保费支出。为每个请求或作业存储这些字段：

• 请求的网关层。
• 选定的提供商级别或容量级别。
• 等级结果：选择、降级、升级、排队、溢出、拒绝。
• 结果的原因。
• 租户、API 密钥、用户和工作流程标识符。
• 模型别名和上游模型或部署。
• 发货前的预估费用。
• 在了解提供商的使用情况后结算费用。
• 同步请求的延迟和重试计数。
• 异步作业的批量提交时间、完成时间和结果提取状态。

通过这些字段，网关可以回答财务和工程提出的问题：

• 本周哪些租户使用了优质容量？
• 哪些工作流程带来了最高的溢价支出？
• 高级请求降级为标准的频率如何？
• interactive_fast 是否改善了 p95 延迟足以证明溢价合理？
• 与同步标准处理相比，后台批处理节省了多少？
• 预配置容量产生了多少标准溢出？

重要建议：对实际使用的层开具发票，同时还显示操作上下文所请求的层。否则，租户要么会对成本感到惊讶，要么会对服务质量产生误导。

添加护栏，使高级服务不会成为默认设置

一旦团队发现更快的层级，他们可能会过度使用它。在广泛部署之前对网关进行限制。

• 每租户保费预算：每月和每日的硬性上限。
• 工作流程审批：仅允许指定工作流程使用高级版。
• 流量份额上限：例如，未经批准，不得超过 10% 的租户同步请求可以使用 interactive_fast。
• 标准到高级警报：通常使用标准的工作流程升级时发出警报。
• 高级烧钱率警报：当预计支出超出批准的范围时发出警报。
• 自动到期：临时紧急覆盖应在无需手动清理的情况下到期。
• 批量资格检查：当批量作业符合批量标准时，阻止来自同步高级层的批量作业。

护栏应该是可翻转的。在发生事故期间，授权操作员可能需要授予临时保费超驰。该覆盖应该有原因、审批者、预算、到期时间和审核记录。

执行顺序

安全部署并不是从到处打开高级路由开始的。从测量开始。

1。添加影子层分类

将每个请求分类到建议的网关层，但暂时不要更改路由。在现有延迟、成本和工作流程元数据旁边记录建议的层。这揭示了如果执行策略，有多少流量将转移到高级、批量或保留容量。

2。创建能力矩阵

列出提供商机制、支持的模型、区域、限制、报告字段和已知的降级行为。在经过测试之前，将未知的降级行为视为风险。

3。在试运行模式下强制执行租户权限

记录每个请求是否被允许、降级、排队或拒绝。在实施之前与产品所有者分享结果。

4。为一个群组启用一层

选择一个狭窄的工作流程，例如实时支持回复路径或夜间总结作业。为小规模租户群体启用相关网关层。测量 p50 延迟、p95 延迟、成本、降级率、错误率和面向用户的业务指标（如果有）。

5。仅在数据支持时才展开

如果高级层改善了延迟，但没有改善产品结果，请保持限制。如果批处理可以降低成本而不损害产品行为，则可以扩展它。如果预配置容量闲置，请重新审视承诺或将更可预测的流量引入其中。

权衡以明确

• 高级低延迟层可以提高响应能力，但它们可能共享速率限制或触发斜坡限制。它们不能替代速率限制调整。
• 预配置容量可提高可预测性，但在利用率较低时可能会浪费金钱。标准或批量容量可能更适合尖峰或耐延迟的流量。
• 批处理可以降低令牌成本，但它会改变产品行为，因为响应是异步的，并且可能会晚得多。
• 提供商中立的层名称简化了应用程序代码，但网关必须维护最新的功能矩阵，因为提供商使用不同的名称、限制、计费行和降级行为。
• 自动降级可以提高可用性，但它可能会模糊 SLO 和计费预期，除非网关记录实际使用的层。
• 严格的租户控制可以防止意外支出，但过于严格的政策可能会阻碍紧急的生产工作流程，除非有受控的替代路径。

预测：服务层将成为一流的路由维度

预测：随着模型 API 的成熟，服务层对于 AI 路由来说将变得与模型选择、区域和上下文窗口一样重要。团队不会只问“哪个模型应该回答这个问题？”他们会问“哪种型号、哪种容量等级、哪种租户预算、哪种降级政策？”

建议：立即设计网关账本和策略模型，以便可以在不更改应用程序代码的情况下添加新的提供商容量类别。即使您一开始仅使用标准和批次，也可以从一开始就使用 requested_gateway_tier、selected_provider_tier 和 tier_outcome 等字段。

可行的清单

• 定义不超过五个提供商中立网关层。
• 要求每个 API 密钥声明它可以使用哪些层和工作流程。
• 针对优质、标准、配置、批量和溢出行为构建提供商能力矩阵。
• 记录请求的等级、选定的等级、降级或溢出结果、延迟、使用情况和结算成本。
• 标准层或后台层的默认新键。
• 添加高级预算、流量份额上限和提醒。
• 明确每个工作流程的降级行为。
• 在实施之前从影子指标开始。
• 首先向一小群人推出高级或预配置容量。
• 仅在延迟、可靠性或业务指标证明成本合理时才进行扩展。

结论

服务层路由属于 AI API 网关，因为它是一个跨领域的策略决策。它会影响延迟、成本、配额、租户权限、发票和运营预期。应用程序团队不应仅仅为了表达工作负载的紧迫性而对特定于提供商的层名称或部署类进行硬编码。

实用的网关会公开中性层，例如 interactive_fast、interactive_standard、reserved_capacity 和 background_discount。它将这些层映射到特定于提供商的机制，强制租户权限，记录实际结果，并使高级容量成为有意的例外而不是默认路径。

相关阅读

• 提供商之前的速率限制调整429s
• 异步批处理作业的持久网关模式
• 计费分类帐报价、保留、结算和对账