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 especificadonodeSelector
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 especificadonodeSelector
pela extensão e ao campo especificadonodeSelector
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 especificadonodeSelector
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 umInstanceType
recurso personalizado no cluster quando você está executando o comandokubectl 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 e1500Mi
para memória. - Os pods recebem limites de recursos para
1
CPU,2Gi
memória e1
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 aresources
seção . - Se você não definir a
resources
seção, o sistema usará o tipo de instância para criar a implantação.