OpenRouter: Как с помощью "модельного транзитного узла" построить компанию стоимостью в 1 миллиард долларов?

Автор: Чжан Айла

Сегодня поговорим о прокси-серверах для моделей.

Проще говоря, прокси-сервер моделей — это интерфейс, который подключает различные модели, такие как OpenAI, Claude, Gemini, DeepSeek и другие, к одному входу, позволяя разработчикам вызывать несколько моделей через один API, один аккаунт и единый счет, а также выбирать, переключаться и использовать резервные варианты между разными моделями и поставщиками.

Конечно, для китайских пользователей более серьёзная причина использования прокси-серверов — доступ к зарубежным моделям и более низкая цена.

Это всем известно, и мы не будем много говорить о китайских прокси-серверах. Сегодня в основном представляем OpenRouter.

К 2026 году OpenRouter привлёк 113 миллионов долларов в раунде B, и его оценка приблизилась к 1,3 миллиарда долларов.

То есть это уже компания-единорог.

Давайте проанализируем, почему прокси-сервер моделей, который «не создаёт модели», стоит так много?

Чем именно занимается OpenRouter?

OpenRouter официально позиционирует себя как: единый интерфейс для больших моделей.

Сейчас OpenRouter поддерживает более 400 моделей и более 70 поставщиков моделей.

На официальном сайте также указано, что ежемесячная обработка платформы достигла 100 триллионов токенов, а количество пользователей по всему миру превышает 10 миллионов.

В объявлении о финансировании раунда B в мае 2026 года также упоминалось, что за последние 6 месяцев еженедельный объём обработки OpenRouter вырос с 5 триллионов токенов до 25 триллионов, и он обслуживает более 8 миллионов разработчиков.

Эти цифры говорят об одном:

OpenRouter — это уже не нишевый инструмент для разработчиков, а крупный вход для вызова ИИ.

Способ использования разработчиками также очень прост.

Раньше нужно было подключать каждую модель отдельно: OpenAI, Anthropic, Google, DeepSeek, Mistral, xAI и т.д.

Для каждой нужно было читать документацию, получать API-ключ, привязывать счёт, разбираться с различиями в интерфейсах, изучать лимиты трафика и обрабатывать ошибки.

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

Часто код, который раньше использовал интерфейс OpenAI, нужно только изменить base URL, заменить API-ключ и указать имя модели, чтобы через OpenRouter вызывать другие модели.

Это одна из причин его быстрого роста на ранних этапах: низкая стоимость миграции.

Почему разработчики не подключаются напрямую к компаниям-моделям?

Казалось бы, разработчики могут полностью обойти OpenRouter и получить API напрямую на сайте компании-модели.

Но в реальной разработке всё не так просто.

Если AI-продукт — это просто демо, достаточно одной модели. Но как только он переходит в реальную коммерческую эксплуатацию, трудно полагаться только на одну модель.

Например, AI-инструмент для написания текстов может иметь несколько разных задач:

Создание заголовков — достаточно дешёвой модели;

Написание длинных статей — требуются более мощные текстовые способности;

Анализ данных — нужна модель с длинным контекстом;

Модерация контента — требуется дешёвая и стабильная классификация;

Корпоративные клиенты требуют, чтобы данные не сохранялись — нужно выбирать поставщика, соответствующего политике обработки данных;

В пиковые периоды модель может быть ограничена по трафику, и нужно автоматически переключаться на резервную модель.

В такой ситуации проблема уже не просто «подключить один API».

Команде нужно поддерживать целую систему вызова моделей:

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

Более того, рынок моделей меняется очень быстро.

Сегодня Claude подходит для написания кода, завтра Gemini выигрывает по длине контекста, послезавтра DeepSeek или какая-нибудь open-source модель снижает цену.

Способности моделей, цены, длина контекста, политика поставщиков — всё постоянно меняется.

В этом и заключается ценность OpenRouter.

Он не пишет за разработчиков AI-приложения, а управляет за них тем, «какую модель использовать, как вызывать, как обеспечить отказоустойчивость и как контролировать затраты».

Не просто супермаркет моделей, а слой оркестрации моделей

Если понимать OpenRouter только как «супермаркет моделей», это недооценка.

Супермаркет моделей решает проблему «здесь много моделей, вы можете выбирать».

Но настоящая важная способность OpenRouter — это оркестрация между моделями и поставщиками.

Одна и та же модель может обслуживаться разными поставщиками.

Например, open-source модель может быть размещена на нескольких облачных сервисах или сервисах инференса. Цены, скорость и стабильность разных поставщиков различаются.

В документации OpenRouter есть функция provider routing — маршрутизация поставщиков.

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

Также поддерживается fallback — если модель или поставщик выходит из строя, система автоматически переключается на резервный вариант.

Для разработчиков OpenRouter позволяет вынести «выбор модели» и «обработку сбоев» из бизнес-кода и передать специализированной платформе.

Зачем предприятиям нужен этот слой?

Когда предприятия внедряют AI, на ранних этапах проблема обычно в том, «можно ли его использовать», но быстро она превращается в «как им управлять».

Внутри компании может быть много отделов, использующих AI.

Маркетинговый отдел пишет контент, служба поддержки отвечает клиентам, разработчики пишут код, операционный отдел анализирует данные, юридический отдел обрабатывает контракты.

Если каждый отдел подключает модели самостоятельно, возникает всё больше проблем:

Счета не различаются; выбор моделей не унифицирован;

Политика обработки данных непрозрачна; разные отделы дублируют подключение;

При сбое никто не знает, какой вызов вызвал проблему;

При изменении поставщика моделей систему сложно единообразно адаптировать.

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

Например, нулевое сохранение данных.

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

В документации OpenRouter поддерживается Zero Data Retention — нулевое сохранение данных.

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

Другой пример — prompt caching (кэширование подсказок).

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

OpenRouter поддерживает повышение частоты попадания в кэш с помощью sticky routing (липкой маршрутизации) поставщиков, стараясь направлять последующие запросы к тому же конечному точке поставщика, что снижает затраты на повторяющийся контекст.

Такие функции звучат несексуально, но очень практичны, и чем больше масштаб AI-приложения, тем заметнее экономия.

Как OpenRouter зарабатывает деньги?

Бизнес-модель OpenRouter очень ясна: зарабатывать на объёме использования.

Разработчики сначала покупают кредиты платформы, а затем платят за фактически вызванные модели и токены.

OpenRouter официально указывает:

Платформа взимает 5,5% комиссии при покупке кредитов, минимум 0,8 доллара; цены базовых поставщиков моделей передаются пользователям без дополнительной наценки на стоимость инференса моделей.

Это типичный бизнес «плата за проход трафика».

Преимущество этой модели в том, что доход привязан к объёму использования.

Чем больше вызовов делают разработчики, тем выше доход платформы; чем больше AI-приложений и чем больше потребляется токенов, тем больше бизнес OpenRouter.

Но у него есть и особенность: комиссия за один вызов невелика, поэтому нужно полагаться на масштаб.

Именно поэтому объём обработки токенов так важен для OpenRouter.

Его ключевой показатель — не количество зарегистрированных пользователей, а то, сколько токенов проходит через него еженедельно и ежемесячно.

В 2025 году годовой объём обработки OpenRouter вырос с примерно 10 триллионов токенов до более 100 триллионов.

К 2026 году годовой объём обработки OpenRouter достиг примерно 1,5 квадриллиона токенов.

В этом и заключается основная логика этого бизнеса.

Пока всё больше AI-приложений работают на многомодельных системах, OpenRouter может постоянно получать плату за обслуживание от этих вызовов.

Почему рост такой быстрый в последнее время?

Рост OpenRouter можно объяснить тремя изменениями.

Первое изменение — моделей становится всё больше.

Раньше при создании AI-приложений многие команды по умолчанию использовали OpenAI. Теперь всё иначе.

Claude, Gemini, DeepSeek, Qwen, Mistral, Llama, Grok, а также множество открытых и open-weight моделей имеют преимущества в разных сценариях.

Это не рынок, где «одна полностью заменяет другую».

Одни модели хороши для написания кода, другие дёшевы, третьи сильны в длинных текстах, четвёрты быстры, пятые подходят для ролевых игр, шестые — для корпоративных документов, седьмые — для мультимодальности.

Чем больше моделей, тем выше стоимость выбора; чем выше стоимость выбора, тем ценнее промежуточный слой.

Второе изменение — AI-приложения начинают обращать внимание на затраты.

Многие продукты на ранних этапах используют самые мощные модели, потому что сначала нужно добиться результата.

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

Если все запросы к чат-боту, AI-поиску, помощнику по коду или генератору контента проходят через самую дорогую модель, маржа быстро съедается.

Более зрелый подход — разделить задачи:

Простые задачи — дешёвая модель;

Сложные задачи — мощная модель;

Частые задачи — приоритет низкой задержки;

При сбое — переключение на резервную модель;

При работе с чувствительными данными — только поставщик, соответствующий политике обработки данных.

Это и есть сценарий использования OpenRouter.

Он не обязательно поможет найти «самую мощную модель», но может помочь сбалансировать эффективность, цену, скорость и стабильность.

Третье изменение — AI-приложения переходят от чат-окон к агентам.

Агенты вызывают инструменты, читают файлы, ищут в интернете, выполняют задачи и требуют много последовательных вызовов моделей.

По сравнению с обычным чатом, агенты потребляют больше токенов и сильнее зависят от стабильности.

Это на руку OpenRouter.

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

Именно поэтому в объявлении о финансировании OpenRouter подчёркивается, что AI переходит от экспериментов к ключевым производственным приложениям и сценариям с агентами.

Его рост по сути обусловлен ростом объёмов вызовов AI.

У этого бизнеса есть и риски

Позиция OpenRouter хороша, но не безопасна.

Он находится между компаниями-моделями, облачными провайдерами и разработчиками приложений. Эта позиция ценна, но её легко сжать.

Первый риск — крупные компании могут построить свои аналоги.

Для небольших команд OpenRouter очень удобен.

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

Особенно финансовые, медицинские и государственные клиенты могут больше беспокоиться о контроле данных и приватном развёртывании.

OpenRouter для работы с такими клиентами не может полагаться только на «много моделей». Ему нужно глубоко проработать управление правами, аудит, политику данных, управление поставщиками и корпоративную поддержку.

Второй риск — облачные провайдеры тоже делают шлюзы моделей.

AWS, Google Cloud, Azure и другие облачные платформы уже имеют корпоративных клиентов, системы счетов, права доступа и соответствие требованиям.

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

Преимущество OpenRouter — открытость и нейтральность, более широкий охват моделей и более быстрое подключение.

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

Третий риск — отношения с поставщиками моделей.

OpenRouter приносит трафик компаниям-моделям, но также отдаляет их от конечных разработчиков.

Когда платформа становится больше, она контролирует больше пользовательских отношений и данных об использовании моделей.

Поставщики моделей хотят получать дистрибуцию, но также опасаются, что их переговорная сила ослабнет.

Такие промежуточные платформы на ранних этапах приветствуются поставщиками; с ростом масштаба отношения становятся более деликатными.

Четвёртый риск — платёжная комиссия может быть снижена.

OpenRouter взимает 5,5% комиссии платформы. Сейчас это кажется небольшим.

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

Если некоторые конкуренты предложат более низкую комиссию, или облачные провайдеры упакуют такие возможности в свои существующие сервисы, OpenRouter нужно будет доказать, что он не просто «перенаправитель запросов».

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