▲

any-llm - 다양한 LLM 프로바이더를 위한 단일 인터페이스

 (github.com/mozilla-ai)
7P by xguru 8일전 | ★ favorite | 댓글 3개
  • Mozilla AI팀이 만든, 20개 이상의 LLM 프로바이더를 하나의 함수로 사용할 수 있는 Python 라이브러리
    • OpenAI, Anthropic, Google, Mistral, AWS Bedrock 등의 모델 교체 시 provider_id/model_id만 바꾸면 됨
  • 공식 프로바이더 SDK를 우선 활용해 호환성 문제를 최소화하며, 프록시/게이트웨이 서버를 별도로 설치할 필요가 없어 pip 설치 후 바로 사용할 수 있음
  • 개발자 친화적으로 완벽한 IDE 타입 힌트, 직관적 예외 처리, 커스텀 예외, 문서 및 빠른 가이드 제공
  • 경량화된 라우터로 프레임워크 비종속적이며, 별도 프록시/게이트웨이 서버 불필요(API Key만 있으면 바로 사용)
  • 기존 솔루션의 문제를 해결하며, 액티브한 유지보수 진행중 : Mozilla의 any-agent 등 실제 제품에 사용 중임
    • LiteLLM: 공식 SDK 대신 직접 구현 → 호환성/버그 우려가 있음
    • AISuite: 모듈러 구조지만 관리 및 타이핑 미흡
    • 프레임워크 종속형: 프로젝트별로 또다시 파편화
    • 프록시 전용: 별도 서버 필요, 복잡성 증가

관련 문서

▲
kaydash 7일전  [-]

LLM 프로바이더 별로 key를 관리해야할텐데.

답변달기
▲
GN⁺ 8일전  [-]
Hacker News 의견
  • 나는 LiteLLM이 공식 SDK가 아닌 공급자 인터페이스를 직접 구현한다고 해서 꼭 문제라고 생각하지 않음
    텍스트 API에서는 큰 호환성 이슈를 경험하지 못했고, 다양한 API를 표준화하려면 자체적으로 인터페이스를 구현해야만 하는 것을 이해함
    특정 라우터를 만들려면 이 과정이 필수적임
    • LiteLLM에는 실제로 가벼운(lite) 부분이 없는 느낌
      실험적으로 라이브러리로 써봤지만 결국 Simon의 llm으로 옮겼음. Simon에게 감사의 마음을 전함
    • 텍스트 완성 등 표준 사용에는 두 방식 모두 잘 동작함
      스트리밍 비헤이비어나 타임아웃 처리, 새 기능 도입 등 경계 조건에서 차이가 더 많이 드러남
      우리도 API 정규화를 위해 인터페이스를 다시 만드는데, SDK 사용 여부는 어디서 레이어를 나누냐의 차이일 뿐
      SDK를 채택하는 건 주로 유지보수 선호 때문이지 LiteLLM 접근 방식의 근본적 결함 때문은 아님
    • 공식 SDK 역시 의존성 문제가 생기는 경우가 있음
      Together의 SDK는 Apache Arrow라는 60MB짜리 의존성을 포함하기도 했고, 이를 직접 패치해서 옵션으로 만들었음
      의존성 버전을 강제로 고정해버리면 내 프로젝트와 충돌이 생길 수 있음
      많은 의존성을 끌고 오는 라이브러리보다는 OpenAPI/REST 만 사용하는 게 낫다는 생각
    • LiteLLM도 전체적으로 꽤 실전 경험이 쌓임
      공식 SDK를 사용하는 것만으로도 모든 호환성 이슈가 해결되는 것은 아니고, any_llm도 결국 공식 SDK와 직접적으로 호환성 유지 작업이 필요함
      어떤 방식이 더 우월하다고 명확하게 말하긴 어려움
    • 나는 개인적으로 Litellm을 AI 게이트웨이로 쓰고 있음
      사용자 입장에서는 프록시에서 공식 SDK를 쓰든 아니든 실사용 차이는 없음
      프록시 개발자에겐 이점이 있을 수 있음
      예를 들어 최근에 Litellm이 Deepseek Reasoning 처리에서 이슈가 있었고, 동기/스트리밍 응답 모두에서 reasoning 부분이 누락된 적이 있었음
  • 블로그 포스트에선 LiteLLM이 다양한 LLM 제공자 지원으로 인기라고 언급했지만, 실제로는 “공식 SDK를 쓰지 않고 직접 구현해서 호환성 이슈를 일으킬 수 있다”고 비판함
    내 경험으론 LiteLLM이 실제로 매우 견고하게 동작함
    공급자들은 API 변경이 있을 때 사전 공지를 확실히 해주고, LiteLLM이 이 때문에 문제가 된 적은 없음
    LLM 관련 부정적인 가상의 단점은 이 글에서만 등장함
    프록시/게이트웨이 솔루션으로 OpenRouter, Portkey 이야기도 했는데 실제로 OpenRouter는 사용자가 직접 서버를 세울 필요 없이 엔드포인트에 바로 API 호출만 하면 됨
    이 글에선 OpenRouter를 셀프호스팅 프록시로 잘못 인식했음
    그리고 AISuite는 Andrew NG가 만든 제품인데 블로그는 “2024년 12월 이후로 미유지보수 중”이라고 썼지만, 실제론 릴리즈 태그만 없을 뿐 작은 커뮤니티 프로젝트들은 태깅을 잘 안할 때가 있음
    이런 부분 사실 확인 없이 블로그에 올리는 건 문제가 있다고 느꼈음
    Mozilla 브랜드가 아니었으면 사기나 악성코드로 오해했을 것 같음
    이름도 Anything-LLM과 너무 비슷해 혼란스럽기도 함
  • 새로운 any-llm 프로젝트가 기대됨
    지금까지 LiteLLM을 써왔지만 실제 내부 구현을 보면 매우 복잡하고 문제가 많았음
    예시로 최근 몇 달간 Ollama 항목의 Structured Output이 완전히 깨진 상태로 방치되어 있었고, 문서도 정리가 전혀 안되어 있었음
  • 프로젝트가 멋있게 보여 흥미로움
    Python을 선택한 이유는 아마도 대부분의 SDK가 Python 기반이라서일 것 같음
    하지만, 인터프리터 없이 여러 언어에 이식 가능한 형태였으면 정말 혁신적이었을 거라고 생각함
    • 핵심 질문임. 많은 도구들이 시스템-레벨 문제(크로스-언어 모델 실행)를 어플리케이션 레이어(Python 라이브러리)에서 해결하려고 함
      진짜 보편적인 솔루션을 만들려면 모델의 런타임과 언어를 완전히 분리할 필요가 있고, 이는 훨씬 어려운 문제지만 큰 발전임
    • JS/TS 용으로는 Vercel AISDK가 있고, C++ 용은 ClickHouse ai-sdk-cpp, Flutter/ReactNative/Kotlin 용 Cactus 등 이미 여러 언어에서 사용할 수 있는 SDK가 존재함. 이 프로젝트와 목적이 유사
    • 우리는 SDK가 아니라 서비스-형 게이트웨이를 직접 만들었음. 참고: Portkey-AI Gateway 프로젝트
  • 기존에 SimonW의 llm 프로젝트와 어떤 차별점이 있는지 궁금함
    • SimonW의 프로젝트는 OpenAI 및 호환 모델 지원이 중심이고, 예를 들어 Amazon Bedrock과 같은 모델을 쓰려면 *추가 게이트웨이/프록시* 를 직접 배포해야함
      Mozilla 쪽 프로젝트(LiteLLM 포함)는 이미 다양한 인터페이스를 지원해서 즉시 여러 모델을 쓸 수 있다는 점이 강점
      별도 프록시/게이트웨이 서버 없이 바로 여러 LLM Provider와 연결이 가능함. LiteLLM과의 비교는 경험이 부족해 잘 모르겠음
  • 나도 Python용 LLM 추상화 레이어 오픈소스 프로젝트를 만들고 있음
    내 연구 직무에서 필요해서 개발하게 됨
    기존 프로젝트에서 아이디어를 얻어서 더 범용적인 용도로 만들었음
    https://github.com/proxai/proxai
    https://proxai.co/
  • 정말 타이밍이 신기하다고 느낌
    나도 최근에 비슷한 LLM 추상화 레이어 를 출시했음
    pip install로 쉽게 쓸 수 있고, Langchain 호환성을 중점으로 만들어서 기존 시스템에 쉽게 교체 가능함
    게다가 자동 Rate Limit 초과 시 가상 프로바이더를 통한 자동 페일오버도 가능함
  • 요즘 LLM 게이트웨이/프록시 레이어로 LiteLLM, OpenRouter, Arch, any-llm 등 다양한 선택지가 생기고 있음. 이쯤 되니 다같이 새로운 문제를 찾아야 할지도 모르겠음
    • LiteLLM은 조금 복잡하다고 생각함. 개인 프로젝트에서 Docker 컨테이너로 간단히 쓰기에는 괜찮겠지만, 실제 프로덕션 사용에는 만족스럽지 않음
    • 80%의 모델 공급자가 OpenAI 호환 엔드포인트를 지원함에도 불구하고, 다양한 솔루션이 등장함
    • Portkey도 소개하고 싶음. JS 및 오픈소스로 활용 가능함
    • 우리는 모델 라우팅을 학술 연구 및 PDF 챗봇 분야로 적용하고 있음. 의견을 듣고 싶음
  • 이런 솔루션에는 Docker 이미지가 꼭 필요하다고 생각함. Docker를 언급하지 않은 것 같은데, pip나 Python 버전 충돌을 피하고 싶어서임
  • 나는 개발환경에서도 Litellm Proxy를 Docker로 계속 사용 중임
    Usage/Logs 기능이 실제 LLM 사용량을 가시화해주고, Cache 기능으로 반복 테스트 시 비용 절감에도 큰 도움이 됨
답변달기
▲
egirlasm 7일전  [-]

좋은글 감사합니다. 마침 오늘 27번째로 리팩토링 하고 있었는데 말이죠.
C++로 하다가,javascript로 하다고 이제는 또 rust로...

답변달기