모델 저장소

모델 저장소 (Model Repository)

모델 저장소를 처음 설정하는 건가요? 이 튜토리얼들을 확인해 Triton 여정을 시작해 보세요!

Triton Inference Server는 서버를 시작할 때 지정한 하나 이상의 모델 저장소에서 모델을 서빙해요. Triton이 실행되는 동안 서빙 중인 모델은 Model Management에서 설명한 대로 수정할 수 있어요.

저장소 레이아웃 (Repository Layout)

이 저장소 경로들은 --model-repository 옵션으로 Triton을 시작할 때 지정해요. --model-repository 옵션은 여러 저장소의 모델을 포함하도록 여러 번 지정할 수 있어요. 모델 저장소를 구성하는 디렉토리와 파일은 필수 레이아웃을 따라야 해요. 저장소 경로가 다음과 같이 지정됐다고 가정할게요.

$ tritonserver --model-repository=<model-repository-path>

해당 저장소 레이아웃은 다음과 같아야 해요:

  <model-repository-path>/
    <model-name>/
      [config.pbtxt]
      [<output-labels-file> ...]
      [configs]/
        [<custom-config-file> ...]
      <version>/
        <model-definition-file>
      <version>/
        <model-definition-file>
      ...
    <model-name>/
      [config.pbtxt]
      [<output-labels-file> ...]
      [configs]/
        [<custom-config-file> ...]
      <version>/
        <model-definition-file>
      <version>/
        <model-definition-file>
      ...
    ...

최상위 모델 저장소 디렉토리 안에는 0개 이상의 하위 디렉토리가 있어야 해요. 각 하위 디렉토리는 해당 모델의 저장소 정보를 담아요. config.pbtxt 파일은 모델의 모델 구성을 설명해요. 일부 모델에서는 config.pbtxt가 필수이고 다른 모델에서는 선택적이에요. 자세한 내용은 Auto-Generated Model Configuration을 참고하세요.

각 디렉토리는 선택적 하위 디렉토리 configs를 포함할 수 있어요. configs 디렉토리 안에는 .pbtxt 파일 확장자를 가진 0개 이상의 이 있어야 해요. Triton이 커스텀 모델 구성을 어떻게 처리하는지에 대한 자세한 내용은 Custom Model Configuration을 참고하세요.

각 디렉토리는 모델의 버전을 나타내는 숫자 하위 디렉토리를 최소 하나는 가져야 해요. Triton이 모델 버전을 어떻게 처리하는지에 대한 자세한 내용은 Model Versions을 참고하세요. 각 모델은 특정 backend에 의해 실행돼요. 각 버전 하위 디렉토리 안에는 해당 backend가 필요로 하는 파일이 있어야 해요. 예를 들어 TensorRT, PyTorch, ONNX, OpenVINO 같은 프레임워크 backend를 사용하는 모델은 프레임워크별 모델 파일을 제공해야 해요.

모델 저장소 위치 (Model Repository Locations)

Triton은 로컬에서 접근 가능한 하나 이상의 파일 경로, Google Cloud Storage, Amazon S3, Azure Storage에서 모델에 접근할 수 있어요.

로컬 파일 시스템 (Local File System)

로컬에서 접근 가능한 파일 시스템의 경우 절대 경로를 지정해야 해요.

$ tritonserver --model-repository=/path/to/model/repository ...

환경 변수로 클라우드 스토리지 (Cloud Storage with Environment variables)

Google Cloud Storage

Google Cloud Storage에 있는 모델 저장소의 경우 저장소 경로를 gs://로 접두사 처리해야 해요.

$ tritonserver --model-repository=gs://bucket/path/to/model/repository ...

Google Cloud Storage를 사용할 때 자격 증명(credential)은 다음 순서로 가져오고 시도해요:

GOOGLE_APPLICATION_CREDENTIALS 환경 변수
- 환경 변수를 설정하고 자격 증명 JSON 파일의 위치를 담아야 해요.
- 인증된 사용자 자격 증명을 먼저 시도하고, 그다음 서비스 계정 자격 증명을 시도해요.
연결된 서비스 계정
- Authorization HTTP 헤더 값을 얻을 수 있어야 해요.
익명 자격 증명(공개 버킷이라고도 함)
- 버킷(및 객체)이 모든 사용자에게 get과 list 권한을 부여해야 해요.
- 그러한 권한을 부여하는 한 방법은 "allUsers"에 storage.objectViewer와 storage.legacyBucketReader 사전 정의 역할을 모두 추가하는 거예요. 예:
```
$ gsutil iam ch allUsers:objectViewer "${BUCKET_URL}"
$ gsutil iam ch allUsers:legacyBucketReader "${BUCKET_URL}"
```

기본적으로 Triton은 원격 모델 저장소를 임시 폴더에 로컬 복사본으로 만들고, Triton 서버가 종료된 후 삭제해요. 원격 모델 저장소가 복사될 위치를 제어하려면 TRITON_GCS_MOUNT_DIRECTORY 환경 변수를 로컬 머신의 기존 폴더를 가리키는 경로로 설정할 수 있어요.

export TRITON_GCS_MOUNT_DIRECTORY=/path/to/your/local/directory

TRITON_GCS_MOUNT_DIRECTORY가 로컬 머신에 존재하고 비어 있는지 확인하세요.

S3

Amazon S3에 있는 모델 저장소의 경우 경로를 s3://로 접두사 처리해야 해요.

$ tritonserver --model-repository=s3://bucket/path/to/model/repository ...

로컬 또는 프라이빗 S3 인스턴스의 경우 s3:// 접두사 뒤에 호스트와 포트(세미콜론으로 구분)가 오고 그다음 버킷 경로가 와야 해요.

$ tritonserver --model-repository=s3://host:port/bucket/path/to/model/repository ...

기본적으로 Triton은 HTTP로 S3 인스턴스와 통신해요. S3 인스턴스가 HTTPS를 지원하고 Triton이 HTTPS 프로토콜로 통신하길 원한다면 모델 저장소 경로에서 호스트 이름 앞에 https://를 붙여 지정할 수 있어요.

$ tritonserver --model-repository=s3://https://host:port/bucket/path/to/model/repository ...

S3를 사용할 때 자격 증명과 기본 리전은 aws config 명령이나 각각의 환경 변수로 전달할 수 있어요. 환경 변수가 설정되면 더 높은 우선순위를 가지며 aws config 명령으로 설정한 자격 증명 대신 Triton이 사용해요.

기본적으로 Triton은 원격 모델 저장소를 임시 폴더에 로컬 복사본으로 만들고, Triton 서버가 종료된 후 삭제해요. 원격 모델 저장소가 복사될 위치를 제어하려면 TRITON_AWS_MOUNT_DIRECTORY 환경 변수를 로컬 머신의 기존 폴더를 가리키는 경로로 설정할 수 있어요.

export TRITON_AWS_MOUNT_DIRECTORY=/path/to/your/local/directory

TRITON_AWS_MOUNT_DIRECTORY가 로컬 머신에 존재하고 비어 있는지 확인하세요.

Azure Storage

Azure Storage에 있는 모델 저장소의 경우 저장소 경로를 as://로 접두사 처리해야 해요.

$ tritonserver --model-repository=as://account_name/container_name/path/to/model/repository ...

공유 키 인증 (Shared Key Authentication, 기본)

Azure Storage를 공유 키 인증으로 사용할 때는 Azure Storage 저장소에 접근 권한이 있는 계정으로 AZURE_STORAGE_ACCOUNT와 AZURE_STORAGE_KEY 환경 변수를 설정해야 해요.

AZURE_STORAGE_KEY를 모르고 Azure CLI가 올바르게 구성돼 있다면, AZURE_STORAGE_ACCOUNT에 해당하는 키를 찾는 예는 다음과 같아요:

$ export AZURE_STORAGE_ACCOUNT="account_name"
$ export AZURE_STORAGE_KEY=$(az storage account keys list -n $AZURE_STORAGE_ACCOUNT --query "[0].value")

Azure Managed Identity 인증

Triton은 공유 키 인증의 대안으로 Azure Managed Identity(MI)를 지원해요. 이는 스토리지 계정 키를 배포하거나 회전시킬 필요를 없애고 Azure의 엔터프라이즈 보안 모범 사례와 일치해요.

Managed Identity 인증을 켜려면 AZURE_STORAGE_AUTH_TYPE 환경 변수를 설정하세요:

$ export AZURE_STORAGE_ACCOUNT="account_name"
$ export AZURE_STORAGE_AUTH_TYPE="managed_identity"
$ tritonserver --model-repository=as://account_name/container_name/path/to/model/repository ...

사용자 할당(user-assigned) Managed Identity의 경우 클라이언트 ID도 추가로 지정하세요:

$ export AZURE_STORAGE_AUTH_TYPE="managed_identity"
$ export AZURE_STORAGE_CLIENT_ID="<your-managed-identity-client-id>"

AZURE_STORAGE_AUTH_TYPE="default"를 사용해 Azure의 DefaultAzureCredential 체인을 활성화할 수도 있는데, 이는 환경 변수, managed identity, Azure CLI 등 여러 자격 증명 소스를 순서대로 탐색해요. 이는 로컬 개발에 유용하지만 탐색 때문에 시작 지연이 다소 높아요.

전제 조건:

Managed Identity(시스템 또는 사용자 할당)에 대상 스토리지 계정 또는 컨테이너에 Storage Blob Data Reader 역할(또는 그보다 더 넓은)이 할당되어야 해요.
Triton 호스트(AKS 파드, VM, VMSS, App Service 등)에 Managed Identity가 할당되어야 해요.
AKS 워크로드의 경우 파드가 AAD 토큰을 얻을 수 있도록 pod identity 또는 workload identity 페더레이션이 구성되어 있는지 확인하세요.

Sovereign clouds: Azure Identity SDK는 AZURE_AUTHORITY_HOST 환경 변수를 존중하므로 이 인증 모드는 sovereign cloud 엔드포인트에서도 동작해요.

로컬 모델 디렉토리 (Local Model Directory)

기본적으로 Triton은 원격 모델 저장소를 임시 폴더에 로컬 복사본으로 만들고, Triton 서버가 종료된 후 삭제해요. 원격 모델 저장소가 복사될 위치를 제어하려면 TRITON_AZURE_MOUNT_DIRECTORY 환경 변수를 로컬 머신의 기존 폴더를 가리키는 경로로 설정할 수 있어요.

export TRITON_AZURE_MOUNT_DIRECTORY=/path/to/your/local/directory

TRITON_AZURE_MOUNT_DIRECTORY가 로컬 머신에 존재하고 비어 있는지 확인하세요.

자격 증명 파일로 클라우드 스토리지 (Cloud Storage with Credential file, Beta)

이 기능은 현재 베타이며 변경될 수 있어요.

자격 증명을 Triton용 단일 파일로 묶으려면 TRITON_CLOUD_CREDENTIAL_PATH 환경 변수를 로컬 파일 시스템에 있는 다음 형식의 JSON 파일 경로로 설정할 수 있어요.

export TRITON_CLOUD_CREDENTIAL_PATH="cloud_credential.json"

"cloud_credential.json":

{
  "gs": {
    "": "PATH_TO_GOOGLE_APPLICATION_CREDENTIALS",
    "gs://gcs-bucket-002": "PATH_TO_GOOGLE_APPLICATION_CREDENTIALS_2"
  },
  "s3": {
    "": {
      "secret_key": "AWS_SECRET_ACCESS_KEY",
      "key_id": "AWS_ACCESS_KEY_ID",
      "region": "AWS_DEFAULT_REGION",
      "session_token": "",
      "profile": ""
    },
    "s3://s3-bucket-002": {
      "secret_key": "AWS_SECRET_ACCESS_KEY_2",
      "key_id": "AWS_ACCESS_KEY_ID_2",
      "region": "AWS_DEFAULT_REGION_2",
      "session_token": "AWS_SESSION_TOKEN_2",
      "profile": "AWS_PROFILE_2"
    }
  },
  "as": {
    "": {
      "account_str": "AZURE_STORAGE_ACCOUNT",
      "account_key": "AZURE_STORAGE_KEY"
    },
    "as://Account-002/Container": {
      "account_str": "",
      "account_key": ""
    },
    "as://Account-MI/Container": {
      "account_str": "AZURE_STORAGE_ACCOUNT",
      "auth_type": "managed_identity",
      "client_id": ""
    }
  }
}

자격 증명을 매칭할 때는 주어진 경로의 시작 부분에 대해 가장 길게 매칭되는 자격 증명 이름이 사용돼요. 예를 들어 gs://gcs-bucket-002/model_repository는 "gs://gcs-bucket-002" GCS 자격 증명과 매칭되고, gs://any-other-gcs-bucket은 "" GCS 자격 증명과 매칭돼요.

이 기능은 각 클라우드 스토리지 제공자에 여러 자격 증명이 필요한 사용 사례를 위한 거예요. 위 예제의 자격 증명 경로/키를 실제 경로/키로 반드시 교체하세요.

TRITON_CLOUD_CREDENTIAL_PATH 환경 변수가 설정되지 않으면 Cloud Storage with Environment variables가 사용돼요.

클라우드 스토리지 캐싱

Triton은 현재 클라우드 스토리지에 대해 파일 캐싱을 수행하지 않아요. 그러나 이 기능은 repository agent API를 통해 구현할 수 있어요. 프록시를 주입해 모델의 클라우드 스토리지(원래 경로)가 주어지면 특정 로컬 디렉토리의 캐싱을 확인하고 캐시된 파일을 사용할지 결정하는 방식이에요.

모델 버전 (Model Versions)

각 모델은 모델 저장소에서 하나 이상의 버전을 가질 수 있어요. 각 버전은 자체 숫자 이름의 하위 디렉토리에 저장되는데, 하위 디렉토리 이름이 모델의 버전 번호에 해당해요. 숫자 이름이 아니거나 "0" 문자로 시작하는 하위 디렉토리는 무시돼요. 각 모델 구성은 주어진 시점에 모델 저장소의 어떤 버전을 Triton이 제공할지 제어하는 버전 정책을 지정해요.

모델 파일 (Model Files)

각 모델 버전 하위 디렉토리의 내용은 모델 유형과 그 모델을 지원하는 backend의 요구 사항에 따라 결정돼요.

TensorRT 모델

TensorRT 모델 정의를 Plan이라고 불러요. TensorRT Plan은 기본적으로 model.plan이라는 이름이어야 하는 단일 파일이에요. 이 기본 이름은 모델 구성의 default_model_filename 속성으로 덮어쓸 수 있어요.

TensorRT Plan은 GPU의 CUDA Compute Capability에 특화돼 있어요. 결과적으로 TensorRT 모델은 각 Plan 파일을 해당 Compute Capability와 연결하려면 모델 구성에서 cc_model_filenames 속성을 설정해야 해요.

TensorRT 모델의 최소 모델 저장소는 다음과 같아요:

  <model-repository-path>/
    <model-name>/
      config.pbtxt
      1/
        model.plan

ONNX 모델

ONNX 모델은 단일 파일 또는 여러 파일을 담은 디렉토리예요. 기본적으로 파일 또는 디렉토리 이름은 model.onnx여야 해요. 이 기본 이름은 모델 구성의 default_model_filename 속성으로 덮어쓸 수 있어요.

Triton은 Triton이 사용하는 ONNX Runtime 버전이 지원하는 모든 ONNX 모델을 지원해요. 오래된 ONNX opset 버전을 사용하거나 지원되지 않는 타입의 연산자를 포함하는 모델은 지원되지 않아요.

단일 파일에 담긴 ONNX 모델의 최소 모델 저장소는 다음과 같아요:

  <model-repository-path>/
    <model-name>/
      config.pbtxt
      1/
        model.onnx

여러 파일로 구성된 ONNX 모델은 디렉토리에 담겨야 해요. 기본적으로 이 디렉토리 이름은 model.onnx여야 하지만 모델 구성의 default_model_filename 속성으로 덮어쓸 수 있어요. 이 디렉토리 안의 기본 모델 파일은 model.onnx라는 이름이어야 해요. 디렉토리에 담긴 ONNX 모델의 최소 모델 저장소는 다음과 같아요:

  <model-repository-path>/
    <model-name>/
      config.pbtxt
      1/
        model.onnx/
           model.onnx
           <other model files>

TorchScript 모델

TorchScript 모델은 기본적으로 model.pt라는 이름이어야 하는 단일 파일이에요. 이 기본 이름은 모델 구성의 default_model_filename 속성으로 덮어쓸 수 있어요. 서로 다른 PyTorch 버전으로 trace된 일부 모델은 밑바탕 opset의 변경으로 인해 Triton이 지원하지 못할 수 있어요.

TorchScript 모델의 최소 모델 저장소는 다음과 같아요:

  <model-repository-path>/
    <model-name>/
      config.pbtxt
      1/
        model.pt

OpenVINO 모델

OpenVINO 모델은 .xml과 .bin 두 파일로 표현돼요. 기본적으로 .xml 파일 이름은 model.xml이어야 해요. 이 기본 이름은 모델 구성의 default_model_filename 속성으로 덮어쓸 수 있어요.

OpenVINO 모델의 최소 모델 저장소는 다음과 같아요:

  <model-repository-path>/
    <model-name>/
      config.pbtxt
      1/
        model.xml
        model.bin

Python 모델

Python backend는 Triton 내에서 Python 코드를 모델로 실행할 수 있게 해줘요. 기본적으로 Python 스크립트 이름은 model.py여야 하지만 이 기본 이름은 모델 구성의 default_model_filename 속성으로 덮어쓸 수 있어요.

Python 모델의 최소 모델 저장소는 다음과 같아요:

  <model-repository-path>/
    <model-name>/
      config.pbtxt
      1/
        model.py

DALI 모델

DALI backend는 DALI pipeline을 Triton 내에서 모델로 실행할 수 있게 해줘요. 이 backend를 사용하려면 기본적으로 model.dali라는 이름의 파일을 생성해 모델 저장소에 포함해야 해요. model.dali를 생성하는 방법에 대한 설명은 DALI backend 문서를 참고하세요. 기본 모델 파일 이름은 모델 구성의 default_model_filename 속성으로 덮어쓸 수 있어요.

DALI 모델의 최소 모델 저장소는 다음과 같아요:

  <model-repository-path>/
    <model-name>/
      config.pbtxt
      1/
        model.dali

더 알아보기 (Learn more)

모델 구성 (Model Configuration) — 구성 파일 작성
모델 관리 (Model Management) — 실행 중 모델 저장소 변경
동적 배치 (Batchers) — 모델별 배치 설정

출처: 공식문서 (Model Repository)