Итак, вы хотите использовать OpenRouter?

· 2 мин чтения
openrouter llm-api open-source-models production reliability
Итак, вы хотите использовать OpenRouter?

Использовать OpenRouter кажется просто: один API — и доступ к десяткам open-source моделей. Но автор блога, запустивший Olly — AI-ассистента в iMessage — на открытых моделях через OpenRouter, утверждает обратное: «боль всю дорогу вниз». Olly обработал более 18 миллионов сообщений, примерно треть из них — на открытых моделях через OpenRouter. Такого объёма достаточно, чтобы столкнуться с каждым граничным случаем хотя бы раз. Ниже — выжимка из десяти уроков, которые автор хотел бы знать заранее.

Сначала словарь. Модель — это веса. Провайдер — тот, к кому OpenRouter маршрутизирует запрос: он хостит модель на своих GPU, на выбранной им точности квантизации, со своими «проприетарными» оптимизациями и своими парсерами XML/tool-вызовов — а значит, и со своим списком багов. Запрашивая deepseek/deepseek-v4-flash, вы получаете одну из примерно двадцати компаний, о которых никогда не слышали. На бумаге модель та же — в реальности очень разные.

1. Одна и та же модель бенчмаркится очень по-разному

OpenRouter публикует пер-провайдерские бенчмарки одной и той же модели: GPQA Diamond (знания) и TAU-Bench Airline (tool-calling). На доске за 7 сентября 2026 для DeepSeek V4 Flash 0731 — по точке на каждого провайдера, и все они обслуживают одни и те же веса.

Первый-party DeepSeek: 90% GPQA и 81% TAU. DigitalOcean на тех же весах: 75% и 58%. Большинство хостингов кластеризуются на 5–7 пунктов ниже первого party по tool-calling, а четыре из них проваливаются по знаниям. Для агента именно TAU — важная метрика, и разрыв в 20 пунктов — не шум. В июле было ещё хуже: Fireworks показывал 46% на TAU — отставание в 30 пунктов.

Вывод: перед тем как довериться провайдеру, проверьте доску по бенчмарку, ближайшему к вашей нагрузке. И перепроверяйте при смене модели — на GLM-5.3 те же провайдеры выглядели совершенно иначе.

2. У vision-модели бывают «слепые» провайдеры

Заметив странное недетерминированное поведение на задачах с изображениями, автор прогнал три крошечные картинки (буква, сплошной цвет, слово на фоне) через всех хостеров двух открытых vision-моделей.

Эндпоинт DeepInfra для Qwen3.5 122B прочитал букву K как R, назвал красный цвет синим, а слово на фоне описал как «забавное» — при этом четыре других хостера тех же весов всё распознали правильно. Venice и Together вообще «не видели» картинки MiniMax M3, отвечая «no image provided». Страница модели заявляет поддержку входных изображений, но часть провайдеров её не поддерживает — и хуже того, отвечает 200 OK, притворяясь, что всё в порядке.

3. Ручка effort — необязательная для некоторых провайдеров

Параметр reasoning.effort принимается везде, но работает ли он — зависит от модели и провайдера. Автор закрепил каждого провайдера DeepSeek V4 Flash 0731 и трижды отправил один и тот же промпт с уровнями low, high и max с продовой машины, отслеживая количество reasoning-токенов.

Большинство провайдеров уважают настройку, но DigitalOcean, GMI Cloud, Mancer и Venice — нет. Вывод: отслеживайте reasoning-токены для вашего уровня effort отдельно по каждому провайдеру.

4. Фильтр по квантизации не покупает качество

OpenRouter позволяет фильтровать провайдеров по заявленной точности: quantizations: ["fp8"] вместо fp4. Интуиция подсказывает: меньше бит — глупее модель. Автор месяц гонял этот фильтр на DeepSeek, а потом положил рядом пер-провайдерскую доску бенчмарков и заявленные квантизации.

Результат: fp4-хостеры оказались в середине fp8-пачки. Три худших результата GPQA на DeepSeek — по одному от каждой категории: fp4-хост, fp8-хост и тот, кто вообще ничего не заявляет. Лучший по обоим бенчмаркам на GLM — Wafer — не заявляет никакой квантизации. Точность — плохой прокси для качества, а жёсткий фильтр к тому же сужает пул провайдеров, к которым OpenRouter может откатиться при сбое. Фильтруйте по доске, а не по битам.

5. Tool call — в тексте

Идеальный сценарий: модель эмитит вызов в разметке, парсер провайдера превращает его в структурированный tool call, ваш код исполняет его. Но иногда парсер промахивается, и в ответе оказывается сырой текст вроде:

<use_skills><parameters>{"skills":["search"]}</parameters></use_skills>

Частота таких случаев сильно варьируется между провайдерами. Сталкиваетесь вы с этим достаточно часто и упорно, чтобы начать парсить на своей стороне. Причём есть два случая, требующих противоположной обработки: обёрнутые tool calls и обёрнутые/наполовину обёрнутые ответы. Примеры парсинга для DeepSeek/GLML автор выложил в открытом репозитории github.com/0xmmo/190proof.

6. 200 OK без ответа

Reasoning-модели иногда складывают всё в поле reasoning и возвращают content: null с finish_reason: "stop". 345 completion-токенов, HTTP 200 — и нечего показать пользователю.

HTTP 200 говорит лишь о том, что запрос был обслужен, а не что в нём есть ответ. Нет контента и нет tool call — это failure: бросайте исключение и повторяйте запрос.

7. Полые completions

Похожая, но отдельная проблема. Некоторые эндпоинты возвращают 200 с content: null, reasoning: null и вообще без объекта usage. В июле таким греш StreamLake на DeepSeek: около 20% трафика автора и 92% всех пустых completions. Месяц спустя то же самое делал Together на чекпойнте DeepSeek 0731.

8. Одни модели — разные правила истории

DeepSeek в режиме мышления эмитит блок reasoning_content. В агентском цикле модель часто делает tool call с пустым reasoning. Если вернуть такую пустую историю reasoning обратно через OpenRouter, а запрос уйдёт, например, к SiliconFlow — получите 400 с кодом 20015: «The reasoning_content in the thinking mode must be passed back to the API». Baidu, Alibaba и Cloudflare принимают ровно ту же историю без жалоб.

Контракт — не пер-модельный, а пер-провайдерный. И пропустить tool-историю нельзя: модель будет бесконечно повторять задачу. Ещё одна вещь, которую придётся обрабатывать.

9. Тестируйте из прода, а не с ноутбука

Причины — скорость и латентность, но показателен и другой пример: Venice и Novita идеально работали с Mac автора для DeepSeek V4 Flash, но почти каждый пробный запрос с его инфраструктуры получал 429. Тот же ключ, та же минута. Предположение — рейт-лимиты по IP.

Бенчмаркьте оттуда, где работает прод. По несколько провайдеров за раз, с бóльшим количеством сэмплов, чем кажется нужным.

10. Почему бы просто не запинить одного провайдера?

В какой-то момент у автора стояло provider.order: [cloudflare, baidu, alibaba] с allow_fallbacks: false — не один, а целых три надёжных провайдера. Две недели спустя Baidu начал рейт-лимитить всё подряд (429), Cloudflare, как выяснилось, вообще больше не обслуживал эту модель, а 100% трафика уходило к Alibaba — которая тоже начала отдавать 429. Модель номер один в OpenRouter (DeepSeek V4 Flash), запиненная к трём самым надёжным провайдерам, оказалась недоступна — и Olly вместе с ней.

Мораль: даже пиннинг к нескольким провайдерам не спасает. Крупные моделиоткрытые модели через роутер требуют постоянного мониторинга, ручной обработки ошибок и готовности к тому, что «тот же» ответ придёт от совершенно другой инфраструктуры.

Ссылки

Источник: https://mmoustafa.com/blog/so-you-want-to-use-openrouter/