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

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

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

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

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

这会造成三个操作失败：

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

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

事实：提供程序推理控制不是等效

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

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

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

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

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

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

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

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

工作负载策略示例

{
  "workload_policies": {
    "extract_invoice_fields": {
      "default_reasoning_profile": "none",
      "max_reasoning_profile": "low",
      "max_output_tokens": 800
    },
    "classify_support_ticket": {
      "default_reasoning_profile": "none",
      "max_reasoning_profile": "low",
      "max_output_tokens": 300
    },
    "draft_customer_reply": {
      "default_reasoning_profile": "low",
      "max_reasoning_profile": "standard",
      "max_output_tokens": 1200
    },
    "code_review": {
      "default_reasoning_profile": "standard",
      "max_reasoning_profile": "deep",
      "max_output_tokens": 4000
    },
    "security_review": {
      "default_reasoning_profile": "deep",
      "max_reasoning_profile": "capped-deep",
      "max_output_tokens": 6000
    },
    "agent_plan": {
      "default_reasoning_profile": "standard",
      "max_reasoning_profile": "deep",
      "max_output_tokens": 5000
    }
  }
}

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

构建兼容性矩阵

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

示例矩阵形状

{
  "providers": {
    "provider_a": {
      "model_family_x": {
        "supports_reasoning": true,
        "control_type": "effort_enum",
        "allowed_values": ["none", "minimal", "low", "medium", "high", "xhigh"],
        "can_disable": true,
        "reports_reasoning_tokens": true
      }
    },
    "provider_b": {
      "model_family_y": {
        "supports_reasoning": true,
        "control_type": "budget_tokens",
        "min_budget_tokens": 1024,
        "max_budget_tokens": 32000,
        "can_disable": false,
        "reports_reasoning_tokens": true
      }
    },
    "provider_c": {
      "model_family_z": {
        "supports_reasoning": true,
        "control_type": "thinking_level",
        "allowed_values": ["minimal", "low", "medium", "high"],
        "can_disable": false,
        "reports_reasoning_tokens": true
      }
    }
  }
}

兼容性矩阵不仅仅是供人类使用的文档。它应该是可执行的政策。请求路由器应在分派之前使用它，帐单分类帐应在结算期间使用它。

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

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

映射示例

{
  "reasoning_profile_mappings": {
    "none": {
      "effort_enum": "none",
      "budget_tokens": 0,
      "thinking_level": "minimal"
    },
    "low": {
      "effort_enum": "low",
      "budget_tokens": 2048,
      "thinking_level": "low"
    },
    "standard": {
      "effort_enum": "medium",
      "budget_tokens": 8192,
      "thinking_level": "medium"
    },
    "deep": {
      "effort_enum": "high",
      "budget_tokens": 20000,
      "thinking_level": "high"
    },
    "capped-deep": {
      "effort_enum": "high",
      "budget_tokens": 12000,
      "thinking_level": "high"
    }
  }
}

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

当映射不安全时失败关闭

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

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

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

决策记录示例

{
  "request_id": "req_123",
  "tenant_id": "tenant_42",
  "api_key_id": "key_abc",
  "workflow": "code_review",
  "requested_reasoning_profile": "deep",
  "applied_reasoning_profile": "standard",
  "decision": "downgraded",
  "decision_reason": "tenant_monthly_deep_reasoning_budget_exceeded",
  "served_provider": "provider_a",
  "served_model": "model_family_x",
  "provider_reasoning_param": {
    "effort": "medium"
  }
}

此决策记录在支持、计费争议和质量调查期间非常有价值。它还可以防止预算压力期间出现无形的质量下降。

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

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

使用分层上限：

• 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、提供商和模型别名。
• 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 成本控制的显式控制界面。

相关阅读

• 保留和结算每个模型调用的帐单
• 内部模型别名和功能合约
• 对最终使用情况和部分响应进行流式令牌核算