7 
Содержание
- Зачем управлять провайдером в OpenRouter
- Автовыбор и сортировка провайдеров
- Сортировка по цене, скорости и пропускной способности
- Свой порядок через order
- Разрешать ли fallback
- Белый и чёрный список провайдеров
- Как узнать провайдеров модели
- Резерв по моделям
- Auto-роутер для ленивого выбора
- Топ моделей прямо из кода
- Сравнение моделей на сайте
- Что дальше в серии
- Референсные ссылки
Разобраться, как настроить маршрутизацию OpenRouter, стоит сразу после первого запроса. У одной модели обычно несколько провайдеров, и роутер по умолчанию сам решает, кому отдать вызов. Обычно это удобно, но иногда вам важнее цена, скорость или конкретный провайдер. В этой статье мы научимся управлять выбором: сортировать провайдеров, задавать свой порядок и строить резерв, чтобы запрос не падал из-за одного сбоя. Весь код прогнан на реальном стенде, провайдеры в выводах настоящие.
Зачем управлять провайдером в OpenRouter
Одна и та же модель в OpenRouter часто доступна у разных поставщиков. Например, у meta-llama/llama-3.3-70b-instruct на момент проверки было 13 провайдеров. Цена за миллион токенов входа у них отличается больше чем в десять раз, а скорость и стабильность у каждого свои. Роутер по умолчанию балансирует между ними по цене и аптайму, но это поведение можно переопределить.
По умолчанию роутер держит баланс между провайдерами по цене и надёжности. Если провайдер тормозит или отвечает ошибками, его вес автоматически снижается. Для многих задач этого достаточно, и лезть в настройки не нужно. Но как только появляется жёсткое требование по цене, скорости или доверию к поставщику, ручное управление оправдано.
Если вы ещё не выпустили ключ и не сделали первый запрос, начните с первой статьи серии про старт с OpenRouter. Здесь мы считаем, что ключ уже в окружении, и идём дальше. Управление провайдером решает три частые задачи: сэкономить, ускорить ответ и не зависеть от одного поставщика.
Дальше разберём каждую ветку этой схемы на рабочем коде.
Автовыбор и сортировка провайдеров
По умолчанию вы просто указываете модель, а провайдера подбирает OpenRouter. Когда важен конкретный критерий, его задают через объект provider. В библиотеке openai настройки провайдера передаются в поле extra_body, потому что это расширение поверх стандартного API OpenAI.
ИИ-агенты для оптимизации бизнес-процессов
Код курса
AGENT
Ближайшая дата курса
26 октября, 2026
Продолжительность
24 ак.часов
Стоимость обучения
66 000
Сортировка по цене, скорости и пропускной способности
Поле sort говорит роутеру, по какому признаку ставить провайдеров в очередь. Значений три, и каждое решает свою задачу.
- price. Сначала самый дешёвый провайдер. Подходит для массовых и некритичных запросов.
- throughput. Сначала провайдер с наибольшей пропускной способностью. Полезно под нагрузку и пакетную обработку.
- latency. Сначала самый быстрый по отклику. Нужно там, где важна отзывчивость в реальном времени.
Критерий выбирают под сценарий. Для фоновой обработки логов берут price и терпят задержку. Для чата с пользователем важнее latency. Для ночной пакетной генерации на первый план выходит throughput. Сам код при этом не меняется, правится только значение sort.
Проверим первые два на одной модели. Один и тот же запрос, меняется только критерий.
# протестировано на EU-ноде (AWS Stockholm) 2026-08-04: Python 3.12.3, openai 2.53.0, OpenRouter API
import os
from openai import OpenAI
client = OpenAI(
base_url="https://openrouter.ai/api/v1",
api_key=os.environ["OPENROUTER_API_KEY"],
)
MODEL = "meta-llama/llama-3.3-70b-instruct"
for sort_by in ("price", "throughput"):
resp = client.chat.completions.create(
model=MODEL,
messages=[{"role": "user", "content": "Ответь одним словом: готово"}],
max_tokens=20,
extra_body={"provider": {"sort": sort_by}},
)
print(f"sort={sort_by:<11} provider={resp.provider}")
Поле provider в ответе показывает, кто реально обслужил запрос. На стенде критерий менял провайдера так.
sort=price provider=DeepInfra sort=throughput provider=SambaNova
Под цену запрос ушёл к DeepInfra, под пропускную способность к SambaNova. Полный сценарий лежит в файле provider_sort.py в репозитории кода статьи.
Свой порядок через order
Иногда нужен не критерий, а конкретный провайдер. Для этого есть поле order со списком провайдеров в нужном порядке. Роутер идёт по списку сверху вниз и берёт первого доступного. Ниже часть провайдеров llama с ценой за миллион токенов входа, чтобы был виден разброс.
| Провайдер | Цена за 1М токенов входа | Контекст |
|---|---|---|
| DeepInfra | 0.10$ | 131072 |
| Nebius | 0.13$ | 131072 |
| Groq | 0.59$ | 131072 |
| Together | 1.04$ | 131072 |
Поставим Together первым и запретим подмену. Запрос обязан уйти именно туда.
# протестировано на EU-ноде (AWS Stockholm) 2026-08-04: Python 3.12.3, openai 2.53.0, OpenRouter API
resp = client.chat.completions.create(
model="meta-llama/llama-3.3-70b-instruct",
messages=[{"role": "user", "content": "Ответь одним словом: готово"}],
max_tokens=20,
extra_body={"provider": {"order": ["Together", "DeepInfra"], "allow_fallbacks": False}},
)
print("provider:", resp.provider)
provider: Together
Разрешать ли fallback
Флаг allow_fallbacks решает, что делать, когда провайдеры из списка недоступны. При значении false запрос упадёт с ошибкой, но не уйдёт к постороннему провайдеру. Это нужно, когда данные должны обрабатываться только у доверенного поставщика. При значении true роутер после вашего списка попробует остальных, и запрос с большей вероятностью получит ответ. Выбор между строгостью и живучестью зависит от задачи.
Белый и чёрный список провайдеров
Рядом с order живут ещё два поля. Список only оставляет лишь перечисленных провайдеров, всех остальных роутер игнорирует. Список ignore наоборот исключает названных, а прочих оставляет. Это удобно, когда часть провайдеров не подходит по региону, цене или политике данных. Мы уже пользовались only в примере с резервом, чтобы отсечь всех, кроме OpenAI. Рядом есть поле data_collection, оно ограничивает провайдеров по политике хранения данных, но это тема отдельной статьи серии про приватность.
Как узнать провайдеров модели
Список провайдеров и цены отдаёт отдельный эндпоинт. Достаточно GET-запроса на /models с автором и слагом модели и суффиксом endpoints. В ответе для каждого провайдера видно имя, цену и длину контекста. Именно оттуда взята таблица выше. Так удобно собирать order или only не наугад, а по актуальным данным.
Резерв по моделям
Провайдер это половина истории. Иногда стоит подстраховаться на уровне самих моделей. Поле models задаёт список: основная модель плюс резервные. Если первую обслужить некому, OpenRouter переключается на следующую из списка.
Чтобы показать переключение вживую, мы намеренно ломаем первую модель. Разрешаем только провайдера OpenAI, который llama не обслуживает. Роутер видит, что первую подать некому, и уходит на вторую.
# протестировано на EU-ноде (AWS Stockholm) 2026-08-04: Python 3.12.3, openai 2.53.0, OpenRouter API
FALLBACK = ["meta-llama/llama-3.3-70b-instruct", "openai/gpt-4o-mini"]
messages = [{"role": "user", "content": "Ответь одним словом: готово"}]
# Обычный вызов: первую модель есть кому обслужить.
normal = client.chat.completions.create(
model=FALLBACK[0], messages=messages, max_tokens=20,
extra_body={"models": FALLBACK},
)
print("обычный вызов -> ответила:", normal.model, "| провайдер:", normal.provider)
# Ломаем первую: разрешаем только OpenAI, который llama не обслуживает.
forced = client.chat.completions.create(
model=FALLBACK[0], messages=messages, max_tokens=20,
extra_body={"models": FALLBACK, "provider": {"only": ["OpenAI"]}},
)
print("сбой первой -> ответила:", forced.model, "| провайдер:", forced.provider)
обычный вызов -> ответила: meta-llama/llama-3.3-70b-instruct | провайдер: Novita сбой первой -> ответила: openai/gpt-4o-mini | провайдер: OpenAI
В обычном вызове ответила основная llama через провайдера Novita. Как только её стало некому подать, запрос сам ушёл на резервную gpt-4o-mini. Приложению не пришлось ничего ловить и повторять вручную. Полный сценарий в файле model_fallback.py.
Стоит помнить про цену резерва. Токены считаются по той модели, которая реально ответила. Если резервная дороже основной, редкие переключения обойдутся дороже обычного. Зато приложение переживает сбой провайдера без падения, а это часто важнее пары лишних центов.
ИИ-агенты для оптимизации бизнес-процессов
Код курса
AGENT
Ближайшая дата курса
26 октября, 2026
Продолжительность
24 ак.часов
Стоимость обучения
66 000
Auto-роутер для ленивого выбора
Когда не хочется выбирать модель вручную, есть особый идентификатор openrouter/auto. Роутер сам подбирает подходящую модель под запрос. Это удобно для черновых сценариев и быстрых проверок, хотя для продакшена лучше фиксировать модель осознанно.
# протестировано на EU-ноде (AWS Stockholm) 2026-08-04: Python 3.12.3, openai 2.53.0, OpenRouter API
resp = client.chat.completions.create(
model="openrouter/auto",
messages=[{"role": "user", "content": "Ответь одним словом: готово"}],
max_tokens=20,
)
print("реально ответила модель:", resp.model, "| провайдер:", resp.provider)
реально ответила модель: openai/gpt-5.6-sol | провайдер: OpenAI
На нашем запросе auto выбрал gpt-5.6-sol. Результат зависит от запроса и текущей доступности моделей, поэтому на другом прогоне модель может отличаться. Auto экономит время на старте, но лишает контроля над ценой и поведением. Поэтому в боевых сценариях его обычно заменяют явным выбором модели и провайдера.
Топ моделей прямо из кода
Маршрутизация опирается на то, какие модели вообще в ходу. Раньше это смотрели глазами на сайте, теперь есть датасет-эндпоинт rankings-daily. Он отдаёт топ-50 моделей по объёму токенов за день плюс служебную строку other. Дёргать его можно тем же ключом, лимиты общие: 30 запросов в минуту и 500 в день на аккаунт.
# протестировано на EU-ноде (AWS Stockholm) 2026-08-04: Python 3.12.3, httpx 0.28.1, OpenRouter API
import httpx
day = "2026-08-03"
r = httpx.get(
"https://openrouter.ai/api/v1/datasets/rankings-daily",
params={"start_date": day, "end_date": day},
headers={"Authorization": f"Bearer {os.environ['OPENROUTER_API_KEY']}"},
timeout=30,
)
r.raise_for_status()
rows = [x for x in r.json()["data"] if x["model_permaslug"] != "other"][:10]
for i, x in enumerate(rows, 1):
print(f"{i:>2}. {x['model_permaslug']:<45} {int(x['total_tokens'])/1e9:>8.1f}B")
Топ-10 моделей OpenRouter за 2026-08-03 по токенам: 1. deepseek/deepseek-v4-flash-20260731 1015.8B 2. deepseek/deepseek-v4-flash-20260423 950.7B 3. tencent/hy3-20260706 880.3B 4. xiaomi/mimo-v2.5-20260422 744.1B 5. openai/gpt-5.6-luna-20260709 553.2B 6. deepseek/deepseek-v4-pro-20260423 426.0B 7. z-ai/glm-5.2-20260616 408.4B 8. nvidia/nemotron-3-ultra-550b-a55b-20260604:free 320.9B 9. poolside/laguna-s-2.1-20260720:free 268.6B 10. minimax/minimax-m3-20260531 253.5B
Такой список удобно тянуть в свой дашборд или использовать как подсказку при выборе модели. Полный сценарий в файле rankings_top.py.
Строка other в ответе суммирует весь хвост за пределами топ-50. По ней прикидывают долю топовых моделей в общем объёме. Ответ кэшируется на сервере около минуты, так что частить запросами смысла нет. По динамике этих чисел видно, какие модели набирают ход, а какие выдыхаются.
Сравнение моделей на сайте
Для ручного анализа на сайте OpenRouter есть страница сравнения. На ней можно поставить рядом до пяти моделей и сравнить цену, контекст и провайдеров в одном экране. Там же легко отсеять слишком дорогие или слишком медленные варианты. Это быстрый способ выбрать кандидатов, а тонкую настройку маршрутизации потом уже описать кодом, как мы делали выше.
Что дальше в серии
Итог такой. Вы научились сортировать провайдеров по цене и скорости, задавать жёсткий порядок, строить резерв по моделям и дёргать топ моделей из кода. Этого хватает, чтобы маршрутизация работала предсказуемо и дёшево. Следующий шаг это уже экономика запросов. В третьей статье серии разберём кэш промптов, липкую маршрутизацию и субагентов, которые сбрасывают рутину на дешёвую модель, и посчитаем реальную экономию.
