# Провайдер в OpenRouter: чем отличаются only и order

Чем отличаются provider.only и provider.order в OpenRouter: допустимые исполнители, предпочтение, fallback, точные slugs и проверка маршрута на контролируемом запросе.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/openrouter-provider-only-order/
Language: ru

В OpenRouter параметры `provider.only` и `provider.order` решают разные задачи. Первый ограничивает допустимое множество исполнителей, второй задаёт предпочтительный порядок. Если важно исключить определённые маршруты, одного списка предпочтений недостаточно без проверки остальных правил.

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

## Разделите разрешение и предпочтение

[Provider Routing](https://openrouter.ai/docs/guides/routing/provider-selection) описывает поля объекта `provider`. Читайте их как отдельные ограничения, а не как взаимозаменяемые способы записать один список.

| Поле | Основной вопрос |
| --- | --- |
| `only` | Кто вообще может обслужить запрос |
| `order` | Кого пробовать предпочтительно и в какой последовательности |
| `allow_fallbacks` | Разрешены ли запасные провайдеры по правилам маршрута |
| `require_parameters` | Обязательна ли поддержка всех переданных параметров |

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

## Возьмите точные идентификаторы

Используйте slugs из текущего каталога провайдеров модели. Отображаемое название в интерфейсе и точный идентификатор могут отличаться, в том числе для отдельного варианта endpoint. Не создавайте строку по догадке из логотипа поставщика.

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

## Проверьте взаимодействие с BYOK

В [руководстве BYOK](https://openrouter.ai/docs/guides/overview/auth/byok) объясняется использование собственных ключей и порядок при явном выборе провайдеров. Разрешение провайдера и выбор источника credentials — связанные, но разные настройки. Успех на нужном бренде ещё не доказывает использование вашего аккаунта у него.

Условное приложение предпочитает провайдера A, но допускает B в резерве. Для другой задачи требуется исключительно A. Эти запросы должны иметь разные правила и разные ожидаемые результаты при недоступности A: получение ответа любой ценой не подходит второму сценарию.

## Сделайте отрицательный тест

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

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

## Сохраните конфигурацию как решение команды

Укажите, почему выбран каждый жёсткий фильтр и что допускается в резерве. Тогда изменение политики данных, качества или расходов можно будет проверить отдельно. Слишком узкий набор целей может уменьшить доступность; слишком широкий — нарушить исходные требования.

Дальше полезны [роутинг провайдеров](/ru/journal/openrouter-provider-routing/) и [предел цены fallback](/ru/journal/openrouter-fallback-price-cap/). Выход внешнего GPU-провайдера на платформу требует отдельного рассмотрения и не происходит от настройки клиентского списка `only`.