Litelm, LiteLLM 기능을 덜어낸 경량 LLM 호출 호환층 공개

README는 사람이 직접 다시 써야 한다고 봄. 이런 LLM 문체는 프로젝트에 얼마나 신경 썼는지 가늠하는 냄새 테스트 같음.

나도 동의함. LLM 특유의 표현이 거슬림.

사람이 써야 할 문서를 LLM으로 쓰지 않았으면 좋겠음.

LLM이 쓴 티는 나지만, 배지와 이모지, 맥락 없는 스크린샷, 과장된 도입문으로 가득한 README보다는 훨씬 직관적임. 그래도 그 특유의 문체가 불편하다는 말은 이해함.

README는 보통 것보다 나음. 어떤 방식으로 만들었든 전달은 잘 됨.

나도 oh-my-pi README에서 같은 불만을 느낌. 냉소적이면서도 무심한 척 똑똑함을 과시하는 말투임.

오픈소스에서 필요한 기능만 골라 LLM 클라이언트를 만든 발상은 괜찮다고 봄. 다만 비용 추적, 스트리밍, 캐시는 LiteLLM 사용자가 찾는 이유라서, 그걸 뺀 것을 'bloat'라고 부르는 데는 동의 못 함.

LiteLLM은 이름과 달리 가볍지 않음. 의존성까지 넣으면 700MB쯤 되는데, 훨씬 작은 구성으로도 같은 일을 할 수 있다면 그건 비대하다고 봄.

코드 줄 수와 의존성이 줄었다는 것만으로는 부족함. 지연 시간이나 메모리 사용량이 얼마나 줄었는지도 README에 있어야 판단할 수 있음.

Bifrost와 비교하면 어떤 차이인지 궁금함.

LLM 프록시의 도구 호출 지원은 늘 헷갈림. 내가 본 Bifrost는 프록시 쪽 MCP 도구 목록을 주입하지만 클라이언트 대신 호출하진 않아서, 클라이언트에는 없는 도구 호출 요청이 돌아와 혼란스러웠음.

내가 보기엔 LiteLLM은 파이썬 생태계의 Bifrost에 가까움.

의존성 둘 중 httpx는 사실상 유지보수가 멈춘 상태임. Pydantic이 httpx2로 가져갔음.

프런티어 LLM이면 이런 라우터는 30분 안에 만들 수 있다고 봄. 지금은 기법이 가치 있지 라이브러리 자체는 오래 못 갈 것 같음.

그렇게 단순하지 않음. 예외 처리가 많고, 라우터가 실사용되려면 최소한의 관측 기능도 필요함. LLM은 대충 작동하는 MVP는 잘 만들지만 운영 가능한 도구에는 여전히 팀이 듦.

우리 플랫폼에서 LiteLLM을 쓰는 이유가 바로 여기서 뺀 기능들임. 여러 서비스와 고객별 토큰 비용을 믿을 만하게 추적해야 하는데 LiteLLM이 그 일을 처리함.

캐시와 비용 처리를 원하는 방식으로 붙일 수 있게 플러그인 구조가 있으면 좋겠음.

토큰 계산은 여전히 쓸모 있음. 크기를 줄이려면 기능을 통째로 빼기보다 플러그인 API로 분리하는 방법도 있음.

'LiteLLM Without the Bloat'라는 문구는 빼는 게 좋겠음. 허용 라이선스 오픈소스를 깎아내리지 않아도 프로젝트 가치가 있으면 설명할 수 있음.

컨테이너 이미지는 rootless로 만들어 줬으면 함.