Чем заменить LiteLLM: Bifrost, Portkey или aisuite

Чем заменить LiteLLM: Bifrost, Portkey или aisuite. Выбор между Bifrost, Portkey и aisuite решается одним вопросом: нужен отдельный общий HTTP gateway или библиотека внутри Python-процесса. Bifrost и Portkey OSS — самостоятельные self-hosted сервисы с OpenAI-совместимым endpoint. aisuite — Python-библиотека, которая живёт внутри вашего процесса и общего HTTP endpoint не создаёт.

Граница процесса: библиотека или gateway

Первый шаг — определить, где живёт ваш слой доступа к моделям. Если это один Python-ноутбук или один сервис, и отдельный HTTP-сервис вам не нужен, речь идёт о библиотеке. Если у вас несколько клиентов — Python backend и JavaScript backend — и нужен один общий endpoint, речь идёт о gateway.

Bifrost в своём README описывается как высокопроизводительный AI gateway, объединяющий доступ к 23+ провайдерам через единый OpenAI-совместимый API. Запуск: docker run -p 8080:8080 maximhq/bifrost, Web UI на порту 8080, вызов через POST /v1/chat/completions. Отдельно проект публикует Go SDK для прямой интеграции.

Portkey в README на GitHub описывает AI Gateway как лёгкое open-source решение для маршрутизации к 1600+ моделям. Локальный запуск: npx @portkey-ai/gateway, gateway слушает http://localhost:8787/v1, консоль доступна на http://localhost:8787/public/.

aisuite в README определяется как lightweight Python library с двумя слоями: Chat Completions API и Agents API. Базовый pip install aisuite не включает SDK провайдеров; для примера ниже используйте документированный вариант pip install 'aisuite[all]'. Вызов идёт через import aisuite as ai, ai.Client(), client.chat.completions.create(model="provider:model-name", messages=...).

Различие принципиальное. Bifrost и Portkey принимают HTTP-запросы от любого клиента. aisuite работает как импортируемая библиотека: JavaScript-клиент через неё к моделям не обратится. Если у вас только Python и централизованный endpoint не нужен, gateway добавляет лишний сервис в эксплуатацию.

Таблица трёх продуктов

Таблица отвечает на вопрос «что именно ставится». Для Bifrost и Portkey вы поднимаете сервис и дальше его эксплуатируете. Для aisuite вы добавляете зависимость в Python-проект. В этом разборе выбран ручной маршрут настройки: адреса, ключи, имена моделей и нужные правила сопоставляются с форматом целевого инструмента. Возможности автоматического импорта отдельных конфигураций здесь не проверялись.

Учебный вход A: один Python-ноутбук

Разберём условный пример. Вход A: один Python-ноутбук, отдельный HTTP-сервис запрещён, централизованный endpoint не нужен, Python-вызовы менять можно.

При таких требованиях Bifrost Gateway и Portkey OSS Gateway исключаются — оба предполагают отдельный сервис. Остаётся aisuite Chat Completions. Вы переписываете вызов на формат библиотеки:

import os
import aisuite as ai

client = ai.Client({
    "openai": {"api_key": os.environ["OPENAI_API_KEY"]},
})

response = client.chat.completions.create(
    model="openai:gpt-4o",
    messages=[{"role": "user", "content": "Кратко объясни, что такое gateway."}],
)
print(response.choices[0].message.content)

Пример читает OPENAI_API_KEY из переменной окружения и делает один вызов OpenAI; ключ другого провайдера для него не требуется. Идентификатор модели строится по документированному формату <provider>:<model-name>. После подготовки SDK и ключа нужного провайдера его выбирают изменением этой строки.

Проверка результата: если для входа A вы получили ровно aisuite, логика выбора сработала. Если в ответе появился gateway, значит требование «отдельный HTTP-сервис запрещён» нарушено. Это проверка логики выбора.

Учебный вход B: существующий LiteLLM Proxy

Вход B: у вас уже есть LiteLLM Proxy. Python backend и JavaScript backend обращаются к нему обычным OpenAI-совместимым HTTP chat-completions клиентом. Прямых вызовов litellm Python SDK в коде нет. Нужен один общий HTTP endpoint, отдельный сервис обслуживать разрешено. Разрешено явно менять base_url, API key, provider headers и настроенное имя модели, метод обычного chat-completions вызова сохраняется.

При таких требованиях aisuite в одиночку исключается: библиотека Python общий HTTP endpoint не создаёт, а JavaScript-клиенту нужен именно он. Проходят оба gateway — Bifrost и Portkey OSS. Это честный shortlist из двух вариантов.

Между двумя прошедшими gateway этот набор требований победителя не определяет. Чисел скорости или стоимости из пройденного теста у нас нет, поэтому подменять выбор рейтингом производительности нельзя. Дальше решение принимает команда по своим критериям: привычный стек, требования к консоли, наличие нужного провайдера в списке.

Проверка результата: для входа B в ответе должны стоять оба HTTP gateway. Если остался один или появилась библиотека, логика выбора нарушена.

Portkey: OSS main, 2.0 pre-release и hosted

Portkey требует аккуратности в разделении трёх состояний. В README на GitHub отдельно помечено: Gateway 2.0 находится в статусе Pre-Release, ядро enterprise gateway сливается в open-source с релизом 2.0, попробовать можно на ветке 2.0.0. Это отдельная ветка, отдельное состояние кода.

Второе разделение — OSS main и hosted/enterprise. В README функции помечены звёздочкой, и сноска прямо указывает: доступны в hosted и enterprise версиях. К таким функциям относятся, например, semantic caching, provider optimization и prompt template management. Читайте пометки в README, прежде чем планировать функцию в self-hosted развёртывании.

Третье — enterprise-развёртывание. README описывает enterprise-версию как набор возможностей для org management, governance и security, со ссылкой на сравнение функций. Архитектура private cloud deployment описана отдельно.

Платные и бесплатные лимиты в этом разборе не приводятся: цифр тарифов в источниках нет. Практический вывод: определите, какое именно состояние Portkey вы ставите — OSS main, ветку 2.0 pre-release или hosted/enterprise, — и сверяйте доступность функций по пометкам в README этого состояния.

Ручной перенос конфигурации

Готового миграционного скрипта из LiteLLM в любой из трёх вариантов в этом разборе нет, и обещать его мы не будем. Перенос делается вручную, по шагам.

Порядок для Bifrost Gateway. Поднимите сервис: docker run -p 8080:8080 maximhq/bifrost. Откройте Web UI на порту 8080. Заново заведите ключи и provider settings. Проверьте вызов через POST /v1/chat/completions. Отдельно выпишите нужные алиасы, бюджеты и fallback из исходного LiteLLM YAML; проверьте их доступность и эквивалентную настройку в выбранном развёртывании Bifrost.

Порядок для Portkey OSS Gateway. Запустите npx @portkey-ai/gateway. Gateway слушает http://localhost:8787/v1, консоль — на /public/. Настройте выбор провайдера и Portkey Configs. Правила из model_list и router_settings исходного LiteLLM нужно сопоставить с возможностями выбранной версии Portkey и настроить доступные аналоги; один объект Configs не доказывает эквивалентность всех исходных правил.

Порядок для aisuite. Установите пакет вместе с нужными SDK провайдеров; документированный вариант pip install 'aisuite[all]' включает все такие зависимости. Задайте ключи только используемых провайдеров, перепишите Python-вызов и идентификатор модели на формат provider:model-name.

Смена base_url сама по себе не переносит model alias, виртуальные ключи, бюджет или правила маршрутизации. Эти сущности заводятся заново в целевом инструменте.

Частые вопросы

Чем заменить LiteLLM, если нужен один общий endpoint для Python и JavaScript?

Bifrost Gateway и Portkey OSS Gateway. Оба поднимаются как отдельный self-hosted HTTP-сервис и принимают OpenAI-совместимые запросы от любого клиента. aisuite для этой задачи не подходит: это Python-библиотека внутри процесса, общего HTTP endpoint она не создаёт.

Подходит ли aisuite как замена LiteLLM Proxy?

Как замена HTTP Proxy — нет. aisuite работает как импортируемая библиотека: вызов идёт через ai.Client() и client.chat.completions.create(). Если у вас один Python-процесс и централизованный endpoint не нужен, библиотека закрывает задачу. Если endpoint нужен нескольким клиентам, выбирайте gateway.

Переносится ли конфигурация LiteLLM автоматически?

В этом разборе показан ручной маршрут, автоматический перенос не проверялся. Отдельно настройте адрес и ключи, сопоставьте имена моделей, проверьте эквивалентность правил и доступность функций в выбранном развёртывании. Простая смена base_url сама по себе не переносит всю конфигурацию LiteLLM.

Какую версию Portkey ставить?

Зависит от задачи. OSS main — открытый gateway, запускается через npx @portkey-ai/gateway. Ветка 2.0.0 помечена в README как Pre-Release. Hosted и enterprise версии дают функции, помеченные звёздочкой. Сверяйте пометки в README выбранного состояния.

Что делать, если требования не определяют победителя между Bifrost и Portkey?

Оставить оба в shortlist. Набор требований входа B проходят оба gateway, а чисел скорости и стоимости из пройденного теста нет. Выбор делайте по своим критериям: стек команды, нужные провайдеры, требования к консоли и наблюдаемости.