LiteLLM 프록시: 100개 이상의 LLM을 위한 단일 API (15분 도커 설정)

LiteLLM 프록시: 100개 이상의 LLM을 위한 단일 API (15분 도커 설정)

팀원들이 Slack 다이렉트 메시지(DM)에서 OpenAI API 키를 공유하고 있습니까? 지난 화요일에 누가 $400를 지출했는지 아무도 모릅니다. 속도 제한도 없고, 제공업체에 장애가 발생했을 때 대체 수단도 없으며, GPT-4o에서 Claude로 전환하려면 열두 군데의 코드를 수정해야 합니다. 익숙한 상황인가요? 자체 호스팅 LLM 게이트웨이는 이 모든 문제를 해결하며, LiteLLM 프록시는 가장 인기 있는 오픈소스 옵션으로, 100개 이상의 LLM 제공업체로 요청을 라우팅하는 단일 OpenAI 호환 엔드포인트를 제공합니다.

이 가이드에서는 완전한 litellm 프록시 설정 과정을 다룹니다. PostgreSQL과 함께 사용하는 Docker Compose, 예산이 설정된 가상 팀 키, 비용 추적, 속도 제한, 그리고 Claude Code와 Cursor 같은 AI IDE 연결 방법을 포함합니다. LLM 게이트웨이 도구를 평가 중이라면, 처음부터 프로덕션 환경까지 구축할 수 있는 이 실습 튜토리얼이 도움이 될 것입니다.

시작하기 전 중요한 참고 사항: LiteLLM의 SDK(Python 라이브러리)와 프록시 서버는 서로 다른 것입니다. SDK는 Python에서 여러 LLM API를 호출하는 개별 개발자를 위한 것입니다. 반면 프록시는 팀을 위해 설계되었으며, 앱과 LLM 제공업체 사이에 서버로 배치됩니다. 스크립트를 작성하는 솔로 개발자라면 SDK만으로 충분합니다. 하지만 팀의 키, 예산 및 액세스를 관리해야 한다면 프록시가 필요합니다. 여기서는 바로 그 프록시를 설정하는 방법을 다룹니다.

한눈에 보는 LiteLLM 프록시

배포 방법을 비교하면 다음과 같습니다.

대부분의 팀에게는 PostgreSQL과 함께 사용하는 Docker Compose가 최적의 선택입니다. 이를 목표로 구축하겠지만, 먼저 60초 안에 프록시를 실행해 보겠습니다.

필수 조건 및 환경 설정

시작하기 전에 다음 사항이 준비되어 있는지 확인하세요.

• Docker 및 Docker Compose 설치됨 (Docker Desktop에는 둘 다 포함됨)
• 최소 하나의 LLM API 키 (OpenAI, Anthropic 또는 로컬 Ollama 인스턴스)
• 기본적인 터미널 / CLI 숙련도

Docker가 준비되었는지 확인하고 API 키를 export하세요.

# Check Docker is installed
docker --version
docker compose version

# Export your LLM API keys (add to your shell profile for persistence)
export OPENAI_API_KEY="sk-..."
export ANTHROPIC_API_KEY="sk-ant-..."

# Optional: set a master key for your proxy (you'll need this later)
export LITELLM_MASTER_KEY="sk-master-your-secret-key"

끝입니다. 특별한 Python 버전이나 OS별 도구가 필요하지 않습니다. 머신에서 Docker가 실행된다면 준비 완료입니다.

빠른 시작, 60초 만에 첫 LiteLLM 프록시 실행하기

GPT-4o와 함께 프록시를 시작하는 명령어 하나:

docker run -d \
  --name litellm-proxy \
  -p 4000:4000 \
  -e OPENAI_API_KEY=$OPENAI_API_KEY \
  -e LITELLM_MASTER_KEY=$LITELLM_MASTER_KEY \
  ghcr.io/berriai/litellm:main-stable \
  --model openai/gpt-4o

curl로 테스트하기:

curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o",
    "messages": [{"role": "user", "content": "Say hello from LiteLLM"}]
  }'

또는 Python에서 테스트하기:

from openai import OpenAI

# Point the standard OpenAI SDK at your proxy
client = OpenAI(
    api_key="sk-master-your-secret-key",
    base_url="http://localhost:4000/v1"
)

response = client.chat.completions.create(
    model="openai/gpt-4o",
    messages=[{"role": "user", "content": "Say hello from LiteLLM"}]
)
print(response.choices[0].message.content)

무슨 일이 일어났을까요? 코드는 표준 OpenAI SDK 형식을 사용하여 localhost:4000과 통신합니다. 프록시는 요청을 받아 실제 키를 사용하여 OpenAI의 API로 전달하고 응답을 반환합니다. 애플리케이션 코드는 실제 API 키에 직접 접근하지 않습니다.

이것이 핵심 개념입니다. 이제 프로덕션 환경을 구축해 보겠습니다.

PostgreSQL을 사용한 프로덕션 Docker Compose 설정

단일 docker run 명령어는 테스트에는 적합하지만, 프로덕션 팀은 지속적인 비용 추적, 가상 키 및 적절한 데이터베이스 저장이 필요합니다. 이는 PostgreSQL과 함께 Docker Compose를 사용해야 함을 의미합니다.

Docker Compose 파일

# docker-compose.yml
version: "3.9"

services:
  litellm:
    image: ghcr.io/berriai/litellm:main-stable
    container_name: litellm-proxy
    ports:
      - "4000:4000"         # Proxy API port
    volumes:
      - ./config.yaml:/app/config.yaml   # Mount your config file
    environment:
      - LITELLM_MASTER_KEY=${LITELLM_MASTER_KEY}
      - OPENAI_API_KEY=${OPENAI_API_KEY}
      - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
      - DATABASE_URL=postgresql://litellm:litellm_password@postgres:5432/litellm
      - LITELLM_SALT_KEY=${LITELLM_SALT_KEY:-sk-salt-random-string}
    command: --config /app/config.yaml --detailed_debug
    depends_on:
      postgres:
        condition: service_healthy
    restart: unless-stopped

  postgres:
    image: postgres:16-alpine
    container_name: litellm-db
    environment:
      POSTGRES_DB: litellm
      POSTGRES_USER: litellm
      POSTGRES_PASSWORD: litellm_password
    volumes:
      - litellm_pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U litellm"]
      interval: 5s
      timeout: 5s
      retries: 5
    restart: unless-stopped

volumes:
  litellm_pgdata:

LITELLM_SALT_KEY는 데이터베이스의 가상 키 데이터를 암호화합니다. LiteLLM 프로덕션 모범 사례 문서에서는 모든 팀 배포에 이를 설정할 것을 권장합니다.

스택 시작하기

# Create a .env file with your keys (don't commit this to git)
echo "LITELLM_MASTER_KEY=sk-master-your-secret" > .env
echo "OPENAI_API_KEY=sk-..." >> .env
echo "ANTHROPIC_API_KEY=sk-ant-..." >> .env
echo "LITELLM_SALT_KEY=sk-salt-$(openssl rand -hex 16)" >> .env

# Start everything
docker compose up -d

# Check logs
docker compose logs -f litellm

모든 것이 작동하는지 확인하기

# Health check
curl http://localhost:4000/health

# Test a request
curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "gpt-4o", "messages": [{"role": "user", "content": "ping"}]}'

성공적인 응답이 표시되면 프로덕션 스택이 실행 중입니다. PostgreSQL은 컨테이너 재시작 시에도 모든 비용 데이터, 가상 키 및 사용량 메트릭을 영구적으로 저장합니다.

결론: Docker Compose + PostgreSQL은 권장되는 프로덕션 설정입니다. 약 10분의 작업으로 영구 저장소, 비용 추적 및 가상 키를 제공합니다. 나중에 자동 확장이 필요하면 Docker 배포 문서에서 Kubernetes와 Helm을 확인할 수 있습니다.

config.yaml walkthrough, 실제 다중 제공업체 설정

대부분의 튜토리얼은 모델이 하나인 config.yaml을 보여줍니다. 다음은 세 개의 제공업체, 폴백 및 로드 밸런싱이 포함된 실제 팀 구성 파일의 예시입니다.

구성 파일

# config.yaml -- Real multi-provider setup
model_list:
  # Primary: OpenAI GPT-4o
  - model_name: gpt-4o          # The name YOUR code uses
    litellm_params:
      model: openai/gpt-4o      # The actual provider/model
      api_key: os.environ/OPENAI_API_KEY

  # Secondary: Anthropic Claude
  - model_name: claude-sonnet
    litellm_params:
      model: anthropic/claude-sonnet-4-20250514
      api_key: os.environ/ANTHROPIC_API_KEY

  # Local: Ollama for development / cost-free testing
  - model_name: local-llama
    litellm_params:
      model: ollama/llama3.1
      api_base: http://host.docker.internal:11434

  # Fallback: route "gpt-4o" to Claude if OpenAI is down
  - model_name: gpt-4o
    litellm_params:
      model: anthropic/claude-sonnet-4-20250514
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  routing_strategy: least-busy    # Load balance across same-name models
  num_retries: 3
  retry_after: 5                  # Seconds between retries
  fallbacks: [{"gpt-4o": ["claude-sonnet"]}]

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL

모델 별칭 및 라우팅

설정 파일에서 gpt-4o가 두 번 나타나는 것을 주목하세요. 한 번은 OpenAI를 가리키고, 다른 한 번은 Anthropic을 가리킵니다. 코드에서 gpt-4o를 요청하면 LiteLLM은 먼저 OpenAI를 시도합니다. 실패하면 fallbacks 설정이 자동으로 Claude로 라우팅합니다. 애플리케이션 코드는 전혀 변경되지 않습니다.

vLLM이나 SGLang 같은 프로덕션 추론 백엔드를 사용한다면, 동일한 방식으로 추가하고 api_base를 추론 서버로 설정하면 됩니다.

제공업체 빠른 참조

routing_strategy: least-busy 설정은 동일한 model_name을 가진 모델 간에 요청을 분산합니다. OpenAI 키가 두 개 있다면(아마도 다른 조직의 서로 다른 속도 제한을 가진 키), 둘 다 gpt-4o 아래에 나열하면 LiteLLM이 부하를 균형 있게 분배합니다.

가상 키, 예산 및 속도 제한이 있는 팀별 API 키

이 지점에서 LiteLLM은 "단순한 프록시"를 넘어 팀 관리 도구가 됩니다. 가상 키를 사용하면 각 팀원이나 서비스에 지출 한도와 속도 제한이 적용된 고유한 API 키를 발급할 수 있으며, 이 모든 것은 단일 세트의 제공업체 API 키를 통해 라우팅됩니다.

예산이 있는 팀 키 생성하기

# Create a virtual key with a $50/month budget
curl http://localhost:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "team_id": "frontend-team",
    "max_budget": 50.0,
    "budget_duration": "1mo",
    "models": ["gpt-4o", "claude-sonnet"],
    "metadata": {"purpose": "frontend AI features"}
  }'

응답에는 sk-team-abc123...와 같은 새 키가 제공됩니다. 이를 프런트엔드 팀에 전달하세요. 그들은 이를 OpenAI 키와 정확히 동일하게 사용할 수 있지만, 월 $50로 제한되며 지정된 모델에만 액세스할 수 있습니다.

속도 제한 설정하기

# Create a key with rate limits: 100 requests/minute, 50K tokens/minute
curl http://localhost:4000/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "team_id": "backend-team",
    "max_budget": 200.0,
    "budget_duration": "1mo",
    "rpm_limit": 100,
    "tpm_limit": 50000,
    "models": ["gpt-4o", "claude-sonnet", "local-llama"]
  }'

가상 키 문서에는 모든 매개변수가 설명되어 있습니다. 더 세밀한 제어를 위해 사용자별 예산 및 속도 제한을 설정할 수도 있습니다.

키 사용량 모니터링하기

import requests

# Check a key's current spend and limits
response = requests.get(
    "http://localhost:4000/key/info",
    headers={"Authorization": f"Bearer {MASTER_KEY}"},
    params={"key": "sk-team-abc123..."}
)
info = response.json()
print(f"Spent: ${info['spend']:.2f} / ${info['max_budget']:.2f}")
print(f"RPM used: {info['rpm_limit_used']} / {info['rpm_limit']}")

침해된 키를 폐기해야 하나요? API 호출 한 번으로 가능합니다.

curl -X POST http://localhost:4000/key/delete \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"keys": ["sk-team-abc123..."]}'

결론: 가상 키야말로 LiteLLM을 개인용 프록시가 아닌 팀 도구로 만듭니다. 가상 키가 없으면 코드와 LLM 사이에 홉(hop)을 하나 추가하는 것에 불과합니다. 하지만 가상 키를 사용하면 액세스 제어, 예산 집행 및 사용량 귀속이 가능해져 CFO가 당황하지 않도록 할 수 있습니다.

비용 추적 및 LiteLLM 대시보드

PostgreSQL이 연결되면 LiteLLM은 모든 요청의 비용을 자동으로 추적합니다. 별도의 구성이 필요하지 않으며, 지원되는 모든 모델의 토큰당 가격을 알고 있습니다.

대시보드

마스터 키로 로그인하여 http://localhost:4000/ui에서 내장 UI에 액세스하세요. 다음 정보를 확인할 수 있습니다.

• 모든 팀 및 키의 총 지출액
• 모델별 분류, 어떤 모델이 예산을 소모하고 있는지
• 팀별 지출, 누가 무엇을 사용하고 있는지
• 시간 경과에 따른 요청 볼륨

LLM API 비용 절감에 진심인 팀이라면 대시보드 자체만으로도 프록시 실행을 정당화합니다. 더 깊은 분석을 위해 LiteLLM을 Langfuse나 Helicone 같은 외부 AI 관찰 플랫폼에 연결할 수도 있습니다.

제공업체별 비용 비교

다음은 주요 모델의 백만 토큰당 비용입니다 (2026년 4월 기준).

대시보드에서 팀별로 구분된 이러한 숫자를 보면, "이 사용 사례에는 더 저렴한 모델을 사용해야 할까?"라는 논의가 매우 구체적으로 이루어집니다.

결론: 월 LLM API 지출이 $100 이상인 팀이라면 비용 추적 alone으로도 프록시 도입을 정당화합니다. 측정할 수 없는 것은 최적화할 수 없습니다.

AI IDE 연결, Claude Code, Cursor 및 Continue

대부분의 LiteLLM 가이드가 완전히 건너뛰는 부분이 있습니다. AI 코딩 도구를 프록시로 향하도록 설정할 수 있다는 점입니다. 하나의 프록시, 모든 IDE 도구, 통합 청구.

Claude Code

# Set Claude Code to use your LiteLLM proxy
export ANTHROPIC_BASE_URL=http://localhost:4000/v1
export ANTHROPIC_API_KEY=sk-team-your-virtual-key

끝입니다. Claude Code는 요청을 프록시로 보내며, 프록시는 이를 Anthropic(또는 설정에 지정된 곳)으로 라우팅하면서 가상 키 아래에서 비용을 추적합니다.

Cursor

Cursor 설정에서 custom OpenAI-compatible 엔드포인트를 추가하세요.

{
  "openai.apiBaseUrl": "http://localhost:4000/v1",
  "openai.apiKey": "sk-team-your-virtual-key"
}

Continue (VS Code)

Continue의 config.json에서:

{
  "models": [
    {
      "title": "GPT-4o via LiteLLM",
      "provider": "openai",
      "model": "gpt-4o",
      "apiBase": "http://localhost:4000/v1",
      "apiKey": "sk-team-your-virtual-key"
    }
  ]
}

왜手間을 들일까요? 이제 모든 개발자의 IDE 사용량이 프록시를 통과하기 때문입니다. AI 코딩 어시스턴트에 대한 개인별 비용 추적, 코딩 세션 중 누군가가 실수로 $500를 소모하지 않도록 하는 속도 제한, 그리고 더 나은 옵션을 찾았을 때 모델을 전환할 수 있는 단일 장소를 확보하게 됩니다.

일반적인 문제 해결

"Config file not found" (구성 파일을 찾을 수 없음)

일반적으로 Docker의 볼륨 마운트 경로가 잘못되었음을 의미합니다. config.yaml이 마운트하는 디렉토리에 있는지 확인하세요.

# Check the file exists where you think it does
ls -la ./config.yaml

# The volume mount in docker-compose.yml should match
# volumes:
#   - ./config.yaml:/app/config.yaml

PostgreSQL에 대한 "Connection refused" (연결 거부)

Docker 네트워킹은 누구나 한 번쯤 겪는 함정입니다. LiteLLM이 Postgres에 도달할 수 없다면 다음 사항을 확인하세요.

• DATABASE_URL의 서비스 이름이 Docker Compose 서비스 이름(localhost가 아닌 postgres)과 일치하는지
• depends_on with condition: service_healthy가 설정되어 있는지 (LiteLLM이 Postgres가 준비될 때까지 기다리도록)
• 두 서비스가 동일한 Docker 네트워크에 있는지 (Compose에서는 기본적으로 동일함)

"Invalid API key format" (유효하지 않은 API 키 형식)

가장 흔한 혼동: LITELLM_MASTER_KEY는 관리자 작업(가상 키 생성, 대시보드 액세스)용입니다. 가상 키(sk-team-...)는 애플리케이션이 사용하는 것입니다. 혼동하지 마세요.

"Model not found" (모델을 찾을 수 없음)

요청의 model 필드는 config.yaml의 model_name과 일치해야 합니다. 구성에서 gpt-4o를 정의했는데 코드가 openai/gpt-4o를 요청하면 일치하지 않습니다. 정확한 철자를 확인하세요.

프록시는 시작되지만 요청이 멈춤

일반적으로 방화벽 또는 포트 바인딩 문제입니다. 포트 4000이 노출되어 있고 차단되지 않았는지 확인하세요.

# Check if the port is listening
docker port litellm-proxy
# Should show: 4000/tcp -> 0.0.0.0:4000

보안: 버전 1.82.7 및 1.82.8 피하기

2026년 3월, 공급망 사고로 LiteLLM 버전 1.82.7 및 1.82.8이 영향을 받았습니다. 손상된 버전은 제거되었고, 1.83.0에서 깨끗한 릴리스가 배포되었습니다. Docker 이미지를 항상 특정 버전으로 고정하고 업그레이드 전에 공식 보안 업데이트를 확인하세요. 1.82.7 또는 1.82.8을 사용 중이라면 즉시 업데이트하세요.

어떤 LiteLLM 설정 방법을 선택해야 할까요?

이 가이드를 처음 읽는다면 Docker Compose + PostgreSQL로 시작하세요. 나중에 Kubernetes로 마이그레이션할 수 있으며, config.yaml은 동일하게 유지됩니다.

FAQ

LiteLLM 프록시는 무엇이며 어떻게 작동하나요?

LiteLLM 프록시는 애플리케이션과 OpenAI, Anthropic 같은 LLM 제공업체 사이에 위치하는 오픈소스 AI 게이트웨이 서버입니다. 단일 OpenAI 호환 엔드포인트를 노출하므로, 코드는 하나의 URL과 통신하는 동안 프록시가 백그라운드에서 라우팅, 키 관리, 비용 추적 및 폴백을 처리합니다.

Docker Compose로 LiteLLM 프록시를 어떻게 설정하나요?

LiteLLM 프록시 이미지와 PostgreSQL 데이터베이스가 포함된 docker-compose.yml을 생성하고, config.yaml을 마운트하며, API 키를 환경 변수로 설정한 후 docker compose up -d를 실행하세요. 위의 프로덕션 Docker Compose 섹션에 복사해서 붙여넣기 가능한 완전한 파일이 있습니다.

LiteLLM으로 팀 API 키를 어떻게 관리하나요?

가상 키를 사용하세요. 마스터 키로 /key/generate 엔드포인트를 호출하여 팀별 또는 사용자별 키를 생성하세요. 각 가상 키는 고유한 월별 예산, 속도 제한(RPM 및 TPM) 및 모델 액세스 제한을 가질 수 있습니다. 가상 키 섹션에서 전체 워크플로를 다룹니다.

LLM API에 비용 추적 및 속도 제한을 어떻게 추가하나요?

PostgreSQL을 프록시에 연결하면 (DATABASE_URL 통해) 비용 추적이 자동으로 발생합니다. 속도 제한의 경우, 가상 키를 생성할 때 rpm_limit 및 tpm_limit을 설정하세요. /ui의 내장 대시보드에서 팀별 및 모델별 지출을 확인할 수 있습니다.

LiteLLM 프록시를 프로덕션에서 안전하게 사용할 수 있나요?

네, 단 한 가지 주의 사항이 있습니다. 2026년 3월 공급망 사고의 영향을 받은 버전 1.82.7 및 1.82.8은 피하세요. 버전 1.83.0 이상을 사용하세요. Docker 이미지 버전을 고정하고, 암호화를 위해 LITELLM_SALT_KEY를 설정하며, 공식 프로덕션 모범 사례를 따르세요.

LiteLLM SDK와 LiteLLM 프록시의 차이점은 무엇인가요?

SDK는 코드에서 여러 LLM API를 호출하기 위한 Python 라이브러리입니다. 프록시는 전체 팀이 연결하는 독립형 서버입니다. 스크립트를 작성하는 솔로 개발자라면 SDK를 사용하세요. 팀 전체에서 공유 액세스 제어, 비용 추적 및 속도 제한이 필요하면 프록시를 사용하세요.

LiteLLM 프록시를 Ollama 및 로컬 모델과 함께 사용할 수 있나요?

물론입니다. config.yaml에 model: ollama/llama3.1 및 api_base: http://host.docker.internal:11434 (또는 Ollama 호스트) 항목을 추가하세요. 그러면 팀은 동일한 프록시 엔드포인트를 통해 로컬 모델에 액세스할 수 있어 개발 및 무료 테스트에 적합합니다.

LiteLLM 프록시 비용은 얼마인가요?

LiteLLM 프록시는 무료이며 오픈소스(MIT 라이선스)입니다. 자체 인프라에서 호스팅합니다. 유일한 비용은 서버(대부분의 팀에는 소형 VPS로 충분함)와 이미 지불 중인 LLM API 비용입니다. 자체 호스팅을 원하지 않는다면 BerriAI에서 관리형 클라우드 버전도 제공합니다.

LiteLLM은 어떤 제공업체를 지원하나요?

100개 이상으로, OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, Ollama, Hugging Face, Cohere, Replicate 등이 포함됩니다. 전체 목록은 LiteLLM GitHub 저장소에서 확인할 수 있습니다.

LiteLLM 프록시를 안전하게 업데이트하는 방법은 무엇인가요?

Docker 이미지 태그에서 항상 특정 버전을 고정하세요 (예: ghcr.io/berriai/litellm:v1.83.2-stable). 업그레이드 전에 변경 로그에서 파괴적 변경 사항을 확인하세요. 프로덕션에서는 절대 latest를 사용하지 마세요. 또한 새 버전이 보안 권고 목록에 없는지 항상 확인하세요. 2026년 3월 사건은 신뢰할 수 있는 패키지조차 손상될 수 있음을 입증했습니다.

최종 결론 및 다음 단계

팀이 LLM API에 비용을 지출하고 있는데 아직 프록시가 없다면, 오늘 Docker Compose + Postgres로 시작하세요. 설정에는 15분이 소요되며, 종료 시점에는 비용 가시성과 액세스 제어를 확보하게 됩니다.

실행 중이라면 콘텐츠 필터링 및 안전 검사를 위해 LLM 파이프라인에 가드레일 추가를 탐색하세요. 프록시는 기반이며, 나머지 모든 것은 그 위에 구축됩니다.

출처

• LiteLLM 프록시 빠른 시작, 공식 문서
• LiteLLM Docker 배포 가이드
• LiteLLM 가상 키 문서
• LiteLLM 프로덕션 모범 사례
• LiteLLM 보안 업데이트, 2026년 3월
• BerriAI/litellm, GitHub 저장소