로컬 LLM 라우팅을 위한 Tokios와 LiteLLM의 비교

​

개요

LiteLLM은 오픈소스 Python 기반 프록시이자 API 게이트웨이입니다. 이는 LLM 백엔드 앞단에서 작동하며 OpenAI, Anthropic, Azure, Bedrock 및 100개 이상의 다른 제공업체들의 API 간 통신을 번역해줍니다. 또한 가상 API 키 생성, 예산 추적, 부하 분산, 모니터링 기능도 제공합니다. 강력한 라우팅 및 비용 관리 도구라 할 수 있습니다. 핵심 차이점은 LiteLLM은 터널이 아닌 프록시라는 점입니다. 이는 호출자와 백엔드 간의 API 트래픽을 관리하지만, 로컬 모델을 인터넷에서 접근 가능하게 만드는 네트워크 문제는 해결하지 못합니다. 원격 접속을 위해서는 Tailscale, Cloudflare 또는 Tokios 같은 별도의 터널이 필요합니다. Tokios는 터널 기능, API 게이트웨이, 사용자별 API 키 관리, 관리용 대시보드를 1 관리형 서비스 안에 모두 통합합니다. 모델 접근성을 보장하는 네트워크 계층과 인증, 스트리밍, 프로토콜 변환을 처리하는 API 계층을 모두 관리합니다.

​

비교 표

​

LiteLLM이 우수한 점들

• 오픈소스. 전체 소스 코드가 공개되어 자체 호스팅도 가능하며 특정 벤더에 종속되지 않습니다. 감사, 포크, 수정도 자유롭게 할 수 있습니다
• 100개 이상의 제공업체. OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex, Together AI 등 수십 개의 서비스를 통합된 OpenAI 형식 API를 통해 활용할 수 있습니다
• 고급 라우팅 기능. 가중치 기반 부하 분산, 지연 시간에 따른 라우팅, 제공업체 장애 시 자동 폴백, 속도 제한이 적용된 모델에 대한 쿨다운 로직도 지원합니다
• 세밀한 예산 관리. 가상 키, 팀, 프로젝트별로 지출 한도를 설정할 수 있으며 모델, 사용자, 일자별 비용도 추적 가능합니다. 이 부분에서 LiteLLM은 훨씬 더 성숙한 기능을 제공합니다
• 완성도 높은 관측 기능. Langfuse, Datadog, Prometheus, Helicone 및 사용자 정의 콜백 훅과의 기본 통합이 가능합니다. 모든 요청에 대한 상세 로그, 토큰 수, 지연 시간 측정값도 기록됩니다
• 정확한 비용 산출. 어느 팀이 어떤 모델에 얼마를 지출했는지 정확히 파악할 수 있습니다. 여러 클라우드 제공업체를 활용하는 조직에게는 필수적인 기능입니다

​

Tokios가 우위를 점하는 부분

• 터널 기능도 포함됩니다. LiteLLM의 경우에도 로컬 모델을 인터넷에서 접근 가능하게 하려면 별도의 네트워크 계층이 필요합니다. Tokios는 아웃바운드 터널 기능을 기본으로 제공하므로 cloudflared 설정이나 Tailscale, nginx 설정이 전혀 필요하지 않습니다.
• 관리형 서비스입니다. Docker 컨테이너 실행이나 Kubernetes 배포, Python 환경 유지 관리가 전혀 필요하지 않습니다. Tokios는 커넥터 바이너리와 웹 대시보드만으로 구성됩니다.
• 내장형 대시보드입니다. 여러 커넥터와 배포 정보, API 키를 하나의 UI에서 관리할 수 있습니다. 반면 LiteLLM의 관리 UI는 별도의 설정과 구성 과정이 요구됩니다.
• 게이트웨이에서의 프로토콜 변환 기능. 터널 엔드포인트에서 OpenAI 및 Anthropic 형식을 지원합니다. LiteLLM은 OpenAI 형식으로 데이터를 정규화하지만 호출자에게는 Anthropic 프로토콜을 제공하지 않습니다.
• 로컬 모델 사용에 더 간편합니다. “로컬에 설치된 Ollama 모델을 API 키로 접근 가능하게 만들고 싶다”는 목적이라면 Tokios 설정은 단 2 분이면 충분합니다. 반면 LiteLLM은 Docker 배포와 설정 파일, 별도의 터널 설정까지 필요합니다.

​

네트워크 관련 한계점

이것이 두 솔루션 간의 근본적인 차이점입니다. LiteLLM은 프록시 계층으로서 호출자와 백엔드가 동일한 네트워크 혹은 접근 가능한 네트워크 상에 있을 때만 작동합니다. 만약 모델이 CGNAT 환경의 홈 서버에서 실행 중이라면 LiteLLM 단독으로는 인터넷에서 접근 가능하게 할 수 없습니다. 다음이 필요합니다:

1. LiteLLM 프록시를 외부에서 접근 가능하게 만들기 위한 터널(Cloudflare Tunnel, Tailscale Funnel 또는 Tokios)
2. 라우팅, API 키 관리, 사용량 제한 기능을 처리하기 위한 터널 뒤편의 LiteLLM
3. LiteLLM 뒤편에 위치한 LLM 백엔드들

이처럼 총 3 단계의 설정 및 유지 관리가 필요합니다. Tokios는 1 단계와 2 단계를 하나의 관리형 서비스로 통합해주지만, 여러 제공업체에 대한 라우팅 기능은 LiteLLM이 그대로 제공합니다.

​

두 서비스를 함께 사용하기

복잡한 환경에서는 서로 상호보완적인 역할을 합니다:

• LiteLLM은 로컬 네트워크 내에서 작동하며 여러 백엔드(로컬 vLLM, 클라우드 OpenAI, Azure 등) 간의 라우팅을 처리하고 비용 추적 및 부하 분산 기능도 제공합니다.
• Tokios는 API 키를 활용한 공개용 터널 엔드포인트를 제공하므로 외부 사용자나 코딩 에이전트들이 별도의 터널 설정 없이도 귀하의 LiteLLM 프록시에 접근할 수 있습니다.

In this architecture, the Tokios connector points at your LiteLLM proxy instead of directly at a backend. Callers hit api.tokios.com with a sk-tok-… key, Tokios tunnels to your machine, and LiteLLM handles the multi-provider routing from there.

​

LiteLLM을 선택해야 하는 경우

• 다중 클라우드 제공자 라우팅. OpenAI, Anthropic, Azure 및 로컬 모델들 간에 폴백 기능과 부하 분산을 적용한 라우팅이 필요할 때입니다.
• 고급 비용 추적. 팀별 예산 관리, 프로젝트별 지출 한도 설정, 상세한 비용 분석이 필요한 경우입니다.
• DevOps 역량 보유. Docker/Kubernetes 환경에서 설정 파일과 모니터링 체계를 갖춘 배포 환경을 운영할 수 있어야 합니다.
• 다양한 제공업체 지원이 필요합니다. 귀하는 5개 이상의 서로 다른 LLM 제공업체들을 통합하고자 하며, 단일한 API 인터페이스를 원하십니다.

​

Tokios를 선택해야 하는 경우

• 로컬 모델에 공개 API 엔드포인트 필요. 하드웨어에 설치된 모델을 인증 기능과 함께 어디서든 접근 가능하게 만들고자 할 때입니다.
• 관리형 서비스를 원하신다면. 인프라 운영이나 컨테이너 오케스트레이션, Python 환경 관리가 전혀 필요하지 않습니다.
• 터널, 프록시, API 키 기능을 하나로 원하신다면. 하나의 도구만으로 네트워킹, 인증, 스트리밍 기능을 모두 처리할 수 있습니다. 굳이 3 개별 레이어를 따로 사용할 필요가 없습니다.
• 간단한 로컬 백엔드 설정을 원하신다면. Ollama나 vLLM 뒤에 하나 혹은 두 개의 로컬 모델만 배치하면 됩니다. 복잡한 다중 제공자 라우팅 메시도 필요하지 않습니다.