모델 관리

모델 관리 (Model Management)

Triton은 HTTP/REST와 GRPC 프로토콜의 일부로, 그리고 C API의 일부로 모델 관리 API를 제공해요. Triton은 NONE, EXPLICIT, POLL 세 가지 모델 제어 모드 중 하나로 동작해요. 모델 제어 모드는 Triton이 모델 저장소의 변경을 어떻게 처리하는지, 그리고 이 프로토콜·API 중 어떤 것들을 사용할 수 있는지 결정해요.

모델 제어 모드 NONE

  • Triton은 시작 시 모델 저장소의 모든 모델을 로드하려고 시도해요. 로드하지 못한 모델은 "UNAVAILABLE"로 표시되고 추론에 사용할 수 없어요.

  • 서버 실행 중 모델 저장소의 변경은 무시돼요. model control 프로토콜을 사용한 모델 로드·언로드 요청은 효과가 없고 오류 응답을 반환해요.

  • 이 모델 제어 모드는 Triton을 시작할 때 --model-control-mode=none을 지정해 선택돼요.

  • 이게 기본 모델 제어 모드예요.

[!IMPORTANT] Triton이 실행되는 동안 모델 저장소를 변경하는 것은 Modifying the Model Repository에서 설명한 대로 신중하게 해야 해요.

모델 제어 모드 EXPLICIT

  • 시작 시 Triton은 --load-model 커맨드라인 옵션으로 명시적으로 지정된 모델만 로드해요.

  • 모든 모델을 시작 시 로드하려면 --load-model=*을 유일한 --load-model 인자로 지정하세요. --load-model=*을 다른 --load-model 인자와 함께 지정하면 오류가 발생해요.

  • --load-model이 지정되지 않으면 시작 시 로드되는 모델이 없어요. 로드하지 못한 모델은 "UNAVAILABLE"로 표시되고 추론에 사용할 수 없어요.

  • 시작 후에는 모든 모델 로드·언로드 동작을 model control 프로토콜로 명시적으로 시작해야 해요. model control 요청의 응답 상태가 로드·언로드 동작의 성공 여부를 나타내요. 이미 로드된 모델을 다시 로드하려 시도할 때는 갱신된 버전이 로드되기 전에 기존 모델을 명시적으로 언로드해야 해요.

  • 이 모델 제어 모드는 --model-control-mode=explicit을 지정해 켜요.

대체 메모리 할당 라이브러리 사용하기 (Using Alternate Memory Allocation Libraries)

model control 프로토콜로 모델을 로드·언로드할 때 메모리 증가가 보인다면, 실제 메모리 누수가 아니라 일부 시스템의 malloc 휴리스틱 때문에 메모리를 OS에 바로 반환하지 못하는 경우일 수 있어요.

메모리 성능을 개선하려면 Triton을 실행할 때 LD_PRELOAD 환경 변수를 설정해 malloc에서 tcmalloc 또는 jemalloc으로 전환하는 것을 고려할 수 있어요. 아래처럼요:

  • tcmalloc 사용:

    LD_PRELOAD=/usr/lib/$(uname -m)-linux-gnu/libtcmalloc.so.4:${LD_PRELOAD} tritonserver --model-repository=/models ...

  • jemalloc 사용:

    PRELOAD=/usr/lib/$(uname -m)-linux-gnu/libtcmalloc.so:${LD_PRELOAD} tritonserver --model-repository=/models ...

tcmalloc과 jemalloc은 서로 다른 메모리 할당·해제 전략을 가지며 워크로드에 따라 성능이 다를 수 있으므로, 둘 다 실험해 사용 사례에 더 잘 맞는 것을 결정하길 권해요.

tcmalloc과 jemalloc 라이브러리는 모두 Triton 컨테이너에 이미 설치돼 있어요. 그러나 설치가 필요하다면 다음 명령으로 설치할 수 있어요:

  • tcmalloc 설치:

    apt-get install gperf libgoogle-perftools-dev

  • jemalloc 설치:

    apt-get install libjemalloc-dev

모델 제어 모드 POLL

  • Triton은 시작 시 모델 저장소의 모든 모델을 로드하려고 시도해요. 로드하지 못한 모델은 "UNAVAILABLE"로 표시되고 추론에 사용할 수 없어요.

  • 모델 저장소의 변경을 감지하고 Triton은 그 변경에 따라 필요에 따라 모델을 로드·언로드하려고 시도해요.

    • 모델 재로드가 실패하면 이미 로드된 모델은 변경되지 않고 로드된 채로 유지돼요.
    • 모델 재로드가 성공하면 기존 로드된 모델이 가용성 손실 없이 새로 로드된 인스턴스로 대체돼요.

Triton이 주기적으로 저장소를 폴링하기 때문에 모델 저장소의 변경이 즉시 감지되지 않을 수 있어요. 폴링 간격은 --repository-poll-secs 옵션으로 제어할 수 있어요. 콘솔 로그나 model ready 프로토콜, 또는 model control 프로토콜의 index 연산으로 모델 저장소 변경이 적용됐는지 판단할 수 있어요.

[!WARNING] Triton이 모델 저장소를 폴링하는 시점과 사용자가 저장소를 변경하는 시점 사이에는 동기화가 없어요. 결과적으로 Triton이 부분적이고 불완전한 변경을 관찰해 예상치 못한 동작으로 이어질 수 있어요. 이런 이유로 POLL 모드는 운영 환경에서 권장되지 않아요.

model control 프로토콜을 사용한 모델 로드·언로드 요청은 효과가 없고 오류 응답을 반환해요.

이 모델 제어 모드는 Triton을 시작할 때 --model-control-mode=poll을 지정하고 --repository-poll-secs를 0이 아닌 값으로 설정해 켜요. Triton이 실행되는 동안 모델 저장소를 변경하는 것은 Modifying the Model Repository에서 설명한 대로 신중하게 해야 해요.

POLL 모드에서 Triton은 다음 모델 저장소 변경에 응답해요:

  • 해당 버전 하위 디렉토리를 추가·제거해서 모델에 버전을 추가하고 제거할 수 있어요. Triton은 제거된 모델 버전을 사용 중인 in-flight 요청도 완료되도록 허용해요. 제거된 모델 버전에 대한 새 요청은 실패해요. 모델의 버전 정책에 따라 가용 버전 변경이 기본으로 서빙되는 모델 버전을 바꿀 수 있어요.

  • 해당 모델 디렉토리를 제거해서 기존 모델을 저장소에서 제거할 수 있어요. Triton은 제거된 모델의 어떤 버전에 대한 in-flight 요청도 완료되도록 허용해요. 제거된 모델에 대한 새 요청은 실패해요.

  • 새 모델 디렉토리를 추가해서 새 모델을 저장소에 추가할 수 있어요.

  • 모델 구성 파일(config.pbtxt)을 변경할 수 있고 Triton은 새 모델 구성을 반영하도록 모델을 언로드·재로드해요.

  • 분류를 나타내는 출력의 라벨을 제공하는 라벨 파일을 추가·제거·수정할 수 있고 Triton은 새 라벨을 반영하도록 모델을 언로드·재로드해요. 라벨 파일이 추가·제거되면 모델 구성에서 그에 대응하는 출력의 label_filename 속성도 같은 시점에 편집해야 해요.

모델 저장소 수정하기 (Modifying the Model Repository)

모델 저장소의 각 모델은 자체 하위 디렉토리에 있습니다. 모델의 하위 디렉토리 내용에 대해 허용되는 활동은 Triton이 그 모델을 어떻게 사용하고 있는지에 따라 달라져요. 모델의 상태는 model metadata 또는 repository index API로 확인할 수 있어요.

  • 모델이 활발히 로드·언로드되는 동안에는 그 하위 디렉토리 안의 어떤 파일이나 디렉토리도 추가·제거·수정하면 안 돼요.

  • 모델이 한 번도 로드된 적 없거나 완전히 언로드된 경우에는 모델 하위 디렉토리 전체를 제거하거나 내용을 수정할 수 있어요.

  • 모델이 완전히 로드되면 그 하위 디렉토리 안의 어떤 파일·디렉토리든 추가·제거·수정할 수 있어요. 단, 모델의 backend를 구현하는 공유 라이브러리는 제외해요.

    • Triton은 모델이 로드되는 동안 backend 공유 라이브러리를 사용하므로, 이를 제거·수정하는 것은 Triton 프로세스를 불안정하게 만들 수 있어 권장하지 않아요.

    • 모델의 backend를 갱신하려면 그 모델이 Triton에 로드되지 않은 상태여야 해요:

      1. 갱신할 backend에 의존하는 로드된 모델을 언로드한다.
      2. backend의 공유 라이브러리를 수정한다.
      3. 이전에 언로드한 모델을 로드한다.

    [!TIP] 일부 운영 체제에서는 기존 공유 라이브러리를 모델 저장소 밖의 다른 위치로 단순히 옮기고, 새 공유 라이브러리를 복사한 다음 모델을 재로드하는 것도 가능할 수 있어요.

  • 모델 구성 파일(config.pbtxt)의 모델 인스턴스 구성만 수정된 경우(예: 인스턴스 수 증가/감소) Triton은 모델을 재로드하지 않고 갱신해요.

  • Model Control Mode EXPLICIT에서 로드 요청을 받거나 Model Control Mode POLL에서 모델 구성 파일(config.pbtxt)의 변경을 감지한 경우.

    • 새 모델 구성은 load API로 Triton에 전달될 수도 있어요.

    • 일부 텍스트 편집기는 모델 구성 파일(config.pbtxt)을 제자리에서 수정할 때 모델 디렉토리에 swap 파일을 만들어요. swap 파일은 모델 구성의 일부가 아니므로, 그 존재가 모델 디렉토리에서 새 파일로 감지되어 업데이트만 기대할 때 모델이 완전히 재로드될 수 있어요.

  • 시퀀스 모델이 갱신(예: 인스턴스 수 감소)될 때 Triton은 해당 시퀀스 뒤의 인스턴스가 제거되기 전에 in-flight 시퀀스가 완료되거나 정리될 때까지 기다려요.

    • 인스턴스 수가 감소하면 유휴 인스턴스와 in-flight 시퀀스를 가진 인스턴스 중에서 임의의 인스턴스가 제거를 위해 선택돼요.

  • 시퀀스 모델이 in-flight 시퀀스와 함께 재로드(예: 모델 파일 변경)되면 Triton은 in-flight 시퀀스의 남은 요청이 처리를 위해 같은 모델 인스턴스로 라우팅될 것을 보장하지 않아요.

    [!IMPORTANT] 시퀀스 모델을 재로드하기 전에 in-flight 시퀀스를 완료하는 것은 현재 사용자의 책임이에요.

모델 동시 로드 (Concurrently Loading Models)

서비스 다운타임을 줄이기 위해 Triton은 기존 모델에서 추론을 계속 제공하면서 백그라운드에서 새 모델을 로드해요. 사용 사례와 성능 요구 사항에 따라 모델 로드에 전념하는 최적의 리소스 양이 다를 수 있어요.

Triton은 모델 로드에 전념하는 스레드 수를 구성하는 --model-load-thread-count 옵션을 노출하며 기본값은 4예요.

C API로 이 파라미터를 설정하려면 tritonserver.h의 TRITONSERVER_ServerOptionsSetModelLoadThreadCount를 참고하세요.

더 알아보기 (Learn more)

출처: 공식문서 (Model Management)