Skip to main content

LiteLLM Gateway 아키텍처

multi-saas-kit에서 LiteLLM은 단순 외부 툴이 아니라 기본 LLM control plane 역할을 합니다.

역할 분리​

구조는 다음처럼 이해하면 됩니다.

App / Client / Worker
        │
        │ OpenAI-compatible API + Virtual Key
        ▼
llm.apis.how
        │
        ├─ 운영 정책 / 문서 / 관리 UX
        └─ LiteLLM Gateway
                │
                ├─ provider routing
                ├─ retry / fallback
                ├─ spend tracking
                └─ model catalog

상위 API 서비스까지 포함하면 구조는 조금 더 넓어집니다.

Browser / App
        │
        │ Speech API Token / API Access Key
        ▼
speech.apis.how / other API services
        │
        ├─ introspection
        └─ internal service key
                ▼
            llm.apis.how
                ▼
            LiteLLM Gateway

왜 이렇게 나누나요?​

LiteLLM이 이미 잘하는 일과, multi-saas-kit가 잘해야 하는 일을 분리하기 위해서입니다.

LiteLLM이 맡는 일​

  • OpenAI-compatible gateway
  • provider adapter
  • virtual key
  • routing / retry / fallback
  • 기본 spend tracking

multi-saas-kit가 맡는 일​

  • llm.apis.how 도메인 운영
  • 문서화와 onboarding
  • 프로젝트별 정책과 preset
  • admin UX와 플랫폼 통합
  • 상위 API 서비스와 LiteLLM spend/cost 연결
  • API Access Key Core 운영

앱에서 지켜야 할 원칙​

  • 공급사 원본 key를 직접 앱에 넣지 않습니다.
  • 공급사 원본 모델명보다 alias를 사용합니다.
  • 앱은 LiteLLM 내부 구현이 아니라 OpenAI-compatible contract에 의존합니다.
  • 상위 API 서비스는 외부 access key와 내부 LiteLLM key를 분리합니다.

권장 운영 구성​

  • LiteLLM + DB
  • 필요 시 Redis
  • virtual key 기반 호출
  • alias 기반 model selection
  • fallback 1개 이상
  • observability 1개 이상

관련 문서​