triton inference server 모델관리

이전 포스팅에서 성능 최적화하는 방법까지 알아봤다.
이번 포스팅에는 서비스를 운영하며 어떻게 모델을 관리해야할까? 하는 문제에서 시작된다.

---

모델을 로드하고 사용하는 방식?

triton 모델관리 문서를 보면 3가지 모델제어 방식을 제공한다.

• NONE(기본 제어모드)
• POLL
• EXPLICIT

NONE

None 제어모드로 triton을 실행하면 현재 저장소에 저장된 모든 모델들을 로드한다.
동적으로 모델을 추가하고 제거할 수 없어 서버가 실행중일 때 모델을 제어하는 api를 호출하면 에러가 반환된다.
또한 사용하지 않는 모델들이 모두 메모리에 로드되기 때문에 불필요한 리소스 낭비가 발생하고 운영단계에 사용하기 적합하지 않은 모드다.

POLL

주기적으로 모델 저장소의 모델들을 로드한다. 즉 저장소에 모델을 추가하면, 추론서버가 이를 감지하고 새로운 모델을 로드하는것이다. NONE과 달리 런타임에 모델관리가 가능한 점이 장점이다. 하지만, POLL 모드 역시 모든 모델들을 로드한다는 문제가 있기 때문에 운영단계에 적합하지 않은 모드다.

EXPLICIT

명시적으로 모델을 관리할 수 있는 모드다. 다른 모드들과 달리 서버를 실행시켜도 모든 모델들이 자동으로 로드되지 않고 직접 로드 / 언로드 호출을 통해 관리해야한다. 모델 추가와 로드는 다르다. 저장소에 모델을 추가하면 get_model_repository_index api를 통해 모델이 추가된것을 확인할 수 있다. 하지만 추가만 된 것이고, 로드는 별개로 진행해야한다.

예를들어, 2개의 모델이 있는 추론서버를 실행시키고 index를 조회하면 다음과 같은 내용을 확인할 수 있다.

{
  "models": [
    {
      "name": "densenet_onnx",
      "version": null,
      "state": null,
      "reason": null
    },
    {
      "name": "simple",
      "version": null,
      "state": null,
      "reason": null
    }
  ]
}

version, state 등의 세부정보가 조회되지 않는다. 저장소에만 있는 상태이고 실제 모델이 로드되지 않았다. densenet_onnx 모델을 로드하면 다음과 같이 바뀐다.

{
  "models": [
    {
      "name": "densenet_onnx",
      "version": "1",
      "state": "READY",
      "reason": null
    },
    {
      "name": "simple",
      "version": null,
      "state": null,
      "reason": null
    }
  ]
}

현재 모델의 버전이 명시되고, READY 상태로 변경된다. 언로드하면 역시 상태가 바뀐다.

{
  "models": [
    {
      "name": "densenet_onnx",
      "version": "1",
      "state": "UNAVAILABLE",
      "reason": "unloaded"
    },
    {
      "name": "simple",
      "version": null,
      "state": null,
      "reason": null
    }
  ]
}

기본적으로 위 제어 api들과 저장소를 통해 서비스에 필요한 모델들을 동적으로 관리할 수 있다.
모델자체를 배포하는것은 큰 문제가 없겠지만, 해당 모델에대한 pbtxt 파일을 작성하는데에는 여러 오류가 발생할 가능성이 있다.
explicit 방식을 사용하지 않고 잘못된 pbtxt 파일을 저장소에 넣어 배포했을 때 추론서버 배포자체를 실패하곤했는데, 이런 문제없이 안전하게 서비스를 할 수 있는 장점이있다.

(NONE) 저장소(잘못된 pbtxt) -> 추론서버 실행 실패
(EXPLICIT) 저장소(잘못된 pbtxt) -> 모델 로드 -> 로드 실패(서비스 이용에 문제없음)

explicit 모드 옵션은 --model-control-mode={MODE} 로 정의할 수 있다.

---

모델 로드

모델을 로드하는 api를 보면 단순히 모델을 로드하는것을 넘어 오버라이딩하는 기능도 지원한다.

POST /v2/repository/models/mymodel/load HTTP/1.1
Host: localhost:8000
{
  "parameters": {
    "config": "{
      "name": "mymodel",
      "backend": "onnxruntime",
      "inputs": [{
          "name": "INPUT0",
          "datatype": "FP32",
          "shape": [ 1 ]
        }
      ],
      "outputs": [{
          "name": "OUTPUT0",
          "datatype": "FP32",
          "shape": [ 1 ]
        }
      ]
    }",

    "file:1/model.onnx" : "<base64-encoded-file-content>"
  }
}

config 필드를 보면 pbtxt에서 볼 수 있는 익숙한 형식을 확인할 수 있다.
이 스키마를 보고 저장소에 저장된 모델과 pbtxt 정보를 덮어쓰기 하는줄 알았으나, 그렇지는 않고 임시로 모델정보를 바꾸는 정도의 의미만 있었다. 즉, 서버를 새로 시작하면 저장소에 있는 기존데이터로 로드된다.
이 기능은 잘 사용하지 않을 것 같다. 필요하면 새로운 버전의 모델을 저장소에 추가해서 사용하는것이 더 좋은 방식이라고 생각한다.

모델을 다시 로드하려면(변경사항 적용하려면) 언로드 후 다시 로드해줘야한다.

---

결론

서비스에 필요한 동적인 모델관리를 위해서는 EXPLICIT 방식의 모델제어 방식이 가장 적합하다고 생각한다.
동적 모델관리에 적합한 시스템을 만들기위한 과정 중 triton 모델 관리(제어)를 다루어봤다.
다음은 triton에서 제어할 수 없는 모델 메타데이터 관리에 대해 고민해보려고 한다.
pbtxt에 포함되는 정보들과 및 어떤 종류의 모델인지 관리해야 이에 적합한 서비스를 제공할 수 있다.