LLM 게이트웨이 패턴 — 프록시를 두는 이유

여러 서비스가 LLM 을 쓸 때, 각 서비스가 OpenAI 나 Bedrock 을 직접 부르면 편할 것 같습니다. 그런데 서비스가 늘면 문제가 쌓입니다. 그래서 앞에 게이트웨이(LLM 프록시)를 하나 둡니다.

직접 호출의 문제

서비스 A → Azure OpenAI (GPT-4)
서비스 B → AWS Bedrock (Claude)
서비스 C → Azure OpenAI (GPT-3.5)
서비스 D → OpenAI

여기서 네 가지가 걸립니다.

• API 키가 서비스마다 흩어집니다. 키를 로테이션하려면 모든 서비스를 건드려야 합니다.
• 비용을 못 추적합니다. 어느 서비스가 얼마나 썼는지 알 수 없습니다.
• provider 를 바꾸면 코드를 고쳐야 합니다. Azure → Bedrock 이동이 코드 수정 작업이 됩니다.
• rate limit, fallback 로직이 서비스마다 중복됩니다.

게이트웨이 패턴

프록시 하나를 앞에 두고, 모든 서비스가 그 단일 엔드포인트만 부릅니다.

서비스는 /chat/completions 하나만 압니다. provider 라우팅, fallback, rate limit, 비용 추적은 프록시가 합니다. 위의 네 문제가 전부 한 곳으로 모입니다.

게이트웨이가 하는 것들

모델 로드 밸런싱 — 같은 모델 이름에 여러 provider 를 매핑하면, 클라이언트는 이름 하나만 요청하고 프록시가 분산합니다.

model_list:
  - model_name: gpt-4
    litellm_params:
      model: azure/gpt-4
      api_base: https://<region-a>.openai.azure.com
  - model_name: gpt-4        # 같은 이름 → 자동 분산
    litellm_params:
      model: azure/gpt-4
      api_base: https://<region-b>.openai.azure.com
  - model_name: gpt-4        # fallback
    litellm_params:
      model: bedrock/claude-3-5-sonnet

클라이언트는 model: gpt-4 만 요청하고, 프록시가 세 provider 에 분산하고 하나가 죽으면 다음으로 넘깁니다.

Virtual Key — 팀별 예산 — 실제 API 키를 노출하지 않고 팀마다 가상 키를 발급합니다.

팀 A 키 → 월 $100, gpt-4·claude만
팀 B 키 → 월 $500, 모든 모델

키가 새어도 그 팀 예산 안에서만 쓰이고, 실제 provider 키는 프록시에만 있습니다.

응답 캐싱 — 같은 프롬프트의 응답을 저장해두고, 같은 질문이 또 오면 provider 를 안 부르고 캐시에서 돌려줍니다. 비용이 줄고 응답이 빨라집니다.

요청: "리스트 정렬하는 법?"
  → 캐시 확인 → HIT → 즉시 반환 (provider 호출 없음)
              → MISS → provider 호출 → 응답 + 캐시 저장

관리 지점 하나 — 키·비용·provider·캐싱

게이트웨이는 “한 곳에서 관리” 를 만듭니다. 키, 비용, provider 선택, 캐싱이 프록시 하나로 모입니다. 서비스가 하나둘일 땐 직접 호출이 간단하지만, 여러 팀이 여러 모델을 쓰기 시작하면 이 관리 지점이 없으면 통제가 안 됩니다.