Скрытые подводные камни OpenRouter: один эндпоинт — разное поведение

Один из главных аргументов в пользу OpenRouter звучит заманчиво: сервис сам «обрабатывает откаты и выбирает наиболее экономичный вариант для каждого запроса». Вы обращаетесь к единственному эндпоинту для нужной модели, а система маршрутизирует запрос к лучшему из доступных backend-провайдеров. Удобно — до тех пор, пока не начинаешь разбираться, что скрывается за этой абстракцией.

Мохамед Мустафа, на чью заметку ссылается Саймон Уиллисон, перечисляет целый набор проблем, вытекающих из такой автоматики. Корень в том, что разные провайдеры запускают разное серверное ПО — с разными оптимизациями и настройками. В результате один и тот же эндпоинт OpenRouter может обслуживать запросы к якобы одной модели, но вести себя при этом по-разному от вызова к вызову.

Одна модель, разные ответы

Расхождения не сводятся к мелочам. Некоторые провайдеры вовсе не поддерживают работу с изображениями — даже когда речь идёт о моделях, которые формально считаются мультимодальными (vision). Различается и то, как обрабатывается параметр, задающий «усилие на рассуждение» (reasoning effort). Иными словами, поведение, на которое вы рассчитываете при разработке, может незаметно измениться просто потому, что запрос ушёл к другому бэкенду.

Для тех, кто строит приложение поверх LLM, это неприятный источник нестабильности: код и промпты остаются прежними, а результат «плавает» без видимой причины.

Как вернуть себе контроль

Хорошая новость в том, что маршрутизацией можно управлять вручную. OpenRouter предоставляет опцию provider.only, которая позволяет жёстко зафиксировать, к какому именно провайдеру отправлять запросы. А чтобы понять, из чего вообще выбирать, есть метод /endpoints — он возвращает список доступных провайдеров для конкретного идентификатора модели.

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

Источник: Simon Willison