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

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

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

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

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

<ул>

Премиум-обработка запросов с малой задержкой для путей, ориентированных на пользователя.

Стандартная общая емкость для обычного синхронного трафика.

Выделенные или выделенные мощности для предсказуемой пропускной способности.

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

Повторное поведение при исчерпании зарезервированной емкости.

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

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

Факты, на которые можно опираться

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

<ул>

Факт. Некоторые поставщики предоставляют уровень обслуживания для каждого запроса для премиум-обработки. OpenAI описывает быстрый режим как вариант для каждого запроса с использованием параметра service_tier и заявляет, что за него взимается дополнительная плата по сравнению со стандартной обработкой. OpenAI также заявляет, что 30 июля 2026 года приоритетная обработка была переименована в быстрый режим, при этом для запросов API принимаются как service_tier=priority, так и service_tier=fast.

Факт. Обработка запросов Premium не может быть отдельной квотой. OpenAI отмечает, что ограничения скорости в быстром режиме используются совместно с другими уровнями обслуживания и что быстрое увеличение трафика может спровоцировать повышение скорости, когда часть трафика вместо этого может быть отправлена на стандартную обработку.

Факт. Уровень обслуживания может быть параметром отчетности и выставления счетов. OpenAI утверждает, что клиенты API могут группировать данные информационной панели использования по уровню обслуживания и позиции. Anthropic документирует standard, priority и batch как значения уровня обслуживания в отчетах об использовании API.

Факт. Пакетные API могут существенно снизить затраты на асинхронную работу. В ценовой документации Anthropic говорится, что ее Batch API поддерживает асинхронную обработку больших объемов со скидкой 50 % на входные и выходные токены. В документации Google Gemini Batch API описаны большие асинхронные рабочие нагрузки за 50 % стандартной стоимости с компромиссными вариантами выполнения, например до 24 часов для некоторых объемных заданий.

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

Рекомендуется не отражать каждый термин поставщика в коде приложения. Рекомендуется преобразовать эти механизмы в бизнес-ориентированные уровни шлюзов.

Определить уровни шлюза, независимые от поставщика

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

<таблица> <голова> <тр> Уровень шлюза Типичная рабочая нагрузка Ожидаемая задержка Положение о затратах Поведение при переходе на более раннюю версию <тело> <тр> interactive_fast Голосовые петли, чат, важные действия пользователей Самая низкая практическая задержка Премиум разрешен Действовать стандартно или быстро, в зависимости от рабочего процесса <тр> interactive_standard Обычный чат, поддержка разработки, внутренние вторые пилоты Синхронно Стоимость по умолчанию Повторить попытку, откат или возврат контролируемой ошибки <тр>зарезервированная_емкость Предсказуемый производственный трафик с устойчивым использованием Предсказуемая пропускная способность Предоплаченная или гарантированная мощность Передача только тогда, когда это разрешено политикой <тр> background_discount Оценки, дополнение, обобщение, внедрение, отчеты Асинхронный Предпочтительна скидка Поставить в очередь, пока не станет доступен путь к пакету <тр> emergency_fallback Реагирование на инцидент или временная эскалация клиента Зависит от политики Управляемое исключение Срок действия истекает автоматически после окна утверждения

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

Отделить запрошенный уровень от выбранного уровня

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

Пример метаданных запроса:

{
  "модель": "поддержка-чат-по умолчанию",
  "сообщения": [...],
  "метаданные": {
    "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": "поддержка-чат-по умолчанию",
  "requested_gateway_tier": "interactive_fast",
  "selected_provider": "provider_a",
  "selected_provider_tier": "быстро",
  "tier_outcome": "selected_as_requested",
  «причина_понижения»: ноль,
  «входные_токены»: 1840,
  «выходные_токены»: 420,
  «латентность_мс»: 1420,
  "estimated_cost_usd": "0,0312",
  "settled_cost_usd": "0,0308"

Если запрос премиум-класса отправляется на стандартную обработку из-за ограничений скорости или правил бюджета арендатора, это должно быть видно:

{
  "requested_gateway_tier": "interactive_fast",
  "selected_provider_tier": "стандартный",
  "tier_outcome": "понижен",
  "downgrade_reason": "tenant_premium_budget_exhausted"

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

Перед маршрутизацией создайте матрицу возможностей

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

Минимум полей:

<ул>

поставщик

model_or_deployment

регионы

support_sync

support_batch

support_premium_tier

support_provisioned_capacity

support_spillover

provider_tier_values

billing_line_items

known_downgrade_behavior

tenant_allowlist

Упрощенный пример:

gateway_tier_map:
  интерактивный_быстрый:
    предпочтительно:
      - провайдер: openai
        request_params:
          уровень обслуживания: быстрый
      - провайдер: антропный
        request_params:
          уровень_сервиса: приоритет
    запасной вариант:
      - уровень_шлюза: интерактивный_стандарт
        разрешено_когда: policy.allows_standard_downgrade
  фон_скидка:
    предпочтительно:
      - провайдер: антропный
        режим: пакетный
      - провайдер: Близнецы
        режим: пакетный
    запасной вариант:
      - очередь: Delayed_Retry
        разрешено_когда: правда
  зарезервированная_емкость:
    предпочтительно:
      - поставщик: azure_openai
        класс_развертывания: предоставлено
    запасной вариант:
      - поставщик: azure_openai
        класс_развертывания: стандартный
        разрешено_когда: policy.allows_spillover

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

Классифицируйте рабочие нагрузки перед выбором емкости

Самое сложное — это не сопоставление поставщиков. Он решает, какие запросы заслуживают того или иного уровня.

Хорошие кандидаты на interactive_fast

<ул>

Голосовые помощники, которые прерывают разговор из-за задержки.

Чат для клиентов, посвященный ценным путям конверсии и удержания.

Операции, выполняемые человеком в процессе, когда агент активно ожидает.

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

Хорошие кандидаты на interactive_standard

<ул>

Внутренние вторые пилоты.

Поддержка разработки, при которой человек может выдержать нормальное время ответа.

Функции продукта, для которых время отклика имеет значение, но не имеет решающего значения.

Хорошие кандидаты на background_discount

<ул>

Подведение итогов за вечер.

Большое обогащение документов.

Офлайн-оценки.

Массовое обновление встраивания.

Маркировка аналитики и создание отчетов.

Хорошие кандидаты на роль reserved_capacity

<ул>

Постоянные большие объемы производственных нагрузок.

Контрактные рабочие нагрузки клиентов с предсказуемыми обязательствами по пропускной способности.

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

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

Принудительное использование разрешений клиента и ключа API

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

Пример политики для арендаторов:

{
  "tenant_id": "tenant_123",
  "allowed_gateway_tiers": [
    "интерактивный_стандарт",
    "background_discount"
  ],
  "премиум_уровень": {
    «включено»: ложь,
    "monthly_budget_usd": "0,00",
    «approval_required»: правда
  },
  "reserved_capacity": {
    «включено»: правда,
    "deployment_pool": "support-prod-ptu",
    «allow_spillover_to_standard»: правда,
    "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:
    запрошенный_уровень: интерактивный_быстрый
    if_fast_unavailable:fail_fast
    код ошибки: tier_capacity_unavailable
  customer_support_reply:
    запрошенный_уровень: интерактивный_быстрый
    if_fast_unavailable: continue_on_standard
    запись_результата: понижена
  nightly_document_enrichment:
    запрошенный_уровень: фон_скидка
    if_batch_unavailable: очередь
    max_queue_delay_hours: 24
  контракт_api_customer:
    запрошенный_уровень: зарезервированная_емкость
    if_reserved_exhausted: перелив_to_standard
    require_spillover_budget: true

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

Подключение маршрутизации на уровне служб к выставлению счетов

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

<ул>

Запрошенный уровень шлюза.

Выбранный уровень или класс мощности поставщика.

Результат уровня: выбрано, понижено, повышено, поставлено в очередь, перераспределение, отклонено.

Причина результата.

Идентификаторы клиента, ключа API, пользователя и рабочего процесса.

Псевдоним модели и исходная модель или развертывание.

Ориентировочная стоимость до отправки.

Установленная стоимость после того, как станет известна стоимость использования поставщика.

Задержка и количество повторов для синхронных запросов.

Время пакетной отправки, время завершения и статус приема результатов для асинхронных заданий.

С помощью этих полей шлюз может ответить на вопросы, которые зададут финансисты и инженеры:

<ул>

Какие арендаторы использовали емкость премиум-класса на этой неделе?

Какие рабочие процессы привели к наибольшим расходам?

Как часто запросы премиум-класса переводились на стандартный уровень?

Улучшил ли interactive_fast задержку p95 настолько, чтобы оправдать дополнительную плату?

Насколько экономится фоновая пакетная обработка по сравнению с синхронной стандартной обработкой?

Какой стандартный дополнительный эффект создал выделенная мощность?

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

Добавьте ограждения, чтобы премиум не стал стандартным

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

<ул>

Бюджет премиум-класса на одного арендатора: жесткий месячный и дневной лимит.

Утверждение рабочего процесса: Премиум разрешен только для именованных рабочих процессов.

Ограничение доли трафика. Например, не более 10 % синхронных запросов клиента могут использовать interactive_fast без одобрения.

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

Премиум-уведомление о расходе средств. Оповещение, когда прогнозируемые расходы превышают утвержденный размер.

Автоматическое истечение срока действия. Срок действия временных экстренных настроек истекает без очистки вручную.

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

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

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

Безопасное развертывание не начинается с повсеместного включения премиум-маршрутизации. Начните с измерения.

1. Добавить классификацию теневого уровня

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

2. Создайте матрицу возможностей

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

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

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

4. Включить один уровень для одной когорты

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

5. Развертывайте только тогда, когда данные поддерживают это

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

Компромиссы, которые следует четко обозначить

<ул>

Уровни «Премиум» с низкой задержкой могут улучшить скорость реагирования, но они могут иметь одинаковые ограничения по скорости или вызывать ограничения по нарастанию скорости. Они не заменяют формирование ограничения скорости.

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

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

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

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

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

Прогноз: уровень обслуживания станет первоклассным измерением маршрутизации

Прогноз: По мере развития API моделей уровень обслуживания станет таким же важным для маршрутизации ИИ, как выбор модели, региона и контекстного окна. Команды не будут спрашивать только «какая модель должна ответить на этот вопрос?» Они спросят: «Какая модель, в каком классе мощности, для какого бюджета арендатора, с какой политикой понижения?»

Рекомендация. Разработайте реестр шлюзов и модель политики прямо сейчас, чтобы можно было добавлять новые классы мощности поставщика без изменения кода приложения. Даже если вы начинаете только со стандартного и пакетного режима, с самого начала используйте такие поля, как requested_gateway_tier, selected_provider_tier и tier_outcome.

Полезный контрольный список

<ул>

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

Требовать, чтобы для каждого ключа API было указано, какие уровни и рабочие процессы он может использовать.

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

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

Новые ключи по умолчанию для стандартных или фоновых уровней.

Добавьте премиальные бюджеты, ограничения доли трафика и оповещения.

Укажите поведение перехода на более раннюю версию явно для каждого рабочего процесса.

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

Сначала внедрите премиальные или выделенные мощности для небольшой группы пользователей.

Расширяйте только тогда, когда задержка, надежность или бизнес-показатели оправдывают затраты.

Заключение

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

Практический шлюз предоставляет нейтральные уровни, такие как interactive_fast, interactive_standard, reserved_capacity и background_discount. Он сопоставляет эти уровни с механизмами, специфичными для поставщика, обеспечивает соблюдение разрешений клиента, записывает фактический результат и делает премиальную емкость намеренным исключением, а не путем по умолчанию.

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

• формирование ограничения скорости перед поставщиком 429s
• надежный шаблон шлюза для асинхронных пакетных заданий
• книга счетов для котировок, резервирования, расчета и сверки