Как выжать максимум из OpenRouter при помощи Provider Selection

При работе с большими языковыми моделями через OpenRouter разработчики часто используют стандартные настройки шлюза. Однако OpenRouter — это не просто прокси к API. Для большинства популярных моделей с открытым исходным кодом (например, Llama 3 или DeepSeek) на платформе доступно сразу несколько независимых хостинг-провайдеров (DeepInfra, Together AI, Fireworks, Lepton и др.) с разной стоимостью, задержкой и пропускной способностью.

Разберем, как устроен выбор провайдеров (Provider Selection) в OpenRouter и как с помощью объекта provider в теле запроса оптимизировать приложения под конкретные задачи: скорость, бюджет или отказоустойчивость.

Как работает балансировка по умолчанию

Если не передавать дополнительные параметры, OpenRouter распределяет нагрузку между доступными провайдерами автоматически, отдавая приоритет цене и стабильности.

Алгоритм выглядит следующим образом:

1. Исключаются провайдеры, у которых за последние 30 секунд были зафиксированы сбои.
2. Из оставшихся стабильных провайдеров выбирается наиболее дешевый. Вероятность отправки запроса конкретному провайдеру рассчитывается как обратно пропорциональная квадрату цены.
3. Остальные провайдеры используются как резервные (fallbacks) на случай сбоя основного.

Быстрые настройки :nitro и :floor

Если вам не хочется писать сложные конфигурации в коде, можно использовать встроенные суффиксы прямо в названии модели:

• :nitro — автоматически сортирует провайдеров по скорости (throughput). Эквивалентно установке sort: «throughput».
  • Пример: meta-llama/llama-3.3-70b-instruct:nitro
• :floor — жестко выбирает исключительно самый дешевый вариант на рынке. Эквивалентно sort: «price».
  • Пример: meta-llama/llama-3.3-70b-instruct:floor

Тонкая настройка через объект provider

Для детального контроля над логикой маршрутизации в тело POST-запроса добавляется объект provider.

Ниже представлен пример простой сортировки по одному из критериев (при этом стандартная балансировка отключается):

{
  "model": "meta-llama/llama-3.3-70b-instruct",
  "messages": [{"role": "user", "content": "Привет!"}],
  "provider": {
    "sort": "latency" 
  }
}

Параметр sort поддерживает три режима: «price» (минимальная цена), «throughput» (максимальная скорость генерации токенов в секунду) и «latency» (минимальное время до первого токена).

Продвинутая сортировка без группировки (partition: «none»)

По умолчанию при настройке списка резервных моделей (fallbacks) OpenRouter группирует эндпоинты по моделям (partition: «model»). Это значит, что запросы сначала будут отправляться на все эндпоинты основной модели, и только при их отказе — на резервную модель.

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

Пример сценария: Выбрать самый быстрый эндпоинт среди трех разных моделей:

{
  "models": [
    "anthropic/claude-sonnet-4.5",
    "openai/gpt-5-mini",
    "google/gemini-3-flash-preview"
  ],
  "messages": [{"role": "user", "content": "Реши задачу..."}],
  "provider": {
    "sort": {
      "by": "throughput",
      "partition": "none"
    }
  }
}

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

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

Иногда просто выбрать «самый быстрый» эндпоинт недостаточно — важна предсказуемость поведения системы под нагрузкой. OpenRouter собирает статистику работы провайдеров за скользящее 5-минутное окно и позволяет задавать требования по перцентилям:

• p50 (медиана) — типичная скорость работы.
• p90 — 90% запросов выполняются быстрее этого значения.
• p99 — худший сценарий (позволяет отсечь провайдеров с редкими, но долгими задержками).

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

Пример настройки:

{
  "model": "deepseek/deepseek-v3.2",
  "messages": [{"role": "user", "content": "Запрос к API"}],
  "provider": {
    "sort": "price",
    "preferred_max_latency": {
      "p50": 1.0,  
      "p90": 3.0   
    },
    "preferred_min_throughput": {
      "p50": 100,  
      "p90": 50    
    }
  }
}

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

Безопасность данных и соответствие стандартам (Compliance)

В корпоративных приложениях часто возникают строгие требования к обработке данных. Объект provider позволяет контролировать и эти аспекты:

1. Zero Data Retention (ZDR)

Если по соображениям конфиденциальности провайдерам запрещено сохранять историю ваших запросов, принудительно включите этот режим:

"provider": { "zdr": true }

OpenRouter отфильтрует провайдеров и оставит только те эндпоинты, которые гарантируют политику нулевого хранения данных.

2. Наличие специфических параметров (require_parameters)

Не все провайдеры поддерживают сложные функции, такие как вызовы инструментов (tool calling) или структурированный вывод (JSON-схемы). С флагом «require_parameters»: true роутер автоматически исключит провайдеров, которые не поддерживают параметры вашего запроса.

3. Квантование моделей (quantizations)

Если вы хотите избежать сильно сжатых версий моделей, которые могут терять в качестве ответов, укажите желаемый уровень квантования:

"provider": { "quantizations": ["fp16", "fp8"] }

4. Белые и черные списки провайдеров

Вы можете явно разрешить или заблокировать определенных провайдеров:

• «only»: [«azure», «together»] — отправлять запросы только им.
• «ignore»: [«deepinfra»] — полностью игнорировать этого провайдера.