팀/프로젝트별 자격 증명 라우팅

팀/프로젝트별 자격 증명 라우팅 (Per-Team/Project Credential Routing)

어느 팀이나 프로젝트가 요청하는지에 따라 같은 모델을 서로 다른 LLM 공급자 엔드포인트(예: 다른 Azure 인스턴스)로 라우팅해요.

출처: 문서

본문

개요 (Overview)

멀티 테넌트 배포에서 서로 다른 팀이 같은 모델 이름(예: gpt-5.6-terra)을 서로 다른 공급자 엔드포인트에 보내야 하는 경우가 흔해요. 예를 들어 비용 격리, 데이터 상주, 요율 제한 분리를 위해 사업부별로 분리된 Azure OpenAI 인스턴스를 쓰는 경우예요.

자격 증명 라우팅을 사용하면 모델 정의를 중복하거나 팀별로 별도 모델 그룹을 만들지 않고도, 기존 credentials 테이블을 사용해 팀/프로젝트 메타데이터에서 이를 구성할 수 있어요.

Hotel Team → gpt-5.6-terra → https://hotel-eastus.openai.azure.com/
Flight Team → gpt-5.6-terra → https://flight-centralus.openai.azure.com/

우선순위 체인 (Precedence Chain)

요청이 들어오면 시스템은 이 우선순위 체인을 따라가요 (첫 매치가 이김):

1. 클라이언트측 자격 증명 — 요청 본문에 전달된 api_base/api_key (문서)
2. 프로젝트 모델별 — 프로젝트의 model_config에서 이 정확한 모델에 대한 재정의
3. 프로젝트 기본 — 프로젝트의 model_config의 defaultconfig
4. 팀 모델별 — 팀의 model_config에서 이 정확한 모델에 대한 재정의
5. 팀 기본 — 팀의 model_config의 defaultconfig
6. 배포 기본 — config.yaml에 구성된 모델의 litellm_params

빠른 시작 (Quick Start)

1단계: 자격 증명 생성

Azure 엔드포인트 자격 증명을 credentials 테이블에 저장하세요. UI 또는 API로 할 수 있어요:

# Hotel 팀의 Azure 엔드포인트용 자격 증명 생성
curl -X POST 'http://0.0.0.0:4000/credentials' \
-H "Authorization: Bearer ***" \
-H 'Content-Type: application/json' \
-d '{
    "credential_name": "hotel-azure-eastus",
    "credential_values": {
        "api_base": "https://hotel-eastus.openai.azure.com/",
        "api_key": "«redacted:sk-…»"
    }
}'

# Flight 팀의 Azure 엔드포인트용 자격 증명 생성
curl -X POST 'http://0.0.0.0:4000/credentials' \
-H "Authorization: Bearer ***" \
-H 'Content-Type: application/json' \
-d '{
    "credential_name": "flight-azure-centralus",
    "credential_values": {
        "api_base": "https://flight-centralus.openai.azure.com/",
        "api_key": "«redacted:sk-…»"
    }
}'

2단계: 팀에 model_config 설정

팀의 메타데이터에 자격 증명을 이름으로 참조하는 model_config 키를 추가하세요:

# Hotel 팀 — 모든 모델의 기본 Azure 엔드포인트
curl -X PATCH 'http://0.0.0.0:4000/team/update' \
-H "Authorization: Bearer ***" \
-H 'Content-Type: application/json' \
-d '{
    "team_id": "hotel-team-id",
    "metadata": {
        "model_config": {
            "defaultconfig": {
                "azure": {
                    "litellm_credentials": "hotel-azure-eastus"
                }
            }
        }
    }
}'

# Flight 팀 — 모든 모델의 기본 Azure 엔드포인트
curl -X PATCH 'http://0.0.0.0:4000/team/update' \
-H "Authorization: Bearer ***" \
-H 'Content-Type: application/json' \
-d '{
    "team_id": "flight-team-id",
    "metadata": {
        "model_config": {
            "defaultconfig": {
                "azure": {
                    "litellm_credentials": "flight-azure-centralus"
                }
            }
        }
    }
}'

3단계: 요청 보내기

API 키의 팀에 따라 요청이 자동으로 올바른 Azure 엔드포인트로 라우팅돼요:

# Hotel 팀 API 키로 요청 → hotel-eastus.openai.azure.com으로 라우팅
curl http://localhost:4000/v1/chat/completions \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer ***' \
-d '{"model": "gpt-5.6-terra", "messages": [{"role": "user", "content": "Hello"}]}'
# Flight 팀 API 키로 요청 → flight-centralus.openai.azure.com으로 라우팅
curl http://localhost:4000/v1/chat/completions \
-H 'Content-Type: application/json' \
-H 'Authorization: Bearer ***' \
-d '{"model": "gpt-5.6-terra", "messages": [{"role": "user", "content": "Hello"}]}'

모델별 재정의 (Per-Model Overrides)

나머지에는 기본을 유지하면서 특정 모델에 대해 다른 자격 증명을 설정할 수 있어요:

curl -X PATCH 'http://0.0.0.0:4000/team/update' \
-H "Authorization: Bearer ***" \
-H 'Content-Type: application/json' \
-d '{
    "team_id": "hotel-team-id",
    "metadata": {
        "model_config": {
            "defaultconfig": {
                "azure": {
                    "litellm_credentials": "hotel-azure-eastus"
                }
            },
            "gpt-5.6-terra": {
                "azure": {
                    "litellm_credentials": "hotel-azure-westus"
                }
            }
        }
    }
}'

이 콘피그로:

• gpt-5.6-terra 요청 → hotel-azure-westus 자격 증명 (모델별)
• 다른 모든 모델 → hotel-azure-eastus 자격 증명 (기본)

프로젝트 수준 재정의 (Project-Level Overrides)

프로젝트는 팀의 model_config를 상속하되 프로젝트 수준에서 재정의할 수 있어요. 프로젝트 재정의가 팀 재정의보다 우선해요.

# 프로젝트가 모든 모델에 대해 팀 기본값을 재정의
curl -X PATCH 'http://0.0.0.0:4000/project/update' \
-H "Authorization: Bearer ***" \
-H 'Content-Type: application/json' \
-d '{
    "project_id": "hotel-rec-app-id",
    "metadata": {
        "model_config": {
            "defaultconfig": {
                "azure": {
                    "litellm_credentials": "hotel-rec-azure"
                }
            },
            "gpt-4-vision": {
                "azure": {
                    "litellm_credentials": "hotel-rec-vision"
                }
            }
        }
    }
}'

전체 예시: 두 프로젝트를 가진 Hotel 팀 (Full Example: Hotel Team with Two Projects)

설정:

• Hotel 팀: 기본 hotel-azure-eastus, gpt-5.6-terra 재정의를 hotel-azure-westus로
• Hotel Rec App (프로젝트): 기본 hotel-rec-azure, GPT-4-Vision 재정의를 hotel-rec-vision으로
• Hotel Review App (프로젝트): 재정의 없음, 팀 콘피그 상속

해석 (Resolution):

model_config 스키마 (model_config Schema)

model_config 키는 팀/프로젝트 메타데이터의 JSON 객체예요:

{
    "model_config": {
        "defaultconfig": {
            "<provider>": {
                "litellm_credentials": "<credential-name>"
            }
        },
        "<model-name>": {
            "<provider>": {
                "litellm_credentials": "<credential-name>"
            }
        }
    }
}

자격 증명 값 (Credential Values)

참조된 자격 증명은 다음의 어떤 조합이든 포함할 수 있어요:

자격 증명에 있는 키만 적용돼요. 요청에 이미 있는 키(예: 클라이언트측 api_version)는 절대 덮어쓰지 않아요.

기능 활성화 (Enabling the Feature)

이 기능은 기본적으로 비활성화되어 있으며 명시적으로 활성화해야 해요.

config.yaml

litellm_settings:
  enable_model_config_credential_overrides: true

환경 변수

export LITELLM_ENABLE_MODEL_CONFIG_CREDENTIAL_OVERRIDES=true

info

특징 플래그는 팀/프로젝트 메타데이터의 model_config 항목이 효과를 내기 전에 활성화되어야 해요. 없으면 자격 증명 라우팅은 완전히 무활동이에요. 메타데이터를 읽지 않고 자격 증명을 해석하지 않아요.

관련 문서 (Related Documentation)

• Adding LLM Credentials — 재사용 가능한 자격 증명 생성 및 관리
• Project Management — 프로젝트 계층과 API
• Team Budgets — 팀 수준 예산 관리
• Clientside LLM Credentials — 요청 본문에 자격 증명 전달
• Credential Usage Tracking — 자격 증명별 지출 추적