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

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

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

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

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

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

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

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

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

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

• API OpenAI, способные рассуждать, предоставляют Объект reasoning для поддерживаемых моделей, включая значения усилий, такие как none, minimal, low, medium, high и xhigh. Меньшие усилия могут уменьшить количество токенов рассуждения и повысить скорость ответа.
• В документации OpenAI указано, что max_output_tokens может ограничить общее количество сгенерированных токенов, включая токены рассуждения и окончательные выходные данные.
• Антропное расширенное мышление можно включить с помощью значения budget_tokens. Токены мышления оплачиваются как токены вывода и засчитываются в max_tokens вместе с видимым текстом ответа.
• В документации Anthrop также отмечается, что выставленное счету количество токенов вывода может не совпадать с количеством токенов видимого ответа, поскольку внутренние токены мышления могут выставляться в счет, даже если они не полностью видимы.
• В документации Gemini Thinking указано, что цена ответа может включать как токены вывода, так и токены мышления, с полями использования, разделяющими токены мысли и выходные данные. токены.
• Элементы управления в стиле 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": "нет",
      "max_reasoning_profile": "низкий",
      «max_output_tokens»: 800
    },
    "classify_support_ticket": {
      "default_reasoning_profile": "нет",
      "max_reasoning_profile": "низкий",
      "max_output_tokens": 300
    },
    "draft_customer_reply": {
      "default_reasoning_profile": "низкий",
      "max_reasoning_profile": "стандарт",
      «max_output_tokens»: 1200
    },
    "code_review": {
      "default_reasoning_profile": "стандартный",
      "max_reasoning_profile": "глубокий",
      «max_output_tokens»: 4000
    },
    "security_review": {
      "default_reasoning_profile": "глубокий",
      "max_reasoning_profile": "ограниченная глубина",
      «max_output_tokens»: 6000
    },
    "agent_plan": {
      "default_reasoning_profile": "стандартный",
      "max_reasoning_profile": "глубокий",
      «max_output_tokens»: 5000
    }
  }
}

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

Создайте матрицу совместимости

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

Пример формы матрицы

{
  "провайдеры": {
    "провайдер_а": {
      "model_family_x": {
        "supports_reasoning": правда,
        "control_type": "effort_enum",
        "allowed_values": ["нет", "минимальный", "низкий", "средний", "высокий", "xhigh"],
        «can_disable»: правда,
        «reports_reasoning_tokens»: правда
      }
    },
    "provider_b": {
      "model_family_y": {
        "supports_reasoning": правда,
        "control_type": "бюджетные токены",
        "min_budget_tokens": 1024,
        "max_budget_tokens": 32000,
        «can_disable»: ложь,
        «reports_reasoning_tokens»: правда
      }
    },
    "provider_c": {
      "model_family_z": {
        "supports_reasoning": правда,
        "control_type": "think_level",
        "allowed_values": ["минимальный", "низкий", "средний", "высокий"],
        «can_disable»: ложь,
        «reports_reasoning_tokens»: правда
      }
    }
  }
}

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

Перевести внутренние профили в параметры поставщика

Сопоставления поставщиков должны быть явными и иметь версии. Не полагайтесь на расплывчатые фразы вроде «используйте более разумные рассуждения». Шлюз должен точно знать, какой параметр поставщика был отправлен.

Пример сопоставления

{
  "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",
  "рабочий процесс": "code_review",
  "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, поставщика и псевдоним модели.
• requested_reasoning_profile и applied_reasoning_profile.
• provider_reasoning_param, сохраненный в виде структурированного JSON.
• input_tokens, visible_output_tokens, reasoning_tokens_or_equiвалент, 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, пользователя, команду и рабочий процесс.
2. Классифицируйте рабочую нагрузку. По возможности используйте явное поле клиента.Для известных конечных точек привяжите класс рабочей нагрузки при конфигурации маршрута.
3. Политика загрузки. Объедините глобальные ограничения, ограничения арендатора, ключа и рабочего процесса.
4. Выберите кандидатов на модель. Используйте существующий псевдоним модели или политику выбора модели перед разрешением элементов управления рассуждениями.
5. Разрешите профиль рассуждений. Начните с запрошенного профиля, затем примените настройки рабочего процесса по умолчанию и максимальные значения.
6. Проверьте совместимость. Убедитесь, что пара поставщик/модель безопасно поддерживает выбранный профиль.
7. Оцените стоимость и резервный бюджет. Включите вероятное обоснованное использование, а не только видимый результат.
8. Отправка с собственными параметрами поставщика. Отправьте перечисление усилий, жетоны бюджета, уровень мышления или отсутствие контроля рассуждений в зависимости от адаптера.
9. Нормализация использования включена ответ. Разделяйте входные данные, видимые выходные данные, обоснование, кэширование, инструменты и общие токены, где это возможно.
10. Расчет и оповещение. Согласовывайте зарезервированные и фактические затраты, обновляйте квоты и отправляйте сигналы об аномалиях.

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

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

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

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

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

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

Компромиссы

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

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

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

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

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

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

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

Вывод

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

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

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

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