Мультимодальность через один эндпоинт: что архитектура OpenRouter говорит каждому оператору AI-шлюза

Любой роадмап AI-продукта рано или поздно упирается в проблему N модальностей. Первый спринт даёт чат. Затем нужна генерация изображений для продукта. Затем голосовой ввод для мобильного приложения. Затем база знаний, которой нужны эмбеддинги. Не успеваешь оглянуться — и вот уже четыре SDK провайдеров, четыре биллинговых контракта, четыре схемы обновления токенов и четыре реализации логики повторных попыток — и это ещё до того, как написана хоть одна строка продуктового кода.

16 июля OpenRouter опубликовал технический разбор того, как они решают эту проблему на уровне платформы: единый base URL (https://openrouter.ai/api/v1), один API-ключ, один счёт, и одни и те же правила маршрутизации, применяемые единообразно ко всем модальностям. Статья ценна не только описанием самого OpenRouter, но и тем, что она обнажает: архитектурный выбор, который каждый оператор AI-шлюза незаметно делает прямо сейчас.

Карта мультимодальных эндпоинтов OpenRouter

Дизайн OpenRouter делит модальности на две группы. Пять из них — текстовый чат, визуальный ввод (изображения), PDF, аудиовход и видеовход — работают через существующий эндпоинт /chat/completions и отличаются только content type в массиве сообщений. Вы уже вызываете этот эндпоинт для текста; добавить изображение или аудио — значит изменить тип содержимого, а не эндпоинт.

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

Генерация видео асинхронна по своей природе: вы отправляете промпт, получаете job ID и опрашиваете результат — именно такой паттерн нужен любому оператору для задач с большой задержкой.

Почему слой маршрутизации — это главный урок

Поверхность API — это видимая часть. Более важный тезис: один и тот же объект политики маршрутизации применяется единообразно ко всем модальностям. Failover провайдера, data_collection: "deny" для конфиденциальных нагрузок, сортировка по стоимости или задержке — всё это работает одинаково, вызываете ли вы /chat/completions или /embeddings.

Это принципиально важно с операционной точки зрения. Когда каждая модальность интегрируется через отдельный SDK и провайдера, применение политик становится фрагментированным:

• Ваши чат-запросы соблюдают правило резидентности данных; генерация изображений его обходит, потому что идёт через другую интеграцию.
• Ваша логика failover покрывает сбои текстовых провайдеров; отказ провайдера изображений выражается в необработанной ошибке.
• Ваш биллинг-дашборд показывает расходы на текстовые токены; генерация изображений оседает в отдельном счёте.

Слой маршрутизации, который рассматривает модально-агностичную политику как основной примитив, устраняет все три разрыва. Одно правило управляет каждым вызовом независимо от того, что он возвращает.

Фреймворк принятия решений для оператора

Когда ваш продукт становится мультимодальным, перед вами развилка:

Вариант A: интеграции по модальностям. Каждая команда выбирает лучшего провайдера для своей модальности, интегрируется напрямую — и вы получаете N биллинговых контрактов и N поверхностей политик. Быстрый старт, дорогое управление при масштабировании.

Вариант B: весь трафик через единый шлюз. Один набор учётных данных, одна биллинговая поверхность, одна точка принудительного применения rate limiting, бюджетных лимитов, резидентности данных и логики failover — одновременно для чата, изображений, аудио и эмбеддингов.

Цена варианта B: ваш шлюз должен понимать каждую маршрутизируемую модальность. Шлюз, построенный только для /chat/completions, не может применить failover провайдера к запросу на генерацию изображения, потому что этот трафик вообще через него не проходит.

Практический чеклист для операторов, оценивающих текущий стек:

1. Маршрутизирует ли ваш шлюз генерацию изображений и видеозадачи так же, как чат? Если нет, эти модальности находятся вне вашей политики маршрутизации.
2. Настроен ли у вас failover для провайдеров генерации изображений? Рынок генерации изображений по-прежнему сосредоточен у небольшого числа провайдеров; отказ одного без fallback — это отказ продукта.
3. Учитываются ли асинхронные медиазадачи (генерация видео, длинный TTS) в том же журнале использования, что и синхронные вызовы? Если нет, в вашем учёте затрат есть пробел.
4. Можете ли вы применить data_collection: deny или эквивалентные средства контроля приватности к запросам эмбеддингов? Эмбеддинги зачастую несут наиболее семантически чувствительный контент приложения.

Что это значит для вашей политики маршрутизации

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

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

Несколько практических ограничений из разбора OpenRouter, о которых стоит знать заранее: эмбеддинги не поддерживают стриминг (возвращаются целиком), аудиовход принимается только в base64 (без URL-ссылок), поддержка видео по URL зависит от провайдера. Это реальные шероховатости, возникающие на пересечении единого интерфейса и принципиально разных реализаций провайдеров — их важно знать до того, как вы привязываетесь к провайдеру для конкретной модальной нагрузки.