Implantações de Modelo

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.

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. Este ambiente conda de inferência contém todas as dependências do modelo e é instalado no contêiner do servidor do modelo. Você pode especificar um dos ambientes conda do Data Science ou um ambiente publicado que você criou.

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 para distribuir o tráfego de um ponto para muitos servidores modelo em execução em um pool de VMs (máquinas virtuais). A largura de banda do Balanceador de Carga deve ser especificada em Mbps e é um valor estático. Você pode alterar a largura da banda do Balanceador de Carga editando a implantação do 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 do modelo requer um artefato do modelo que seja armazenado no catálogo de modelo e que o modelo esteja em um 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) que um modelo exige. Os ambientes conda Python suportam Python versões 3.10, 3.11 e 3.12. A versão do Python que você especifica com INFERENCE_PYTHON_VERSION deve corresponder à versão usada ao criar o pack 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 OCI SDK, a CLI ou a Console, você deve fornecer um arquivo runtime.yaml como parte de um artefato do modelo que inclua esses parâmetros.

Observação

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

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 do modelo a extrair o ambiente conda publicado do caminho do serviço Object Storage definido por INFERENCE_ENV_PATH.

MODEL_ARTIFACT_VERSION: '3.0'
MODEL_DEPLOYMENT:
  INFERENCE_CONDA_ENV:
    INFERENCE_ENV_SLUG: generalml_p312_cpu_x86_64_v1
    INFERENCE_ENV_TYPE: data_science
    INFERENCE_ENV_PATH: oci://service-conda-packs@id19sfcrra6z/service_pack/cpu/General_Machine_Learning_for_CPUs_on_Python_3.12/1.0/generalml_p312_cpu_x86_64_v1
    INFERENCE_PYTHON_VERSION: '3.12'

Seus ambientes conda publicados

Você pode criar e publicar ambientes conda para uso em implantações de modelo.

No exemplo a seguir, o arquivo runtime.yaml instrui que a implantação de modelo extraia o ambiente conda publicado pelo caminho do Object Storage definido por tensorflow220_p312_gpu_x86_64_v1. 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>@<namespace>/<prefix>/<env>
    INFERENCE_PYTHON_VERSION: '3.12'

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

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 essas operações de tempo de inatividade zero para trocar o modelo por outro, alterar o formato da VM e a configuração do log, evitando o tempo de inatividade.

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

Você pode integrar implantações de modelo ao serviço Logging. Use essa integração opcional para emitir logs de um modelo e depois 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 exige para inferência. Ele também inclui um servidor de inferência preferencial, como o servidor de inferência Triton, o serviço TensorFlow, o serviço de runtime ONNX, etc.

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 Pré-treinados Generativos.

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.

Saída Pública

Os administradores de tenancy podem desativar o acesso à internet pública gerenciado pelo serviço impondo a política de zona de segurança deny model_deploy_public_network do serviço Data Science. Quando esta política está em vigor, as tentativas de criar ou atualizar implantações de modelo falham com um erro NotAuthorizedOrNotFound e a alternância da Console para acesso público à internet está indisponível.

Observação

O acesso público à internet não está disponível para implantações que usam rede privada ou pontos finais privados.

Consulte Listando Implantações de Modelo e Obtendo Detalhes de uma Implantação de Modelo.