AI API 网关中的推理工作路由：控制提供商之间的思维令牌、延迟和成本

推理深度不再是一个简单的模型选项。一些提供商公开了枚举式的工作水平。其他人则公开了代币预算、动态思维或无法完全禁用思维的模型系列。可见的答案可能很短，而隐藏的推理会消耗可计费的输出令牌。如果每个应用程序团队都直接设置这些控制，则成本、延迟和质量将变得难以解释。

实际的答案是将推理工作控制移至 API 网关。网关应对工作负载进行分类，将其映射到特定于提供商的推理控制，强制执行租户预算，记录实际推理使用情况，并使降级决策在分析中可见。模型 ID、服务层、最大输出和推理深度应该是单独的策略维度。

读者问题：简单的请求为深度推理付出代价

采用具有推理能力的模型的团队通常从一个合理的目标开始：提高艰巨任务的质量。当相同的默认值被重复用于提取、简短摘要、格式化和分类时，问题就会出现。这些请求不需要昂贵的测试时计算，但它们仍然可能会触发它。

这会造成三个操作失败：

• 成本不透明：用户看到一个简短的答案，但分类帐包含隐藏的推理令牌或特定于提供商的等效项。
• 延迟漂移：看起来交互式的工作流程变得缓慢，因为同一模型背后的推理工作量增加了
• 策略碎片化：每个产品团队了解不同的提供商参数并应用不同的上限。

网关级推理策略在控制问题成为计费问题之前解决了它。

事实：提供商推理控制并不等效

以下是实现事实，而不是建议。

• 支持 OpenAI 推理API 公开受支持模型的推理对象，包括无工作量值、最小工作量值、低工作量值、低工作量值、中工作量值、高工作量值和 x 高工作量值。降低工作量可以减少推理令牌并提高响应速度。
• OpenAI 文档指出，max_output_tokens 可以限制生成的令牌总数，包括推理和最终输出令牌。
• 可以通过 budget_tokens 值启用人择扩展思维。思考令牌作为输出令牌进行计费，并与可见响应文本一起计入 max_tokens。
• 人性文档还指出，计费的输出令牌计数可能与可见响应令牌计数不匹配，因为即使不完全可见，内部思考令牌也可以计费。
• Gemini 思考文档指出，响应定价可以包括输出令牌和思考令牌，并使用分隔思考令牌和输出令牌的使用字段。
• Gemini 2.5 风格的控件包括 thinkingBudget，对支持的模型进行动态思考，并在某些模型系列上禁用零预算。某些模型无法禁用思考。
• 较新的 Gemini 指南建议为 Gemini 3.x 样式模型使用 thinking_level 值，例如 minimal、low、medium 和 high，而不是原始数字预算。

核心架构含义很简单：不要将提供者本机推理控制作为唯一契约公开。它们对于多提供商治理而言不够稳定、不够可移植或具有足够的可比性。

建议：创建提供商中立的推理配置文件

定义一个小的内部词汇表，让产品团队无需阅读每个提供商 API 参考即可理解。对于大多数网关，五个配置文件就足够了：

配置文件是面向应用程序的合同。提供者参数成为适配器详细信息。这使客户端代码保持可移植性，并允许平台所有者在提供程序 API 发生变化时更新映射。

在映射提供程序之前映射工作负载类

推理工作应根据工作负载意图进行选择，而不是根据个人偏好或模型流行度进行选择。添加网关字段，例如 workload_class，由客户端提供或从批准的路由配置推断。

示例工作负载策略

{
  “工作负载策略”：{
    “提取发票字段”：{
      "default_reasoning_profile": "无",
      "max_reasoning_profile": "低",
      “最大输出令牌”：800
    },
    “classify_support_ticket”：{
      "default_reasoning_profile": "无",
      "max_reasoning_profile": "低",
      “最大输出令牌”：300
    },
    “草稿客户回复”：{
      "default_reasoning_profile": "低",
      "max_reasoning_profile": "标准",
      “最大输出令牌”：1200
    },
    “代码审查”：{
      "default_reasoning_profile": "标准",
      "max_reasoning_profile": "深",
      “最大输出令牌”：4000
    },
    “安全审查”：{
      "default_reasoning_profile": "深",
      "max_reasoning_profile": "上限深",
      “最大输出令牌”：6000
    },
    “代理计划”：{
      "default_reasoning_profile": "标准",
      "max_reasoning_profile": "深",
      “最大输出令牌”：5000
    }
  }
}

该政策有两个有用的作用。首先，它可以防止简单端点继承昂贵的默认值。其次，它为管理员提供了具体的审查界面：允许哪些工作流程请求深度推理，以及在什么上限下？

构建兼容性矩阵

网关适配器应该为每个提供程序和模型系列维护一个矩阵。至少，存储模型是否支持禁用推理、枚举工作量、数字预算、动态思维、最大支持预算以及推理标记的使用字段。

示例矩阵形状

{
  “提供商”：{
    “provider_a”：{
      “model_family_x”：{
        “支持推理”：正确，
        “control_type”：“effort_enum”，
        “allowed_values”：[“无”，“最小”，“低”，“中”，“高”，“xhigh”]，
        “can_disable”：正确，
        “reports_reasoning_tokens”：true
      }
    },
    “provider_b”：{
      “model_family_y”：{
        “支持推理”：正确，
        "control_type": "预算代币",
        “min_budget_tokens”：1024，
        “最大预算代币”：32000，
        “can_disable”：假，
        “reports_reasoning_tokens”：true
      }
    },
    “provider_c”：{
      “model_family_z”：{
        “支持推理”：正确，
        "control_type": "thinking_level",
        “allowed_values”：[“最小”，“低”，“中”，“高”]，
        “can_disable”：假，
        “reports_reasoning_tokens”：true
      }
    }
  }
}

兼容性矩阵不仅仅是人类的文档。它应该是可执行的政策。请求路由器应在调度之前使用它，计费账本应在结算期间使用它。

将内部配置文件转换为提供商参数

提供商映射应该是明确的和版本化的。不要依赖诸如“使用更聪明的推理”之类的模糊短语。网关应该确切地知道发送的是哪个提供者参数。

示例映射

{
  “reasoning_profile_mappings”：{
    “无”：{
      "effort_enum": "无",
      “预算代币”：0，
      "thinking_level": "最小"
    },
    “低”：{
      "effort_enum": "低",
      “预算代币”：2048，
      "thinking_level": "低"
    },
    “标准”：{
      "effort_enum": "中等",
      “预算代币”：8192，"thinking_level": "中"
    },
    “深”：{
      "effort_enum": "高",
      “预算代币”：20000，
      "thinking_level": "高"
    },
    “上限深”：{
      "effort_enum": "高",
      “预算代币”：12000，
      "thinking_level": "高"
    }
  }
}

这些数字只是示例，并非通用默认值。正确的预算取决于型号系列、定价、延迟要求和评估结果。重要的实现细节是网关拥有映射并记录每个请求的已解析提供程序参数。

当映射不安全时失败关闭

不支持的推理控件不应默默地成为提供程序默认值。默认值可能会很昂贵，并且可能会随着时间的推移而发生变化。

当请求的配置文件无法安全映射时，请使用以下三种结果之一：

• 允许：提供商/模型支持请求的配置文件并且租户策略允许。
• 降级：请求的配置文件高于策略，因此网关应用最高批准的配置文件并记录降级。
• 拒绝：配置文件无法安全地表示，租户要求严格的行为，否则降级将违反产品期望。

决策记录示例

{
  “request_id”：“req_123”，
  “tenant_id”：“tenant_42”，
  "api_key_id": "key_abc",
  “工作流程”：“代码审查”，
  "requested_reasoning_profile": "深",
  "applied_reasoning_profile": "标准",
  "决定": "降级",
  "decision_reason": "tenant_monthly_deep_reasoning_budget_exceeded",
  “served_provider”：“provider_a”，
  “served_model”：“model_family_x”，
  “provider_reasoning_param”：{
    “努力”：“中等”
  }
}

此决策记录在支持、计费争议和质量调查期间非常有价值。它还可以防止预算压力期间看不见的质量倒退。

预算控制需要超过最大输出令牌

最大输出令牌限制是必要的，但还不够。对于具有推理能力的模型，模型可能会花费很大一部分极限推理，而为最终答案留下的空间太少。然后，用户可以为不可用的截断响应付费。

使用分层上限：

• max_reasoning_profile 每个租户、API 密钥和工作流程。
• max_thinking_budget 或每个提供商/模型对的等效值。
• max_output_tokens 用于提供商计算推理的总生成令牌和可见输出在一起。
• 每个租户或经销商客户的daily_deep_reasoning_spend。
• deep_reasoning_requests_per_hour用于大容量端点。
• reasoning_token_ratio_threshold用于异常警报。

预算检查应在调度之前进行。然后，结算步骤应在提供商响应到达后协调实际使用情况。如果提供商单独报告思考令牌，请将它们单独存储。如果它仅报告总输出标记，则存储最佳可用标准化字段并标记置信水平。

用于推理使用的分类帐字段

分析必须显示可见答案长度和付费推理工作之间的差异。有用的账本行应包括：

• tenant_id、api_key_id、end_user_id 和 workflow。
• requested_model、served_model、provider 和 model别名。
• requested_reasoning_profile 和 applied_reasoning_profile。
• provider_reasoning_param，存储为结构化 JSON。
• input_tokens、visible_output_tokens、 reasoning_tokens_or_equivalent、cached_tokens 和 total_billable_tokens。
• max_output_tokens 以及任何特定于提供商的思考预算。
• latency_to_first_token_ms、total_latency_ms 和流完成状态。
• estimated_cost_before_dispatch、reserved_budget、settled_cost 和 reconciliation_status。
• policy_decision，例如允许、降级、拒绝或回退。

不记录原始数据默认的思路。对于大多数治理和金融运营工作来说，统计和政策决策就足够了。存储敏感推理文本可能会产生可避免的隐私、合规性和保留问题。

实现流程

生产网关可以将推理工作路由实现为确定性请求管道。

1. 对请求进行身份验证。解析租户、API 密钥、用户、团队和工作流程。
2. 对工作负载进行分类。在以下位置使用显式客户端字段：可能的。对于已知端点，在路由配置中绑定工作负载类。
3. 加载策略。合并全局、租户、密钥和工作流约束。
4. 选择候选模型。在解析推理控制之前使用现有模型别名或模型选择策略。
5. 解析推理配置文件。从请求的配置文件开始，然后应用工作流默认值和最大值。
6. 检查兼容性。确认提供程序/模型对安全地支持所选配置文件。
7. 估计成本和储备预算。包括可能的推理使用情况，而不仅仅是可见输出。
8. 使用提供程序本机参数进行调度。根据适配器发送枚举工作量、预算令牌、思维水平或无推理控制。
9. 标准化响应时的使用情况。尽可能将输入、可见输出、推理、缓存、工具和总令牌分开。
10. 解决并发出警报。协调预留成本和实际成本，更新配额，并发出异常信号。

此管道使推理控制保持可审计。当提供商 API 发展时，它还为平台团队提供了一个更改默认值的地方。

更改默认值之前进行评估

不要仅基于一些令人印象深刻的示例来促进更高的推理工作。在更改工作负载类的默认值之前运行评估。

至少衡量四个结果：

• 任务质量：准确性、审阅者接受度、架构有效性或工具调用成功。
• 延迟：第一个令牌的时间和总完成时间。
• 成本：每个请求的成本和每个接受的成本
• 失败模式：截断、拒绝、格式错误的输出、过多的工具调用或超时。

关键指标不是“每个请求的令牌”。验证失败的较低令牌答案在重试后可能会更昂贵。更高推理的答案对于安全审查来说可能是合理的，但对于标记票证来说是浪费的。按工作流程进行评估。

权衡

推理治理增加了控制，但它不是免费的。

• 可移植性与提供商功能：内部配置文件保持应用程序代码可移植，但高级团队可能需要经过批准的逃生口来进行特定于提供商的控制。
• 预算确定性与质量：硬上限保护租户免受支出失控的影响，但过于严格在推理代币已用完后，上限可能会截断有用的答案。
• 动态思维与可预测性：动态提供商控制可以提高便利性，但它们会削弱预调度成本估算，除非网关记录实际使用情况并强制执行结算限制。
• 降级可用性与一致性：在预算压力期间降级推理可以保留可用性，但响应应在遥测中标记并包含在质量中分析与隐私：推理令牌指标很有用，但除非有经过深思熟虑、批准的保留策略，否则不应存储原始推理跟踪。

预测：推理策略将成为标准网关控制

这是预测，而不是经过验证的事实：推理工作将与模型路由、速率限制、服务层级和令牌预算一起成为正常的生产控制。随着提供商继续公开不同的思维控制，应用程序团队将不太愿意将这些差异硬编码到产品代码中。

将推理视为受控运行时维度的网关将具有更清晰的租户计费、更清晰的可移植性以及更好的延迟控制。将其视为附带模型参数的网关将很难解释为什么简短的答案有时比长的答案花费更多。

可行的清单

• 定义内部配置文件：none、low、standard、deep和capped-deep。
• 为每个工作负载分配默认和最大配置文件类。
• 为推理控制构建提供者/模型兼容性矩阵。
• 将配置文件转换为适配器层中的提供者本机参数。
• 当请求的配置文件无法安全映射时，失败关闭。
• 使用推理感知估计在调度之前预留预算。
• 记录请求的配置文件、应用的配置文件、提供程序参数、推理使用情况、可见输出、延迟和成本。
• 添加异常警报在大容量简单工作流程中实现高推理令牌率和深度推理。
• 在更改默认工作量之前运行工作流程级别评估。
• 默认情况下避免记录原始推理文本；相反，存储计数和策略决策。

结论

具有推理能力的模型非常有用，因为它们可以在难题上花费更多计算。当不加区别地应用同样的功能时，它会变得昂贵。网关应决定何时允许更深入的推理、如何映射到每个提供者、可以消耗多少预算以及如何衡量结果。

持久模式是将推理工作与模型 ID 分开。按工作负载进行路由，按租户策略进行限制，根据提供商进行调整，并将实际使用情况记入分类帐。这将推理从隐藏的成本变量转变为 AI API 成本控制的显式控制界面。

相关阅读

• 预留和结算每个模型调用的计费账本
• 内部模型别名和功能合约
• 最终使用和部分响应的流式令牌会计