LiteLLM vs OpenRouter: 비용, 제어권, 장애 조치 비교

LLM 게이트웨이를 고를 때 핵심은 LiteLLM과 OpenRouter가 OpenAI 스타일 API를 지원하느냐가 아닙니다. 라우팅 계층을 누가 운영하느냐가 진짜 차이입니다. 이미 프로덕션 게이트웨이 인프라를 운영하고 있지 않다면 OpenRouter가 부담 적은 출발점입니다. 반대로 프라이빗 네트워크, 세밀한 정책, 지속적인 사용량 때문에 제어권이 중요하다면 운영 부담을 감수하고 LiteLLM을 선택할 이유가 생깁니다.

API 형식이 아니라 운영 모델의 선택이다

LiteLLM은 Python SDK 또는 셀프 호스팅 프록시로 실행할 수 있는 오픈소스 소프트웨어입니다. OpenRouter는 관리형 API이자 모델 카탈로그입니다. 게이트웨이 운영, 여러 프로바이더에 대한 액세스 통합, 모델 사용량을 한 계정으로 관리하는 일을 OpenRouter가 맡습니다.

두 서비스 모두 OpenAI 호환 인터페이스를 제공할 수 있지만, 책임의 위치는 서로 다릅니다.

이 차이 덕분에 두 서비스를 결합하는 아키텍처도 가능합니다. LiteLLM이 내부 정책과 비용 집계 계층을 맡고, OpenRouter가 일부 모델 액세스를 담당하는 방식입니다.

가장 먼저 문제가 될 제약 조건을 기준으로 고르자

정답은 팀이 가장 먼저 양보할 수 없게 되는 요구사항에 달려 있습니다.

토큰 비용부터 엔지니어링 비용까지 전체 비용을 계산하자

LiteLLM과 OpenRouter는 서로 다른 계층에 비용을 부과합니다. OpenRouter는 추론 마크업 없이 기본 모델 가격을 전달한 뒤, 크레딧 구매 시 5.5%의 수수료를 받습니다. LiteLLM의 오픈소스 프록시에는 토큰당 게이트웨이 수수료가 없지만, 이를 운영하는 데 필요한 인프라와 인력 비용은 직접 부담해야 합니다.

수수료 조건은 OpenRouter의 pricing page를 기준으로 확인해야 합니다. 이 수수료는 크레딧 구매에 붙는 비용이지, 모든 모델의 토큰 가격에 단순히 5%를 더하는 방식은 아닙니다.

OpenRouter 수수료가 더 저렴한 비용 항목이 되는 경우

팀이 월간 추론 비용을 충당할 만큼 OpenRouter 크레딧을 구매한다고 가정해 보겠습니다.

• 월 사용량이 $500이면 5.5% 크레딧 구매 수수료는 $27.50입니다.
• $20,000이면 같은 비율의 수수료는 $1,100입니다.
• $50,000이면 $2,750입니다.

이 금액과 비교해야 하는 것은 호스팅, 배포, 패치, 알림, 백업, 엔지니어링 시간을 모두 포함한 LiteLLM 운영 비용입니다. 월 $500 수준에서는 이미 게이트웨이를 운영하고 있지 않은 팀이라면, 프라이빗 네트워크가 필수가 아닌 한 OpenRouter가 운영 부담이 적은 선택인 경우가 많습니다. 월 $20,000에 이르면 플랫폼 운영 역량을 가진 팀이라면 LiteLLM을 진지하게 계산해 볼 만합니다.

LiteLLM의 게이트웨이 수수료 0원이 실제로 더 저렴해지는 경우

플랫폼 팀이 이미 고정 운영비를 부담하고 있거나, 절약되는 비율 수수료가 프록시를 운영하는 추가 비용보다 클 때 LiteLLM의 경제성이 생깁니다.

공식 Docker 빠른 시작 가이드는 데이터베이스가 없는 단순 프록시와 데이터베이스 기반 배포를 구분합니다. Compose 구성에서는 모델, 키, 지출 로그에 PostgreSQL을 사용합니다. 데이터베이스가 없으면 LiteLLM은 가상 키, 지출 추적, 실질적인 예산 강제 기능을 사용할 수 없다고 설명합니다. 구성한 max_budget도 신뢰할 수 있는 하드 상한으로 작동하지 않습니다.

Redis를 도입해야 하는 시점도 따로 있습니다. LiteLLM의 Redis 요구사항은 프록시가 둘 이상의 워커나 레플리카로 실행될 때 공유 Redis 상태를 권장합니다. Redis가 없으면 속도 제한, 예산, 쿨다운, 캐시 항목, 라우팅 관측 정보가 워커별로 분리됩니다. 단일 워커 테스트는 저렴하지만, 수평 확장된 프로덕션 게이트웨이는 훨씬 큰 시스템입니다.

토큰 가격만 보지 말고 다음과 같이 비교하세요.

LiteLLM total cost = provider bills + infrastructure + operations + security ownership
OpenRouter total cost = provider inference + credit-purchase fee

모든 팀에 적용되는 손익분기점은 없습니다. 월간 추론 비용, 호스팅 비용, 엔지니어링 시간, 온콜 범위, 컴플라이언스에 따른 추가 비용을 실제 입력값으로 삼아야 합니다.

직접 운영해야 할 컨트롤 플레인을 비교하자

LiteLLM은 플랫폼 팀에 더 많은 제어권을 주지만, 프로바이더 액세스까지 대신 만들어 주지는 않습니다. OpenRouter는 모델 탐색과 통합 결제가 간편하지만, 호스팅 카탈로그를 이용하는 것과 프로바이더와 직접 관계를 맺는 것은 같은 일이 아닙니다.

신뢰성 측면에서는 두 제품의 차이가 더 선명해진다

두 서비스 모두 재시도나 장애 조치를 지원할 수 있지만, 장애 조치의 책임 주체가 다릅니다. OpenRouter는 프로바이더 풀을 관리하고, LiteLLM은 사용자가 풀을 정의하는 대신 신뢰성 스택의 일부로 직접 운영해야 합니다.

OpenRouter의 프로바이더 라우팅 문서에 따르면 기본 동작은 가격과 최근 프로바이더 장애를 고려하면서 사용 가능한 프로바이더 사이에 부하를 분산하는 방식입니다. 프로바이더 순서를 요청하거나 폴백을 허용 또는 비활성화할 수 있고, 특정 파라미터를 요구하거나 데이터 정책으로 필터링할 수도 있습니다. 가격, 처리량, 지연 시간을 기준으로 정렬하는 것도 가능합니다. 모델 폴백 가이드는 순서가 있는 models 목록을 설명하며, 최종적으로 요청을 처리한 모델을 기준으로 과금한다고 안내합니다.

LiteLLM의 라우팅 문서에는 가중치 또는 셔플 기반 선택, 사용량 인식 라우팅, 지연 시간 기반 라우팅, 최소 사용량 라우팅, 비용 기반 라우팅, 커스텀 라우팅 전략이 설명되어 있습니다. 배포 우선순위, 쿨다운, 재시도, 폴백 그룹도 지원합니다. 이런 제어 기능은 더 프로그래밍 가능하지만, 실제로 제대로 작동하려면 구성, 헬스 체크, 공유 상태, 장애 대응 체계가 모두 정확해야 합니다.

에이전트 지연 시간, 캐시, 프로바이더 변화

긴 스트리밍 응답 하나를 처리할 때는 네트워크 홉이 하나 늘어나는 일이 크게 중요하지 않을 수 있습니다. 하지만 에이전트가 짧은 모델 호출을 수십 번 반복한다면 이야기가 달라집니다. 호출마다 게이트웨이, 네트워크, 재시도 지연이 누적되기 때문입니다. 셀프 호스팅 LiteLLM 프록시는 애플리케이션 가까이에 배치할 수 있지만, OpenRouter는 선택된 프로바이더 앞에 관리형 서비스 홉을 추가합니다. 어떤 서비스의 일반 문서도 여러분의 리전, 모델, 스트리밍 모드, 동시성에 대한 실제 테스트를 대신할 수는 없습니다.

라우팅은 캐시 비용 구조에도 영향을 줍니다. OpenRouter는 동일한 모델에 대해 여러 프로바이더 엔드포인트 중 하나를 선택할 수 있고, LiteLLM도 구성된 배포본 사이에 요청을 분산할 수 있습니다. 프로바이더 측 프롬프트 캐싱에 의존하는 워크플로라면 라우트가 바뀔 때 캐시 지역성과 토큰 비용이 달라질 수 있습니다. 캐시 동작 역시 워크로드 테스트의 일부로 다뤄야 합니다.

같은 모델 슬러그를 사용한다고 해서 동작까지 같아지는 것은 아닙니다. 프로바이더별 구현에 따라 컨텍스트 한도, 툴 호출 지원, 지연 시간, 양자화, 캐싱, 프로바이더 전용 파라미터가 달라질 수 있습니다. OpenRouter는 require_parameters 같은 프로바이더 필터를 제공하고, LiteLLM은 프로바이더 호출을 공통 인터페이스로 정규화합니다. 에이전트가 실제로 사용하는 툴 스키마와 모델 파라미터를 기준으로 테스트해야 합니다.

대비해야 할 장애 시나리오

OpenRouter에서는 인프라 장애가 벤더 의존성으로 바뀝니다. LiteLLM에서는 플랫폼 팀이 직접 확인하고 변경할 수 있는 장애가 됩니다.

관측성과 개인정보 보호의 경계는 서로 다르다

‘셀프 호스팅’과 ‘프라이빗’은 같은 말이 아니며, ‘관리형’이라고 해서 모든 프롬프트를 기록한다는 뜻도 아닙니다. 중요한 것은 어떤 계층이 콘텐츠를 저장하는지, 어떤 계층이 메타데이터를 저장하는지, 그리고 어느 프로바이더에 요청이 전달되는지입니다.

OpenRouter의 Zero Data Retention 문서에 따르면 ZDR은 계정 전체, 모델 그룹, 가드레일 또는 요청 단위로 강제할 수 있습니다. 보존하지 않는 엔드포인트와, 학습에는 사용하지 않지만 일시적으로 데이터를 보관할 수 있는 프로바이더를 구분한다는 점도 설명합니다. ZDR은 추론 라우팅에 적용되며, 활성화한 툴과 플러그인은 별도로 검토해야 합니다.

LiteLLM을 사용하면 게이트웨이의 네트워크, 데이터베이스, 인증, 로그를 더 세밀하게 통제할 수 있습니다. 하지만 그 책임도 전부 사용자에게 있습니다. 프록시를 보호하고, 소프트웨어를 패치하고, 관리자 경로를 제한하고, 프로바이더 키를 안전하게 관리해야 합니다. 각 업스트림 프로바이더의 데이터 보존 및 학습 관련 약관도 직접 확인해야 합니다.

현실적인 답은 하이브리드 구성일 때가 많다

안정적인 내부 엔드포인트와 거버넌스는 필요하지만 모델이나 프로바이더마다 직접 계정을 만들고 싶지 않다면 LiteLLM 앞에 OpenRouter를 둘 수 있습니다. 민감하거나 사용 패턴이 예측 가능한 트래픽은 승인된 프로바이더로 직접 보내고, 탐색적인 요청이나 카탈로그 의존적인 트래픽은 OpenRouter를 통과시키는 방식입니다.

간단한 구성 패턴은 다음과 같습니다.

model_list:
  - model_name: direct-claude
    litellm_params:
      model: anthropic/claude-sonnet-latest
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: catalogue-model
    litellm_params:
      model: openrouter/<provider>/<model>
      api_base: https://openrouter.ai/api/v1
      api_key: os.environ/OPENROUTER_API_KEY

이렇게 하면 LiteLLM이 내부 키, 예산, 태그, 로그를 적용할 수 있습니다. 다만 OpenRouter 경로로 전송되는 요청에 대해서는 OpenRouter 수수료, 호스팅된 데이터 전송, 프로바이더 정책이라는 경계가 그대로 남습니다. 홉과 장애 영역도 하나 더 생기므로 모든 요청을 자동으로 두 계층 모두 통과시키는 것은 피해야 합니다.

다음과 같이 나누는 것이 합리적입니다.

1. 민감한 데이터, 안정적인 프로덕션 모델, 협상된 프로바이더 계약에는 직접 프로바이더 경로를 사용합니다.
2. 모델 탐색, 롱테일 프로바이더, 관리형 프로바이더 폴백에는 OpenRouter 경로를 사용합니다.
3. 애플리케이션 키, 팀, 예산, 내부 비용 귀속은 LiteLLM으로 통제합니다.
4. 직접 프로바이더 트래픽과 OpenRouter 트래픽에 대해 대시보드와 알림을 분리합니다.

마이그레이션 시 바뀌는 것과 바뀌지 않는 것

OpenAI 호환 클라이언트의 연결 대상을 두 게이트웨이 사이에서 바꾸는 일 자체는 간단할 수 있습니다. 하지만 프로덕션 워크로드를 옮기는 작업은 기본 URL 하나를 수정하는 것으로 끝나지 않습니다.

from openai import OpenAI
import os

client = OpenAI(
    base_url=os.environ["LLM_BASE_URL"],
    api_key=os.environ["LLM_API_KEY"],
)

OpenRouter는 일반적으로 https://openrouter.ai/api/v1을 사용하고 (API reference), LiteLLM 프록시는 일반적으로 http://localhost:4000 같은 프라이빗 엔드포인트를 제공합니다 (proxy quickstart). 그래도 모델 ID, 프로바이더 접두사, 인증 방식, 선택적 파라미터는 서로 다를 수 있습니다.

프로덕션 트래픽을 전환하기 전에 다음 항목을 테스트하세요.

1. 스트리밍과 타임아웃 동작
2. 실제 사용하는 JSON 스키마를 적용한 툴 호출
3. 구조화된 출력과 엄격한 JSON 처리
4. 추론, 캐싱, 프로바이더 전용 파라미터
5. 기본 모델이 429, 5xx 또는 검증 오류를 반환할 때의 폴백 동작
6. 비용 귀속. 결제 이벤트가 애플리케이션 요청과 다른 계층에서 발생할 수 있기 때문입니다.

API 호환성은 첫 통합을 빠르게 진행하게 해줄 뿐입니다. 출력, 지연 시간, 프로바이더 선택, 결제 방식까지 동일하다는 보장은 없습니다.

선택 전에 팀이 자주 묻는 질문

LiteLLM과 OpenRouter를 함께 사용할 수 있나요?

가능합니다. LiteLLM에서 OpenRouter를 업스트림 경로로 사용하면 LiteLLM이 내부 키, 예산, 로깅, 정책을 담당하고 OpenRouter가 선택한 모델 액세스와 프로바이더 라우팅을 제공할 수 있습니다. 다만 결합된 경로에는 홉이 하나 더 생기며, 해당 트래픽에는 OpenRouter 수수료와 호스팅 데이터 경계가 계속 적용됩니다.

프로덕션 API에는 어느 쪽이 더 저렴한가요?

이미 게이트웨이 인프라를 운영하고 있지 않은 소규모 팀이라면 OpenRouter가 운영 부담이 적은 선택인 경우가 많습니다. 반면 필요한 인프라를 이미 운영하고 있고 비율 기반 게이트웨이 수수료를 피하고 싶다면, 사용량이 많을수록 LiteLLM이 더 저렴할 수 있습니다. 토큰 비용만이 아니라 전체 비용을 비교해야 합니다.

LiteLLM으로 OpenRouter의 전체 카탈로그에 접근할 수 있나요?

LiteLLM만으로는 불가능합니다. LiteLLM은 proxy quickstart에서 100개 이상의 LLM과 폭넓은 프로바이더를 지원한다고 설명하지만, 실제로는 사용자가 구성한 프로바이더와 인증 정보에 해당하는 모델만 이용할 수 있습니다. OpenRouter를 업스트림으로 추가하면 접근 가능한 카탈로그를 넓힐 수 있지만, 해당 요청은 OpenRouter의 모델 및 프로바이더 가용성에 따르게 됩니다.

개인정보 보호와 컴플라이언스에는 어느 쪽이 더 나은가요?

셀프 호스팅 LiteLLM은 게이트웨이의 배포 위치, 로그, 인증 정보, 네트워크 경계를 더 세밀하게 통제할 수 있습니다. OpenRouter도 콘텐츠 로깅 제어, 프로바이더 정책 필터, ZDR 라우팅, Enterprise EU/US 리전 옵션을 제공하지만 요청 경로의 일부로 남습니다. 선택하기 전에 실제로 사용할 프로바이더와 계약상 요구사항을 확인해야 합니다.

팀이 실제로 운영할 수 있는 경계를 선택하세요. 비율 수수료를 실제 게이트웨이 운영 비용과 비교하고, 호스팅 중개 서비스를 거쳐도 되는 요청을 분류한 뒤, 애플리케이션에 필요한 라우팅과 툴 호출 동작을 기준으로 장애 테스트를 진행해야 합니다. LiteLLM의 데이터베이스, Redis, 업그레이드, 온콜 운영을 맡을 수 없다면 OpenRouter가 더 현실적인 기본 선택입니다. 반대로 이미 이러한 플랫폼 역량을 갖추고 있다면 LiteLLM이나 하이브리드 구성이 제어권을 되찾고 반복적인 게이트웨이 수수료를 줄이는 방법이 될 수 있습니다.

OpenRouter를 대체할 수 있는 더 다양한 선택지는 OpenRouter alternatives에서 확인할 수 있습니다. 이 글은 범위를 의도적으로 좁혀 LiteLLM의 운영 모델 선택에 집중했습니다.