provider в теле запроса для Chat Completions Объект.
Объект provider может содержать следующие поля:
Балансировка нагрузки на основе цены (стратегия по умолчанию)
Для каждой модели в вашем запросе LLMSTORE по умолчанию выполняет запросы балансировки нагрузки между поставщиками, отдавая приоритет цене. Если вы более чувствительны к пропускной способности, чем к цене, вы можете использоватьsort для явного определения приоритета пропускной способности.
Вот стандартная стратегия балансировки нагрузки LLMSTORE:
- Отдайте приоритет поставщикам, у которых не было значительных сбоев в работе сети за последние 30 секунд.
- Для стабильных поставщиков посмотрите на кандидатов с наименьшими затратами и выберите одного, взвешенного по обратному квадрату цены (пример ниже).
- Остальных провайдеров использовать как резервные.
Пример балансировки нагрузкиЕсли поставщик A стоит 1 доллар США за миллион токенов, поставщик B стоит 2 доллара США, а поставщик C стоит 3 доллара США, а у провайдера B недавно произошло несколько сбоев.
- Ваш запрос направляется поставщику A. Вероятность того, что поставщик A сначала будет перенаправлен поставщику A, в 9 раз выше, чем поставщику C, поскольку (обратный квадрат цены).
- Если у провайдера 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 отслеживает показатели задержки и пропускной способности для каждой модели и поставщика, используя процентильную статистику, рассчитанную в течение скользящего 5-минутного окна. Доступные процентили:- p50 (медиана): 50 % запросов выполняются лучше этого значения.
- p75: 75 % запросов выполняются лучше этого значения.
- p90: 90% запросов выполняются лучше этого значения.
- p99: 99% запросов выполняются лучше этого значения.
Когда использовать процентильные предпочтения
Маршрутизация на основе процентилей полезна, когда вам нужны предсказуемые характеристики производительности:- Приложения реального времени: используйте пороговые значения задержки p90 или p99, чтобы обеспечить единообразное время отклика для функций, ориентированных на пользователя.
- Пакетная обработка: используйте пороговые значения пропускной способности p50, если вас больше интересует средняя производительность, чем наихудшие сценарии.
- Соответствие SLA: используйте несколько пороговых значений процентилей, чтобы гарантировать, что поставщики соблюдают ваши соглашения об уровне обслуживания на разных уровнях производительности.
- Оптимизация затрат: в сочетании с
sort: "price", чтобы получить самого дешевого провайдера, который по-прежнему соответствует вашим требованиям к производительности.
Вариант использования 2: найти самую дешевую модель, соответствующую требованиям к производительности
Объединитьpartition: "none" с пороговыми значениями производительности, чтобы найти самый дешевый вариант из нескольких моделей, отвечающий вашим требованиям к производительности. Это полезно, когда у вас есть минимальная производительность, но вы хотите минимизировать затраты.
preferred_max_latency , чтобы установить максимально допустимую задержку:
Пример: использование нескольких процентилей отсечения
Вы можете указать несколько пороговых значений процентилей, чтобы установить как типичные, так и наихудшие требования к производительности. Чтобы модель и поставщик вошли в предпочтительную группу, должны быть соблюдены все указанные ограничения.Вариант использования 3: максимальное использование BYOK в разных моделях
Если вы используете Принесите свой ключ (BYOK) и хотите максимально эффективно использовать свои собственные ключи API,partition: "none" может помочь. Если в вашей основной модели нет доступного поставщика BYOK, LLMSTORE может перенаправиться на резервную модель, которая поддерживает BYOK.
partition: "none", маршрутизатор всегда сначала будет проверять эндпоинты Клода, прежде чем вернуться к GPT-4o.
Эндпоинтам BYOK автоматически назначается приоритет, если у вас настроены ключи API для поставщика. Параметр
partition: "none" позволяет этой приоритезации работать за пределами модели.Заказ конкретных поставщиков
Вы можете указать поставщиков, которым LLMSTORE будет уделять приоритетное внимание вашему запросу, используяorder поле.
Маршрутизатор будет определять приоритетность поставщиков в этом списке и в этом порядке для используемой вами модели. Если вы не зададите это поле, маршрутизатор будет балансировать нагрузку у ведущих поставщиков, чтобы максимально увеличить время безотказной работы.
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 , вы можете быть уверены, что ваш запрос будет направлен к нужной эндпоинту:
Требование к поставщикам поддержки всех параметров
Вы можете ограничить запросы только теми поставщиками, которые поддерживают все параметры вашего запроса, используяrequire_parameters поле.
При использовании стратегии маршрутизации по умолчанию поставщики, которые не поддерживают все параметры LLM , указанный в вашем запросе, все еще может получить запрос, но будет игнорировать неизвестные параметры. Когда вы установите
require_parameters чтобы true, запрос даже не будет перенаправлен этому провайдеру.
Пример: исключение поставщиков, не поддерживающих формат JSON.
Например, чтобы использовать только поставщиков, поддерживающих формат JSON:Требование к поставщикам соблюдения политики обработки данных
Вы можете ограничить запросы только поставщиками, которые соответствуют вашей политике в отношении данных, используяdata_collection поле.
allow: (по умолчанию) разрешить провайдерам, которые постоянно хранят пользовательские данные и могут на них обучаться.deny: используйте только поставщиков, которые не собирают пользовательские данные
Пример: исключение поставщиков, не соблюдающих политику обработки данных.
Чтобы исключить поставщиков, которые не соблюдают вашу политику использования данных, установитеdata_collection чтобы deny:
Обеспечение нулевого хранения данных
Вы можете обеспечить нулевое сохранение данных (ZDR) для каждого запроса, используяzdr , обеспечивающий маршрутизацию вашего запроса только к эндпоинтам, которые не сохраняют запросы.
Когда
zdr установлено на trueзапрос будет перенаправляться только на эндпоинты, имеющие политику нулевого хранения данных. Когда zdr это false или не указано, это не влияет на маршрутизацию.
Пример: принудительное применение ZDR для конкретного запроса
Чтобы гарантировать, что запрос использует только эндпоинты ZDR, установитеzdr чтобы true:
Принудительное применение дистиллируемого текста
Вы можете включить фильтрацию текста для каждого запроса, используя Параметрenforce_distillable_text , гарантирующий, что ваш запрос будет перенаправляться только к моделям, в которых автор разрешил дистилляцию текста.
Когда
enforce_distillable_text установлено на trueзапрос будет перенаправляться только к моделям, в которых автор явно включил дистилляцию текста. Когда enforce_distillable_text это false или не указано, это не влияет на маршрутизацию.
Этот параметр полезен для приложений, которым необходимо гарантировать, что в их запросах используются только модели, допускающие дистилляцию текста в учебных целях, например, при построении наборов данных для точной настройки модели или рабочих процессов дистилляции.
Пример: принудительное использование выделяемого текста для конкретного запроса.
Чтобы гарантировать, что в запросе используются только модели, допускающие дистилляцию текста, установитеenforce_distillable_text чтобы true:
Отключение резервных вариантов
Чтобы гарантировать, что ваш запрос будет обслуживаться только лучшим (самым дешевым) поставщиком, вы можете отключить резервные варианты. Это сочетается с Полеorder из Заказ конкретных поставщиков , чтобы ограничить поставщиков, которым LLMSTORE будет уделять приоритетное внимание, только выбранным вами списком.
Разрешение только определенных поставщиков
Вы можете разрешить запросы только определенным поставщикам, установив Полеonly в поле Параметр provider объект.
Пример: разрешение Azure для запроса, вызывающего GPT-4 Omni
Вот пример, в котором Azure будет использоваться только для запроса, вызывающего GPT-4 Omni:Игнорирование поставщиков
Вы можете игнорировать поставщиков по запросу, установив полеignore в поле Параметр provider объект.
Пример: игнорирование 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или Сообщенияnvfp4mxfp4: Микромасштабирование с плавающей запятой (4 бита).nvfp4: NVIDIA с плавающей запятой (4 бита).fp6: Плавающая точка (6 бит).fp8: Плавающая точка (8 бит), включаяmxfp8mxfp8: Микромасштабирование с плавающей запятой (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 и направьте нормально.