저는 2주 동안 LiteLLM과 Bifrost를 나란히 실행하며 테스트했습니다. 동일한 트래픽, 동일한 모델, 동일한 인프라를 사용했습니다. 우리 팀을 위한 게이트웨이(gateway)를 하나 선택해야 했고, 마케팅 페이지의 말이 아닌 실제 수치가 필요했습니다.

제가 발견한 내용은 다음과 같습니다.

설정 (The Setup)

두 게이트웨이는 모두 동일한 로드 밸런서(load balancer) 뒤에 배치되었습니다. 트래픽은 50/50으로 분할되었습니다. 백엔드는 OpenAI, Anthropic, Bedrock 호출이 혼합된 형태였습니다. 인위적인 데이터는 없었습니다. 우리 에이전트 플랫폼에서 발생하는 실제 사용자 대상 요청이었으며, 업무 시간 동안 대략 200-400 RPS(초당 요청 수)를 기록했습니다.

저는 c5.xlarge 인스턴스(4 vCPUs, 8GB RAM)에서 테스트했습니다. 대부분의 벤치마크에서 볼 수 있는 t3.medium이 아닙니다. 운영 환경용 게이트웨이를 선택하고 있다면, 실제 운영 하드웨어에서 테스트해야 합니다.

제공업체(Providers): 100개 이상 vs 23개

이것이 첫 번째 필터였습니다. LiteLLM은 100개 이상의 제공업체(providers)를 지원합니다. Bifrost는 약 23개를 지원합니다.

OpenAI와 Anthropic을 사용하는 대부분의 팀에게는 23개로도 충분합니다. 하지만 저희는 Bedrock, Vertex, Groq, Deepseek, 그리고 몇몇 커스텀 OpenAI 호환 엔드포인트(endpoints)로도 라우팅합니다. LiteLLM은 다음과 같은 동일한 설정 패턴으로 이 모든 것을 처리했습니다:

model_list:
  - model_name: fast-chat
    litellm_params:
...

세 개의 제공업체, 하나의 모델 이름, 자동 로드 밸런싱(load balancing). 새로운 제공업체를 추가하는 것은 YAML 블록 하나면 충분합니다. 반면 Bifrost의 경우, 저희가 사용하는 일부 제공업체가 지원되지 않았습니다. 이는 성능을 확인하기도 전에 이미 결정적인 결격 사유(dealbreaker)였습니다.

성능: 솔직한 버전 (Performance: The Honest Version)

순수 게이트웨이 오버헤드(overhead) 측면에서는 Bifrost가 더 빠릅니다. 이는 마케팅 용어가 아니라, 단순히 Go와 Python의 차이입니다. 그들의 벤치마크는 5K RPS에서 11µs의 오버헤드를 주장합니다. 제 하드웨어에서 측정한 결과 약 0.08ms였으며, 이 역시 매우 훌륭한 수치입니다.

LiteLLM의 Python 프록시(proxy)는 요청당 대략 7-8ms의 오버헤드를 추가했습니다. 단일 인스턴스에서 1K RPS로 구동할 때, Bifrost가 측정 가능한 수준으로 더 빠릅니다.

하지만 모든 Bifrost 벤치마크가 간과하는 사실이 있습니다. 실제 LLM 호출(LLM call)에는 500ms에서 30초가 소요된다는 점입니다. 그 7ms의 오버헤드는 빠른 모델 호출 시 전체 지연 시간(latency)의 0.3%에 불과하며, 느린 모델 호출 시에는 사실상 보이지 않는 수준입니다. 저는 이 내용에 대해 제 latency post에서 다룬 바 있습니다.

그리고 LiteLLM-Rust가 있습니다. 팀에서 방금 Rust 기반의 게이트웨이 경로(gateway path)를 출시했는데, 이를 통해 오버헤드를 0.05ms로 낮추고, 메모리는 11배 적게 사용하면서 처리량(throughput)은 15배 높였습니다. Bifrost의 전체 셀링 포인트(pitch)가 의존하고 있는 단일 인스턴스 성능 격차가 빠르게 좁혀지고 있습니다.

# LiteLLM-Rust 벤치마크 (동일 워크로드)
Rust gateway:  6,782 RPS | 32MB RAM  | 0.05ms overhead
Python proxy:    453 RPS | 359MB RAM | 7.5ms overhead

만약 순수 게이트웨이 지연 시간(gateway latency)만이 유일한 기준이라면, 3개월만 기다렸다가 다시 평가해 보십시오.

비용 추적 (Spend Tracking): 격차가 벌어지는 지점

이 지점부터는 비교가 무의미해집니다. LiteLLM은 모든 제공자(provider), 모든 키(key), 모든 팀에 대해 비용(spend)을 자동으로 추적합니다. 별도의 설정 없이도 키별 예산, 팀별 예산, 일일 비용 보고서, 그리고 이 모든 것을 보여주는 UI를 제공합니다.

# 특정 키의 비용 확인
curl http://localhost:4000/spend/keys   -H "Authorization: Bearer sk-admin-key"

...

Bifrost는 예산 제한이 있는 가상 키(virtual keys)와 키, 팀, 고객 수준의 속도 제한(rate limiting) 기능을 갖추고 있습니다. 기능적으로는 작동합니다. 하지만 LiteLLM의 비용 추적은 더 깊이 들어갑니다. 모델별, 제공자별, 배포(deployment)별로 비용 귀속(cost attribution) 정보를 얻을 수 있습니다. /global/spend/report 엔드포인트는 재무 팀이 실제로 사용할 수 있는 상세 내역을 제공합니다.

6개의 제공자를 통해 한 달에 1,000만 건 이상의 호출을 실행할 때, "어느 팀이 어떤 모델에 얼마를 썼는가"는 있으면 좋은 기능(nice-to-have)이 아닙니다. 그것은 CTO가 매주 월요일마다 던지는 질문입니다.

라우팅 (Routing): 더 많은 전략, 더 많은 제어

LiteLLM은 다섯 가지 라우팅 전략을 기본적으로 제공합니다: simple-shuffle, least-busy, latency-based, cost-based, 그리고 usage-based입니다. 설정에서 하나를 선택하면 됩니다:

Bifrost는 가중치 기반 로드 밸런싱(weighted load balancing)과 적응형 라우팅(adaptive routing)을 제공합니다. 키와 공급자(provider) 전반에 걸쳐 트래픽을 분산시키는 데 아주 좋습니다. 하지만 비용 기반 라우팅 옵션은 찾지 못했습니다. 만약 '이 요청을 처리할 수 있는 가장 저렴한 모델을 항상 선택하고 싶다'면, LiteLLM이 이를 기본적으로 제공합니다.

관측 가능성 (Observability)

Bifrost는 내장 Prometheus 메트릭(metrics), OpenTelemetry, Datadog 통합 기능과 자체 Maxim 관측 가능성 플랫폼을 갖추고 출시됩니다. SQLite나 Postgres에 대한 내장 로깅은 소규모 환경에 좋습니다.

LiteLLM은 Langfuse, Arize Phoenix, LangSmith, Datadog, 그리고 범용적인 OpenTelemetry와 통합됩니다. 이는 '자체 관측 가능성을 가져오는(bring your own observability)' 접근 방식이라서 특정 누군가의 대시보드에 갇히지 않는다는 의미입니다.

두 가지 모두 견고합니다. Bifrost가 초기 사용 경험(out-of-the-box experience) 면에서 약간 더 좋습니다. LiteLLM은 통합 옵션이 더 많습니다.

커뮤니티 및 생태계 (Community and Ecosystem)

LiteLLM: GitHub 스타 45K+개 이상. 거대한 커뮤니티. 주간 릴리스. AWS는 이를 Bedrock AgentCore의 1급 공급자로 지정했습니다. Adobe, Netflix, Spotify가 프로덕션 환경에서 사용합니다.

Bifrost: 스타 약 5.9K개. Maxim AI의 지원을 받습니다. 활발하게 개발되고 있지만 커뮤니티 규모는 더 작습니다. 작성 시점 기준으로 마지막 커밋은 6월 8일이었으며, 2주간 활동이 적었습니다.

커뮤니티 격차는 새벽 2시에 에지 케이스(edge case)에 부딪혀 GitHub 이슈를 검색해야 할 때 중요합니다.

Bifrost가 우세한 영역 (Where Bifrost Wins)

원시 단일 인스턴스 게이트웨이 오버헤드. 요청당 추가되는 최소 지연 시간(latency)을 필요로 하고 공급자 목록이 23개 미만이라면, Bifrost는 정말 빠릅니다. 또한 다중 도구 에이전트(multi-tool agents)의 토큰 사용량을 줄이는 MCP Code Mode 역시 영리한 엔지니어링입니다. 그리고 제로 설정(zero-config) 시작 경험은 깔끔합니다.

LiteLLM이 우세한 영역 (Where LiteLLM Wins)

공급자 커버리지(100개 이상 대 23개). 지출 추적 깊이(Spend tracking depth). 라우팅 전략 옵션. 커뮤니티 규모와 성숙도. 대규모 엔터프라이즈 채택률. 그리고 LiteLLM-Rust는 성능 논쟁 자체를 완전히 없앨 예정입니다.

제가 선택한 것 (My Pick)

저는 LiteLLM을 선택했습니다. 제공업체 커버리지(Provider coverage)가 첫 번째 필터였고, 비용 추적(Spend tracking) 기능이 결정적인 이유였습니다. CFO가 "코딩 에이전트 팀이 지난달 Claude 사용에 얼마를 썼나요?"라고 물었을 때, 직접 구축해야 하는 Prometheus 쿼리가 아니라 실제적인 답변이 필요하기 때문입니다.

Bifrost는 탄탄한 엔지니어링 결과물입니다. 적당한 규모로 OpenAI와 Anthropic만 운영하는 팀에게는 정당한 선택지가 될 수 있습니다. 하지만 그 이상의 범위를 고려한다면, LiteLLM의 폭넓은 제공업체 지원과 엔터프라이즈 기능이 더 실용적인 선택을 가능하게 합니다.

"50배 더 빠르다"는 벤치마크요? 실제 트래픽이 발생하는 실제 하드웨어에서 직접 테스트해 보십시오. 실제 LLM이 응답하는 순간, 게이트웨이의 오버헤드(Overhead)는 노이즈 수준으로 사라집니다.