CELL AI DEVLOG

1~3편에서 라우팅 전략·폴백·프로덕션 배포를 다뤘습니다. 4편은 그 다음 단계입니다. 6개의 기본 전략이 모두 "어느 배포로 보낼까"를 결정했다면, 여기서는 "어떤 모델 티어로 보낼까"를 결정하는 콘텐츠 기반 라우팅을 다룹니다. 그리고 프로덕션 현장에서 실제로 쓰이는 세 가지 아키텍처 패턴 — 고가용성 멀티 리전, 비용 최적화 3티어, 하이브리드 클라우드+로컬 — 을 완전한 config.yaml과 함께 정리합니다. 시리즈의 마무리로, LiteLLM의 한계도 솔직하게 다룹니다.이 포스트 한 줄 요약 → Tag 라우팅: x-litellm-tags 헤더로 요청을 특정 배포 그룹으로 분류 → 복잡도 라우터: 임베딩 API 호출 없이 규칙 기반으로 서브밀리초 분류 → 시맨틱 라우터: 발화(utterance) 임..

1편에서 라우팅 전략을, 2편에서 폴백과 장애 대응을 다뤘습니다. 코드는 완성됐지만 프로덕션에 올리면 달라지는 게 있습니다. 단일 프로세스로 돌리면 멀티 인스턴스 간 RPM/TPM 상태를 공유할 수 없고, API 키를 코드에 박으면 팀원에게 공유할 수 없고, 누가 얼마나 쓰는지 보이지 않으면 월말에 청구서로 알게 됩니다. 3편은 그 세 가지를 해결합니다. Redis로 멀티 인스턴스 상태 동기화, Docker/K8s Proxy 서버 배포, Virtual Key로 팀별 예산과 Rate Limit 관리, Langfuse·Prometheus 연동까지 — 프로덕션에서 LiteLLM이 실제로 어떻게 운영되는지 전부 다룹니다.이 포스트 한 줄 요약 → Redis 없이 멀티 인스턴스 → 각 인스턴스가 독립적으로 RPM..

2024년 4월 9일 UTC 13:00, Anthropic 클러스터에 장애가 발생했습니다. 단일 Anthropic 키에 의존하던 한 팀의 고객 지원 코파일럿은 1시간 동안 완전히 다운됐습니다. 엔지니어가 수동으로 SDK의 base_url을 OpenAI로 바꾸고 재배포하는 데 14분이 걸렸습니다. 같은 해 11월 OpenAI 장애로 2시간, 2025년 2월 Gemini 장애로 반나절. 이 팀이 LiteLLM 폴백을 설정했다면 세 번의 다운타임 모두 자동으로 흡수됐을 것입니다. 폴백은 "있으면 좋은 것"이 아닙니다. 1편의 라우팅 전략이 정상 트래픽을 분산한다면, 2편의 폴백·재시도·쿨다운은 장애 시 시스템을 살려두는 안전망입니다. 이 포스트 한 줄 요약 → 폴백 3종: fallbacks (일반 오류) · ..

LLM 프로덕션에서 단일 엔드포인트에 의존하는 순간 리스크가 시작됩니다. Azure OpenAI 리전이 다운되거나, OpenAI가 Rate Limit을 내뱉거나, 트래픽 폭증으로 TPM 한도가 터질 때 — 이 모든 상황을 코드 한 줄 바꾸지 않고 흡수하는 것이 LiteLLM Router입니다. 100개 이상의 LLM 프로바이더를 단일 OpenAI 호환 인터페이스로 추상화하면서, 6가지 라우팅 전략과 자동 폴백·재시도를 제공합니다. 이 편에서는 Router의 내부 구조와 6가지 전략 각각이 어떻게 동작하는지, 언제 무엇을 써야 하는지를 실전 코드와 함께 완전히 정리합니다.이 포스트 한 줄 요약 → LiteLLM Router: 동일 model_name으로 여러 배포를 등록하면 자동 로드밸런싱 → 핵심 내부 ..