Udostępnij za pośrednictwem

Wdrażanie modelu w punkcie końcowym online przy użyciu niestandardowego kontenera

  • Artykuł

DOTYCZY: Rozszerzenie interfejsu wiersza polecenia platformy Azure w wersji 2 (current)Zestaw PYTHON SDK azure-ai-ml v2 (bieżąca)

Dowiedz się, jak za pomocą kontenera niestandardowego wdrożyć model w punkcie końcowym online w usłudze Azure Machine Learning.

Wdrożenia kontenerów niestandardowych mogą używać serwerów internetowych innych niż domyślny serwer platformy Python Flask używany przez usługę Azure Machine Learning. Użytkownicy tych wdrożeń nadal mogą korzystać z wbudowanych funkcji monitorowania, skalowania, alertów i uwierzytelniania usługi Azure Machine Learning.

W poniższej tabeli wymieniono różne przykłady wdrożenia, które używają kontenerów niestandardowych, takich jak TensorFlow Serving, TorchServe, Triton Inference Server, Plumber R package i Azure Machine Learning Inference Minimal image.

Przykład Skrypt (interfejs wiersza polecenia) opis
minimalna/wielomodelowa deploy-custom-container-minimal-multimodel Wdrażanie wielu modeli w jednym wdrożeniu przez rozszerzenie obrazu Minimalne wnioskowanie usługi Azure Machine Learning.
minimalny/pojedynczy model deploy-custom-container-minimal-single-model Wdrażanie pojedynczego modelu przez rozszerzenie obrazu wnioskowania usługi Azure Machine Learning — minimalny.
mlflow/multideployment-scikit deploy-custom-container-mlflow-multideployment-scikit Wdróż dwa modele MLFlow z różnymi wymaganiami języka Python w dwóch oddzielnych wdrożeniach za jednym punktem końcowym przy użyciu minimalnego obrazu wnioskowania usługi Azure Machine Learning.
r/multimodel-plumber deploy-custom-container-r-multimodel-plumber Wdrażanie trzech modeli regresji w jednym punkcie końcowym przy użyciu pakietu Plumber R
tfserving/half-plus-two deploy-custom-container-tfserving-half-plus-two Wdróż model Half Plus Two przy użyciu kontenera niestandardowego Obsługującego bibliotekę TensorFlow przy użyciu standardowego procesu rejestracji modelu.
tfserving/half-plus-two-integrated deploy-custom-container-tfserving-half-plus-two-integrated Wdróż model Half Plus Two przy użyciu kontenera niestandardowego TensorFlow Obsługującego model zintegrowany z obrazem.
torchserve/gęsta sieć deploy-custom-container-torchserve-densenet Wdrażanie pojedynczego modelu przy użyciu niestandardowego kontenera TorchServe.
triton/pojedynczy model deploy-custom-container-triton-single-model Wdrażanie modelu Triton przy użyciu kontenera niestandardowego

Ten artykuł koncentruje się na obsłudze modelu TensorFlow za pomocą usługi TensorFlow (TF).

Ostrzeżenie

Firma Microsoft może nie być w stanie rozwiązać problemów spowodowanych przez obraz niestandardowy. Jeśli wystąpią problemy, może zostać wyświetlony monit o użycie obrazu domyślnego lub jednego z obrazów, które firma Microsoft udostępnia, aby sprawdzić, czy problem jest specyficzny dla twojego obrazu.

Wymagania wstępne

Przed wykonaniem kroków opisanych w tym artykule upewnij się, że masz następujące wymagania wstępne:

  • Użytkownik lub używana jednostka usługi musi mieć dostęp współautora do grupy zasobów platformy Azure, która zawiera obszar roboczy. Jeśli skonfigurowano obszar roboczy przy użyciu artykułu Szybki start, masz taką grupę zasobów.

  • Aby wdrożyć lokalnie, aparat platformy Docker musi działać lokalnie. Ten krok jest zdecydowanie zalecany. Pomaga to debugować problemy.

Pobieranie kodu źródłowego

Aby wykonać czynności opisane w tym samouczku, sklonuj kod źródłowy z usługi GitHub.

git clone https://github.com/Azure/azureml-examples --depth 1
cd azureml-examples/cli

Inicjowanie zmiennych środowiskowych

Zdefiniuj zmienne środowiskowe:

BASE_PATH=endpoints/online/custom-container/tfserving/half-plus-two
AML_MODEL_NAME=tfserving-mounted
MODEL_NAME=half_plus_two
MODEL_BASE_PATH=/var/azureml-app/azureml-models/$AML_MODEL_NAME/1

Pobieranie modelu TensorFlow

Pobierz i rozpakuj model, który dzieli dane wejściowe przez dwa i dodaje 2 do wyniku:

wget https://aka.ms/half_plus_two-model -O $BASE_PATH/half_plus_two.tar.gz
tar -xvf $BASE_PATH/half_plus_two.tar.gz -C $BASE_PATH

Uruchamianie obrazu obsługującego tf lokalnie w celu przetestowania, czy działa

Użyj platformy Docker, aby uruchomić obraz lokalnie na potrzeby testowania:

docker run --rm -d -v $PWD/$BASE_PATH:$MODEL_BASE_PATH -p 8501:8501 \
 -e MODEL_BASE_PATH=$MODEL_BASE_PATH -e MODEL_NAME=$MODEL_NAME \
 --name="tfserving-test" docker.io/tensorflow/serving:latest
sleep 10

Sprawdź, czy możesz wysyłać żądania liveness i oceniania do obrazu

Najpierw sprawdź, czy kontener jest aktywny, co oznacza, że proces wewnątrz kontenera jest nadal uruchomiony. Powinna zostać wyświetlona odpowiedź 200 (OK).

curl -v http://localhost:8501/v1/models/$MODEL_NAME

Następnie sprawdź, czy możesz uzyskać przewidywania dotyczące danych bez etykiet:

curl --header "Content-Type: application/json" \
  --request POST \
  --data @$BASE_PATH/sample_request.json \
  http://localhost:8501/v1/models/$MODEL_NAME:predict

Zatrzymywanie obrazu

Po przetestowaniu lokalnie zatrzymaj obraz:

docker stop tfserving-test

Wdrażanie punktu końcowego online na platformie Azure

Następnie wdróż punkt końcowy online na platformie Azure.

Tworzenie pliku YAML dla punktu końcowego i wdrożenia

Wdrożenie w chmurze można skonfigurować przy użyciu języka YAML. Zapoznaj się z przykładowym kodem YAML w tym przykładzie:

tfserving-endpoint.yml

$schema: https://azuremlsdk2.blob.core.windows.net/latest/managedOnlineEndpoint.schema.json
name: tfserving-endpoint
auth_mode: aml_token

tfserving-deployment.yml

$schema: https://azuremlschemas.azureedge.net/latest/managedOnlineDeployment.schema.json
name: tfserving-deployment
endpoint_name: tfserving-endpoint
model:
  name: tfserving-mounted
  version: {{MODEL_VERSION}}
  path: ./half_plus_two
environment_variables:
  MODEL_BASE_PATH: /var/azureml-app/azureml-models/tfserving-mounted/{{MODEL_VERSION}}
  MODEL_NAME: half_plus_two
environment:
  #name: tfserving
  #version: 1
  image: docker.io/tensorflow/serving:latest
  inference_config:
    liveness_route:
      port: 8501
      path: /v1/models/half_plus_two
    readiness_route:
      port: 8501
      path: /v1/models/half_plus_two
    scoring_route:
      port: 8501
      path: /v1/models/half_plus_two:predict
instance_type: Standard_DS3_v2
instance_count: 1

Istnieje kilka ważnych pojęć, które należy wziąć pod uwagę w tym parametrze YAML/Python:

Obraz podstawowy

Obraz podstawowy jest określany jako parametr w środowisku i docker.io/tensorflow/serving:latest jest używany w tym przykładzie. Podczas inspekcji kontenera można znaleźć, że ten serwer używa ENTRYPOINT do uruchomienia skryptu punktu wejścia, który przyjmuje zmienne środowiskowe, takie jak MODEL_BASE_PATH i MODEL_NAME, i uwidacznia porty, takie jak 8501. Te szczegóły są wszystkimi szczegółowymi informacjami dla tego wybranego serwera. Aby określić sposób definiowania wdrożenia, możesz użyć tej wiedzy na temat serwera. Jeśli na przykład ustawisz zmienne środowiskowe dla MODEL_BASE_PATH i MODEL_NAME w definicji wdrożenia, serwer (w tym przypadku obsługa serwera TF) pobierze wartości, aby zainicjować serwer. Podobnie, jeśli ustawisz port dla tras, które mają znajdować 8501 się w definicji wdrożenia, żądanie użytkownika do takich tras będzie prawidłowo kierowane do serwera obsługującego tf.

Należy pamiętać, że ten konkretny przykład jest oparty na przypadku obsługi serwera TF, ale można użyć dowolnych kontenerów, które pozostaną i będą odpowiadać na żądania przychodzące do tras utrzymania, gotowości i oceniania. Możesz odwołać się do innych przykładów i zobaczyć, jak jest tworzony plik dockerfile (na przykład przy użyciu CMD zamiast ENTRYPOINT) w celu utworzenia kontenerów.

Konfiguracja wnioskowania

Konfiguracja wnioskowania jest parametrem w środowisku i określa port i ścieżkę dla 3 typów trasy: liveness, readiness i scoring route. Konfiguracja wnioskowania jest wymagana, jeśli chcesz uruchomić własny kontener z zarządzanym punktem końcowym online.

Trasa gotowości a trasa liveness

Wybrany serwer interfejsu API może zapewnić sposób sprawdzania stanu serwera. Istnieją dwa typy trasy, które można określić: żywość i gotowość. Trasa aktualności służy do sprawdzania, czy serwer jest uruchomiony. Trasa gotowości służy do sprawdzania, czy serwer jest gotowy do pracy. W kontekście wnioskowania uczenia maszynowego serwer może odpowiedzieć 200 OK na żądanie aktualności przed załadowaniem modelu, a serwer może odpowiedzieć 200 OK na żądanie gotowości dopiero po załadowaniu modelu do pamięci.

Aby uzyskać więcej informacji na temat ogólnych sond aktualności i gotowości, zobacz dokumentację platformy Kubernetes.

Trasy dostępności i gotowości będą określane przez wybrany serwer interfejsu API, tak jak podczas testowania kontenera lokalnie we wcześniejszym kroku. Należy pamiętać, że przykładowe wdrożenie w tym artykule używa tej samej ścieżki zarówno dla gotowości, jak i dostępności, ponieważ obsługa serwera TF definiuje tylko trasę aktualności. Zapoznaj się z innymi przykładami różnych wzorców, aby zdefiniować trasy.

Trasa oceniania

Wybrany serwer interfejsu API umożliwia odbieranie ładunku do pracy. W kontekście wnioskowania uczenia maszynowego serwer odbiera dane wejściowe za pośrednictwem określonej trasy. Zidentyfikuj tę trasę dla serwera interfejsu API podczas testowania kontenera lokalnie we wcześniejszym kroku i określ ją podczas definiowania wdrożenia do utworzenia. Należy pamiętać, że pomyślne utworzenie wdrożenia spowoduje również zaktualizowanie parametru scoring_uri punktu końcowego, który można zweryfikować za pomocą polecenia az ml online-endpoint show -n <name> --query scoring_uri.

Lokalizowanie zainstalowanego modelu

Podczas wdrażania modelu jako punktu końcowego online usługa Azure Machine Learning instaluje model w punkcie końcowym. Instalowanie modelu umożliwia wdrażanie nowych wersji modelu bez konieczności tworzenia nowego obrazu platformy Docker. Domyślnie model zarejestrowany przy użyciu nazwy foo i wersji 1 znajduje się w następującej ścieżce wewnątrz wdrożonego kontenera: /var/azureml-app/azureml-models/foo/1

Jeśli na przykład masz strukturę katalogów /azureml-examples/cli/endpoints/online/custom-container na komputerze lokalnym, gdzie model ma nazwę half_plus_two:

Diagram przedstawiający widok drzewa struktury katalogów lokalnych.

A tfserving-deployment.yml zawiera:

model:
    name: tfserving-mounted
    version: 1
    path: ./half_plus_two

Następnie model będzie znajdować się w obszarze /var/azureml-app/azureml-models/tfserving-deployment/1 we wdrożeniu:

Diagram przedstawiający widok drzewa struktury katalogu wdrożenia.

Opcjonalnie możesz skonfigurować plik model_mount_path. Umożliwia zmianę ścieżki, w której jest zainstalowany model.

Ważne

Musi model_mount_path być prawidłową ścieżką bezwzględną w systemie Linux (system operacyjny obrazu kontenera).

Na przykład możesz mieć model_mount_path parametr w tfserving-deployment.yml:

name: tfserving-deployment
endpoint_name: tfserving-endpoint
model:
  name: tfserving-mounted
  version: 1
  path: ./half_plus_two
model_mount_path: /var/tfserving-model-mount
.....

Następnie model znajduje się w lokalizacji /var/tfserving-model-mount/tfserving-deployment/1 we wdrożeniu. Pamiętaj, że nie jest już w obszarze azureml-app/azureml-models, ale w określonej ścieżce instalacji:

Diagram przedstawiający widok drzewa struktury katalogu wdrożenia podczas korzystania z mount_model_path.

Tworzenie punktu końcowego i wdrożenia

Teraz, gdy już wiesz, jak utworzono kod YAML, utwórz punkt końcowy.

az ml online-endpoint create --name tfserving-endpoint -f endpoints/online/custom-container/tfserving-endpoint.yml

Tworzenie wdrożenia może potrwać kilka minut.

az ml online-deployment create --name tfserving-deployment -f endpoints/online/custom-container/tfserving-deployment.yml --all-traffic

Wywoływanie punktu końcowego

Po zakończeniu wdrażania sprawdź, czy możesz wysłać żądanie oceniania do wdrożonego punktu końcowego.

RESPONSE=$(az ml online-endpoint invoke -n $ENDPOINT_NAME --request-file $BASE_PATH/sample_request.json)

Usuwanie punktu końcowego

Teraz, gdy punkt końcowy został pomyślnie wygenerowany, możesz go usunąć:

az ml online-endpoint delete --name tfserving-endpoint

Powiązana zawartość