OpenRouter привлекает $113 млн и обрабатывает 25 трлн токенов в неделю: что взрыв multi-model трафика означает для вашей routing-архитектуры

Заголовочная цифра — $113 млн. Операционно значимая цифра — 5x: именно во столько раз вырос еженедельный объём токенов, которые обрабатывает OpenRouter, за шесть месяцев — с 5 трлн до 25 трлн в неделю. Именно этот темп роста, а не сам факт инвестиционного раунда, требует реакции со стороны вашей routing-архитектуры.

Когда AI gateway обрабатывает 25 трлн токенов в неделю через 400+ моделей для 8 млн пользователей и за год удваивает оценку до $1,3 млрд — это сигнал о реальном направлении корпоративного AI-трафика: не к единственному provider, а через multi-model control plane, которая одновременно управляет стоимостью, задержкой и выбором нужной модели под задачу.

Что произошло

26 мая 2026 года OpenRouter объявил о привлечении $113 млн в раунде Series B под лидерством CapitalG (независимый growth-фонд Alphabet), с участием NVentures (венчурное подразделение Nvidia), ServiceNow Ventures, MongoDB Ventures, Snowflake Ventures и Databricks Ventures. В раунде также участвовали действующие инвесторы Andreessen Horowitz и Menlo Ventures.

Двенадцать месяцев назад — Series A при оценке около $547 млн (раунд на $40 млн, июнь 2025 года). Текущая оценка после раунда — около $1,3 млрд.

Заявленное использование средств: расширение возможностей routing, governance и оптимизации по мере того, как предприятия масштабируют AI в production.

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

Почему это важно для AI engineering команд

Состав инвесторов неслучаен: CapitalG (материнская компания — Google), NVentures (Nvidia), ServiceNow Ventures, MongoDB Ventures, Snowflake Ventures, Databricks Ventures — это ключевые игроки корпоративной инфраструктуры. Их совместное участие выражает консенсусный вывод: multi-model routing-инфраструктура стала постоянным стратегическим слоем корпоративного AI-стека, а не временным решением.

Самый приземлённый ориентир из анонса — данные исследования Deloitte: 67% предприятий уже потребляют около миллиарда токенов в месяц. При таком масштабе привязка к единственному provider — не упрощение архитектуры, а операционная ошибка в управлении затратами.

Что означает пятикратный рост для вашей команды:

• Объём токенов на вашем масштабе занижен. Полгода назад single-provider подход ещё можно было обосновать управляемыми объёмами. Кривая роста показывает: по мере того как agentic-нагрузки набирают сложный процент, это допущение быстро устаревает.
• Выбор модели превратился из задачи оценки в задачу эксплуатации. Команды маршрутизируют трафик между Qwen3.7 Max ($2,50 за млн input-токенов) и GPT-5.5 ($5,00 за млн) не потому, что провели полноценные evals, а потому что разные задачи имеют разные оптимальные точки на кривой стоимость/производительность — и модель, которая была оптимальной полгода назад, сегодня может таковой не быть.
• Governance и billing — новое узкое место. Routing через 400+ моделей без политик обработки данных на уровне запроса, командного контроля доступа, лимитов расходов на seat и audit-friendly отчётов по использованию создаёт compliance-риски, которые security и finance-команды отклонят при корпоративном аудите.

Угол зрения router/operator

Архитектурный тезис, заложенный в рост OpenRouter, стоит сформулировать прямо: routing инференса — это задача непрерывной переоптимизации, а не разовый выбор вендора. Слова CEO расставляют всё по местам: «Эпоха выбора единственной модели закончилась. Успех теперь зависит от непрерывного routing'а на меняющемся рынке».

Для команд, строящих или эксплуатирующих собственный routing-слой, это порождает ключевое архитектурное решение:

Строить vs. использовать готовый routing control plane. Реализация multi-model routing поверх OpenAI-compatible SDK требует самостоятельного решения следующих задач:

1. Health check и circuit breaker для каждого provider
2. Учёт стоимости по модели (input/output/cached токены с разными rate у каждого provider)
3. Fallback-цепочки с политиками деградации (что происходит, когда основной provider попадает под rate limit или у него растут задержки?)
4. Лимиты расходов и командные квоты
5. Audit-ready логи использования, пригодные для сверки с биллингом

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

Проблема политики задержки и надёжности. Routing по стоимости — задача очевидная. Routing по задержке требует наблюдения за хвостовыми задержками по каждому provider в реальном времени и динамической переранжировки. Routing по надёжности требует fallback-цепочек, которые не порождают каскадные retry-шторма. Большинство in-house реализаций routing хорошо справляются со стоимостью, но недоинвестируют в уровни задержки и надёжности.

Governance-слой решает судьбу корпоративных контрактов. Политики обработки данных на уровне запроса, командный контроль доступа, role-based доступ к моделям, дашборды видимости расходов — именно эти возможности позволяют routing-слою пройти проверку со стороны юридического и закупочного отделов. Без них технически корректная реализация routing всё равно может не пройти корпоративный аудит.

Чеклист для routing-команд прямо сейчас:

• Есть ли у вас учёт стоимости по каждому provider, отражающий текущие опубликованные rate (а не оценки полугодовой давности)?
• Есть ли у вас fallback-политика, которая срабатывает до того, как основной provider вас rate-лимитирует, а не после?
• Видимость расходов команды на уровне preset открыта руководителям, а не только инженерам?
• Ваша routing-политика обновляется без деплоя кода?
• Есть ли у вас audit-логи использования API, пригодные для сверки с биллинговой выпиской?

Если хотя бы на один вопрос нельзя ответить «да» — по мере роста объёма токенов накапливается операционный технический долг в вашей routing-архитектуре.

Что стоит проверить и попробовать пользователям TheRouter

Сигнал роста OpenRouter подтверждает проблему, которую решает TheRouter: routing OpenAI-compatible запросов между provider с единым биллингом и fallback-политикой.

Если вы уже используете TheRouter — сейчас хороший момент для ревизии конфигурации provider:

• Проверьте, какие provider настроены как primary и fallback для каждого preset, и соответствуют ли они вашим текущим ожиданиям
• Убедитесь, что ваш биллинговый дашборд отражает актуальные rate для provider, добавленных за последние 90 дней
• Проверьте, открыто ли командное использование по preset нетехническим стейкхолдерам — руководителям, финансовым командам

Если вы оцениваете, строить ли routing in-house или использовать gateway, кривая роста OpenRouter — полезный ориентир: она показывает, как выглядит спрос на управляемый gateway в корпоративном масштабе, и чётко обозначает governance и billing-возможности, которые потребует корпоративный закупочный процесс.

Рынок моделей меняется так быстро, что ваша routing-политика полугодовой давности, скорее всего, уже устарела. Структуры ценообразования Qwen3.7 Max, DeepSeek V4 Pro и Gemini 3.5 Flash, существующие сегодня, не существовали полгода назад — и через полгода этот список снова будет другим.