Uruchom modele ensemble ML na Amazon SageMaker

Wdrażanie modeli w uczeniu maszynowym (ML) staje się coraz bardziej złożone. Chcesz wdrożyć nie tylko jeden model ML, ale duże grupy modeli ML reprezentowane jako zespołowe przepływy pracy. Te przepływy pracy składają się z wielu modeli ML. Produkcja tych modeli ML jest trudna, ponieważ musisz przestrzegać różnych wymagań dotyczących wydajności i opóźnień.

Amazon Sage Maker obsługuje jednoinstancyjne zespoły z Serwer wnioskowania Triton. Ta funkcja umożliwia uruchamianie zespołów modeli, które pasują do jednego wystąpienia. Za kulisami SageMaker wykorzystuje Triton Inference Server do zarządzania zespołem w każdej instancji za punktem końcowym, aby zmaksymalizować przepustowość i wykorzystanie sprzętu przy bardzo niskich (jednocyfrowych milisekundach) opóźnieniach wnioskowania. Dzięki Triton możesz również wybierać spośród szerokiej gamy obsługiwanych platform ML (w tym TensorFlow, PyTorch, ONNX, XGBoost i NVIDIA TensorRT) oraz zaplecza infrastruktury, w tym procesorów graficznych, procesorów i Inferencja AWS.

Dzięki tej funkcji w programie SageMaker można zoptymalizować obciążenia, unikając kosztownych opóźnień w sieci i czerpiąc korzyści z lokalizacji obliczeniowej i danych dla potoków wnioskowania zespołu. W tym poście omawiamy zalety korzystania z Triton Inference Server wraz z rozważaniami, czy jest to właściwa opcja dla Twojego obciążenia.

Omówienie rozwiązania

Triton Inference Server został zaprojektowany, aby umożliwić zespołom wdrażanie, uruchamianie i skalowanie przeszkolonych modeli sztucznej inteligencji z dowolnej struktury w dowolnej infrastrukturze opartej na GPU lub CPU. Ponadto został zoptymalizowany, aby oferować wysokowydajne wnioskowanie na dużą skalę dzięki funkcjom takim jak dynamiczne grupowanie, współbieżne uruchomienia, optymalna konfiguracja modelu, możliwości zespołu modeli i obsługa strumieniowych danych wejściowych.

Obciążenia powinny uwzględniać możliwości oferowane przez firmę Triton, aby zapewnić obsługę ich modeli. Triton obsługuje wiele popularnych platform, w tym TensorFlow, PyTorch, ONNX, XGBoost i NVIDIA TensorRT. Triton obsługuje również różne backendy które są wymagane do prawidłowego działania algorytmów. Powinieneś upewnić się, że Twoje modele są obsługiwane przez te backendy, a w przypadku, gdy backend nie, Triton pozwala na zaimplementowanie własnego i zintegrowanie go. Należy również sprawdzić, czy Twoja wersja algorytmu jest obsługiwana, a także upewnić się, że artefakty modelu są akceptowane przez odpowiedni backend. Aby sprawdzić, czy dany algorytm jest obsługiwany, zapoznaj się z Zaplecze serwera wnioskowania Triton aby zapoznać się z listą natywnie obsługiwanych backendów obsługiwanych przez firmę NVIDIA.

Mogą istnieć pewne scenariusze, w których Twoje modele lub zespoły modeli nie będą działać na Triton bez większego wysiłku, na przykład jeśli nie istnieje natywnie obsługiwany backend dla Twojego algorytmu. Należy wziąć pod uwagę kilka innych kwestii, na przykład format ładunku może nie być idealny, zwłaszcza gdy rozmiar ładunku może być duży dla żądania. Jak zawsze, po wdrożeniu tych obciążeń należy sprawdzić poprawność wydajności, aby upewnić się, że spełniono oczekiwania.

Przyjrzyjmy się modelowi sieci neuronowej klasyfikacji obrazów i zobaczmy, jak możemy przyspieszyć nasze obciążenia. W tym przykładzie używamy backendu NVIDIA DALI do przyspieszenia naszego przetwarzania wstępnego w kontekście naszego zespołu.

Twórz zestawy modeli Triton

Triton Inference Server upraszcza wdrażanie modeli AI na dużą skalę. Triton Inference Server zawiera wygodne rozwiązanie, które upraszcza tworzenie potoków przetwarzania wstępnego i przetwarzania końcowego. Platforma Triton Inference Server zapewnia harmonogram zespołu, którego można użyć do budowania modeli zespołów potokowych uczestniczących w procesie wnioskowania, zapewniając jednocześnie wydajność i optymalizację przepustowości.

Triton Inference Server obsługuje modele z repozytoriów modeli. Przyjrzyjmy się układowi repozytorium modelu dla modelu zespołu zawierającego model przetwarzania wstępnego DALI, model TensorFlow inception V3 oraz konfigurację zespołu modelu. Każdy podkatalog zawiera informacje o repozytorium dla odpowiednich modeli. The config.pbtxt plik opisuje konfigurację modelu dla modeli. Każdy katalog musi mieć jeden podfolder numeryczny dla każdej wersji modelu i jest obsługiwany przez określony backend obsługiwany przez Triton.

NVIDIA DALI

W tym poście używamy biblioteki ładowania danych NVIDIA (DALI) jako modelu przetwarzania wstępnego w naszym zespole modeli. NVIDIA DALI to biblioteka do ładowania i wstępnego przetwarzania danych w celu przyspieszenia aplikacji głębokiego uczenia. Zapewnia kolekcję zoptymalizowanych bloków konstrukcyjnych do ładowania i przetwarzania danych obrazu, wideo i audio. Można go używać jako przenośnego zamiennika wbudowanych modułów ładujących dane i iteratorów danych w popularnych platformach uczenia głębokiego.

Poniższy kod przedstawia konfigurację modelu dla zaplecza DALI:

name: "dali"
backend: "dali"
max_batch_size: 256
input [
  {
    name: "DALI_INPUT_0"
    data_type: TYPE_UINT8
    dims: [ -1 ]
  }
]
output [
  {
    name: "DALI_OUTPUT_0"
    data_type: TYPE_FP32
    dims: [ 299, 299, 3 ]
  }
]
parameters: [
  {
    key: "num_threads"
    value: { string_value: "12" }
  }
]

Początkowy model V3

W tym poście pokazujemy, jak DALI jest używane w zestawie modeli z Inception V3. Wstępnie wytrenowany model Inception V3 TensorFlow jest zapisywany w formacie GraphDef jako pojedynczy plik o nazwie model.graphdef, config.pbtxt plik zawiera informacje o nazwie modelu, platformie, max_batch_sizeoraz kontrakty wejściowe i wyjściowe. Zalecamy ustawienie max_batch_size konfiguracja do mniej niż początkowy rozmiar partii modelu V3. Plik etykiet zawiera etykiety klas dla 1,000 różnych klas. Kopiujemy początkowe etykiety modelu klasyfikacji do inception_graphdef katalogu w repozytorium modelu. Plik etykiet zawiera 1,000 etykiet klas ImageNet zbiór danych klasyfikacji.

name: "inception_graphdef"
platform: "tensorflow_graphdef"
max_batch_size: 256
input [
  {
    name: "input"
    data_type: TYPE_FP32
    format: FORMAT_NHWC
    dims: [ 299, 299, 3 ]
  }
]
output [
  {
    name: "InceptionV3/Predictions/Softmax"
    data_type: TYPE_FP32
    dims: [ 1001 ]
    label_filename: "inception_labels.txt"
  }
]

Zespół Triton

Poniższy kod przedstawia konfigurację modelu modelu zbiorowego dla wstępnego przetwarzania DALI i klasyfikacji obrazów:

name: "ensemble_dali_inception"
platform: "ensemble"
max_batch_size: 256
input [
  {
    name: "INPUT"
    data_type: TYPE_UINT8
    dims: [ -1 ]
  }
]
output [
  {
    name: "OUTPUT"
    data_type: TYPE_FP32
    dims: [ 1001 ]
  }
]
ensemble_scheduling {
  step [
    {
      model_name: "dali"
      model_version: -1
      input_map {
        key: "DALI_INPUT_0"
        value: "INPUT"
      }
      output_map {
        key: "DALI_OUTPUT_0"
        value: "preprocessed_image"
      }
    },
    {
      model_name: "inception_graphdef"
      model_version: -1
      input_map {
        key: "input"
        value: "preprocessed_image"
      }
      output_map {
        key: "InceptionV3/Predictions/Softmax"
        value: "OUTPUT"
      }
    }
  ]
}

Utwórz punkt końcowy SageMaker

Punkty końcowe programu SageMaker pozwalają na hosting w czasie rzeczywistym, gdzie wymagany jest czas odpowiedzi w milisekundach. SageMaker przejmuje niezróżnicowany ciężar zarządzania hostingiem modeli i ma możliwość automatycznego skalowania. Ponadto zapewnianych jest również wiele możliwości, w tym hostowanie wielu wariantów modelu, testowanie A/B modeli, integracja z Amazon Cloud Watch w celu uzyskania obserwowalności wydajności modelu i monitorowania dryfu modelu.

Stwórzmy model SageMaker z artefaktów modelu, które przesłaliśmy do Usługa Amazon Simple Storage (Amazonka S3).

Następnie udostępniamy również dodatkową zmienną środowiskową: SAGEMAKER_TRITON_DEFAULT_MODEL_NAME, który określa nazwę modelu do załadowania przez Triton. Wartość tego klucza powinna być zgodna z nazwą folderu w pakiecie modelu przesłanym do Amazon S3. Ta zmienna jest opcjonalna w przypadkach, gdy używasz jednego modelu. W przypadku modeli zespołowych ten klucz musi być określony, aby Triton mógł się uruchomić w SageMaker.

Dodatkowo możesz ustawić SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT i SAGEMAKER_TRITON_THREAD_COUNT do optymalizacji liczby wątków.

container = {
    "Image": triton_image_uri,
    "ModelDataUrl": model_uri,
    "Environment": {"SAGEMAKER_TRITON_DEFAULT_MODEL_NAME": "ensemble_dali_inception"},
}
create_model_response = sm_client.create_model(
    ModelName=sm_model_name, ExecutionRoleArn=role, PrimaryContainer=container
)

W poprzednim modelu tworzymy konfigurację punktu końcowego, w której możemy określić typ i liczbę instancji, które chcemy w punkcie końcowym:

create_endpoint_config_response = sm_client.create_endpoint_config(
    EndpointConfigName=endpoint_config_name,
    ProductionVariants=[
        {
            "InstanceType": instance_type,
            "InitialVariantWeight": 1,
            "InitialInstanceCount": 1,
            "ModelName": sm_model_name,
            "VariantName": "AllTraffic",
        }
    ],
)
endpoint_config_arn = create_endpoint_config_response["EndpointConfigArn"]

Używamy tej konfiguracji punktu końcowego do tworzenia nowego punktu końcowego SageMaker i czekania na zakończenie wdrożenia. Po pomyślnym wdrożeniu stan zmienia się na InService.

create_endpoint_response = sm_client.create_endpoint(
    EndpointName=endpoint_name, EndpointConfigName=endpoint_config_name
)
endpoint_arn = create_endpoint_response["EndpointArn"]

Ładunek wnioskowania

Wejściowy obraz ładunku przechodzi przez potok wstępnego przetwarzania DALI i jest używany w harmonogramie zespołu dostarczanym przez Triton Inference Server. Konstruujemy ładunek, który ma zostać przekazany do punktu końcowego wnioskowania:

payload = {
    "inputs": [
        {
            "name": "INPUT",
            "shape": rv2.shape,
            "datatype": "UINT8",
            "data": rv2.tolist(),
        }
    ]
}

Wnioskowanie zespołowe

Gdy mamy uruchomiony punkt końcowy, możemy użyć przykładowego obrazu, aby wykonać żądanie wnioskowania przy użyciu formatu JSON jako formatu ładunku. W przypadku formatu żądania wnioskowania Triton używa standardowych protokołów wnioskowania społeczności KFServing.

response = runtime_sm_client.invoke_endpoint(
    EndpointName=endpoint_name, ContentType="application/octet-stream", Body=json.dumps(payload)
)
print(json.loads(response["Body"].read().decode("utf8")))

Z binary+json format, musimy określić długość metadanych żądania w nagłówku, aby umożliwić Tritonowi prawidłowe przeanalizowanie ładunku binarnego. Odbywa się to za pomocą niestandardowego nagłówka Content-Type application/vnd.sagemaker-triton.binary+json;json-header-size={}.

Różni się to od używania an Inference-Header-Content-Length nagłówek na samodzielnym serwerze Triton, ponieważ niestandardowe nagłówki nie są dozwolone w programie SageMaker.

Pakiet tritonclient zapewnia metody narzędziowe do generowania ładunku bez konieczności znajomości szczegółów specyfikacji. Używamy następujących metod, aby przekonwertować nasze żądanie wnioskowania na format binarny, który zapewnia mniejsze opóźnienia dla wnioskowania. Zobacz GitHub notatnik szczegóły realizacji.

response = runtime_sm_client.invoke_endpoint(
    EndpointName=endpoint_name,
    ContentType="application/vnd.sagemaker-triton.binary+json;json-header-size={}".format(
        header_length
    ),
    Body=request_body,
)

Wnioski

W tym poście pokazaliśmy, jak można produkować zestawy modeli, które działają na jednej instancji w SageMaker. Ten wzorzec projektowy może być przydatny do łączenia dowolnej logiki przetwarzania wstępnego i przetwarzania końcowego wraz z przewidywaniami wnioskowania. SageMaker używa Tritona do uruchamiania wnioskowania o zespole na pojedynczym kontenerze na instancji, która obsługuje wszystkie główne frameworki.

Aby uzyskać więcej próbek na zespołach Triton w SageMaker, zapoznaj się z GitHub repo. Wypróbuj to!

O autorach

James Park jest architektem rozwiązań w Amazon Web Services. Współpracuje z Amazon.com przy projektowaniu, budowaniu i wdrażaniu rozwiązań technologicznych w AWS, a szczególnie interesuje się sztuczną inteligencją i uczeniem maszynowym. W wolnym czasie lubi poszukiwać nowych kultur, nowych doświadczeń i być na bieżąco z najnowszymi trendami technologicznymi.

Vikrama Elango jest starszym architektem rozwiązań AI/ML w Amazon Web Services z siedzibą w Wirginii w USA. Vikram pomaga klientom z branży finansowej i ubezpieczeniowej poprzez projektowanie i przemyślane przywództwo w tworzeniu i wdrażaniu aplikacji uczenia maszynowego na dużą skalę. Obecnie koncentruje się na przetwarzaniu języka naturalnego, odpowiedzialnej sztucznej inteligencji, optymalizacji wnioskowania i skalowaniu ML w całym przedsiębiorstwie. W wolnym czasie lubi podróżować, wędrować, gotować i biwakować z rodziną.

Saurabha Trikande jest starszym menedżerem produktu w firmie Amazon SageMaker Inference. Pasjonuje go praca z klientami i motywuje go cel, jakim jest demokratyzacja uczenia maszynowego. Koncentruje się na podstawowych wyzwaniach związanych z wdrażaniem złożonych aplikacji ML, wielodostępnych modeli ML, optymalizacji kosztów oraz zwiększaniem dostępności wdrażania modeli uczenia głębokiego. W wolnym czasie Saurabh lubi wędrować, poznawać innowacyjne technologie, śledzić TechCrunch i spędzać czas z rodziną.