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

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

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

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

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

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

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

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

事实依据

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

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

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

定义提供商中立的网关层

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

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

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

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

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

请求元数据示例：

{
  "model": "support-chat-default",
  "messages": [...],
  "metadata": {
    "workflow": "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",
  "workflow": "customer_support_reply",
  "model_alias": "support-chat-default",
  "requested_gateway_tier": "interactive_fast",
  "selected_provider": "provider_a",
  "selected_provider_tier": "fast",
  "tier_outcome": "selected_as_requested",
  "downgrade_reason": null,
  "input_tokens": 1840,
  "output_tokens": 420,
  "latency_ms": 1420,
  "estimated_cost_usd": "0.0312",
  "settled_cost_usd": "0.0308"
}

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

{
  "requested_gateway_tier": "interactive_fast",
  "selected_provider_tier": "standard",
  "tier_outcome": "downgraded",
  "downgrade_reason": "tenant_premium_budget_exhausted"
}

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

在路由之前构建能力矩阵

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

最少字段：

• provider
• model_or_deployment
• regions
• 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:
  interactive_fast:
    preferred:
      - provider: openai
        request_params:
          service_tier: fast
      - provider: anthropic
        request_params:
          service_tier: priority
    fallback:
      - gateway_tier: interactive_standard
        allowed_when: policy.allows_standard_downgrade

  background_discount:
    preferred:
      - provider: anthropic
        mode: batch
      - provider: gemini
        mode: batch
    fallback:
      - queue: delayed_retry
        allowed_when: true

  reserved_capacity:
    preferred:
      - provider: azure_openai
        deployment_class: provisioned
    fallback:
      - provider: azure_openai
        deployment_class: standard
        allowed_when: policy.allows_spillover

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

的应用程序更安全

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

最困难的部分不是提供商映射。它决定哪些请求应属于哪个层。

interactive_fast

的良好候选人

• 语音助手会因延迟而导致对话中断。
• 在高价值转化或保留路径上面向客户的聊天。
• 代理主动等待的人机交互操作。
• 延迟直接影响缓解的生产事件。

interactive_standard

的良好候选人

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

background_discount

的良好候选人

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

reserved_capacity

的良好候选人

• 稳定的大批量生产工作负载。
• 具有可预测吞吐量承诺的合同客户工作负载。
• 流量不能容忍嘈杂的邻居变化，并且有足够的利用率来证明专用容量的合理性。

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

强制执行租户和API-key 权限

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

租户政策示例：

{
  "tenant_id": "tenant_123",
  "allowed_gateway_tiers": [
    "interactive_standard",
    "background_discount"
  ],
  "premium_tier": {
    "enabled": false,
    "monthly_budget_usd": "0.00",
    "approval_required": true
  },
  "reserved_capacity": {
    "enabled": true,
    "deployment_pool": "support-prod-ptu",
    "allow_spillover_to_standard": true,
    "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",
  "max_premium_traffic_percent": 15
}

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

明确设计降级和溢出行为

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

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

政策示例：

downgrade_policy:
  voice_control_loop:
    requested_tier: interactive_fast
    if_fast_unavailable: fail_fast
    error_code: tier_capacity_unavailable

  customer_support_reply:
    requested_tier: interactive_fast
    if_fast_unavailable: proceed_on_standard
    record_outcome: downgraded

  nightly_document_enrichment:
    requested_tier: background_discount
    if_batch_unavailable: queue
    max_queue_delay_hours: 24

  contracted_api_customer:
    requested_tier: reserved_capacity
    if_reserved_exhausted: spillover_to_standard
    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。它将这些层映射到特定于提供商的机制，强制执行租户权限，记录实际结果，并使高级容量成为有意的例外，而不是默认路径。

相关阅读

• 提供商 429 之前的速率限制调整
• 异步批处理的持久网关模式作业
• 用于报价、预留、结算和对账的帐单