로드 밸런싱

로드 밸런싱 (Load Balancing)

같은 모델의 배포(deployment)가 여러 개 있다면, 요청을 그 배포들에 골고루 나눠 주는 게 로드 밸런싱이에요. LiteLLM 프록시는 내장 라우터로 같은 모델의 여러 배포에 요청을 자동으로 분산해서 성능과 안정성을 최적화해요. 기본 라우팅 전략은 simple-shuffle이에요.

출처: 공식문서

라우팅 전략 (Routing Strategies)

전략	설명	언제 쓰면 좋은가
simple-shuffle (권장)	요청을 무작위로 분산	일반적인 목적, 부하를 고르게 분산할 때
usage-based-routing (성능엔 비추천)	현재 사용량(RPM/TPM)이 가장 낮은 배포로 라우팅	속도 제한을 고르게 지키고 싶을 때
latency-based-routing	가장 빠르게 응답하는 배포로 라우팅	지연 시간이 중요한 애플리케이션
cost-based-routing	비용이 가장 낮은 배포로 라우팅	비용에 민감한 애플리케이션

퀵 스타트 — 로드 밸런싱 설정

config에서 router_settings로 전략과 관련 파라미터를 지정해요.

router_settings:
  routing_strategy: "simple-shuffle"   # Literal["simple-shuffle","least-busy","usage-based-routing","latency-based-routing"], default="simple-shuffle"
  model_group_alias: { "gpt-5.6-terra": "gpt-5.6-luna" }  # gpt-5.6-terra 요청을 gpt-5.6-luna 모델로 라우팅
  num_retries: 2
  timeout: 30                          # 30초
  redis_host: <your redis host>        # litellm proxy를 여러 개 띄울 때: 로드 밸런싱 상태를 redis에 저장
  redis_password: <your redis password>
  redis_port: 1992

모델 속도 제한 강제 (Enforce Model Rate Limits)

기본적으로 rpm(분당 요청)과 tpm(분당 토큰) 값은 라우팅 결정(용량이 있는 배포를 고르는)에만 쓰여요. 그런데 enforce_model_rate_limits를 켜면 이 값들이 하드 제한이 돼요.

제한 유형	강제 방식	정확도
RPM	하드 제한 — 정확한 임계값에서 차단	100% 정확
TPM	최선 노력(best-effort) — 다소 초과 가능	이미 초과 시 차단

왜 TPM이 best-effort일까요? 토큰 수는 LLM이 응답할 때까지 알 수 없거든요. 그래서 TPM은 각 요청 전에 검사(이미 초과면 차단)하고, 요청 후에는 실제 사용 토큰을 더해서 추적해요.

멀티 인스턴스 배포

LiteLLM 프록시 인스턴스가 여러 개라면 Redis를 추가해 속도 제한 상태를 공유해요.

router_settings:
  optional_pre_call_checks:
    - enforce_model_rate_limits
  redis_host: redis.example.com
  redis_port: 6379
  redis_password: your-password

여러 LiteLLM 인스턴스에서의 로드 밸런싱 (Kubernetes · Auto Scaling)

여러 litellm 인스턴스에 걸쳐 rpm/tpm을 공유하려면 redis_host, redis_password, redis_port를 넘겨주면 돼요. LiteLLM이 Redis로 rpm/tpm 사용량을 추적해요.

배포 우선순위 (Deployment Ordering · Priority)

litellm_params에 order를 지정해 배포 우선순위를 정할 수 있어요. 값이 낮을수록 우선순위가 높아요. 여러 배포가 같은 order를 공유하면 라우팅 전략이 그중에서 골라요.

order 기반 페일오버는 어떻게 동작하나요?

order=1 배포에 대한 요청이 실패하면(연결 오류, 404, 429 등) 라우터가 자동으로 order=2 배포를, 그다음 order=3 배포를 시도해요. 각 order 레벨은 다음 레벨로 넘어가기 전에 각자 고유한 재시도 횟수를 가져요.

429(속도 제한) 오류의 경우엔 실패한 배포가 즉시 쿨다운에 들어가요. 모든 order=1 배포가 쿨다운 상태면, 페일오버 경로를 기다릴 필요 없이 재시도 중에 바로 order=2 배포를 골라요.

Responses API 고려사항

OpenAI의 Responses API를 서로 다른 API 키(예: 다른 Azure 지역 또는 조직)를 가진 배포들 간에 로드 밸런싱할 때는 주의가 필요해요. rs_... reasoning 항목 같은 암호화된 콘텐츠는 그걸 만든 API 키로만 해독할 수 있거든요. 그래서 암호화된 콘텐츠가 들어 있는 요청은 그걸 만든 배포로 라우팅하고, 나머지 요청은 평소처럼 로드 밸런싱을 계속하게 해요(Encrypted Content Affinity 기능).

로드 밸런싱