LiteLLM vs Kong AI Gateway
Оба поддерживают self-hosting, и оба построены по модели open-core. Что действительно решает: ваш шлюз — это LLM-шлюз или универсальный API-шлюз, который также умеет говорить с моделями?
LiteLLM и Kong AI Gateway сравнивают, потому что это два self-hosted варианта, которые чаще всего попадают в шорт-лист команд. Это программное обеспечение разного рода. LiteLLM — LLM-прокси: вся его поверхность — модели, провайдеры и OpenAI-compatible маршрутизация. Kong — универсальный API-шлюз (плагины, upstream, ограничение частоты для произвольного HTTP-трафика) с добавленными AI-плагинами. Это различие определяет каждую следующую строку ниже: протокольные точки входа, гранулярность управления и то, сколько вам придётся строить самостоятельно.
Три шлюза, пять критериев
Каждая из первых двух колонок — однострочное резюме соответствующей страницы сравнения. Колонка GateLLM — наша собственная позиция, а не оценка третьей стороны, — взвешивайте её соответственно.
| Критерий | LiteLLM | Kong AI Gateway | GateLLM |
|---|---|---|---|
| Развёртывание | Self-hosted OSS | Self-hosted OSS (+ управляемый Konnect) | Полностью self-hosted (Docker / Helm), без плоскости управления производителя |
| Основа счёта | Бесплатный OSS; Enterprise — по использованию | Бесплатный OSS; плагины только в Enterprise | Лицензия на экземпляр; без наценки на токены, без платы за место |
| Протокольные точки входа | С центром на OpenAI | OpenAI-compatible + AI-плагины | Четыре входа × четыре выхода (OpenAI / Anthropic / Gemini / DashScope) |
| Управление | SSO (лимит 5 пользователей) / RBAC в Enterprise | RBAC / SSO в Enterprise | SSO / SCIM / RBAC + ACL и лимиты бюджета на группу ключей |
| Независимость от производителя | Независимый (BerriAI) | Независимый (Kong Inc.) | Независимый (Fluxon LLC) |
Когда LiteLLM, когда Kong, когда ни один
Выбирайте LiteLLM, если трафик, которым вы управляете, — это только трафик моделей: маршрутизация по моделям, fallback между провайдерами и атрибуция затрат без изучения DSL плагинов, и вы готовы эксплуатировать Python-сервис. Это кратчайший путь от «вызывать многих провайдеров» к «вызывать многих провайдеров через один endpoint».
Выбирайте Kong, если вы уже используете Kong для обычного API-трафика. Повторное использование имеющегося шлюза — его плагинов, ограничения частоты, операционных runbook — обычно лучше, чем вводить второй шлюз только ради AI. AI-плагины — меньшая половина этого решения.
Ни один, если ваша реальная ситуация — один провайдер, одна команда и управляемый месячный счёт. Прямой вызов API провайдера проще любого из вариантов, и ни один шлюз не оправдывает своих операционных затрат, пока вам не понадобятся отказоустойчивость между провайдерами, атрибуция затрат по командам или средства контроля соответствия, которых провайдер дать не может.