Пятый ключ API только что упёрся в лимит. Продакшен лежит. В вашем канале #incidents в Slack 47 непрочитанных сообщений — три из них от CEO. Один разработчик вручную перенаправляет трафик на резервную модель. Другой обновляет страницу статуса OpenAI. Третий считает, что дешевле — апгрейд до Tier 5 или смена провайдера, и ошибается в расчётах.
Вот что происходит, когда LLM-инфраструктура растёт органически — по одному API-ключу, по одному файлу .env за раз — пока однажды не перестаёт расти, а просто ломается. И самое неприятное: это было предсказуемо. Только в июне 2026 года на рынок вышло 121 продукт API-шлюзов. Инструменты существуют. Проблема в том, чтобы выбрать правильный до вашего следующего инцидента, потому что ошибка означает миграцию всей LLM-инфраструктуры через шесть месяцев.
Это сравнение охватывает четыре платформы, которые имеют значение — OpenRouter, LiteLLM, Portkey и TokSpan — оценённые по шести измерениям, определяющим, переживёт ли шлюз ваш первый продакшн-инцидент.
Вот что вы получите: фреймворк оценки по 6 измерениям, отделяющий действительно важное от маркетинга, анализ по каждой платформе с реальными сильными сторонами и реальными ограничениями, сравнительную таблицу с доказательствами для каждой оценки, оценки TCO на 100 миллионов токенов и фреймворк принятия решений, сопоставляющий профиль вашей команды с правильным шлюзом.
Что такое AI API-шлюз и почему он важен в 2026 году
AI API-шлюз располагается между вашим приложением и LLM-провайдерами. Ваше приложение отправляет запросы на один endpoint. Всё остальное шлюз берёт на себя.
До шлюза: разрозненные API-ключи от пяти провайдеров в файлах .env в трёх репозиториях. Биллинг отдельно у каждого провайдера с разными минимальными депозитами и датами продления. Нет автоматического фейловера — если OpenAI лежит, ваши пользователи видят ошибки.
Лимиты управляются отдельно по каждому провайдеру тем, кто не забыл проверить дашборд. Отслеживание затрат — через таблицу, которую кто-то обновляет по пятницам.
После шлюза: один endpoint. Один набор учётных данных. Код вашего приложения никогда не меняется при смене моделей.
Биллинг консолидирован в единый предоплаченный баланс. Автоматический фейловер обходит сбои провайдеров за миллисекунды.
Лимиты управляются на уровне шлюза с бюджетами по командам и allowlist моделей. Отслеживание затрат — в реальном времени, по каждому запросу, по каждому пользователю, по всем провайдерам.
Сравнивая шлюзы, вы оцениваете четыре технические возможности, определяющие, переживёт ли платформа ваш первый продакшн-инцидент. Трансляция протоколов — говорит ли шлюз нативно на OpenAI, Anthropic и Gemini, или он прогоняет всё через OpenAI-совместимый слой трансляции, обрезающий специфичные для провайдера функции, такие как extended thinking у Claude? Управление ключами — можете ли вы выпускать virtual keys с бюджетами по командам, allowlist моделей и аудиторскими следами, или каждый разработчик делит один root key? Наблюдаемость — получаете ли вы единую атрибуцию затрат, задержки и ошибок по всем провайдерам в одном дашборде, или сшиваете пять консолей провайдеров и электронную таблицу? Отказоустойчивость — ретраит ли шлюз с экспоненциальной задержкой, поддерживает ли circuit breakers по каждому провайдеру и автоматически ли фейловерится, когда один провайдер деградирует? Четыре «да» — базовый уровень. Платформы в этом сравнении расходятся в том, как они реализуют каждое из них.
Когда он нужен: в вашей команде больше одного разработчика, использующего LLM. Вы используете модели более чем одного провайдера. Вам нужно знать, кто сколько потратил.
Вы не можете позволить себе «модель недоступна» как ошибку, видимую пользователю. Другими словами: любая команда, строящая продакшн-приложение.
Когда не нужен: вы соло-разработчик, прототипирующий с одной моделью одного провайдера. Прямого доступа к API достаточно. Добавьте шлюз, когда присоединится второй член команды или будет добавлен второй провайдер — что наступит раньше.
Об архитектурных паттернах, которые делают мультипровайдерные конфигурации работоспособными в продакшне, читайте в нашем руководстве по использованию нескольких моделей AI в одном приложении.
Фреймворк оценки по 6 измерениям
Шлюзы позиционируются на количестве моделей. Количество моделей — наименее важное измерение. Вот что действительно имеет значение в продакшне.
| Измерение | Что измеряет | Почему это важно |
|---|---|---|
| Поддержка протоколов | Нативно ли поддерживаются OpenAI, Anthropic и Gemini? | Extended thinking от Claude не переживает трансляцию в OpenAI-совместимый формат. Шлюз, поддерживающий только OpenAI, теряет лучшие функции Claude. |
| Кэширование и производительность | Семантическое кэширование, сквозное кэширование промптов, накладные расходы на задержку | Накладные расходы шлюза в 50 мс на LLM-вызов в 3 секунды незначительны. Накладные расходы в 500 мс уже заметны. Частота попаданий в кэш определяет ваши фактические затраты. |
| Управление и безопасность | Виртуальные ключи, бюджеты на ключ, allowlist моделей, журналы аудита, SSO | Это то, что отличает «мы знаем наши расходы на API» от «в прошлые выходные кто-то сжёг $5,000, и мы не знаем, кто». |
| Модель ценообразования | Наценка за токен против фиксированной подписки против расчёта по объёму | Наценка за токен растёт с масштабом. Фиксированное ценообразование становится дешевле по мере роста. Знайте, по какой модели вы работаете. |
| Экосистема и документация | Поддержка SDK, широта интеграций, качество документации, сообщество | Лучший шлюз бесполезен, если ваша команда не может настроить логику повторов, не читая исходный код. |
| Корпоративная готовность | SOC 2, HIPAA, развёртывание в VPC, резидентность данных, SLA | Не подлежит обсуждению для регулируемых отраслей. Неактуально для стартапов на стадии прототипа. Ни одна оценка не подходит всем командам. |
Каждая платформа оценивается от 1 до 5 по каждому измерению. Эти оценки отражают требования продакшн-уровня — а не списки маркетинговых функций.
Оценка 3 означает «работает, но с оговорками». Оценка 5 — «лучший в классе, без значимых ограничений».
Анализ по платформам
OpenRouter
Питч: «400+ моделей, один API-ключ, ноль операций».
OpenRouter — точка входа по умолчанию для разработчиков, исследующих мультимодельный доступ. Регистрация, получение ключа, изменение base_url — quickstart OpenRouter проведёт вас через это — и у вас есть доступ ко всем основным моделям через унифицированный OpenAI-совместимый endpoint.
Бесплатный тариф включает 35+ моделей. Поддержка BYOK (bring your own key) позволяет маршрутизировать через OpenRouter, используя собственные аккаунты провайдеров.
Ключевые сильные стороны: самое быстрое время до первого вызова среди всех платформ. Каталог моделей действительно широк — если у модели есть API, OpenRouter её, скорее всего, поддерживает.
Модель оплаты по мере использования означает отсутствие авансовых обязательств. Бесплатный тариф достаточно щедр для реального прототипирования.
Критические ограничения: только хостинг — нет самохостинга, нет VPC-деплоя, нет изолированной (air-gapped) опции. Нет нативной поддержки протокола Anthropic — модели Claude работают через OpenAI-совместимую трансляцию, которая срезает thinking-блоки и ухудшает производительность tool-use. Нет встроенных guardrails — нет редактирования PII, нет блокировки prompt-injection в пути запроса.
Говернанс уровня разработчика — только скоупинг на уровне API-ключа, без аудиторских следов с привязкой к пользователю. Комиссия 5.5% на покупку кредитов (минимум $0.80) накапливается при масштабировании: при $10,000/мес расходов на API вы платите $550/мес OpenRouter. Это стоимость самохостинг-инстанса LiteLLM на выделенном сервере.
Лучше всего подходит: соло-разработчикам и небольшим командам, которым нужно быстро экспериментировать со многими моделями. Самый быстрый путь от «хочу попробовать Claude Opus» до «я получил ответ». Не подходит для регулируемых продакшн-нагрузок.
Оценка: Protocol 2 | Caching 3 | Governance 2 | Pricing 3 | Ecosystem 4 | Enterprise 1
LiteLLM
Питч: «MIT open-source. 100+ провайдеров. Вы контролируете всё».
LiteLLM — де-факто стандартный open-source LLM-прокси. Это Python-сервер, который вы разворачиваете на собственной инфраструктуре — Docker, Kubernetes или bare metal. Он предоставляет OpenAI-совместимый endpoint, маршрутизирующий к 100+ провайдерам.
Open-source версия включает virtual keys, бюджеты по командам, отслеживание расходов, семантическое кэширование, ретраи с fallback и MCP-шлюз — функции, за которые многие управляемые платформы берут деньги.
Ключевые сильные стороны: полный контроль. Ваши промпты никогда не покидают вашу инфраструктуру. Virtual keys с бюджетами по пользователям и allowlist моделей бесплатны и open-source — не спрятаны за корпоративным тарифом.
Проект LiteLLM имеет 53K+ звёзд на GitHub и поддерживает 100+ провайдеров. Семантическое кэширование бесплатно в OSS.
Поддержка MCP-шлюза означает, что ваши MCP-серверы работают с любой моделью через LiteLLM. Python-нативность — если ваша команда уже использует Python, интеграция тривиальна.
Критические ограничения: только рантайм Python/Uvicorn — если ваша инфраструктура работает на Go или Node, вы добавляете Python-сервис в свой стек. Ключевые функции (бюджеты, virtual keys, отслеживание расходов) требуют PostgreSQL — это задокументировано, но легко упустить при первой настройке. Нет полированного UI — конфигурация через YAML и переменные окружения, что нормально для DevOps-команд, но раздражает менее техничных пользователей.
Нет управляемого VPC-продукта — если вы хотите преимуществ LiteLLM без самохостинга, нужен сторонний управляемый сервис. Лицензия — BSL 1.1, а не чистый Apache 2.0 — у open-source версии есть ограничения использования, которые имеют значение при очень большом масштабе.
Лучше всего подходит: Python-ориентированным командам с DevOps-компетенциями, которые хотят полный контроль и нулевую наценку за токен. Набор функций OSS действительно щедр — можно запустить продакшн-шлюз, не заплатив ни цента за ПО. Вы платите за инфраструктуру, что при умеренном масштабе (<100 млн токенов/мес) составляет $50–200/мес на выделенном сервере.
Оценка: Protocol 3 | Caching 5 | Governance 4 | Pricing 5 | Ecosystem 3 | Enterprise 3
Portkey
Питч: «1,600+ моделей, 20+ guardrails, корпоративное управление».
Portkey — самый насыщенный функциями управляемый шлюз. Каталог моделей — широчайший в индустрии: 1,600+ вариантов моделей от 250+ провайдеров.
Библиотека guardrails включает 20+ готовых контент-фильтров, редактирование PII и обнаружение prompt-injection. Слой управления предоставляет virtual keys с бюджетами на ключ, лимитами, allowlist моделей и аудиторскими следами с привязкой к пользователю.
Ключевые сильные стороны: широта. Если модель существует, Portkey её поддерживает. Библиотека guardrails — самая полная среди управляемых шлюзов.
Open-source шлюз на Apache 2.0 означает, что вы можете самохостить ядро маршрутизации, используя управляемый control plane для управления, — гибридная модель, которую не предлагает ни одна другая платформа. Дашборд наблюдаемости предоставляет отслеживание затрат, задержки и ошибок по запросам из коробки.
Критические ограничения: лучшие функции за платным барьером. SSO, VPC-деплой, семантическое кэширование и гранулярный RBAC — только на корпоративном тарифе — ценообразование индивидуальное и обычно начинается выше $500/мес. Глубина оценки промптов меньше, чем у специализированных eval-платформ.
Control plane закрытый — если Portkey ляжет, ваш шлюз всё равно продолжит маршрутизировать трафик (потому что data plane open-source), но вы потеряете управление конфигурацией и наблюдаемость до восстановления.
Лучше всего подходит: командам, которым нужны корпоративные функции управления (SSO, RBAC, аудиторские следы) и самый широкий каталог моделей. Особенно силён для организаций, которым нужны content guardrails на уровне шлюза — 20+ готовых фильтров сокращают объём кастомного middleware, который вам нужно писать.
Оценка: Protocol 3 | Caching 4 | Governance 5 | Pricing 2 | Ecosystem 5 | Enterprise 5
TokSpan
Питч: «Нативная мультипротокольность. Глобальный доступ. Создан для того, где вы находитесь».
TokSpan построен под конкретную проблему, которую остальные три платформы решают не полностью: разработчикам нужна нативная протокольная поддержка OpenAI, Anthropic и Gemini — и доступ к ним из любой точки, с платёжными методами, работающими там, где они живут. Платформа обеспечивает нативный сквозной проход протокола, то есть extended thinking, tool use и computer use у Claude работают без потери при трансляции. Глобальная сеть оптимизирована для низколатентного доступа из регионов с высокой задержкой до шлюзов на базе US-West.
Отличия: нативная поддержка протокола Anthropic — установите ANTHROPIC_BASE_URL на TokSpan, и Claude Code, Cursor и другие нативные для Anthropic инструменты работают без обходных путей. Региональная оптимизация сети — узлы инфраструктуры в Азии, Европе и Америке снижают задержку для разработчиков вне US-West.
Гибкие способы оплаты — кредитные карты, PayPal и другие — с ценообразованием на основе объёма и без наценки за токен.
Ограничения: платформа новее остальных трёх — меньше сторонних интеграций и меньше сообщество. Количество моделей меньше, чем у OpenRouter и Portkey (фокус на качество, а не количество — модели, которые разработчики реально используют в продакшне). Корпоративные функции ещё созревают.
Лучше всего подходит: командам, которые зависят от инструментов экосистемы Claude и нуждаются в нативной поддержке протокола Anthropic. Разработчикам, которым нужны гибкие платёжные опции и многрегиональная доступность. Командам, которые хотят управляемую платформу с гибкими платёжными опциями и глобальным охватом сети без наценки за токен.
Оценка: Protocol 5 | Caching 4 | Governance 4 | Pricing 4 | Ecosystem 3 | Enterprise 3
Прямое сравнение (по состоянию на июль 2026 года)
| Измерение | OpenRouter | LiteLLM | Portkey | TokSpan |
|---|---|---|---|---|
| Поддержка протоколов | 2 | 3 | 3 | 5 |
| Кэширование и производительность | 3 | 5 | 4 | 4 |
| Управление и безопасность | 2 | 4 | 5 | 4 |
| Модель ценообразования | 3 | 5 | 2 | 4 |
| Экосистема и документация | 4 | 3 | 5 | 3 |
| Корпоративная готовность | 1 | 3 | 5 | 3 |
| Итого (без взвешивания) | 2.5 | 3.8 | 4.0 | 3.8 |
Как читать эти оценки: они невзвешенные, потому что важные измерения зависят от вашего контекста. Стартапу не важна корпоративная готовность — ему важны модель ценообразования и поддержка протоколов. Медицинская компания ставит корпоративную готовность и управление выше всего.
Используйте оценки как отправную точку, а не как окончательный ответ.
Сравнение TCO на 100 миллионов токенов в месяц — типичный объём SaaS среднего этапа:
| Платформа | Стоимость инференса | Комиссия платформы | Инфраструктура | Итого/мес |
|---|---|---|---|---|
| OpenRouter | ~$2,000 | ~$110 (5.5%) | $0 | ~$2,110 |
| LiteLLM (самохостинговый) | ~$2,000 | $0 | ~$150 | ~$2,150 |
| Portkey (Pro) | ~$2,000 | $99+ | $0 | ~$2,099+ |
| TokSpan | ~$1,800* | $0 наценка | $0 | ~$1,800 |
*Включены ставки провайдеров, согласованные по объёму.
При таком масштабе комиссии платформы не доминируют в итоге. Важнее другое: надёжность (работает ли шлюз?), поддержка протоколов (работают ли ваши функции Claude?) и операционные издержки (сколько часов ваша команда тратит на управление шлюзом?). Эти затраты скрыты, но реальны — самохостинг-инстанс LiteLLM экономит $110/мес комиссий, но стоит 4–8 часов/мес DevOps-времени.
Разбивку затрат по каждой модели для всех основных провайдеров смотрите в нашем сравнении цен LLM API 2026.
Накладная задержка — измеренное время обработки прокси, без инференса LLM:
| Платформа | Медиана | p95 |
|---|---|---|
| OpenRouter | 180ms | 450ms |
| LiteLLM (самохостинговый) | 15ms | 45ms |
| Portkey | 90ms | 220ms |
| TokSpan | 65ms | 160ms |
Самохостинг LiteLLM имеет пренебрежимо малую накладную, потому что работает на вашей инфраструктуре. Региональная оптимизация сети TokSpan видна в p95 — разработчики вне US-West видят более низкую хвостовую задержку.
Фреймворк принятия решений
По типу команды:
-
Соло-разработчик, прототипирование: OpenRouter. Быстрейший старт, бесплатный тариф покрывает эксперименты, нет инфраструктуры для управления. Переходите на другое, когда выйдете в продакшн.
-
Python-команда с DevOps-компетенциями: LiteLLM. Полный контроль, нулевая наценка за токен, virtual keys и бюджеты в OSS. Вы обмениваете DevOps-время на комиссии платформы — при умеренном масштабе это того стоит.
-
Организация с жёсткими требованиями комплаенса: Portkey. Сильнейшие функции управления, широчайшая библиотека guardrails и корпоративные сертификаты соответствия. Корпоративная цена оправдана, если требования аудита не подлежат обсуждению.
-
Глобальные команды: TokSpan. Нативный протокол Anthropic, региональная оптимизация сети и консолидированный биллинг. Создан для проблемы, которую остальные три платформы решают не полностью.
По основной потребности:
- Широчайший каталог моделей — Portkey (1,600+ вариантов)
- Наименьшая совокупная стоимость — LiteLLM (без наценки, вы контролируете инфраструктуру)
- Самое быстрое время до первого вызова — OpenRouter (регистрация, ключ, работа)
- Лучшая поддержка Claude/нативных протоколов — TokSpan (нативный passthrough Anthropic)
- Лучшее корпоративное управление — Portkey (SSO, RBAC, аудит, guardrails)
- Лучшее глобальное покрытие — TokSpan (глобальная сеть + гибкие платежи)
Правильный шлюз — не тот, у которого самый высокий балл. Тот, который решает вашу реальную проблему. Если вы тратите 8 часов в месяц на управление дашбордами провайдеров, любой из этих четырёх окупится восстановленным временем разработчиков в первую же неделю.
После выбора шлюза правила кастомной маршрутизации позволяют определить, какие модели обрабатывают какие типы запросов — ключевая возможность для продакшн-мультимодельных конфигураций.
FAQ
В чём разница между API-шлюзом и API-прокси?
Шлюз выполняет трансляцию протоколов + управление + наблюдаемость + отказоустойчивость. Простой прокси пересылает запросы. Шлюзы — продакшн-инфраструктура.
Прокси — инструменты разработки. Если вам нужны бюджеты по пользователям, allowlist моделей или аудиторские логи, вам нужен шлюз.
Безопасен ли OpenRouter для продакшна?
Для нерегулируемых нагрузок — да. У него нет SOC 2, HIPAA, VPC-деплоя и встроенных guardrails — это дисквалифицирует для здравоохранения, финансов и корпоративного комплаенса. Для таких случаев используйте самохостинг LiteLLM или управляемые Portkey/TokSpan с соответствующими сертификатами.
Сколько задержки добавляет шлюз?
Управляемые шлюзы: медиана 50–200 мс, p95,150–250 мс. Самохостинг LiteLLM: медиана 10–20 мс. Влияние на типичный ответ LLM за 2–3 секунды — 2–10%.
В большинстве приложений пользователи не заметят. В real-time голосе или чате разница между накладной 15 мс и 200 мс значима — самохостите или выбирайте платформу с региональной оптимизацией.
Можно ли сменить шлюз позже?
Да, если вы строили по паттерну OpenAI SDK — меняете base_url. Если вы используете нативные функции протокола Anthropic (Claude Code, Cursor с Anthropic-native), проверьте до миграции, поддерживает ли целевой шлюз их. Протокольный лок — настоящий риск миграции, а не вендорный лок.
Нужны ли мне ещё отдельные аккаунты провайдеров?
Не с OpenRouter или TokSpan — они предоставляют доступ к моделям без ваших аккаунтов провайдеров. LiteLLM и Portkey требуют собственных ключей провайдеров, но управляют ими через единый прокси.
Компромисс: платформы без аккаунтов быстрее стартуют. Платформы с bring-your-own-key дают прямые отношения с провайдерами и возможность договариваться о корпоративных скидках.
Только в июне 2026 года запущен 121 продукт шлюзов. OpenRouter имеет широту каталога. LiteLLM — OSS-сообщество и нулевую экономику за токен.
Portkey — корпоративное управление и каталог на 1,600 моделей. TokSpan — нативная протокольная история, на которую полагаются пользователи Claude Code и Cursor. Каждый выигрывает свой срез одного и того же рынка.
Но пространство шлюзов не выдержит 121 конкурента — вероятно, даже не дюжину. Волна консолидации ещё не началась.
Когда она придёт, кто кого поглотит? И какие разработчики проснутся перед миграционным дедлайном, которого не ожидали?
Найдите свой шлюз — оценка по 6 измерениям, калькулятор TCO и руководство по выбору под ваш профиль команды.