Implantações de Modelo

Treinamento

O treinamento de um modelo é a primeira etapa para implantar um modelo. Você usa sessões de notebook e jobs para treinar modelos de código aberto e do Oracle AutoML.

Salvando e Armazenando

Em seguida, você armazena o modelo treinado no catálogo de modelos. Você tem estas opções para salvar um modelo no catálogo de modelos:

• O ADS SDK fornece uma interface para especificar um modelo de código-fonte aberto, preparar o artefato de modelo e salvar esse artefato no catálogo de modelos.

• Você pode usar a Console do OCI, SDKs e CLIs para salvar seu artefato de modelo no catálogo de modelos.

• Use frameworks diferentes, como scikit-learn, TensorFlow ou Keras.

A implantação de modelo exige que você especifique um ambiente conda de inferência no arquivo de artefato de modelo runtime.yaml. Esse ambiente conda de inferência contém todas as dependências de modelo e é instalado no contêiner do servidor de modelo. Você pode especificar um dos ambientes conda do serviço Data Science ou um ambiente publicado.

Uma Implantação de Modelo

Depois que um modelo é salvo no catálogo de modelos, ele fica disponível para implantação como recurso de Implantação de Modelo. O serviço suporta modelos em execução em um ambiente de runtime Python e suas dependências podem ser compactadas em um ambiente conda.

Você pode implantar e chamar um modelo usando a Console, os SDKs e a CLI do OCI, bem como o ADS SDK nas sessões de notebook.

As implantações de modelo dependem desses componentes principais para implantar um modelo como ponto final HTTP:

Balanceador de Carga.

Quando uma implantação de modelo é criada, um Balanceador de Carga deve ser configurado. Um Balanceador de Carga fornece uma maneira automatizada de distribuir o tráfego de um ponto de entrada para muitos servidores de modelo sendo executados em um pool de máquinas virtuais (VMs). A largura de banda do Balanceador de Carga deve ser especificada em Mbps e é um valor estático. Você pode alterar a largura de banda do Balanceador de Carga editando a implantação de modelo.

Um pool de instâncias de VM que hospedam o servidor de modelos, o ambiente conda e o próprio modelo.

Uma cópia do servidor de modelos é feita em cada instância de Computação no pool de VMs.

Uma cópia do ambiente conda de inferência e do artefato de modelo selecionado também são copiados para cada instância no pool. Duas cópias do modelo são carregadas na memória para cada OCPU de cada instância de VM no pool. Por exemplo, se você selecionar uma instância VM.Standard2.4 para executar o servidor de modelos, 4 OCPUs x 2 = 8 cópias do modelo serão carregadas na memória. Várias cópias do modelo ajudam a tratar solicitações simultâneas feitas ao ponto final de modelo distribuindo essas solicitações entre as réplicas de modelos na memória da VM. Certifique-se de selecionar uma forma de VM com um volume de memória suficiente para levar em conta essas réplicas de modelos na memória. Para a maioria dos modelos de aprendizado de máquina com tamanhos em MBs ou em GBs baixos, a memória provavelmente não é um problema.

O Balanceador de Carga distribui as solicitações feitas ao ponto final de modelo entre as instâncias do pool. Recomendamos que você use formas de VM menores para hospedar o modelo com um número maior de instâncias, em vez de selecionar menos VMs maiores.

Artefatos de modelos no catálogo de modelos.

A implantação de modelo exige um artefato de modelo que esteja armazenado no catálogo de modelos e que o modelo esteja em estado ativo. A implantação de modelo expõe a função predict() definida no arquivo score.py do artefato de modelo.

Ambiente conda com dependências de runtime de modelo.

Um ambiente conda encapsula todas as dependências Python de terceiros (como Numpy, Dask ou XGBoost) exigidas por um modelo. Os ambientes conda Python suportam Python nas versões 3.7, 3.8, 3.9, 3.10 e 3.11. A versão do Python especificada com INFERENCE_PYTHON_VERSION deve corresponder à versão usada ao criar o pacote conda.

A implantação de modelo extrai uma cópia do ambiente conda de inferência definido no arquivo runtime.yaml do artefato de modelo para implantar o modelo e suas dependências. As informações relevantes sobre o ambiente de implantação de modelo estão no parâmetro MODEL_DEPLOYMENT do arquivo runtime.yaml. Os parâmetros MODEL_DEPLOYMENT são capturados automaticamente quando um modelo é salvo usando o ADS em uma sessão de notebook. Para salvar um modelo no catálogo e implantá-lo usando o SDK, a CLI ou a Console do OCI, forneça um arquivo runtime.yaml como parte de um artefato de modelo que inclua esses parâmetros.

Observação

Para todos os artefatos de modelo salvos no catálogo de modelos sem um arquivo runtime.yaml ou quando estiver faltando o parâmetro MODEL_DEPLOYMENT no arquivo runtime.yaml, um ambiente conda padrão será instalado no servidor de modelo e usado para carregar o modelo. O ambiente conda padrão usado é o General Machine Learning com o Python versão 3.8.

Use estes ambientes conda:

Ambientes conda do serviço Data Science

Há uma lista dos ambientes conda em Exibindo os Ambientes Conda.

No exemplo a seguir, o arquivo runtime.yaml instrui a implantação de modelo a extrair o ambiente conda publicado do caminho do serviço Object Storage definido por INFERENCE_ENV_PATH no ONNX 1.10 para CPU com Python 3.7.

MODEL_ARTIFACT_VERSION: '3.0'
MODEL_DEPLOYMENT:
  INFERENCE_CONDA_ENV:
    INFERENCE_ENV_SLUG: envslug
    INFERENCE_ENV_TYPE: data_science
    INFERENCE_ENV_PATH: oci://service-conda-packs@id19sfcrra6z/service_pack/cpu/ONNX 1.10 for CPU on Python 3.7/1.0/onnx110_p37_cpu_v1
    INFERENCE_PYTHON_VERSION: '3.7'

Seus ambientes conda publicados

Você cria e publica ambientes conda para uso em implantações de modelo.

No exemplo a seguir, o arquivo runtime.yaml instrui a implantação do modelo a extrair o ambiente conda publicado do caminho do serviço Object Storage definido por INFERENCE_ENV_PATH. Em seguida, ele o instala em todas as instâncias do pool que hospeda o servidor de modelo e o próprio modelo.

MODEL_ARTIFACT_VERSION: '3.0'
MODEL_DEPLOYMENT:
  INFERENCE_CONDA_ENV:
    INFERENCE_ENV_SLUG: envslug
    INFERENCE_ENV_TYPE: published
    INFERENCE_ENV_PATH: oci://<bucket-name>@I/<prefix>/<env>
    INFERENCE_PYTHON_VERSION: '3.7'

Para todos os artefatos de modelo salvos no catálogo sem um arquivo runtime.yaml, as implantações de modelo também usam o ambiente conda padrão para implantação de modelo. Uma implantação de modelo também pode extrair um ambiente conda do serviço Data Science ou um que você cria ou altera e, em seguida, publica.

Operações sem Indisponibilidade

Operações sem indisponibilidade para implantações de modelo significam que o ponto final de inferência de modelo (previsão) pode atender continuamente às solicitações sem interrupção ou instabilidade.

As implantações de modelo suportam uma série de operações que podem ser executadas durante a manutenção sem indisponibilidade. Esse recurso é essencial para qualquer aplicativo que consuma o ponto final de modelo. Você pode aplicar operações sem indisponibilidade quando o modelo está em um estado ativo atendendo às solicitações. Use estas operações sem indisponibilidade para trocar o modelo por outro, alterar a forma da VM e a configuração de registro em log, evitando a indisponibilidade.

Integração do Serviço Logging para Capturar Logs Emitidos na Implantação de Modelo

Você pode integrar as implantações de modelo com o serviço Logging. Use essa integração opcional para emitir logs de um modelo e, em seguida, inspecionar esses logs.

Contêiner personalizado com dependências de runtime do modelo

Um contêiner personalizado encapsula todas as dependências de terceiros necessárias que um modelo requer para inferência. Ele também inclui um servidor de inferência preferencial, como servidor de inferência Triton, serviço TensorFlow, serviço de runtime ONNX e assim por diante.

Inferência de GPU

A inferência da Unidade de Processamento Gráfico é amplamente usada para modelos com uso intensivo de computação, como LLaMa ou Transformadores Generativos Pré-treinados.

Saída Personalizada

Você pode selecionar entre rede gerenciada pelo serviço ou rede gerenciada pelo cliente, semelhante à saída personalizada com Jobs e Notebooks.

Ponto Final Privado

Para aumentar a segurança e o controle, você pode acessar implantações de modelo por meio de uma rede privada (implantação de modelo privado). Com suporte para pontos finais privados, seu tráfego de inferência permanece seguro dentro da rede privada. Para obter mais informações, consulte a seção Criando um Ponto Final Privado e Criando uma Implantação de Modelo para configurar uma implantação de modelo com um ponto final privado.

Detalhes de Implantações de Modelo

Após você selecionar um projeto, a página de detalhes do Projeto é exibida com uma lista de sessões de notebook e outros recursos, como implantações de modelo.

Selecione Implantações de modelo para ir até a página de detalhes de implantações de modelo do compartimento selecionado, na qual você pode:

• Criar implantações de modelo.

• Selecionar uma implantação de modelo para exibir seus detalhes e trabalhar com ela.

• Use o menu Ações (três pontos) para exibir detalhes, editar, mover uma implantação de modelo ou excluir uma implantação de modelo.

• OCID: O OCID de um recurso. Uma versão abreviada do OCID é exibida, embora você possa usar Mostrar e Ocultar para alternar a exibição do OCID. Use o link Copiar para salvar o OCID inteiro na área de transferência para colá-lo em outro lugar. Por exemplo, você pode colar em um arquivo e salvá-lo e usá-lo em scripts de modelo.

• Usar o filtro Escopo da Lista para exibir em outro compartimento as implantações de modelo associadas ao projeto selecionado.

• Filtrar implantações de modelo por status usando a lista Estado. O padrão é exibir todos os tipos de status.

• Quando as tags aplicadas às implantações de modelo, você pode filtrar ainda mais as implantações clicando em adicionar ou limpar ao lado de Filtros de Tag.

• Selecione outros recursos do serviço Data Science, como modelos, implantações de modelo e sessões de notebook.