Tensorflow 제공 구성

이 가이드에서는 Tensorflow Serving의 다양한 구성 지점을 살펴보겠습니다.

개요

대부분의 구성은 Model Server와 관련되어 있지만 Tensorflow Serving의 동작을 지정하는 방법은 여러 가지가 있습니다.

  • 모델 서버 구성 : 모델 이름, 경로, 버전 정책 및 레이블, 로깅 구성 등을 지정합니다.
  • 모니터링 구성 : Prometheus 모니터링 활성화 및 구성
  • 일괄 처리 구성 : 일괄 처리를 활성화하고 해당 매개변수를 구성합니다.
  • 기타 플래그 : 기타 여러 가지. Tensorflow Serving 배포의 동작을 미세 조정하기 위해 제공할 수 있는 플래그

모델 서버 구성

모델을 제공하는 가장 쉬운 방법은 --model_name 및 --model_base_path 플래그를 제공하는 것입니다(또는 Docker를 사용하는 경우 MODEL_NAME 환경 변수를 설정하는 것). 그러나 여러 모델을 제공하거나 새 버전에 대한 폴링 빈도와 같은 옵션을 구성하려는 경우 모델 서버 구성 파일을 작성하여 수행할 수 있습니다.

--model_config_file 플래그를 사용하여 이 구성 파일을 제공하고 --model_config_file_poll_wait_seconds 플래그를 설정하여 지정된 경로에서 이 구성 파일의 업데이트된 버전을 주기적으로 폴링하도록 Tensorflow Serving에 지시할 수 있습니다.

Docker를 사용한 예:

docker run -t --rm -p 8501:8501 \
    -v "$(pwd)/models/:/models/" tensorflow/serving \
    --model_config_file=/models/models.config \
    --model_config_file_poll_wait_seconds=60

모델 서버 구성 다시 로드 중

Model Server 구성을 다시 로드하는 방법에는 두 가지가 있습니다.

  • --model_config_file_poll_wait_seconds 플래그를 설정하여 서버가 --model_config_file filepath에서 새 구성 파일을 주기적으로 확인하도록 지시합니다.

  • 서버에 HandleReloadConfigRequest RPC 호출을 실행하고 프로그래밍 방식으로 새 모델 서버 구성을 제공합니다.

서버가 새 구성 파일을 로드할 때마다 새로 지정된 구성의 내용과 새로 지정된 구성 만 인식하도록 작동합니다. 이는 모델 A가 첫 번째 구성 파일에 존재하고 모델 B만 포함하는 파일로 대체된 경우 서버가 모델 B를 로드하고 모델 A를 언로드함을 의미합니다.

모델 서버 구성 세부정보

제공된 Model Server 구성 파일은 ModelServerConfig 프로토콜 버퍼 여야 합니다.

가장 고급 사용 사례를 제외한 모든 경우에는 ModelConfig 프로토콜 버퍼 목록인 ModelConfigList 옵션을 사용하는 것이 좋습니다. 아래의 고급 옵션을 살펴보기 전에 기본 예를 살펴보겠습니다.

model_config_list {
  config {
    name: 'my_first_model'
    base_path: '/tmp/my_first_model/'
    model_platform: 'tensorflow'
  }
  config {
    name: 'my_second_model'
    base_path: '/tmp/my_second_model/'
    model_platform: 'tensorflow'
  }
}

하나의 모델 구성

각 ModelConfig는 위의 예에서 볼 수 있듯이 이름과 모델 서버가 제공할 모델 버전을 찾아야 하는 경로를 포함하여 제공될 하나의 모델을 지정합니다. 기본적으로 서버는 버전 번호가 가장 큰 버전을 제공합니다. 이 기본값은 model_version_policy 필드를 변경하여 무시할 수 있습니다.

특정 버전의 모델 제공

버전 번호가 가장 큰 모델로 항상 전환하는 대신 모델의 특정 버전을 제공하려면 model_version_policy를 "특정"으로 설정하고 제공하려는 버전 번호를 제공하세요. 예를 들어 버전 42를 제공할 버전으로 고정하려면 다음 안내를 따르세요.

model_version_policy {
  specific {
    versions: 42
  }
}

이 옵션은 최신 버전에서 문제가 발견된 경우 알려진 양호한 버전으로 롤백하는 데 유용합니다.

여러 버전의 모델 제공

모델의 여러 버전을 동시에 제공하려면(예: 트래픽 조각으로 임시 새 버전 카나리아를 활성화하려면) model_version_policy를 "특정"으로 설정하고 여러 버전 번호를 제공하세요. 예를 들어 버전 42 및 43을 제공하려면 다음을 수행하세요.

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}

카나리아 및 롤백을 단순화하기 위해 모델 버전에 문자열 레이블 할당

때로는 모델 버전에 간접 수준을 추가하는 것이 도움이 될 수 있습니다. 모든 클라이언트에게 버전 42를 쿼리해야 한다는 사실을 알리는 대신 현재 클라이언트가 쿼리해야 하는 버전에 "stable"과 같은 별칭을 할당할 수 있습니다. 트래픽 조각을 임시 카나리아 모델 버전으로 리디렉션하려는 경우 두 번째 별칭 "canary"를 사용할 수 있습니다.

다음과 같이 모델 버전 별칭 또는 라벨을 구성할 수 있습니다.

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}
version_labels {
  key: 'stable'
  value: 42
}
version_labels {
  key: 'canary'
  value: 43
}

위의 예에서는 버전 42와 43을 제공하고 "stable" 레이블을 버전 42에 연결하고 "canary" 레이블을 버전 43에 연결합니다. 클라이언트가 "stable" 또는 "canary" 중 하나로 쿼리를 직접 연결하도록 할 수 있습니다. (아마도 사용자 ID 해싱을 기반으로) ModelSpec 프로토콜 버퍼의 version_label 필드를 사용하고 클라이언트에 알리지 않고 서버에서 레이블을 앞으로 이동합니다. 버전 43의 카나리아 생성을 완료하고 이를 안정 버전으로 승격할 준비가 되면 구성을 다음과 같이 업데이트할 수 있습니다.

model_version_policy {
  specific {
    versions: 42
    versions: 43
  }
}
version_labels {
  key: 'stable'
  value: 43
}
version_labels {
  key: 'canary'
  value: 43
}

나중에 롤백을 수행해야 하는 경우 버전 42가 "안정"인 이전 구성으로 되돌릴 수 있습니다. 그렇지 않으면 버전 42를 언로드하고 준비가 되면 새 버전 44를 로드한 다음 카나리아 레이블을 44로 높이는 등의 방식으로 계속 진행할 수 있습니다.

라벨은 이미 로드되어 게재 가능한 모델 버전에만 할당할 수 있습니다. 모델 버전을 사용할 수 있게 되면 즉시 모델 구성을 다시 로드하여 라벨을 할당할 수 있습니다. 이는 HandleReloadConfigRequest RPC를 사용하거나 위에서 설명한 대로 서버가 구성 파일에 대한 파일 시스템을 주기적으로 폴링하도록 설정된 경우에 달성할 수 있습니다.

아직 로드되지 않은 버전에 라벨을 할당하려면(예: 시작 시 모델 버전과 라벨을 모두 제공) --allow_version_labels_for_unavailable_models 플래그를 true로 설정해야 합니다. 아직 로드되지 않은 모델 버전에 할당됩니다.

이는 새 버전 라벨(즉, 현재 버전에 할당되지 않은 라벨)에만 적용됩니다. 이는 버전 교체 중에 서버가 새 버전에 레이블을 너무 일찍 할당하여 새 버전이 로드되는 동안 해당 레이블에 대한 모든 요청을 삭제하지 않도록 하기 위한 것입니다.

이 안전 검사를 준수하려면 이미 사용 중인 버전 라벨을 다시 할당하는 경우 이미 로드된 버전에만 할당해야 합니다. 예를 들어 버전 N을 가리키는 라벨을 버전 N+1로 이동하려면 먼저 버전 N과 N+1이 포함된 구성을 제출한 다음 버전 N+1이 포함된 구성을 제출하면 됩니다. N+1을 가리키고 버전 N은 없습니다.

REST 사용법

추론 요청을 하기 위해 REST API 표면을 사용하는 경우

/v1/models/<model name>/versions/<version number>

다음과 같이 요청 경로를 구성하여 라벨을 사용하여 버전을 요청하면 됩니다.

/v1/models/<model name>/labels/<version label> .

버전 라벨은 영숫자와 밑줄(예: [a-zA-Z0-9_]+ )로 구성된 일련의 Word 문자로 제한됩니다.

모니터링 구성

MonitoringConfig 프로토콜 버퍼가 포함된 파일을 지정하기 위해 --monitoring_config_file 플래그를 사용하여 서버에 모니터링 구성을 제공할 수 있습니다. 예는 다음과 같습니다.

prometheus_config {
  enable: true,
  path: "/monitoring/prometheus/metrics"
}

위 모니터링 URL에서 지표를 읽으려면 먼저 --rest_api_port 플래그를 설정하여 HTTP 서버를 활성화해야 합니다. 그런 다음 --rest_api_port 및 path 값을 전달하여 Model Server에서 메트릭을 가져오도록 Prometheus 서버를 구성할 수 있습니다.

Tensorflow Serving은 Serving과 핵심 Tensorflow에서 캡처한 모든 측정항목을 수집합니다.

일괄 구성

Model Server에는 더 나은 처리량을 실현하기 위해 다양한 설정으로 요청을 일괄 처리하는 기능이 있습니다. 이 일괄 처리에 대한 예약은 서버의 모든 모델 및 모델 버전에 대해 전역적으로 수행되어 현재 서버에서 제공되는 모델 또는 모델 버전 수에 관계없이 기본 리소스를 최대한 활용할 수 있도록 합니다( 자세한 내용 참조 ). --enable_batching 플래그를 설정하여 이 동작을 활성화하고 --batching_parameters_file 플래그에 구성을 전달하여 이를 제어할 수 있습니다.

일괄 처리 매개변수 파일 예시:

max_batch_size { value: 128 }
batch_timeout_micros { value: 0 }
max_enqueued_batches { value: 1000000 }
num_batch_threads { value: 8 }

자세한 내용은 일괄 처리 가이드를 참조하고 매개변수 설정 방법을 이해하려면 매개변수 섹션을 참조하세요.

기타 플래그

지금까지 가이드에서 다룬 플래그 외에도 여기에 몇 가지 주목할만한 플래그가 나열되어 있습니다. 전체 목록을 보려면 소스 코드를 참조하세요.

  • --port : gRPC API를 수신 대기하는 포트
  • --rest_api_port : HTTP/REST API를 수신할 포트
  • --rest_api_timeout_in_ms : HTTP/REST API 호출 시간 초과
  • --file_system_poll_wait_seconds : 서버가 각 모델의 해당 model_base_path에서 새 모델 버전에 대한 파일 시스템을 폴링하는 기간입니다.
  • --enable_model_warmup : 자산.extra/ 디렉터리에서 사용자 제공 PredictionLogs를 사용하여 모델 준비를 활성화합니다.
  • --mixed_precision=bfloat16 : BF16 자동 혼합 정밀도를 활성화합니다.