공동 책임 모델

공동 책임 모델 (Shared Responsibility Model)

LiteLLM을 직접 호스팅할 때, 어떤 문제를 LiteLLM이 디버깅하고 어떤 문제를 사용자가 디버깅해야 하는지 구분해주는 문서예요. 제품의 문서화된 동작은 LiteLLM이, 실행 환경과 추가 코드는 사용자가 책임지는 구조를 설명할게요.

출처: 문서

본문

LiteLLM을 직접 호스팅하면, 여러분은 소프트웨어를 실행하고 우리는 그걸 만드는 구조예요. 이 분할이 누가 무엇을 디버깅할지 결정해요. 여기서 어떤 문제가 우리 책임이고 어떤 문제가 여러분 책임인지 설명해서, 보고가 올바른 팀에 도달하도록 해요.

요약하면, 우리는 이 사이트에 문서화된 제품 동작을 소유하고, 여러분은 그것이 실행되는 환경 + 여러분이 추가하는 코드를 소유해요.

영역 소유자
문서화된 기능과 엔드포인트의 정확성 LiteLLM
문서화된 기능 세트 내 메모리 누수, 중단, 안정성 문제 LiteLLM
문서화된 대로의 제공자 변환, 비용 추적, 라우팅 동작 LiteLLM
보안 패치 및 공식 Docker 이미지와 Helm 차트 LiteLLM
인스턴스의 업타임과 그 아래의 인프라 사용자
커스텀 콜백, 커스텀 가드레일, 커스텀 인증 및 주입한 기타 코드 사용자
권장 경로와 다른 방식(자체 Dockerfile, 차트, 베이스 이미지)으로 배포해 생긴 인프라 문제 사용자
업스트림에 없는 포크의 자체 패치로 도입된 버그 사용자
제공자 계정, 할당량, 제공자 측 장애 사용자

우리(LiteLLM)의 책임

우리는 제품이 동작하도록 하는 책임이 있어요. 이 사이트에 문서화된 모든 기능은 문서화된 대로 동작해야 해요. 그렇지 않으면 그것은 우리의 버그이고, 이슈를 열거나 엔터프라이즈 지원 채널에 올려야 해요.

그 책임은 정확성뿐 아니라 안정성도 포함해요. 문서화된 기능 세트 내 메모리 증가, 파일 디스크립터/연결 누수, 교착 상태, 중단, 처리량 회귀는 우리가 진단하고 고칠 책임이에요. 이것은 여러분이 상호작용하는 인터페이스를 포함해요: 공개 HTTP 표면은 API Stability Policy로 규제되고, 버전 번호와 패치/마이너 범프가 의미하는 바는 Release Cycle에, 베타 기능이 Enterprise로 이동하는 것은 Migration Policy에 문서화되어 있어요. 우리는 Production Deployment에 설명된 공식 Docker 이미지, Helm 차트, Terraform 모듈을 유지하고, 지원 버전 기간 동안 보안 패치를 제공해요.

수명이 끝난(EOL) 버전을 쓰고 있다면, 최신 버그 수정과 보안 패치를 적용하기 위해 우선 업그레이드를 권장해요.

여러분(사용자)의 책임

애플리케이션 자체의 안정성 결함 외에는 인스턴스를 항상 가동 상태로 유지하는 것이 여러분의 책임이에요. 즉 용량과 크기 조정, 재시작과 롤아웃, 헬스 체크와 오토스케일링, 그리고 Postgres, Redis, 네트워크, 오케스트레이터의 건강이 포함돼요. Production Best Practices, Database Sizing, Redis Sizing이 권장하는 설정과 크기를 다뤄요. 헬스 엔드포인트는 여러분의 프로브용이에요.

게이트웨이에 도입한 커스텀 코드도 여러분의 책임이에요. 커스텀 콜백, 커스텀 가드레일, 커스텀 인증, 커스텀 SSO, 훅, 플러그인은 프록시 프로세스 안에서 실행되므로, 그 코드의 블로킹 호출, 무제한 캐시, 누출된 클라이언트는 프록시가 올바르게 동작하더라도 프록시 지연 시간, 메모리 증가, 중단으로 나타날 수 있어요. 여러분 핸들러의 로직과 성능·메모리 동작은 여러분 소유예요. 사이드카, 앞의 프록시, 요청을 변형하는 추가 미들웨어처럼 게이트웨이를 둘러싼 것도 마찬가지예요.

포크를 운영하는 것도 같아요. 같은 버전의 수정되지 않은 업스트림에서도 재현되는 버그는 분명히 우리가 디버깅하고 고칠 책임이에요. 여러분의 패치로 도입된 버그는 여러분 소유이며, 더 새로운 릴리스에 리베이스하면서 그 패치가 계속 동작하도록 유지하는 것도 여러분 책임이에요. 업스트림에 없어서 패치로 우회했다면 이슈를 만들거나 패치를 풀 리퀘스트로 보내세요. 일반적인 개선이라면 업스트림에 추가해 드릴게요.

또한 배포 전략이 권장 경로를 따르지 않는다면 그 경로는 여러분이 유지할 책임이에요. 많은 팀이 자체 이미지를 만들고, 자체 차트를 작성하고, 베이스 이미지나 Python 버전을 바꾸고, 자체 의존성 세트를 고정하고, 자체 프로세스 매니저와 워커 수를 운영해요. 그것은 지원되는 소프트웨어 사용법이에요. 동시에 깨진 빌드, 누락된 시스템 라이브러리, 불일치된 의존성, 컨테이너 메모리 한도의 OOMKill, 잘못 구성된 워커 수 등은 여러분이 소유해요. 참고:

  • Production Deployment
  • Docker Quick Start
  • Server Tuning

우리에게 이슈 제출하기

다음을 포함해 주세요:

  • LiteLLM 버전
  • 배포 방식
  • 편집된(redacted) config
  • 정확한 요청
  • 상세 디버그 로깅을 켠 전체 오류 또는 트레이스백
  • 안정성 보고에는 시간 경과에 따른 메모리/지연 곡선, 요청 속도, 워커와 컨테이너 한도를 포함해 주세요.
  • 메모리와 지연 문제에는 Pyroscope 프로파일링 결과를 포함해 주세요.

버그와 기능 요청은 GitHub 이슈로 열어 주세요. 엔터프라이즈 고객은 전용 지원 채널도 사용할 수 있어요. 시간과 SLA 옵션은 Professional Support를 참고하세요.

더 알아보기 (Learn more)