open source

Если вы или ваша команда уже используете LLM или планируете интегрировать в проект, то наверняка у вас возникал вопрос, как лучше и красивее написать такой интерфейс, который мог бы общаться с разными моделями. И на такой вопрос уже есть ответ.Теперь можно сэкономить время разработки и управлять нейросетями в одном месте. Поможет в этом простой инструмент LiteLLM, про который далее и пойдет речь. Для чего нужен LiteLLM LiteLLM — это прокси-шлюз (gateway) для LLM, который умеет общаться со 100+ LLM-провайдерами, переводя все их ответы в формат OpenAI API. Это значит, что можно написать один раз код под паттерн chat/completions, а дальше переключаться в любой момент на нужную модель. Локально, например, можно установить Llama через Ollama, и обращаться к ней, а на продакшене использовать любую облачную модель, например GPT-4o, вообще не меняя код. Вкусно же? Очень даже.Этот инструмент также содержит в себе такие полезные функции, как отслеживание расходов, установка лимитов на бюджет по пользователям или группам пользователей, fallback-механизмы моделей, логирование и другие операционные функции. Архитектура LiteLLM: жизненный цикл запроса от пользователя до вызова модели. Источник. На практике LiteLLM особо проявляется, когда появляется необходимость в использовании нескольких нейросетей. Если у вас несколько микросервисов, которые могут обращаться каждый к своей модели, этот инструмент поможет унифицировать запросы и как-то следить за всем этим. Как запустить LiteLLM Проще и быстрее всего развернуть LiteLLM в виде Docker-контейнера — этот способ изолирует окружение и избавляет от ручной настройки Python-зависимостей. Для начала скачаем на сервер актуальный официальный образ шлюза из репозитория: Далее нужно создать конфиг со списком нейросетей. Для примера возьмем двух популярных провайдеров — Perplexity и Groq — и подключим по две модели от каждого. Здесь в model_list находится перечисление всех моделей, которые будут доступны в вашем инстансе LiteLLM. В litellm_settings перечислены параметры, которые применяются ко всем моделям в запросах. В router_settings находятся настройки роутера, которые описывают таймауты, запасные модели, количество попыток при ошибках и тому подобное. А general_settings — это уже настройки самого LiteLLM инстанса. LiteLLM сам знает, какие базовые адреса у провайдеров, но, если что-то изменится или вы захотите переопределить базовый адрес, то можно добавить api_base на том же уровне, что и api_key. Запуск производим через docker run следующим образом: После запуска можно попробовать сделать запрос через curl: В ответе получаем большой JSON, содержащий в себе контент ответа, использованное количество токенов и другую полезную информацию: Хорошо, LiteLLM поднят и базовые запросы на него проходят. Но в чем его главная суть? Она как раз в том, что можно написать один код, который будет работать под все модели. Даже если у ИИ-провайдеров будут разные схемы запросов и ответов, LiteLLM сам подгонит все под один формат. Тестируем возможности Для реализации этого на практике у LiteLLM есть библиотека на Python. Давайте протестируем ее и заодно проверим, как разные модели справляются с поиском актуальной информации. Для этого зададим им специфический вопрос о компании Selectel. Минимальный рабочий код выглядит следующим образом: Здесь импортируется функция completion из библиотеки LiteLLM, добавляется ключ для perplexity в переменные окружения, отправляется запрос и выводится ответ: Теперь можно просто поменять модель, например, на groq/gpt-oss и проверить, какой вывод будет при другой модели: Ответ не верный, но он есть, что говорит о том, что мы можем с легкостью переключаться между моделями в любое время, без необходимости править кучу кода. Хорошо, основную фишку разобрали, теперь пойдем дальше. Интерфейс Помимо работы через код, у LiteLLM есть встроенный веб-интерфейс. В нем можно смотреть расходы, логировать запросы и управлять группами пользователей. Чтобы UI заработал, необходимо подключить базу данных для хранения пользователей, иначе просто не сможем залогиниться. Для этого необходимо в general_settings в конфиге добавить переменную DATABASE_URL. И перезапустить контейнер с пробросом переменной: Вот и все. Теперь, если перейти по адресу localhost:4000/ui, то увидим страницу логина. Тут сразу указаны дефолтные логин и пароль, будем использовать их, так как не переопределяли. После авторизации нас встречает страница со списком виртуальных ключей, пока она не интересна. Если перейти на вкладку Usage, то сразу видим учет расхода: На боковой панели слева также можно наблюдать остальные доступные инструменты, которыми можно пользоваться прямо из коробки. Например, установка лимита на бюджет, создание команд, распределение организаций и еще много полезных штук. Включаем кэширование запросов Раз уж мы заговорили про экономию бюджета, нельзя обойти стороной еще одну мощную возможность LiteLLM — кэширование. Это полезный инструмент, если приходится часто тестировать какой-то функционал с одинаковым промптом, и нет необходимости в разных ответах при одинаковых запросах. Для начала обновим конфиг LiteLLM, добавив в блок litellm_settings следующие параметры: Как видите, мы просто включили параметр cache и задали локальный тип хранения (cache_params) на 10 минут. Этого уже достаточно, чтобы кэширование начало работать. Теперь давайте наглядно проверим результат. Для этого мы слегка обновим наш Python-код, добавив отслеживание времени ответа от LiteLLM. Теперь, после ответа, будет выводиться время, за которое LiteLLM выдал ответ. При первом запуске скрипта системе нужно достучаться до провайдера, дождаться генерации текста и получить его обратно. У меня этот процесс занял почти 5 секунд: А второй раз запрос уже выполнился быстрее, и ответ был тот же. Это указывает на то, что кэширование работает и теперь при одинаковых запросах не будут расходоваться лишние токены. Стоит учесть, что для использования кэширования в продакшене рекомендуется подключать Redis. Для этого необходимо изменить cache_params в litellm_settings следующим образом: После обновления конфига необходимо просто перезапустить LiteLLM с переданными переменными окружения, и кэширование будет работать через Redis. Заключение Будем честны: ввязываться в ИИ-разработку и жестко привязываться к API одного вендора (тот самый Vendor Lock) — это технический долг, который вы берете на себя с первого же дня. Рынок штормит, провайдеры то и дело меняют схемы запросов, обновляют тарифы. В этом плане LiteLLM работает как локальный ИИ-роутер, который забирает на себя всю рутину с маршрутизацией, авторизацией через админку и экономией токенов через кэш. Архитектура вашего приложения остается чистой и независимой. Правда, когда дело доходит до продакшена, удобство open-source начинает требовать внимания. Вам придется самостоятельно администрировать Docker-контейнеры, следить за базой пользователей, настраивать и поддерживать кластер Redis для кэша, а главное — как-то решать проблемы (в том числе и с безопасностью) с оплатой зарубежных API-ключей. Если идея «единого окна» для сотен моделей вам близка, но тратить время команды на поддержку еще одного куска инфраструктуры не хочется, можно использовать готовый ИИ-роутер. В конце концов, задача разработчика — пилить крутые фичи для пользователей, а рутину с шлюзами и серверами интеграции вполне можно делегировать.