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 — це вже не просто інструмент для розробників-нішевиків, а великий вхід для AI-викликів.

Спосіб використання розробниками також дуже простий.

Раніше вам потрібно було окремо підключати моделі OpenAI, Anthropic, Google, DeepSeek, Mistral, xAI тощо.

Для кожного підключення потрібно було читати документацію, подавати заявку на API key, прив'язувати рахунок, обробляти відмінності інтерфейсів, дивитися правила лімітування, робити обробку винятків.

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

Часто код, який спочатку використовував інтерфейс OpenAI, потрібно лише змінити base URL, замінити API key і вказати назву моделі, щоб викликати іншу модель через OpenRouter.

Це одна з причин його швидкого зростання на ранніх етапах: низька вартість міграції.

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

Здається, розробники можуть обійти OpenRouter і безпосередньо зареєструватися на сайті компанії-моделі для отримання API.

Але в реальній розробці все не так просто.

Якщо AI-продукт є лише демо, достатньо однієї моделі. Але як тільки він входить у реальний бізнес, важко покладатися лише на одну модель.

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

Генерація заголовків — підійде дешева модель;

Написання довгих статей — потребує сильніших текстових здібностей;

Аналіз матеріалів — потребує моделі з довгим контекстом;

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

Корпоративні клієнти вимагають, щоб дані не зберігалися — потрібно вибрати постачальника, який відповідає політиці даних;

У пікові години модель може бути обмежена, потрібно автоматично переходити на резервну модель.

У такому випадку проблема не лише в "підключенні одного API".

Команда повинна підтримувати цілу систему виклику моделей:

Яка модель відповідає за яке завдання, яка модель дешевша, який постачальник швидший, який постачальник має нижчий рівень збоїв, як перемикатися при виникненні проблем, як розподіляти рахунки, як ізолювати дані корпоративних клієнтів.

Ще складніше те, що ринок моделей змінюється дуже швидко.

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

Здібності моделей, ціни, довжина контексту, політика постачальників — усе постійно змінюється.

У цьому й цінність OpenRouter.

Він не пише за розробника AI-додатки, а керує для розробника питаннями "яку модель використовувати, як викликати, як резервувати, як контролювати витрати".

Не просто супермаркет моделей, а рівень оркестрації моделей

Якщо розуміти OpenRouter лише як "супермаркет моделей", це применшить його значення.

Супермаркет моделей вирішує проблему "тут багато моделей, ви можете вибрати".

Але справді важлива здатність OpenRouter — це оркестрація між моделями та постачальниками.

Одна й та сама модель може надаватися різними постачальниками для виведення.

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

У документації OpenRouter є функція, яка називається provider routing, тобто маршрутизація постачальників.

Розробники можуть налаштувати автоматичне спрямування запитів до різних постачальників залежно від ціни, затримки, пропускної здатності, порядку постачальників тощо.

Він також підтримує fallback, тобто автоматичне перемикання на резервний варіант у разі збою моделі або постачальника.

Для розробників OpenRouter фактично виносить "вибір моделі" та "обробку збоїв" з бізнес-коду в окрему спеціалізовану платформу.

Навіщо підприємствам потрібен цей рівень?

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

У компанії може бути багато команд, які використовують AI.

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

Якщо кожна команда самостійно підключає моделі, виникає все більше проблем:

Рахунки не розподіляються; вибір моделей не уніфікований;

Політика даних не прозора; різні команди дублюють підключення;

Коли виникає проблема, ніхто не знає, який виклик спричинив її;

Зміни постачальника моделей важко узгодити в усій системі.

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

Наприклад, нульове зберігання даних.

Для багатьох підприємств не всі запити можна вільно надсилати будь-якому постачальнику моделей. Інформація про клієнтів, контракти, медичні дані, фінансові дані можуть мати суворі вимоги.

У документації OpenRouter підтримується Zero Data Retention, тобто нульове зберігання даних.

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

Інший приклад — prompt caching, тобто кешування підказок.

Багато AI-додатків багаторазово використовують довгі системні підказки, вміст бази знань або контекст. Якщо щоразу перераховувати, це буде дорого.

OpenRouter підтримує підвищення частоти влучень у кеш через маршрутизацію з прив'язкою до постачальника, намагаючись спрямовувати наступні запити до того самого кінцевого пункту постачальника, зменшуючи вартість повторного контексту.

Такі функції не звучать привабливо, але дуже практичні, і чим більший масштаб 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, а також велика кількість відкритих моделей із відкритою вагою мають переваги в різних сценаріях.

Це не ринок, де "один повністю замінює іншого".

Одні моделі краще пишуть код, інші дешевші, треті мають сильний довгий текст, четверті швидкі, п'яті підходять для рольових ігор, шості — для корпоративних документів, сьомі — для мультимодальності.

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

Друга зміна — AI-додатки починають звертати увагу на вартість.

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

Але як тільки продукт отримує користувачів, вартість моделі швидко стає проблемою.

Чат-бот служби підтримки, AI-пошуковий продукт, помічник коду, інструмент генерації контенту — якщо всі запити йдуть через найдорожчу модель, маржа легко з'їдається.

Більш зрілий підхід — розділити завдання:

Прості завдання — дешева модель;

Складні завдання — сильна модель;

Високочастотні завдання — модель із низькою затримкою;

При збої — перемикання на резервну модель;

При чутливих даних — тільки постачальник, який відповідає політиці даних.

Це саме той сценарій використання OpenRouter.

Він не обов'язково допомагає знайти "найсильнішу модель", але допомагає збалансувати ефективність, ціну, швидкість і стабільність.

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

Агенти викликають інструменти, читають файли, шукають в Інтернеті, виконують завдання, а також роблять багаторазові послідовні виклики моделей.

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

Це вигідно для OpenRouter.

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

Саме тому в оголошенні про фінансування OpenRouter підкреслюється, що AI переходить від експериментів до ключових виробничих додатків і сценаріїв агентів.

Його зростання по суті зумовлене збільшенням обсягу AI-викликів.

Цей бізнес також має ризики

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

Він знаходиться між компаніями-моделями, хмарними провайдерами та розробниками додатків. Така позиція має цінність, але також легко піддається тиску.

Перший ризик — великі компанії можуть створити своє.

Для невеликих команд OpenRouter дуже зручний.

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

Особливо клієнти з фінансового, медичного, державного секторів можуть більше піклуватися про контроль даних і приватне розгортання.

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

Другий ризик — хмарні провайдери також створюють шлюзи моделей.

AWS, Google Cloud, Azure — ці хмарні платформи вже мають корпоративних клієнтів, системи рахунків, системи прав доступу та можливості відповідності.

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

Перевага OpenRouter — відкритість і нейтральність, ширше охоплення моделей, швидше підключення.

Але перевага хмарних провайдерів — відносини з клієнтами та корпоративні процеси закупівель; це довгострокова конкуренція.

Третій ризик — відносини з постачальниками моделей.

OpenRouter приносить трафік компаніям-моделям, але також віддаляє їх від кінцевих розробників.

Коли платформа стає більшою, вона отримує більше контролю над відносинами з користувачами та даними про використання моделей.

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

Такі проміжні платформи на ранніх етапах зазвичай вітаються постачальниками; коли масштаб зростає, стосунки стають більш делікатними.

Четвертий ризик — комісія платформи може бути знижена.

OpenRouter стягує 5,5% комісії, що зараз здається невисоким.

Але якщо з'явиться більше подібних послуг, розробники порівнюватимуть ціни, стабільність, охоплення моделей і корпоративні функції.

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

Він повинен постійно пропонувати кращу маршрутизацію, ширше охоплення моделей, прозоріші ціни, стабільніший сервіс і повніший корпоративний контроль.