Partilhar via


Criar e gerenciar tipos de instância para utilização eficiente de recursos de computação

Os tipos de instância são um conceito do Azure Machine Learning que permite direcionar determinados tipos de nós de computação para cargas de trabalho de treinamento e inferência. Por exemplo, em uma máquina virtual do Azure, um tipo de instância é STANDARD_D2_V3. Este artigo ensina como criar e gerenciar tipos de instância para seus requisitos de computação.

Em clusters Kubernetes, os tipos de instância são representados em uma definição de recurso personalizada (CRD) instalada com a extensão do Azure Machine Learning. Dois elementos na extensão do Azure Machine Learning representam os tipos de instância:

  • Use nodeSelector para especificar em qual nó um pod deve ser executado. O nó deve ter um rótulo correspondente.
  • Na seção de recursos, você pode definir os recursos de computação (CPU, memória e GPU NVIDIA) para o pod.

Se você especificar um campo nodeSelector ao implantar a extensão do Azure Machine Learning, o nodeSelector campo será aplicado a todos os tipos de instância. Isto significa que:

  • Para cada tipo de instância que você criar, o campo especificado nodeSelector deve ser um subconjunto do campo especificado nodeSelector pela extensão.
  • Se você usar um tipo de instância com nodeSelector, a carga de trabalho será executada em qualquer nó que corresponda ao campo especificado nodeSelector pela extensão e ao campo especificado nodeSelector pelo tipo de instância.
  • Se você usar um tipo de instância sem um nodeSelector campo, a carga de trabalho será executada em qualquer nó que corresponda ao campo especificado nodeSelector pela extensão.

Criar um tipo de instância padrão

Por padrão, um tipo de instância chamado defaultinstancetype é criado quando você anexa um cluster Kubernetes a um espaço de trabalho do Azure Machine Learning. Aqui está a definição:

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

Se você não aplicar um nodeSelector campo, o pod pode ser agendado em qualquer nó. Os pods da carga de trabalho recebem recursos padrão com 0,1 núcleos de CPU, 2 GB de memória e 0 GPUs para a solicitação. Os recursos que os pods da carga de trabalho usam são limitados a 2 núcleos de CPU e 8 GB de memória.

O tipo de instância padrão usa propositalmente poucos recursos. Para garantir que todas as cargas de trabalho de aprendizado de máquina sejam executadas com recursos apropriados (por exemplo, recurso de GPU), é altamente recomendável que você crie tipos de instância personalizados.

Lembre-se dos seguintes pontos sobre o tipo de instância padrão:

  • defaultinstancetype não aparece como um InstanceType recurso personalizado no cluster quando você está executando o comando kubectl get instancetype, mas aparece em todos os clientes (interface do usuário, CLI do Azure, SDK).
  • defaultinstancetype pode ser substituído pela definição de um tipo de instância personalizado que tenha o mesmo nome.

Criar um tipo de instância personalizado

Para criar um novo tipo de instância, crie um novo recurso personalizado para o tipo de instância CRD. Por exemplo:

kubectl apply -f my_instance_type.yaml

Aqui estão os conteúdos de 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"

O código anterior cria um tipo de instância com o comportamento rotulado:

  • Os pods são agendados apenas em nós que têm o rótulo mylabel: mylabelvalue.
  • Pods são atribuídos solicitações de recursos de 700m para CPU e 1500Mi para memória.
  • Os pods recebem limites de recursos para 1 CPU, 2Gi memória e 1 GPU NVIDIA.

A criação de tipos de instância personalizados deve atender aos seguintes parâmetros e regras de definição, ou falha:

Parâmetro Obrigatório ou opcional Description
name Obrigatório Valores de cadeia de caracteres, que devem ser exclusivos em um cluster.
CPU request Necessário Valores de cadeia de caracteres, que não podem ser zero ou vazios.
Você pode especificar a CPU em milicores; por exemplo, 100m. Você também pode especificá-lo como números completos. Por exemplo, "1" é equivalente a 1000m.
Memory request Necessário Valores de cadeia de caracteres, que não podem ser zero ou vazios.
Você pode especificar a memória como um número completo + sufixo; por exemplo, 1024Mi para 1.024 mebibytes (MiB).
CPU limit Necessário Valores de cadeia de caracteres, que não podem ser zero ou vazios.
Você pode especificar a CPU em milicores; por exemplo, 100m. Você também pode especificá-lo como números completos. Por exemplo, "1" é equivalente a 1000m.
Memory limit Necessário Valores de cadeia de caracteres, que não podem ser zero ou vazios.
Você pode especificar a memória como um número completo + sufixo; por exemplo, 1024Mi para 1024 MiB.
GPU Opcional Valores inteiros, que podem ser especificados somente na limits seção .
Para obter mais informações, consulte a documentação do Kubernetes.
nodeSelector Opcional Mapa de chaves e valores de cadeia de caracteres.

Também é possível criar vários tipos de instância ao mesmo tempo:

kubectl apply -f my_instance_type_list.yaml

Aqui estão os conteúdos de 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"

O exemplo anterior cria dois tipos de instância: cpusmall e defaultinstancetype. Essa defaultinstancetype definição substitui a defaultinstancetype definição que foi criada quando você anexou o cluster do Kubernetes ao espaço de trabalho do Azure Machine Learning.

Se você enviar uma carga de trabalho de treinamento ou inferência sem um tipo de instância, ele usará defaultinstancetype. Para especificar um tipo de instância padrão para um cluster Kubernetes, crie um tipo de instância com o nome defaultinstancetype. É automaticamente reconhecido como padrão.

Selecione um tipo de instância para enviar um trabalho de treinamento

Para selecionar um tipo de instância para um trabalho de treinamento usando a CLI do Azure (v2), especifique seu nome como parte da seção de resources propriedades no trabalho YAML. Por exemplo:

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

No exemplo anterior, substitua <Kubernetes-compute_target_name> pelo nome do seu destino de computação do Kubernetes. Substitua <instance type name> pelo nome do tipo de instância que você deseja selecionar. Se você não especificar uma instance_type propriedade, o sistema usará defaultinstancetype para enviar o trabalho.

Selecione um tipo de instância para implantar um modelo

Para selecionar um tipo de instância para uma implantação de modelo usando a CLI do Azure (v2), especifique seu nome para a instance_type propriedade na implantação YAML. Por exemplo:

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

No exemplo anterior, substitua <instance type name> pelo nome do tipo de instância que você deseja selecionar. Se você não especificar uma instance_type propriedade, o sistema usará defaultinstancetype para implantar o modelo.

Importante

Para a implantação do modelo MLflow, a solicitação de recurso requer pelo menos 2 núcleos de CPU e 4 GB de memória. Caso contrário, a implantação falhará.

Validação da secção de recursos

Você pode usar a resources seção para definir a solicitação de recursos e o limite de suas implantações de modelo. Por exemplo:

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>

Se você usar a resources seção, uma definição de recurso válida precisará atender às seguintes regras. Uma definição de recurso inválida faz com que a implantação do modelo falhe.

Parâmetro Obrigatório ou opcional Description
requests:
cpu:
Obrigatório Valores de cadeia de caracteres, que não podem ser zero ou vazios.
Você pode especificar a CPU em milicores; por exemplo, 100m. Você também pode especificá-lo em números completos. Por exemplo, "1" é equivalente a 1000m.
requests:
memory:
Necessário Valores de cadeia de caracteres, que não podem ser zero ou vazios.
Você pode especificar a memória como um número completo + sufixo; por exemplo, 1024Mi para 1024 MiB.
A memória não pode ser inferior a 1 MB.
limits:
cpu:
Opcional
(necessário apenas quando você precisa de GPU)
Valores de cadeia de caracteres, que não podem ser zero ou vazios.
Você pode especificar a CPU em milicores; por exemplo, 100m. Você também pode especificá-lo em números completos. Por exemplo, "1" é equivalente a 1000m.
limits:
memory:
Opcional
(necessário apenas quando você precisa de GPU)
Valores de cadeia de caracteres, que não podem ser zero ou vazios.
Você pode especificar a memória como um número completo + sufixo; por exemplo, 1024Mi para 1.024 MiB.
limits:
nvidia.com/gpu:
Opcional
(necessário apenas quando você precisa de GPU)
Valores inteiros, que não podem estar vazios e podem ser especificados apenas na limits seção .
Para obter mais informações, consulte a documentação do Kubernetes.
Se você precisar apenas de CPU, poderá omitir a seção inteira limits .

O tipo de instância é necessário para a implantação do modelo. Se você definiu a resources seção e ela será validada em relação ao tipo de instância, as regras são as seguintes:

  • Com uma definição de seção válida resource , os limites de recursos devem ser menores do que os limites de tipo de instância. Caso contrário, a implementação irá falhar.
  • Se você não definir um tipo de instância, o sistema usará defaultinstancetype para validação com a resources seção .
  • Se você não definir a resources seção, o sistema usará o tipo de instância para criar a implantação.

Próximos passos