Маршрутизация рассуждений и усилий в шлюзе AI API: управляйте токенами мышления, задержкой и стоимостью между поставщиками

Глубина рассуждений больше не является простым параметром модели. Некоторые поставщики предоставляют уровни усилий в стиле перечисления. Другие разоблачают символические бюджеты, динамическое мышление или модельные семьи, в которых мышление невозможно полностью отключить. Видимый ответ может быть коротким, в то время как скрытые рассуждения потребляют оплачиваемые выходные токены. Если каждая группа разработчиков приложений устанавливает эти элементы управления напрямую, стоимость, задержку и качество становится трудно объяснить.

Практический ответ — переместить контроль логических усилий в шлюз API. Шлюз должен классифицировать рабочую нагрузку, сопоставлять ее с механизмом управления рассуждениями, специфичным для поставщика, обеспечивать соблюдение бюджетов арендаторов, записывать фактическое использование рассуждений и делать решения о переходе на более раннюю версию видимыми в аналитике. Идентификатор модели, уровень обслуживания, максимальный результат и глубина рассуждений должны быть отдельными измерениями политики.

Проблема читателя: простые запросы платят за глубокое рассуждение

Команды, внедряющие модели, способные рассуждать, обычно начинают с разумной цели: улучшить качество выполнения сложных задач. Проблема возникает позже, когда одни и те же значения по умолчанию повторно используются для извлечения, кратких сводок, форматирования и классификации. Эти запросы не требуют дорогостоящих вычислений во время тестирования, но они все равно могут их инициировать.

Это приводит к трем операционным сбоям:

• Непрозрачность стоимости: пользователь видит короткий ответ, но в реестре содержатся скрытые токены рассуждения или эквиваленты, специфичные для поставщика.
• Дрейф задержки: a рабочий процесс, который выглядел интерактивным, становится медленным, потому что при использовании одного и того же псевдонима модели увеличиваются усилия по рассуждению.
• Фрагментация политики: каждая группа разработчиков изучает разные параметры поставщика и применяет разные ограничения.

Политика обоснования на уровне шлюза решает проблему контроля до того, как она становится проблемой выставления счетов.

Факты: средства управления обоснованием поставщика не являются Эквивалент

Ниже приведены факты реализации, а не рекомендации.

• 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 рекомендуются значения thinking_level, такие как minimal, low, medium и high для моделей в стиле Gemini 3.x вместо необработанных числовых бюджетов.

Смысл основной архитектуры прост: не предоставляйте собственные средства управления рассуждениями поставщика в качестве единственного контракта. Они недостаточно стабильны, портативны или достаточно сопоставимы для управления несколькими поставщиками.

Рекомендация: создайте провайдеро-нейтральные профили рассуждений

Определите небольшой внутренний словарь, который команды разработчиков смогут понять, не читая справочник каждого поставщика 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, например разрешенные, пониженные, отклоненные или резервные.

По умолчанию не регистрируйте необработанную цепочку мыслей. Для большинства задач управления и FinOps достаточно подсчетов и политических решений. Хранение конфиденциального текста обоснования может создать предотвратимые проблемы конфиденциальности, соответствия требованиям и хранения.

Последовательность реализации

Производственный шлюз может реализовать маршрутизацию усилий по рассуждению в виде детерминированного конвейера запросов.

1. Аутентификация запроса. Разрешение арендатора, API ключа, пользователя, команды и workflow.
2. Классифицируйте рабочую нагрузку. По возможности используйте явное поле клиента. Для известных конечных точек привяжите класс рабочей нагрузки при конфигурации маршрута.
3. Политика загрузки. Объедините глобальные ограничения, ограничения арендатора, ключа и рабочего процесса.
4. Выберите кандидатов на модель. Используйте существующий псевдоним модели или политику выбора модели перед разрешением элементов управления рассуждениями.
5. Разрешить обоснование Profile. Начните с запрошенного профиля, затем примените значения по умолчанию и максимальные значения рабочего процесса.
6. Проверьте совместимость. Убедитесь, что пара поставщик/модель безопасно поддерживает выбранный профиль.
7. Оцените стоимость и резервный бюджет. Включите вероятное обоснование использования, а не только видимый результат.
8. Отправка с собственными параметрами поставщика. Отправляйте перечисляемые усилия, токены бюджета, уровень мышления или отсутствие контроля над рассуждениями в зависимости от адаптера.
9. Нормализация использования при ответе. Разделяйте входные, видимые выходные данные, рассуждения, кэшированные, инструментальные и общие токены, где это возможно.
10. Согласование и оповещение. Согласование зарезервированных и фактическая стоимость, обновление квот и выдача сигналов об аномалиях.

Этот конвейер позволяет контролировать контроль рассуждений.Это также дает командам платформы единое место для изменения значений по умолчанию по мере развития API-интерфейсов поставщиков.

Оценка перед изменением значений по умолчанию

Не поощряйте более серьезные рассуждения, основанные только на нескольких впечатляющих примерах. Выполняйте оценки перед изменением значений по умолчанию для класса рабочей нагрузки.

Оцените как минимум четыре результата:

• Качество задачи: точность, принятие проверяющим, достоверность схемы или успех вызова инструмента.
• Задержка: время до получения первого токена и полного завершения. time.
• Стоимость: стоимость запроса и стоимость принятого ответа.
• Режимы сбоя: усечение, отказ, неверный вывод, чрезмерные вызовы инструментов или тайм-аут.

Ключевым показателем не является количество токенов на запрос. Ответ с меньшим количеством токенов, который не прошел проверку, может оказаться более дорогостоящим после повторных попыток. Более аргументированный ответ может быть оправдан для проверки безопасности, но бесполезен для маркировки билетов. Оценивайте по рабочему процессу.

Компромиссы

Обоснованное управление добавляет контроля, но оно не является бесплатным.

• Переносимость по сравнению с функциями поставщика: внутренние профили обеспечивают переносимость кода приложения, но продвинутым командам может потребоваться утвержденный аварийный люк для конкретного поставщика контроль.
• Надежность бюджета в сравнении с качеством: жесткие ограничения защищают арендаторов от безудержных расходов, но слишком жесткие ограничения могут привести к сокращению полезных ответов после того, как жетоны рассуждений уже израсходованы.
• Динамическое мышление против предсказуемости: динамический контроль поставщика может повысить удобство, но он ослабляет оценки затрат перед отправкой, если шлюз не регистрирует фактическое использование и не обеспечивает соблюдение требований лимиты расчетов.
• Понижение доступности в сравнении с согласованностью: понижение уровня аргументации во время дефицита бюджета сохраняет доступность, но ответ должен быть помечен в телеметрии и включен в оценку качества.
• Аналитика против конфиденциальности: Показатели маркеров рассуждения полезны, но необработанные следы рассуждений не следует хранить, если не существует преднамеренного и одобренного хранения. policy.

Прогноз: политика обоснования станет стандартным элементом управления шлюзом

Это прогноз, а не проверенный факт: усилия по обоснованию станут обычным производственным контролем наряду с маршрутизацией модели, ограничениями скорости, уровнями обслуживания и бюджетами токенов. Поскольку поставщики продолжают предоставлять различные средства управления мышлением, у команд разработчиков приложений будет меньше желания жестко запрограммировать эти различия в коде продукта.

Шлюзы, которые рассматривают рассуждение как управляемое измерение времени выполнения, будут иметь более четкую систему выставления счетов арендаторам, более чистую переносимость и лучший контроль над задержками.Шлюзам, которые рассматривают его как второстепенный параметр модели, будет сложно объяснить, почему короткие ответы иногда стоят дороже, чем длинные.

Контрольный список действий

• Определите внутренние профили: none, low, standard, deep и capped-deep.
• Назначьте профили по умолчанию и максимальные значения для каждого класса рабочей нагрузки.
• Build матрица совместимости поставщика/модели для управления рассуждениями.
• Преобразование профилей в собственные параметры поставщика на уровне адаптера.
• Закрытие с ошибкой, если запрошенный профиль не может быть безопасно сопоставлен.
• Зарезервируйте бюджет перед отправкой с использованием оценок с учетом рассуждений.
• Запишите запрошенный профиль, примененный профиль, параметр поставщика, обоснованное использование, видимый результат, задержку и Cost.
• Добавляйте оповещения об аномалиях для высокого соотношения токенов рассуждения и глубокого рассуждения в простых рабочих процессах большого объема.
• Выполняйте оценки на уровне рабочего процесса перед изменением усилий по умолчанию.
• Избегайте регистрации необработанного текста рассуждения по умолчанию; Вместо этого сохраняйте количество и решения по политике.

Вывод

Модели, способные рассуждать, полезны, поскольку они позволяют тратить больше вычислений на решение сложных задач. Та же самая возможность становится дорогостоящей, когда она применяется без разбора. Шлюз должен решить, когда разрешено более глубокое рассуждение, как оно сопоставляется с каждым поставщиком, какой бюджет он может потреблять и как измеряется результат.

Надежный шаблон заключается в том, чтобы отделить усилия по рассуждению от идентификатора модели. Маршрутизация по рабочей нагрузке, ограничение по политике арендатора, адаптация для каждого поставщика и запись фактического использования в реестр. Это превращает рассуждения из скрытой переменной стоимости в явную контрольную поверхность для ИИ API контроля затрат.

Связанное чтение

• книга счетов, которая резервирует и рассчитывает каждый вызов модели
• внутренние псевдонимы и возможности модели контракты
• учет потоковых токенов для окончательного использования и частичных ответов