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

Typy wystąpień to koncepcja usługi Azure Machine Learning, 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 zainstalowana z rozszerzeniem usługi Azure Machine Learning. Dwa elementy w rozszerzeniu usługi Azure Machine Learning 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 Learning, 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 nodeSelector nodeSelector 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 Learning. 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:

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 Learning.

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

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

from azure.ai.ml import command

# define the command
command_job = command(
    command="python -c "print('Hello world!')"",
    environment="AzureML-lightgbm-3.2-ubuntu18.04-py37-cpu@latest",
    compute="<Kubernetes-compute_target_name>",
    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

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

from azure.ai.ml import KubernetesOnlineDeployment,Model,Environment,CodeConfiguration

model = Model(path="./model/sklearn_mnist_model.pkl")
env = Environment(
    conda_file="./model/conda.yml",
    image="mcr.microsoft.com/azureml/openmpi3.1.2-ubuntu18.04:latest",
)

# define the deployment
blue_deployment = KubernetesOnlineDeployment(
    name="blue",
    endpoint_name="<endpoint name>",
    model=model,
    environment=env,
    code_configuration=CodeConfiguration(
        code="./script/", scoring_script="score.py"
    ),
    instance_count=1,
    instance_type="<instance type name>",
)

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.

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>

from azure.ai.ml import (
    KubernetesOnlineDeployment,
    Model,
    Environment,
    CodeConfiguration,
    ResourceSettings,
    ResourceRequirementsSettings
)

model = Model(path="./model/sklearn_mnist_model.pkl")
env = Environment(
    conda_file="./model/conda.yml",
    image="mcr.microsoft.com/azureml/openmpi3.1.2-ubuntu18.04:latest",
)

requests = ResourceSettings(cpu="0.1", memory="0.2G")
limits = ResourceSettings(cpu="0.2", memory="0.5G", nvidia_gpu="1")
resources = ResourceRequirementsSettings(requests=requests, limits=limits)

# define the deployment
blue_deployment = KubernetesOnlineDeployment(
    name="blue",
    endpoint_name="<endpoint name>",
    model=model,
    environment=env,
    code_configuration=CodeConfiguration(
        code="./script/", scoring_script="score.py"
    ),
    resources=resources,
    instance_count=1,
    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.

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

• Wymagania dotyczące routera wnioskowania i łączności w usłudze Azure Machine Learning
• Zabezpieczanie środowiska wnioskowania usługi Azure Kubernetes Service