LiteLLM은 앱이 하나 이상의 모델 제공자(model provider)와 통신해야 할 때 우리 중 많은 이들이 찾는 접착제(glue)입니다. 하나의 인터페이스로 수십 개의 백엔드를 지원하죠. 매우 훌륭합니다. 하지만 실제 부하(load) 상황에서 실행해 보면, 핫 패스(hot paths)는 모델 호출 자체가 아니라 그 주변의 배관(plumbing) 작업이 됩니다. 즉, 커넥션 풀링(connection pooling), 속도 제한(rate limiting), 큰 입력값에 대한 토큰 계산(token counting) 같은 작업들입니다. 이 배관 작업들은 순수 Python으로 작성되어 있으며, 그 한계가 드러납니다.

그래서 저는 fast-litellm을 구축했습니다. 이는 핫 패스를 PyO3 확장(extensions)으로 교체하고, 그 외의 모든 부분은 Python으로 폴백(fallback)하는 드롭인(drop-in) Rust 가속 레이어입니다.

솔직한 벤치마크 표

제 뜻대로 되지 않은 결과들을 포함하여 수치부터 먼저 보여드리겠습니다. 이 수치들은 프로덕션급 Python (thread-safe)과 Rust 버전을 비교한 것입니다:

구성 요소	결과
Connection pool	3.2배 빠름 (lock-free DashMap)
...

마지막 블록이 중요한 부분입니다. Python/Rust 경계를 넘는 것은 공짜가 아닙니다. 12개 토큰의 채팅 메시지의 경우, FFI 오버헤드가 절약한 작업량보다 더 크기 때문에 Rust가 손해를 봅니다. 자신의 네이티브 확장(native extension)이 모든 면에서 더 빠르다고 말하는 사람은 작은 케이스(small cases)를 측정하지 않은 것입니다.

Rust가 승리하는 지점은

내가 얻은 교훈

• 포팅하기 전에 프로파일링(Profile) 하세요. 승리는 "코드 전체"가 아니라 세 가지 특정 핫 패스(hot paths)에서 나왔습니다.
• 작은 입력값들도 측정하세요. FFI 오버헤드(FFI overhead)는 실재하며, 당신을 당혹스럽게 만들 것입니다.
• 드롭인(drop-in) 방식으로 만드세요. 그렇지 않으면 프로젝트는 결실을 보지 못하고 사장될 것입니다. 제로 컨피그(Zero-config)와 자동 폴백(automatic fallback) 기능이 있어야 네이티브 가속기(native accelerator)를 실제로 배포하기에 안전합니다.

코드, 전체 벤치마크 상세 분석, 그리고 PyO3 아키텍처는 여기에서 확인할 수 있습니다:
https://github.com/neul-labs/fast-litellm

만약 실제로 상당한 규모로 LiteLLM을 운영하고 계신다면, 어떤 경로가 병목 현상(bottleneck)인지 알려주시면 감사하겠습니다. 마음껏 테스트해 보시고, 이슈(issue) 제기도 환영합니다.