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

> Clean Markdown view of GeekNews topic #22149. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=22149](https://news.hada.io/topic?id=22149)
- GeekNews Markdown: [https://news.hada.io/topic/22149.md](https://news.hada.io/topic/22149.md)
- Type: news
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2025-07-25T09:31:01+09:00
- Updated: 2025-07-25T09:31:01+09:00
- Original source: [github.com/mozilla-ai](https://github.com/mozilla-ai/any-llm)
- Points: 7
- Comments: 3

## Summary

**Mozilla AI팀**이 개발한 이 Python 라이브러리는 **OpenAI, Anthropic, Google, AWS Bedrock** 등 **20개 이상의 LLM 프로바이더**를 **단일 함수와 인터페이스**로 간편하게 교체·연동할 수 있도록 지원합니다. 공식 프로바이더 **SDK 중심의 구조**와 **경량 라우터** 설계로 **프록시 서버 없이 pip 설치만으로 즉시 사용 가능**하며, **IDE 타입 힌트, 직관적인 예외 처리, 문서 제공** 등 **개발자 친화성**이 특징입니다. 기존 솔루션이 가진 **호환성, 파편화, 복잡성 문제**를 효과적으로 해결해, **유지보수성과 확장성**이 필요한 AI 서비스 개발에 적합합니다.

## Topic Body

- 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**: 모듈러 구조지만 관리 및 타이핑 미흡  
  - **프레임워크 종속형**: 프로젝트별로 또다시 파편화  
  - **프록시 전용**: 별도 서버 필요, 복잡성 증가  
  
### 관련 문서  
  
- [빠른 시작 가이드](https://mozilla-ai.github.io/any-llm/quickstart/)  
- [지원 프로바이더 목록](https://mozilla-ai.github.io/any-llm/docs/providers.md)  
- [API 파라미터 설명](https://mozilla-ai.github.io/any-llm/api/completion/)  
- AI 시스템 연동을 위한 지원:  
  - [llms.txt (요약)](https://mozilla-ai.github.io/any-llm/llms.txt)  
  - [llms-full.txt (전체)](https://mozilla-ai.github.io/any-llm/llms-full.txt)

## Comments



### Comment 41816

- Author: kaydash
- Created: 2025-07-26T00:56:08+09:00
- Points: 1

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

### Comment 41776

- Author: neo
- Created: 2025-07-25T09:32:02+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=44650567)   
- 나는 LiteLLM이 공식 SDK가 아닌 **공급자 인터페이스**를 직접 구현한다고 해서 꼭 문제라고 생각하지 않음  
  텍스트 API에서는 큰 **호환성 이슈**를 경험하지 못했고, 다양한 API를 표준화하려면 자체적으로 인터페이스를 구현해야만 하는 것을 이해함  
  특정 라우터를 만들려면 이 과정이 필수적임  
  - LiteLLM에는 실제로 **가벼운(lite)** 부분이 없는 느낌  
    실험적으로 라이브러리로 써봤지만 결국 [Simon의 llm](https://llm.datasette.io/en/stable/index.html)으로 옮겼음. 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 부분이 누락된 적이 있었음  
- [블로그 포스트](https://blog.mozilla.ai/introducing-any-llm-a-unified-api-to-access-any-llm-provider/)에선 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 프로젝트](https://github.com/simonw/llm)와 어떤 **차별점**이 있는지 궁금함  
  - SimonW의 프로젝트는 **OpenAI 및 호환 모델** 지원이 중심이고, 예를 들어 Amazon Bedrock과 같은 모델을 쓰려면 *[*추가 게이트웨이/프록시](https://github.com/aws-samples/bedrock-access-gateway)** 를 직접 배포해야함  
    Mozilla 쪽 프로젝트(LiteLLM 포함)는 **이미 다양한 인터페이스**를 지원해서 즉시 여러 모델을 쓸 수 있다는 점이 강점  
    별도 프록시/게이트웨이 서버 없이 바로 여러 LLM Provider와 연결이 가능함. LiteLLM과의 비교는 경험이 부족해 잘 모르겠음  
- 나도 Python용 **LLM 추상화 레이어** 오픈소스 프로젝트를 만들고 있음  
  내 연구 직무에서 필요해서 개발하게 됨  
  기존 프로젝트에서 아이디어를 얻어서 **더 범용적인 용도**로 만들었음  
  https://github.com/proxai/proxai  
  https://proxai.co/  
- 정말 타이밍이 신기하다고 느낌  
  나도 최근에 비슷한 **[LLM 추상화 레이어](https://github.com/omarkamali/borgllm)** 를 출시했음  
  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 기능**으로 반복 테스트 시 비용 절감에도 큰 도움이 됨

### Comment 41836

- Author: egirlasm
- Created: 2025-07-26T21:13:37+09:00
- Points: 1
- Parent comment: 41776
- Depth: 1

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