​
Уровни обслуживания Параметр

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

​
Использование уровней обслуживания

Пройти service_tier в качестве параметра верхнего уровня в теле вашего запроса. Поддерживаемые значения: flex (меньшая стоимость, более высокая задержка) и priority (быстрее, дороже). fast также принимается как псевдоним для priority — см. Быстрый режим ниже. В приведенном ниже примере запрашивается flex уровень от OpenAI gpt-5 со скидкой 50 % в обмен на более высокую задержку и более низкую доступность. Объект service_tier также принимается в Responses API и API Anthropic сообщений — см. Различия в ответах API ниже, где в каждом случае возвращается поле ответа.
Anthropic Messages API

​
Быстрый режим

service_tier: "fast" (Fast mode OpenAI — переименованная приоритетная обработка), service_tier: "priority" и нативный параметр Anthropic speed: "fast" полностью взаимозаменяемы для всех API и провайдеров. Любой из трёх запрашивает приоритетный уровень (в ответе сообщается priority), а на моделях Anthropic с быстрым вариантом (например anthropic/claude-opus-5-fast) запрос перенаправляется на быстрый вариант. Если вы явно задали конфликтующие значения (например, speed: "standard" с service_tier: "priority"), оба соблюдаются в том виде, в котором они написаны, и ни один из них не является производным от другого. Anthropic сама объявила устаревшим свой уровень приоритета — согласно документации по уровням обслуживания Anthropic: «Обязательства по мощности уровня Priority больше не доступны для покупки. Организации с существующими обязательствами могут продолжать использовать уровень Priority до даты окончания действия контракта».

​
Как работает маршрутизация

Эндпоинты уровня не по умолчанию (flex, priority) рассматриваются только тогда, когда их требует ваш запрос. Есть два способа сделать это:
  1. ** Параметр service_tier .** Для priority, сначала опробуются соответствующие эндпоинты (отсортированные по пропускной способности), с возвратом к другим эндпоинтам, если ни одна из них не увенчалась успехом; выставление счетов всегда соответствует фактически используемой эндпоинту, поэтому приоритетный запрос, который выходит за пределы уровня, оплачивается по стандартному тарифу этой эндпоинта, а не по тарифу уровня. Для flexмаршрутизация ограничена эндпоинтами гибкого доступа (отсортированными по цене) — гибкий интерфейс никогда не возвращается к эндпоинту уровня по умолчанию, поскольку это будет стоить дороже, чем запрошенный вами уровень, поэтому вместо этого появляется ошибка гибкой емкости. Если пул вообще не содержит гибких эндпоинтов (например, в модели нет поставщика с поддержкой гибкости), запросы обычно маршрутизируются со стандартной скоростью. Объединить с allow_fallbacks: false для маршрутизации только к верхней эндпоинту этого уровня.
  2. Эндпоинты уровня в provider.order или Сообщения provider.only. Каждый уровень имеет свой собственный пул эндпоинта, образованный путем добавления уровня к пулу поставщика, например. openai/priority или Сообщения google-vertex/flex. Например, "provider": { "only": ["openai/priority"] } ограничивает маршрутизацию уровнем приоритета OpenAI.
Запросы, которые не используют ни один из них, никогда не перенаправляются на уровень служб, отличный от уровня служб по умолчанию.

​
Эндпоинты уровня в API

Эндпоинты уровня перечислены в API эндпоинтов модели. рядом со стандартными эндпоинтами. Каждый из них отображается как отдельная запись с суффиксом уровня. tag (например. openai/priority) и цены с уже примененным множителем уровня — те же цены, которые используются для выставления счетов. Их присутствие в списке не меняет маршрутизацию: они продолжают участвовать, как описано выше.

​
Поддерживаемые поставщики

Следующие провайдеры поддерживают Уровни обслуживания flex и Параметры priority для некоторых моделей:
  • OpenAI
  • Google Vertex
  • Google AI Studio
  • SpaceXAI ( толькоpriority )
Ответ Поле service_tier сообщает, какой уровень фактически использовался. Возможные значения ответа: default, flex, priority, или null , когда уровень обслуживания недоступен из восходящего потока. Обратите внимание, что LLMSTORE нормализует метки базового уровня, эквивалентные поставщику, такие как Google standard, чтобы default — за исключением API Anthropic сообщений, который сохраняет standard , чтобы соответствовать спецификации Anthropic (см. Различия в ответах API ниже). Документация поставщика:

​
Различия в ответах API

Ответ API включает в себя Поле service_tier , указывающее, какой уровень мощности фактически использовался для обслуживания вашего запроса. Расположение этого поля зависит от формата API:
  • API завершения чата (/v1/chat/completions): service_tier возвращается на верхнем уровне объекта ответа, что соответствует собственному формату OpenAI.
  • Responses API (/v1/responses): service_tier возвращается на верхнем уровне объекта ответа, что соответствует собственному формату OpenAI.
  • API сообщений (/v1/messages): service_tier возвращается внутри usage объект, соответствующий собственному формату Anthropic.

​
Значение service_tier в API сообщений

В спецификации Anthropic используется standard , а не в стиле OpenAI default в качестве метки базового уровня. Итак, API сообщений возвращает service_tier: "standard" , куда возвращаются API-интерфейсы завершения чата и ответов. "default". Другие значения уровня возвращаются без изменений.