Tworzenie typów wystąpień i zarządzanie nimi w celu efektywnego wykorzystania zasobów obliczeniowych

  • Artykuł

Typy wystąpień to koncepcja usługi Azure Machine Edukacja, która umożliwia kierowanie określonych typów węzłów obliczeniowych na potrzeby obciążeń trenowania i wnioskowania. Na przykład na maszynie wirtualnej platformy Azure typ wystąpienia to STANDARD_D2_V3. W tym artykule przedstawiono sposób tworzenia typów wystąpień i zarządzania nimi dla wymagań obliczeniowych.

W klastrach Kubernetes typy wystąpień są reprezentowane w niestandardowej definicji zasobów (CRD), która jest instalowana z rozszerzeniem usługi Azure Machine Edukacja. Dwa elementy w rozszerzeniu usługi Azure Machine Edukacja reprezentują typy wystąpień:

  • Użyj nodeSelector , aby określić węzeł, na którym ma działać zasobnik. Węzeł musi mieć odpowiednią etykietę.
  • W sekcji zasobów można ustawić zasoby obliczeniowe (procesor CPU, pamięć i procesor GPU FIRMY NVIDIA) dla zasobnika.

Jeśli określisz pole nodeSelector podczas wdrażania rozszerzenia usługi Azure Machine Edukacja, nodeSelector pole zostanie zastosowane do wszystkich typów wystąpień. To oznacza, że:

  • Dla każdego tworzonego typu wystąpienia określone nodeSelector pole powinno być podzbiorem określonego pola.nodeSelector
  • Jeśli używasz typu wystąpienia z elementem nodeSelector, obciążenie zostanie uruchomione w dowolnym węźle zgodnym zarówno z polem określonym przez rozszerzenie, jak i polem określonym nodeSelectornodeSelector przez typ wystąpienia.
  • Jeśli używasz typu wystąpienia bez nodeSelector pola, obciążenie zostanie uruchomione w dowolnym węźle zgodnym z polem określonym nodeSelector przez rozszerzenie.

Tworzenie domyślnego typu wystąpienia

Domyślnie typ wystąpienia o nazwie defaultinstancetype jest tworzony podczas dołączania klastra Kubernetes do obszaru roboczego usługi Azure Machine Edukacja. Oto definicja:

resources:
  requests:
    cpu: "100m"
    memory: "2Gi"
  limits:
    cpu: "2"
    memory: "2Gi"
    nvidia.com/gpu: null

Jeśli nie zastosujesz nodeSelector pola, zasobnik można zaplanować w dowolnym węźle. Zasobniki obciążenia są przypisywane do zasobów domyślnych z 0,1 rdzeniami procesora CPU, 2 GB pamięci i 0 procesorami GPU dla żądania. Zasoby używane przez zasobniki obciążenia są ograniczone do 2 rdzeni procesora CPU i 8 GB pamięci.

Domyślny typ wystąpienia celowo używa kilku zasobów. Aby upewnić się, że wszystkie obciążenia uczenia maszynowego są uruchamiane z odpowiednimi zasobami (na przykład zasób procesora GPU), zdecydowanie zalecamy utworzenie niestandardowych typów wystąpień.

Należy pamiętać o następujących kwestiach dotyczących domyślnego typu wystąpienia:

  • defaultinstancetype Nie jest wyświetlany jako InstanceType zasób niestandardowy w klastrze podczas uruchamiania polecenia , ale jest wyświetlany we wszystkich klientach (interfejs użytkownika, interfejs wiersza polecenia kubectl get instancetypeplatformy Azure, zestaw SDK).
  • defaultinstancetype można zastąpić definicją niestandardowego typu wystąpienia o tej samej nazwie.

Tworzenie niestandardowego typu wystąpienia

Aby utworzyć nowy typ wystąpienia, utwórz nowy zasób niestandardowy dla wystąpienia typu CRD. Na przykład:

kubectl apply -f my_instance_type.yaml

Oto zawartość pliku my_instance_type.yaml:

apiVersion: amlarc.azureml.com/v1alpha1
kind: InstanceType
metadata:
  name: myinstancetypename
spec:
  nodeSelector:
    mylabel: mylabelvalue
  resources:
    limits:
      cpu: "1"
      nvidia.com/gpu: 1
      memory: "2Gi"
    requests:
      cpu: "700m"
      memory: "1500Mi"

Powyższy kod tworzy typ wystąpienia z zachowaniem oznaczonym etykietą:

  • Zasobniki są zaplanowane tylko w węzłach, które mają etykietę mylabel: mylabelvalue.
  • Zasobniki są przypisywane żądania 700m zasobów dla procesora CPU i 1500Mi pamięci.
  • Zasobniki mają przypisane limity 1 zasobów dla procesora CPU, 2Gi pamięci i 1 procesora GPU firmy NVIDIA.

Tworzenie niestandardowych typów wystąpień musi spełniać następujące parametry i reguły definicji lub kończy się niepowodzeniem:

Parametr Wymagane lub opcjonalne opis
name Wymagania Wartości ciągów, które muszą być unikatowe w klastrze.
CPU request Wymagania Wartości ciągu, które nie mogą być zerowe ani puste.
Można określić procesor w milisekundach; na przykład 100m. Można również określić je jako pełne numery. Na przykład instrukcja "1" jest równoważna instrukcji 1000m.
Memory request Wymagania Wartości ciągu, które nie mogą być zerowe ani puste.
Pamięć można określić jako pełny numer i sufiks; na przykład 1024Mi dla 1024 mebibajtów (MiB).
CPU limit Wymagania Wartości ciągu, które nie mogą być zerowe ani puste.
Można określić procesor w milisekundach; na przykład 100m. Można również określić je jako pełne numery. Na przykład instrukcja "1" jest równoważna instrukcji 1000m.
Memory limit Wymagania Wartości ciągu, które nie mogą być zerowe ani puste.
Pamięć można określić jako pełny numer i sufiks; na przykład 1024Mi dla 1024 MiB.
GPU Opcjonalnie Wartości całkowite, które można określić tylko w limits sekcji.
Aby uzyskać więcej informacji, zobacz dokumentację platformy Kubernetes.
nodeSelector Opcjonalnie Mapa kluczy ciągów i wartości.

Istnieje również możliwość jednoczesnego utworzenia wielu typów wystąpień:

kubectl apply -f my_instance_type_list.yaml

Oto zawartość pliku my_instance_type_list.yaml:

apiVersion: amlarc.azureml.com/v1alpha1
kind: InstanceTypeList
items:
  - metadata:
      name: cpusmall
    spec:
      resources:
        requests:
          cpu: "100m"
          memory: "100Mi"
        limits:
          cpu: "1"
          nvidia.com/gpu: 0
          memory: "1Gi"

  - metadata:
      name: defaultinstancetype
    spec:
      resources:
        requests:
          cpu: "1"
          memory: "1Gi" 
        limits:
          cpu: "1"
          nvidia.com/gpu: 0
          memory: "1Gi"

W poprzednim przykładzie są tworzone dwa typy wystąpień: cpusmall i defaultinstancetype. Ta defaultinstancetype definicja zastępuje definicję defaultinstancetype utworzoną podczas dołączania klastra Kubernetes do obszaru roboczego usługi Azure Machine Edukacja.

Jeśli przesyłasz obciążenie trenowania lub wnioskowania bez typu wystąpienia, używa go .defaultinstancetype Aby określić domyślny typ wystąpienia klastra Kubernetes, utwórz typ wystąpienia o nazwie defaultinstancetype. Jest ona automatycznie rozpoznawana jako domyślna.

Wybierz typ wystąpienia, aby przesłać zadanie szkoleniowe

Aby wybrać typ wystąpienia zadania szkoleniowego przy użyciu interfejsu wiersza polecenia platformy Azure (wersja 2), określ jego nazwę w sekcji resources właściwości w zadaniu YAML. Na przykład:

command: python -c "print('Hello world!')"
environment:
  image: library/python:latest
compute: azureml:<Kubernetes-compute_target_name>
resources:
  instance_type: <instance type name>

W poprzednim przykładzie zastąp <Kubernetes-compute_target_name> ciąg nazwą docelowego obliczeniowego rozwiązania Kubernetes. Zastąp <instance type name> ciąg nazwą typu wystąpienia, który chcesz wybrać. Jeśli nie określisz instance_type właściwości, system użyje defaultinstancetype polecenia do przesłania zadania.

Wybierz typ wystąpienia, aby wdrożyć model

Aby wybrać typ wystąpienia wdrożenia modelu przy użyciu interfejsu wiersza polecenia platformy Azure (wersja 2), określ jego nazwę dla instance_type właściwości we wdrożeniu YAML. Na przykład:

name: blue
app_insights_enabled: true
endpoint_name: <endpoint name>
model: 
  path: ./model/sklearn_mnist_model.pkl
code_configuration:
  code: ./script/
  scoring_script: score.py
instance_type: <instance type name>
environment: 
  conda_file: file:./model/conda.yml
  image: mcr.microsoft.com/azureml/openmpi3.1.2-ubuntu18.04:latest

W poprzednim przykładzie zastąp <instance type name> ciąg nazwą typu wystąpienia, który chcesz wybrać. Jeśli nie określisz instance_type właściwości, system używa defaultinstancetype jej do wdrożenia modelu.

Ważne

W przypadku wdrożenia modelu MLflow żądanie zasobu wymaga co najmniej 2 rdzeni procesora CPU i 4 GB pamięci. W przeciwnym razie wdrożenie zakończy się niepowodzeniem.

Walidacja sekcji zasobów

Możesz użyć resources sekcji , aby zdefiniować żądanie zasobu i limit wdrożeń modelu. Na przykład:

name: blue
app_insights_enabled: true
endpoint_name: <endpoint name>
model: 
  path: ./model/sklearn_mnist_model.pkl
code_configuration:
  code: ./script/
  scoring_script: score.py
environment: 
  conda_file: file:./model/conda.yml
  image: mcr.microsoft.com/azureml/openmpi3.1.2-ubuntu18.04:latest
resources:
  requests:
    cpu: "0.1"
    memory: "0.2Gi"
  limits:
    cpu: "0.2"
    #nvidia.com/gpu: 0
    memory: "0.5Gi"
instance_type: <instance type name>

Jeśli używasz resources sekcji, prawidłowa definicja zasobu musi spełniać następujące reguły. Nieprawidłowa definicja zasobu powoduje niepowodzenie wdrożenia modelu.

Parametr Wymagane lub opcjonalne opis
requests:
cpu:		 Wymagania Wartości ciągu, które nie mogą być zerowe ani puste.
Można określić procesor w milisekundach; na przykład 100m. Można również określić je w pełnych liczbach. Na przykład instrukcja "1" jest równoważna instrukcji 1000m.
requests:
memory:		 Wymagania Wartości ciągu, które nie mogą być zerowe ani puste.
Pamięć można określić jako pełny numer i sufiks; na przykład 1024Mi dla 1024 MiB.
Pamięć nie może być mniejsza niż 1 MB.
limits:
cpu:		 Opcjonalne
(wymagane tylko wtedy, gdy potrzebujesz procesora GPU)		 Wartości ciągu, które nie mogą być zerowe ani puste.
Można określić procesor w milisekundach; na przykład 100m. Można również określić je w pełnych liczbach. Na przykład instrukcja "1" jest równoważna instrukcji 1000m.
limits:
memory:		 Opcjonalne
(wymagane tylko wtedy, gdy potrzebujesz procesora GPU)		 Wartości ciągu, które nie mogą być zerowe ani puste.
Pamięć można określić jako pełny numer i sufiks; na przykład 1024Mi dla 1024 MiB.
limits:
nvidia.com/gpu:		 Opcjonalne
(wymagane tylko wtedy, gdy potrzebujesz procesora GPU)		 Wartości całkowite, które nie mogą być puste i można je określić tylko w limits sekcji.
Aby uzyskać więcej informacji, zobacz dokumentację platformy Kubernetes.
Jeśli potrzebujesz tylko procesora CPU, możesz pominąć całą limits sekcję.

Typ wystąpienia jest wymagany do wdrożenia modelu. Jeśli zdefiniowano sekcję resources i zostanie ona zweryfikowana względem typu wystąpienia, reguły są następujące:

  • W prawidłowej resource definicji sekcji limity zasobów muszą być mniejsze niż limity typów wystąpień. W przeciwnym razie wdrażanie zakończy się niepowodzeniem.
  • Jeśli nie zdefiniujesz typu wystąpienia, system używa defaultinstancetype do walidacji z sekcją resources .
  • Jeśli nie zdefiniujesz resources sekcji, system użyje typu wystąpienia do utworzenia wdrożenia.

Następne kroki