ИИтог

На GitHub выложили litelm, LiteLLM без прокси и кэша, всего ~2900 строк кода

инструментыРедакция ИИтогHacker News🔥56Рейтинг ИИтог56Влияние50Новизна40Релевантность85Неожиданность30Участники20Достоверность78
На GitHub выложили litelm, LiteLLM без прокси и кэша, всего ~2900 строк кода

На GitHub опубликован litelm, библиотека, которая переписывает с нуля только основную функцию известного инструмента LiteLLM: маршрутизацию вызовов языковых моделей между провайдерами и перевод сообщений в единый формат. По описанию нового проекта, у самой LiteLLM это ядро зарыто под более чем 100 тысячами строк кода прокси-сервера, слоя кэширования, учёта расходов и десятков функций, которыми пользуется не каждый. litelm вырезает именно этот путь вызова, маршрутизацию моделей, перевод сообщений, потоковую передачу, вызов инструментов и эмбеддинги, и ничего сверх этого: ни класса Router, ни прокси, ни кэша. Весь код уместился примерно в 2900 строк и опирается всего на две зависимости, библиотеки openai и httpx.

Устанавливается litelm по частям: базовый набор подтягивает только openai и httpx, расширение litelm[anthropic] добавляет SDK Anthropic, litelm[bedrock], библиотеку boto3 для AWS Bedrock, а litelm[all] ставит все зависимости сразу. По заявлению мейнтейнера, API дословно повторяет LiteLLM, те же имена функций, те же аргументы, те же типы ответов, так что переход описан как замена импорта библиотеки без переписывания остального кода. litelm маршрутизирует вызовы к 19 провайдерам по синтаксису «провайдер/модель» и работает с любым OpenAI-совместимым сервером через параметр api_base, в качестве примеров названы vLLM, Ollama и LM Studio. У каждой функции есть асинхронный вариант (acompletion, aembedding, aresponses, atext_completion), поддерживаются потоковая генерация и вызов инструментов, а ошибки всех провайдеров сведены в собственную иерархию исключений, например, ContextWindowExceededError при переполнении контекста, RateLimitError при упоре в лимит запросов и AuthenticationError при неверном ключе.

Проект открыто говорит о своём происхождении. По словам мейнтейнера, направление и решения, человека, а писали код ИИ-инструменты: основную часть, Claude Code на Claude Opus 4.6/4.7, а всё, что написано начиная с 14 мая 2026 года, инструмент Pi на базе GPT-5.5. При этом отдельно оговорено: заявления о совместимости опираются на тесты и ручную проверку мейнтейнера, а не на то, что код писала ИИ-модель.

11 сентября 2026 года мейнтейнер опубликовал отдельное заявление о проверке совместимости: изменения маршрутизации и форматирования в LiteLLM просмотрели в диапазоне от коммита 649eb2d до 9a715df2, аудит разобрал 360 коммитов, затрагивающих основной путь выполнения, сверился с тестами апстрима на предмет значимого поведения и закрыл найденные расхождения по принципу «сначала тест». По итогам: из локальных тестов самого litelm 262 пройдены и 55 пропущены; все 45 доступных лайв-тестов по провайдерам пройдены; все 10 смоук-тестов интеграции с DSPy пройдены; относительно урезанного набора тестов LiteLLM на коммите 9a715df2 пройдено 75 портированных тестов, и, по словам мейнтейнера, ни падений во время выполнения, ни несовпадений в проверках на этом срезе больше нет. Отдельно названа проверенной поддержка DSPy по всем семи сценариям выполнения, Predict, CoT (цепочка рассуждений), типизированные сигнатуры, потоковый вывод, эмбеддинги, вызов инструментов и вывод с несколькими выходами. При этом сам мейнтейнер прямо ограничивает вывод: заявление подтверждает только заявленную поверхность litelm, маршрутизацию, форматирование и DSPy, а не полную совместимость с LiteLLM. Статус проекта, «альфа»; лайв-тесты идут по собственным ключам API из файла .env.test и по умолчанию не запускаются.

Ключевые факты

  • litelm воспроизводит только маршрутизацию вызовов и перевод сообщений LiteLLM: около 2900 строк кода и всего 2 зависимости (openai, httpx) вместо более чем 100 тысяч строк прокси-сервера, кэша и учёта расходов у LiteLLM.
  • API заявлен идентичным LiteLLM, те же функции, аргументы и типы ответов; поддержаны 19 провайдеров, любой OpenAI-совместимый сервер через api_base, асинхронные версии всех функций, потоковая генерация, вызов инструментов и эмбеддинги.
  • Код написан с помощью ИИ: сначала в Claude Code на Claude Opus 4.6/4.7, а с 14 мая 2026 года, через инструмент Pi на GPT-5.5; по словам мейнтейнера, заявления о совместимости опираются на тесты и ручную проверку, а не на факт ИИ-авторства.
  • 11 сентября 2026 года мейнтейнер опубликовал аудит совместимости: 360 разобранных коммитов LiteLLM, 262 пройденных и 55 пропущенных собственных тестов, 45 из 45 лайв-тестов по провайдерам, 10 из 10 смоук-тестов DSPy и 75 портированных тестов против урезанной базы LiteLLM.
  • Заявление прямо ограничено заявленной поверхностью litelm, маршрутизацией, форматированием и DSPy, а не полной совместимостью с LiteLLM; статус проекта, «альфа».

Почему это важно

LiteLLM, известный опен-сорсный инструмент для вызова разных провайдеров языковых моделей через единый API. По описанию нового проекта litelm, у LiteLLM это ядро, маршрутизация вызовов и перевод сообщений, обросло прокси-сервером, кэшированием, учётом расходов и другими функциями, из-за чего весь вспомогательный код тянет больше 100 тысяч строк, хотя нужен он не каждому. litelm показывает, что тот же основной функционал воспроизводим примерно в 2900 строках на двух зависимостях, конкретный пример того, что для многих задач вокруг вызова LLM достаточно узкого среза функциональности без всей обвязки вокруг неё. Отдельно заметен формат самого релиза: вместо привычного маркетингового обещания бесшовной замены, датированное заявление о совместимости с перечнем проверенных коммитов и тестов; для небольшого проекта с открытым кодом, значительная часть которого написана ИИ-инструментами, это необычно высокая планка отчётности.

Кому это важно

В первую очередь, разработчикам, которые уже используют LiteLLM исключительно как маршрутизатор и переводчик форматов между провайдерами, без прокси-сервера, кэша и учёта расходов, и для которых лишний вес зависимости мешает, при аудите кода, сборке образа или просто установке. Полезно и тем, кто строит поверх DSPy: для этого фреймворка отдельно заявлена и протестирована работа всех семи сценариев выполнения. Не подходит тем, кому нужны именно те функции LiteLLM, которых в litelm нет, прокси-сервер как отдельный процесс, кэширование ответов или встроенный учёт расходов.

Как это применить

Установка, базовый пакет litelm тянет только openai и httpx; litelm[anthropic] добавляет SDK Anthropic, litelm[bedrock], boto3 для AWS Bedrock, litelm[all] ставит всё сразу. Модель указывается строкой «провайдер/модель» (например, «openai/gpt-4o» или «groq/llama-3.1-70b-versatile»), ключи провайдеров задаются переменными окружения или параметром api_key. Любой OpenAI-совместимый сервер, vLLM, Ollama, LM Studio, подключается через параметр api_base. Для обычного и потокового ответа, эмбеддингов и вызова инструментов есть отдельные функции, у каждой, синхронная и асинхронная версии. По заявлению мейнтейнера, переход с LiteLLM сводится к замене импорта библиотеки без переписывания остального кода, но это заявление автора проекта, а не независимо подтверждённый факт.

Можно ли доверять

Заявление о совместимости от 11 сентября 2026 года, это проверка самого мейнтейнера, а не независимый аудит: он же писал код, он же формулировал методику, он же приводит цифры, 360 разобранных коммитов LiteLLM, 262 пройденных и 55 пропущенных собственных тестов, 45 из 45 лайв-тестов по провайдерам, 10 из 10 смоук-тестов DSPy, 75 портированных тестов против урезанной базы LiteLLM на коммите 9a715df2. Сам мейнтейнер прямо ограничивает вывод: заявление подтверждает только заявленную поверхность litelm, маршрутизацию, форматирование и DSPy, а не полную совместимость с LiteLLM целиком. В репозитории отдельно упомянуты ещё 49 «быстрых контрактных тестов» апстрима, источник не уточняет, тот ли это набор, что и 75 портированных, или другой. Лайв-тесты идут по собственным ключам API и по умолчанию не запускаются, так что результат «45 из 45», это прогон самого мейнтейнера, а не то, что подтверждается при обычной установке. Независимых сообщений об использовании litelm в проде или об одобрении со стороны команды самой LiteLLM в источнике нет.

Риски и подводные камни

Главный риск, статус «альфа»: даже по словам мейнтейнера, заявление о совместимости покрывает не всю LiteLLM, а только маршрутизацию, форматирование и DSPy-поверхность litelm, и на остальных участках расхождения не проверялись. Прокси-сервера, кэша и учёта расходов в litelm нет вовсе, тем, кто использовал эти функции LiteLLM, при переходе придётся либо отказаться от них, либо реализовать отдельно. Лицензия проекта в источнике не названа, как и конкретный номер версии за пределами статуса «альфа», это стоит прояснить до использования в рабочем коде. Все цифры о тестах и покрытии, из одного источника, самого мейнтейнера; сравнения производительности или задержек между litelm и LiteLLM источник не даёт, так что меньший объём кода и число зависимостей не означают автоматического выигрыша в скорости.