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 기능으로 반복 테스트 시 비용 절감에도 큰 도움이 됨