LLMSTORE направляет запросы лучшим доступным поставщикам для вашей модели. По умолчанию запросы сбалансированы по нагрузке у ведущих поставщиков, чтобы максимально увеличить время безотказной работы. Вы можете настроить маршрутизацию ваших запросов с помощью Объект provider в теле запроса для Chat Completions Объект. Объект provider может содержать следующие поля:

Балансировка нагрузки на основе цены (стратегия по умолчанию)

Для каждой модели в вашем запросе LLMSTORE по умолчанию выполняет запросы балансировки нагрузки между поставщиками, отдавая приоритет цене. Если вы более чувствительны к пропускной способности, чем к цене, вы можете использовать sort для явного определения приоритета пропускной способности.
Когда вы отправляете запрос с tools или Сообщения tool_choice, LLMSTORE делает приложите все усилия, чтобы направить их к поставщикам, которые поддерживают использование инструментов. Аналогично, если ты установил max_tokens, то LLMSTORE будет осуществлять маршрутизацию только к тем поставщикам, которые поддержите ответ такой длины.
Вот стандартная стратегия балансировки нагрузки LLMSTORE:
  1. Отдайте приоритет поставщикам, у которых не было значительных сбоев в работе сети за последние 30 секунд.
  2. Для стабильных поставщиков посмотрите на кандидатов с наименьшими затратами и выберите одного, взвешенного по обратному квадрату цены (пример ниже).
  3. Остальных провайдеров использовать как резервные.
Пример балансировки нагрузкиЕсли поставщик A стоит 1 доллар США за миллион токенов, поставщик B стоит 2 доллара США, а поставщик C стоит 3 доллара США, а у провайдера B недавно произошло несколько сбоев.
  • ​​Ваш запрос направляется поставщику A. Вероятность того, что поставщик A сначала будет перенаправлен поставщику A, в 9 раз выше, чем поставщику C, поскольку (1/32=1/9)(1 / 3^2 = 1/9) (обратный квадрат цены).
  • Если у провайдера A произошел сбой, то следующим будет опробован провайдер C.
  • Если провайдер C также потерпит неудачу, провайдер B будет опробован последним.
Если у вас есть sort или Сообщения order установлен в настройках вашего провайдера, балансировка нагрузки будет отключена.

Сортировка поставщиков

Как описано выше, LLMSTORE балансирует нагрузку на основе цены, принимая во внимание время безотказной работы. Если вместо этого вы хотите явно установить приоритет определенного атрибута поставщика, вы можете включить Поле sort в поле Параметр provider предпочтения. Балансировка нагрузки будет отключена, и маршрутизатор будет пробовать провайдеров по порядку. Три варианта сортировки:
  • "price": отдавать предпочтение самой низкой цене
  • "throughput": установить приоритет максимальной пропускной способности
  • "latency": установить приоритет наименьшей задержки
Чтобы всегда отдавать приоритет низким ценам и не применять балансировку нагрузки, установите sort чтобы "price". Чтобы всегда отдавать приоритет низкой задержке и не применять балансировку нагрузки, установите sort чтобы "latency".

Ярлык нитро

Вы можете добавить :nitro к любой пуле модели в качестве ярлыка для сортировки по пропускной способности. Это в точности эквивалентно установке provider.sort чтобы "throughput".

Ярлык минимальной цены

Вы можете добавить :floor к любой модели в качестве ярлыка для сортировки по цене. Это в точности эквивалентно установке provider.sort чтобы "price".

Расширенная сортировка с использованием разделов

При использовании поля фолбэков models, sort можно указать как объект с дополнительными параметрами для управления сортировкой эндпоинтов по нескольким моделям. По умолчанию, когда вы указываете несколько моделей (резервных), LLMSTORE группирует эндпоинты по модели перед сортировкой. Это означает, что эндпоинты основной модели всегда проверяются в первую очередь, независимо от их характеристик производительности. Настройка partition чтобы "none" удаляет эту группировку, позволяя сортировать эндпоинты глобально по всем моделям. Чтобы явно использовать поведение по умолчанию, установите partition: "model". Более подробную информацию о том, как работают резервные модели, см. в разделе Резервные модели.
preferred_max_latency и Параметры preferred_min_throughput не гарантируете, что вы получите поставщика или модель с таким уровнем производительности. Однако предпочтение будет отдано поставщикам и моделям, соответствующим вашим пороговым значениям. Поэтому указание этих предпочтений никогда не должно препятствовать выполнению вашего запроса. Это отличается от max_price, что предотвратит выполнение вашего запроса, если цена недоступна.

Вариант использования 1: маршрут к модели с наибольшей пропускной способностью или наименьшей задержкой

Если у вас есть несколько приемлемых моделей и вы хотите использовать ту, которая имеет наилучшую производительность прямо сейчас, используйте partition: "none" с сортировкой по пропускной способности или задержке. Это полезно, когда вас больше заботит скорость, чем использование конкретной модели.
В этом примере LLMSTORE будет маршрутизироваться к любой эндпоинту всех трех моделей, которая в данный момент имеет самую высокую пропускную способность, вместо того, чтобы всегда сначала пробовать Клода.

Пороги производительности

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

Как работают процентили

LLMSTORE отслеживает показатели задержки и пропускной способности для каждой модели и поставщика, используя процентильную статистику, рассчитанную в течение скользящего 5-минутного окна. Доступные процентили:
  • p50 (медиана): 50 % запросов выполняются лучше этого значения.
  • p75: 75 % запросов выполняются лучше этого значения.
  • p90: 90% запросов выполняются лучше этого значения.
  • p99: 99% запросов выполняются лучше этого значения.
Более высокие процентили (например, p90 или p99) дают больше уверенности в производительности в худшем случае, тогда как более низкие процентили (например, p50) отражают типичную производительность. Например, если у модели и поставщика задержка p90 составляет 2 секунды, это означает, что 90% запросов выполняются менее чем за 2 секунды. Когда вы указываете несколько пороговых значений процентилей, все указанные пороговые значения должны соблюдаться, чтобы модель и поставщик вошли в предпочтительную группу. Это позволяет вам устанавливать как типичные, так и наихудшие требования к производительности.

Когда использовать процентильные предпочтения

Маршрутизация на основе процентилей полезна, когда вам нужны предсказуемые характеристики производительности:
  • Приложения реального времени: используйте пороговые значения задержки p90 или p99, чтобы обеспечить единообразное время отклика для функций, ориентированных на пользователя.
  • Пакетная обработка: используйте пороговые значения пропускной способности p50, если вас больше интересует средняя производительность, чем наихудшие сценарии.
  • Соответствие SLA: используйте несколько пороговых значений процентилей, чтобы гарантировать, что поставщики соблюдают ваши соглашения об уровне обслуживания на разных уровнях производительности.
  • Оптимизация затрат: в сочетании с sort: "price" , чтобы получить самого дешевого провайдера, который по-прежнему соответствует вашим требованиям к производительности.

Вариант использования 2: найти самую дешевую модель, соответствующую требованиям к производительности

Объединить partition: "none" с пороговыми значениями производительности, чтобы найти самый дешевый вариант из нескольких моделей, отвечающий вашим требованиям к производительности. Это полезно, когда у вас есть минимальная производительность, но вы хотите минимизировать затраты.
В этом примере LLMSTORE найдет самую дешевую модель и поставщика для всех трех моделей, который имеет пропускную способность не менее 50 токенов в секунду на уровне p90 (это означает, что 90% запросов достигают этой пропускной способности или выше). Модели и поставщики ниже этого порога по-прежнему доступны в качестве запасного варианта, если все предпочтительные варианты не сработают. Вы также можете использовать preferred_max_latency , чтобы установить максимально допустимую задержку:

Пример: использование нескольких процентилей отсечения

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

Вариант использования 3: максимальное использование BYOK в разных моделях

Если вы используете Принесите свой ключ (BYOK) и хотите максимально эффективно использовать свои собственные ключи API, partition: "none" может помочь. Если в вашей основной модели нет доступного поставщика BYOK, LLMSTORE может перенаправиться на резервную модель, которая поддерживает BYOK.
В этом примере, если у вас есть ключ BYOK, настроенный для OpenAI, но не для Anthropic, LLMSTORE может маршрутизироваться к эндпоинту GPT-4o, используя ваш собственный ключ, даже если Клод указан первым. Без partition: "none", маршрутизатор всегда сначала будет проверять эндпоинты Клода, прежде чем вернуться к GPT-4o.
Эндпоинтам BYOK автоматически назначается приоритет, если у вас настроены ключи API для поставщика. Параметр partition: "none" позволяет этой приоритезации работать за пределами модели.

Заказ конкретных поставщиков

Вы можете указать поставщиков, которым LLMSTORE будет уделять приоритетное внимание вашему запросу, используя order поле. Маршрутизатор будет определять приоритетность поставщиков в этом списке и в этом порядке для используемой вами модели. Если вы не зададите это поле, маршрутизатор будет балансировать нагрузку у ведущих поставщиков, чтобы максимально увеличить время безотказной работы.
Вы можете использовать кнопку копирования рядом с именами поставщиков на страницах моделей, чтобы получить точный номер поставщика, , включая любые варианты, такие как “/turbo”. См. Нацеливание на эндпоинты конкретного поставщика для подробностей.
LLMSTORE будет пробовать их по одному и обращаться к другим поставщикам, если ни один из них не работает. Если вы не хотите разрешать использование других поставщиков, вам следует отключить резервные варианты тоже.

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

Этот пример пропускает OpenAI (который не поддерживает Mixtral), пробует Together, а затем возвращается к обычному списку провайдеров на LLMSTORE:

Пример: указание поставщиков с отключенными резервными вариантами

Вот пример с allow_fallbacks установлен на false , который пропускает OpenAI (на котором нет Mixtral), пытается выполнить Together, а затем завершается неудачно, если Together не удается:

Ориентация на эндпоинты конкретного поставщика

Каждый поставщик в LLMSTORE может размещать несколько эндпоинтов для одной и той же модели, например эндпоинт по умолчанию и специализированную эндпоинт «турбо», или эндпоинты, специфичные для региона, например google-vertex/us-east5. Чтобы настроить таргетинг на конкретную эндпоинт, вы можете использовать кнопку копирования рядом с именем поставщика на странице сведений о модели, чтобы получить точный пул поставщика.

Соответствие базовой слизи

Когда вы используете пул базового провайдера (например. "google-vertex") в любом поле маршрутизации провайдера (order, only, или ignore), он соответствует всем эндпоинтам этого провайдера, включая любые варианты и регионы. Например, "google-vertex" совпадений google-vertex, google-vertex/us-east5, google-vertex/us-central1и так далее. Обратите внимание, что эндпоинты уровня обслуживания (например. openai/priority, google-vertex/flex) не совпадают с базовыми пулами — они требуют явного согласия через Параметр service_tier или фрагмент с суффиксом уровня. Чтобы настроить таргетинг на конкретный вариант или регион, используйте полный фрагмент, включая суффикс (например, "google-vertex/us-east5" или Сообщения "deepinfra/turbo").

Пример: таргетинг на конкретный вариант эндпоинта

Например, DeepInfra предлагает DeepSeek R1 через несколько эндпоинтов: — эндпоинт по умолчанию со слизнем. deepinfra
  • Турбо-эндпоинт с пулей deepinfra/turbo
Копируя точный пул провайдера и используя его в своем запросе order , вы можете быть уверены, что ваш запрос будет направлен к нужной эндпоинту:
Этот подход особенно полезен, когда вы хотите последовательно использовать определенный вариант модели от конкретного поставщика.
Для маршрутизации ко всем эндпоинтам провайдера (во всех регионах и вариантах) просто используйте базовый фрагмент без суффикса. Например, "google-vertex" будет маршрутизироваться по всем регионам Vertex AI.

Требование к поставщикам поддержки всех параметров

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

Пример: исключение поставщиков, не поддерживающих формат JSON.

Например, чтобы использовать только поставщиков, поддерживающих формат JSON:

Требование к поставщикам соблюдения политики обработки данных

Вы можете ограничить запросы только поставщиками, которые соответствуют вашей политике в отношении данных, используя data_collection поле.
  • allow: (по умолчанию) разрешить провайдерам, которые постоянно хранят пользовательские данные и могут на них обучаться.
  • deny: используйте только поставщиков, которые не собирают пользовательские данные
Некоторые поставщики моделей могут регистрировать запросы, поэтому мы показываем их с тегом Политика данных на страницах моделей. Это не окончательный источник политик в отношении данных третьих сторон, но он представляет собой наши лучшие знания.
Фильтрация политики данных на уровне аккаунтаЭто также доступно в качестве настройки для всей учетной записи в разделе [ваша конфиденциальность]. настройки](https://llmstore.ru/settings/privacy). Вы можете отключить стороннее поставщики моделей, которые хранят входные данные для обучения.

Пример: исключение поставщиков, не соблюдающих политику обработки данных.

Чтобы исключить поставщиков, которые не соблюдают вашу политику использования данных, установите data_collection чтобы deny:

Обеспечение нулевого хранения данных

Вы можете обеспечить нулевое сохранение данных (ZDR) для каждого запроса, используя zdr , обеспечивающий маршрутизацию вашего запроса только к эндпоинтам, которые не сохраняют запросы. Когда zdr установлено на trueзапрос будет перенаправляться только на эндпоинты, имеющие политику нулевого хранения данных. Когда zdr это false или не указано, это не влияет на маршрутизацию.
ZDR для каждой модели и для всей учетной записиZDR также можно применить для каждой группы моделей (Anthropic, OpenAI, Google, SpaceXAI и нефронтир) в ваших настройках конфиденциальности или через guardrails. За запрос zdr параметр действует как «ИЛИ» с настройками ZDR для всей учетной записи и ограждения — если какой-либо из них включен, применяется принудительное применение ZDR. Параметр уровня запроса может только гарантировать включение ZDR, но не отменять принудительное применение всей учетной записи или ограждения. См. Нулевое сохранение данных. для подробностей.

Пример: принудительное применение ZDR для конкретного запроса

Чтобы гарантировать, что запрос использует только эндпоинты ZDR, установите zdr чтобы true:
Это полезно для клиентов, которые не хотят применять ZDR глобально, но должны обеспечить маршрутизацию определенных запросов только к эндпоинтам ZDR.

Принудительное применение дистиллируемого текста

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

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

Чтобы гарантировать, что в запросе используются только модели, допускающие дистилляцию текста, установите enforce_distillable_text чтобы true:

Отключение резервных вариантов

Чтобы гарантировать, что ваш запрос будет обслуживаться только лучшим (самым дешевым) поставщиком, вы можете отключить резервные варианты. Это сочетается с Поле order из Заказ конкретных поставщиков , чтобы ограничить поставщиков, которым LLMSTORE будет уделять приоритетное внимание, только выбранным вами списком.

Разрешение только определенных поставщиков

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

Пример: разрешение Azure для запроса, вызывающего GPT-4 Omni

Вот пример, в котором Azure будет использоваться только для запроса, вызывающего GPT-4 Omni:

Игнорирование поставщиков

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

Пример: игнорирование DeepInfra для запроса, вызывающего Llama 3.3 70b

Вот пример, в котором DeepInfra игнорирует запрос, вызывающий Llama 3.3 70b:

Квантование

Квантование уменьшает размер модели и требования к вычислениям, стремясь при этом сохранить производительность. Большинство LLM сегодня используют FP16 или BF16 для обучения и вывода, сокращая требования к памяти вдвое по сравнению с FP32. Некоторые оптимизации используют FP8 или квантование для дальнейшего уменьшения размера (например, INT8, INT4).
Квантованные модели могут демонстрировать снижение производительности при выполнении некоторых подсказок, в зависимости от используемого метода.
Провайдеры могут поддерживать различные уровни квантования для моделей с открытым весом.

Уровни квантования

По умолчанию запросы распределяются по всем доступным поставщикам, упорядоченным по цене. Чтобы отфильтровать поставщиков по уровню квантования, укажите quantizations в поле Параметр provider со следующими значениями:
  • int4: целое число (4 бита)
  • int8: Целое число (8 бит)
  • fp4: Плавающая точка (4 бита), включая mxfp4 или Сообщения nvfp4
  • mxfp4: Микромасштабирование с плавающей запятой (4 бита).
  • nvfp4: NVIDIA с плавающей запятой (4 бита).
  • fp6: Плавающая точка (6 бит).
  • fp8: Плавающая точка (8 бит), включая mxfp8
  • mxfp8: Микромасштабирование с плавающей запятой (8 бит).
  • fp16: Плавающая точка (16 бит).
  • bf16: Brain floating point (16 бит)
  • fp32: Плавающая точка (32 бита).
  • unknown: Неизвестно

Пример: запрос квантования FP8

Вот пример, в котором будут использоваться только поставщики, поддерживающие квантование FP8:

Максимальная цена

Чтобы отфильтровать поставщиков по цене, укажите Поле max_price в поле Параметр provider с объектом JSON, указывающим самую высокую цену поставщика, которую вы примете. Например, значение {"prompt": 1, "completion": 2} направит к любому провайдеру по цене <= $1/m токены подсказки и <= $2/m токенов завершения или меньше. Некоторые провайдеры поддерживают цену за запрос, и в этом случае вы можете использовать request атрибут max_price. Наконец, Также доступен вариант image , в котором указана максимальная цена за изображение, которое вы примете. Практически это поле часто совмещается с провайдером sort , чтобы выразить, например: «Используйте провайдера с самой высокой пропускной способностью, если его стоимость не превышает $x/m токенов.”

Заголовки, специфичные для поставщика

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

Anthropic бета-функции

При использовании моделей Anthropic (Claude) вы можете запросить определенные бета-функции, включив x-anthropic-beta заголовок вашего запроса. LLMSTORE передаст Anthropic поддерживаемые бета-функции.

Поддерживаемые бета-функции

LLMSTORE автоматически управляет некоторыми функциями Anthropic:
  • Кэширование подсказок и расширенный контекст включены в зависимости от возможностей модели.
  • Структурированные выходные данные для формата ответа схемы JSON (response_format.type: "json_schema") — заголовок применяется автоматически
  • Детальная потоковая передача инструментов — для каждого потокового запроса (stream: true), включающий пользовательские инструменты и наборы LLMSTORE. eager_input_streaming: true на каждом инструменте, поэтому Anthropic генерирует аргументы инструмента в виде последовательности инкрементных фрагментов, а не буферизует их. Это соответствует поведению потоковой передачи, уже представленному другими поставщиками. См. документацию по потоковой передаче инструментов Anthropic.](https://platform.claude.com/docs/en/agents-and-tools/tool-use/fine-grained-tool-streaming) для подробностей.
За строгое использование инструмента (strict: true по инструментам), вы должны явно передать structured-outputs-2025-11-13 заголовок. Без этого заголовка LLMSTORE удалит strict и направьте нормально.

Пример: включение чередующегося мышления

Объединение нескольких функций бета-версии

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

Условия обслуживания

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