LiteLLM vs Bifrost: 프로덕션 환경에서 두 제품을 직접 테스트해 보았습니다
2주 동안 LiteLLM과 Bifrost를 나란히 실행해 보았습니다.
동일한 트래픽, 동일한 모델, 동일한 인프라를 사용했습니다. 팀을 위해 게이트웨이 하나를 선택해야 했고, 마케팅 문구가 아닌 실제 데이터가 필요했습니다.
테스트 결과는 다음과 같습니다.
테스트 환경 설정
4 vCPU와 8GB RAM을 갖춘 c5.xlarge 인스턴스를 사용했습니다. 작은 테스트용 인스턴스는 사용하지 않았습니다. 우리 에이전트 플랫폼의 실제 사용자 요청을 초당 200~400건 규모로 사용했습니다.
제공업체 지원 범위 (Provider Coverage)
- LiteLLM은 100개 이상의 제공업체를 지원합니다.
- Bifrost는 약 23개의 제공업체를 지원합니다.
LiteLLM은 간단한 설정만으로 OpenAI, Anthropic, Bedrock, Vertex, Groq, Deepseek를 처리합니다. Bifrost는 저희에게 필요한 일부 제공업체가 누락되어 있었습니다. 이 점이 저희에게는 결정적인 결격 사유(dealbreaker)가 되었습니다.
성능
Bifrost는 Go를 사용하기 때문에 순수 게이트웨이 오버헤드 측면에서 더 빠릅니다. 측정 결과 약 0.08ms의 오버헤드가 발생했습니다. LiteLLM의 Python 프록시는 요청당 약 7ms에서 8ms의 지연을 추가했습니다.
하지만 LLM 호출은 500ms에서 30초까지 걸립니다. 모델 응답 시간과 비교하면 7ms의 지연은 거의 느껴지지 않는 수준입니다.
또한, LiteLLM은 최근 Rust 기반 게이트웨이를 출시했습니다. 이를 통해 오버헤드를 0.05ms까지 낮추었으며, 성능 격차를 거의 없앴습니다.
비용 추적 (Spend Tracking)
이 부분은 LiteLLM의 압승입니다. 모든 키와 모든 팀에 대해 비용을 자동으로 추적합니다.
- 키별 예산 설정이 가능합니다.
- 팀별 예산 설정이 가능합니다.
- 일일 비용 보고서를 받을 수 있습니다.
Bifrost에도 예산 제한 기능은 있지만, LiteLLM은 심층적인 비용 귀속(cost attribution) 기능을 제공합니다. 한 달에 1,000만 건의 호출을 실행하면, CTO는 각 팀이 각 모델에 정확히 얼마를 썼는지 물어볼 것입니다. LiteLLM은 그 질문에 즉각적인 답을 줍니다.
라우팅 전략 (Routing Strategies)
LiteLLM은 다섯 가지 라우팅 전략을 제공합니다:
- 단순 셔플 (Simple shuffle)
- 최소 부하 (Least busy)
- 지연 시간 기반 (Latency-based)
- 비용 기반 (Cost-based)
- 사용량 기반 (Usage-based)
Bifrost는 가중치 기반(weighted) 및 적응형(adaptive) 라우팅을 지원하지만, 비용 기반 라우팅은 지원하지 않습니다. LiteLLM은 요청에 대해 가장 저렴한 모델을 자동으로 선택할 수 있습니다.
결론 (Verdict)
저는 LiteLLM을 선택했습니다.
제공업체 목록과 비용 추적 기능이 주요 이유였습니다. Bifrost는 OpenAI나 Anthropic만 사용하는 소규모 팀에게는 훌륭한 엔지니어링 결과물입니다. 하지만 확장성과 다양성을 고려한다면 LiteLLM이 더 실용적입니다.
Optional learning community: https://t.me/GyaanSetuAi