# Четыре варианта собственного AI-шлюза: LiteLLM, Portkey, Kong и Agent Router

Редакционная подборка self-hosted AI gateways с проверенными источниками: варианты размещения, эксплуатация, лицензирование и методика выбора для своей инфраструктуры.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/top-self-hosted-ai-gateways/
Language: ru

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

Подборка проверена 1 ноября 2026 года. Порядок редакционный: от прямого сценария общего LLM-интерфейса к более широкой инфраструктуре управления трафиком. Это не рейтинг скорости. Открытый код, доступность локальной установки и корпоративная функциональность рассматриваются отдельно.

## LiteLLM и Portkey как варианты общего интерфейса

[LiteLLM Proxy](https://docs.litellm.ai/docs/simple_proxy) описан как self-hosted сервер для доступа к исполнителям. Его имеет смысл проверять, если нужны единые ключи, ограничения и маршруты для нескольких приложений. Расходы на базу, наблюдение и обновления зависят от выбранной архитектуры.

[Portkey Gateway](https://github.com/Portkey-AI/gateway) имеет официальный репозиторий и варианты самостоятельного запуска. Текущая документация использует обозначение Prisma AIRS AI Gateway. При оценке нужно фиксировать конкретную версию и не переносить весь набор управляемого предложения на любую локальную установку.

## Kong для общей API-инфраструктуры

[Kong AI Gateway](https://developer.konghq.com/ai-gateway/) рассматривает управление AI-трафиком в более широкой архитектуре. Он может быть интересен команде с существующими процессами доступа и политик. Самостоятельный data plane и способ управления им следует описывать отдельными элементами.

Проверьте состав поставки и лицензируемые функции. Название self-hosted не является обещанием бесплатной эксплуатации. Для выбора полезнее сопоставить необходимые правила и способность команды сопровождать их, чем искать самое длинное описание возможностей.

## Agent Router для инфраструктуры на Envoy

[Agent Router](https://theagentrouter.ai/docs/) — текущее название проекта, ранее известного как Envoy AI Gateway. Официальная страница прямо сообщает об изменении имени. Включаем оба обозначения, чтобы связать поисковый запрос с актуальным проектом, не придумывая изменения всех интерфейсов.

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

## Сравните одинаковый эксплуатационный сценарий

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

Отдельно нарисуйте путь данных. Локальный шлюз может отправлять запрос внешней модели, а журналы — в другой сервис. Поэтому утверждение о полном локальном размещении должно относиться ко всей схеме, а не только к месту запуска одного контейнера.

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

## Практические выводы

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

Далее полезны [OpenRouter и LiteLLM](/ru/journal/openrouter-vs-litellm/) и [затраты роутинга](/ru/journal/token-router-total-cost/).