Implantar modelos personalizados

Este artigo descreve o suporte da implantação de um modelo personalizado usando o Serviço de Modelo do Mosaic AI. Ele também fornece detalhes sobre opções de registro em log de modelo com suporte e tipos de computação, como empacotar dependências de modelo para serviço e criação e dimensionamento de ponto de extremidade.

O que são modelos personalizados?

O Serviço de Modelo pode implantar qualquer modelo do Python como uma API de nível de produção. O Databricks refere-se a modelos como modelos personalizados. Esses modelos de ML podem ser treinados usando bibliotecas ML padrão, como scikit-learn, XGBoost, PyTorch e transformadores do HuggingFace e podem incluir qualquer código Python.

Para implantar um modelo personalizado,

1. Registre o modelo ou o código no formato MLflow usando os tipos internos MLflow nativos ou pyfunc.
2. Depois que o modelo for registrado, registre-o no Catálogo do Unity (recomendado) ou no registro do workspace.
3. A partir daqui, você pode criar um ponto de extremidade de serviço de modelo para implantar e consultar seu modelo.
   1. Confira Criar pontos de extremidade de serviço de modelo personalizados
   2. Confira Pontos de extremidade de serviço de consulta para modelos personalizados.

Para obter um tutorial completo sobre como servir modelos personalizados no Databricks, consulte Tutorial de fornecimento de modelo.

O Databricks também dá suporte ao fornecimento de modelos de base para aplicativos de IA geradores, consulte APIs do Modelo do Foundation e Modelos externos para modelos e ofertas de computação com suporte.

Importante

Se você depender do Anaconda, examine os termos de aviso de serviço para obter informações adicionais.

Registrar em log modelos de ML

Existem diferentes métodos de registrar em log o seu modelo de ML para serviço de modelo. A lista a seguir resume os métodos e exemplos com suporte.

• Registro automático Esse método é habilitado automaticamente ao usar o Databricks Runtime para ML.

  import mlflow
  from sklearn.ensemble import RandomForestRegressor
  from sklearn.datasets import load_iris
  
  iris = load_iris()
  model = RandomForestRegressor()
  model.fit(iris.data, iris.target)
  

• Registrar em log utilizando as variantes internas do MLflow. Você pode usar esse método se quiser registrar manualmente o modelo em log para um controle mais detalhado.

  import mlflow
  from sklearn.ensemble import RandomForestClassifier
  from sklearn.datasets import load_iris
  
  iris = load_iris()
  model = RandomForestClassifier()
  model.fit(iris.data, iris.target)
  
  with mlflow.start_run():
      mlflow.sklearn.log_model(model, "random_forest_classifier")
  

• Registro em log personalizado com pyfunc. Você pode usar esse método para implantar modelos arbitrários de código python ou implantar código adicional com seu modelo.

    import mlflow
    import mlflow.pyfunc
  
    class Model(mlflow.pyfunc.PythonModel):
        def predict(self, context, model_input):
            return model_input * 2
  
    with mlflow.start_run():
        mlflow.pyfunc.log_model("custom_model", python_model=Model())
  

• Baixe do HuggingFace. Você poderá baixar um modelo diretamente do Hugging Face e registrar esse modelo para servir. Para obter exemplos, consulte exemplos de Notebook.

Exemplos de assinatura e entrada

É recomendável adicionar uma assinatura e um exemplo de entrada ao MLflow. As assinaturas são necessárias para registrar modelos em log no Catálogo do Unity.

Veja a seguir um exemplo de assinatura:

from mlflow.models.signature import infer_signature

signature = infer_signature(training_data, model.predict(training_data))
mlflow.sklearn.log_model(model, "model", signature=signature)

Veja a seguir um exemplo de entrada:

input_example = {"feature1": 0.5, "feature2": 3}
mlflow.sklearn.log_model(model, "model", input_example=input_example)

Tipo de computação

Observação

O modelo de serviço de GPU está em Visualização Pública.

O Serviço de Modelo do Mosaic AI oferece uma variedade de opções de CPU e GPU para implementar seu modelo. Ao implantar com uma GPU, é essencial garantir que seu código esteja configurado para que as previsões sejam executadas na GPU, usando os métodos fornecidos por sua estrutura. O MLflow faz isso automaticamente para modelos registrados com as variantes PyTorch ou Transformadores.

Tipo de carga de trabalho	Instância de GPU	memória
CPU		4 GB por simultaneidade
GPU_SMALL	1xT4	16 GB
GPU_LARGE	1xA100	80GB
GPU_LARGE_2	2xA100	160GB

Contêiner e dependências de implantação

Durante a implantação, um contêiner de nível de produção é criado e implantado como o ponto de extremidade. Esse contêiner inclui bibliotecas capturadas ou especificadas automaticamente no modelo do MLflow.

O contêiner de serviço de modelo não contém dependências pré-instaladas, o que pode levar a erros de dependência se nem todas as dependências necessárias forem incluídas no modelo. Ao executar problemas de implantação de modelo, o Databricks recomenda que você teste o modelo localmente.

Dependências de pacote e código

Bibliotecas personalizadas ou privadas podem ser adicionadas à sua implantação. Confira Usar bibliotecas do Python personalizadas com Serviço de Modelo.

Para modelos de sabor nativo do MLflow, as dependências de pacote necessárias são capturadas automaticamente.

Para modelos pyfunc personalizados, as dependências podem ser adicionadas explicitamente.

Você pode adicionar dependências de pacote usando:

• O parâmetro pip_requirements:

  mlflow.sklearn.log_model(model, "sklearn-model", pip_requirements = ["scikit-learn", "numpy"])
  

• O parâmetro conda_env:

  
  conda_env = {
      'channels': ['defaults'],
      'dependencies': [
          'python=3.7.0',
          'scikit-learn=0.21.3'
      ],
      'name': 'mlflow-env'
  }
  
  mlflow.sklearn.log_model(model, "sklearn-model", conda_env = conda_env)
  

• Para incluir requisitos adicionais além do que é capturado automaticamente, use extra_pip_requirements.

  mlflow.sklearn.log_model(model, "sklearn-model", extra_pip_requirements = ["sklearn_req"])
  

Se você tiver dependências de código, elas poderão ser especificadas usando code_path.

  mlflow.sklearn.log_model(model, "sklearn-model", code_path=["path/to/helper_functions.py"],)

Validação de dependência

Antes de implantar um modelo personalizado do MLflow, é bom verificar se o modelo pode ser servido. O MLflow fornece uma API que permite a validação do artefato do modelo que simula o ambiente de implantação e permite o teste de dependências modificadas.

Há duas APIs de validação de pré-implantação no API do Python do MLflow e a CLI do MLflow.

Você pode especificar o seguinte usando qualquer uma dessas APIs.

• O model_uri do modelo que é implantado para o serviço do modelo.
• Um dos seguintes:
  • O input_data no formato esperado para a chamada mlflow.pyfunc.PyFuncModel.predict() do modelo.
  • O input_path que define um arquivo que contém dados de entrada que serão carregados e usados para a chamada para predict.
• O content_type no formato csv ou json.
• Um output_path opcional para gravar as previsões em um arquivo. Se você omitir esse parâmetro, as previsões serão impressas em stdout.
• Um gerenciador de ambiente, env_manager, que é usado para compilar o ambiente para serviço:
  • O padrão é virtualenv. Recomendado para servir a validação.
  • local está disponível, mas potencialmente propenso a erros para a validação de serviço. Geralmente usado apenas para depuração rápida.
• Se deseja instalar a versão atual do MLflow que está em seu ambiente com o ambiente virtual usando install_mlflow. Essa configuração usa False como padrão.
• Se deve atualizar e testar diferentes versões de dependências de pacotes para solução de problemas ou depuração. Você pode especificar isso como uma lista de substituições ou adições de dependência de cadeia de caracteres usando o argumento de substituição, pip_requirements_override.

Por exemplo:

import mlflow

run_id = "..."
model_uri = f"runs:/{run_id}/model"

mlflow.models.predict(
  model_uri=model_uri,
  input_data={"col1": 34.2, "col2": 11.2, "col3": "green"},
  content_type="json",
  env_manager="virtualenv",
  install_mlflow=False,
  pip_requirements_override=["pillow==10.3.0", "scipy==1.13.0"],
)

Atualizações de dependência

Se houver problemas com as dependências especificadas com um modelo registrado, você poderá atualizar os requisitos usando a CLI do MLflow ou mlflow.models.model.update_model_requirements() na API do Python do MLflow sem precisar registrar outro modelo em log.

O exemplo a seguir mostra como atualizar o pip_requirements.txt de um modelo registrado no local.

Você pode atualizar definições existentes com versões de pacote especificadas ou adicionar requisitos inexistentes ao arquivo pip_requirements.txt. Esse arquivo está dentro do artefato do modelo MLflow no local de model_uri especificado.

from mlflow.models.model import update_model_requirements

update_model_requirements(
  model_uri=model_uri,
  operation="add",
  requirement_list=["pillow==10.2.0", "scipy==1.12.0"],
)

Expectativas e limitações

As seções a seguir descrevem expectativas e limitações conhecidas para servir modelos personalizados usando o Serviço de Modelo.

Expectativas de criação e atualização de ponto de extremidade

Observação

As informações desta seção não se aplicam a pontos de extremidade que fornecem modelos de base.

Implantar uma versão de modelo recém-registrada envolve empacotar o modelo e seu ambiente de modelo e provisionar o ponto de extremidade do modelo em si. Esse processo pode levar aproximadamente 10 minutos.

O Azure Databricks executa uma atualização de tempo de inatividade zero dos pontos de extremidade mantendo a configuração do ponto de extremidade existente até que a nova fique pronta. Isso reduz o risco de interrupção para pontos de extremidade que estão em uso.

Se a computação de modelo levar mais de 120 segundos, as solicitações terão tempo limite. Se você acredita que a computação do modelo levará mais de 120 segundos, entre em contato com sua equipe de conta do Azure Databricks.

O Databricks executa atualizações ocasionais do sistema de tempo de inatividade zero e manutenção em pontos de extremidade existentes do Serviço de Modelo. Durante a manutenção, o Databricks recarrega modelos e marca um ponto de extremidade como Falha se um modelo não for recarregado. Verifique se os modelos personalizados são robustos e podem recarregar a qualquer momento.

Expectativas de dimensionamento de ponto de extremidade

Observação

As informações desta seção não se aplicam a pontos de extremidade que fornecem modelos de base.

Os pontos de extremidade de serviço são dimensionados automaticamente com base no tráfego e na capacidade das unidades de simultaneidade provisionadas.

• A simultaneidade provisionada é o número máximo de solicitações paralelas que o sistema pode manipular. Estime a simultaneidade necessária usando a fórmula: simultaneidade provisionada = consultas por segundo (QPS) * tempo de execução do modelo (s).
• Comportamento de dimensionamento: pontos de extremidade aumentam quase imediatamente com o aumento do tráfego e reduzem verticalmente a cada cinco minutos para corresponder ao tráfego reduzido.
• Escala para zero: pontos de extremidade podem reduzir para zero após 30 minutos de inatividade. A primeira solicitação após o dimensionamento para zero experimenta uma “inicialização a frio” levando a uma latência maior. Para aplicativos sensíveis à latência, considere estratégias para gerenciar esse recurso com eficiência.

Limitações da carga de trabalho da GPU

Veja a seguir as limitações para atender pontos de extremidade com cargas de trabalho de GPU:

• A criação de imagem de contêiner para o serviço de GPU leva mais tempo do que a criação de imagem para o serviço de CPU devido ao tamanho do modelo e ao aumento dos requisitos de instalação para modelos servidos da GPU.
• Ao implantar modelos muito grandes, o processo de implantação pode ultrapassar o tempo limite se a implantação do modelo e do build do contêiner exceder uma duração de 60 minutos. Caso isso ocorra, iniciar uma nova tentativa do processo deve implantar o modelo com êxito.
• O dimensionamento automático para o serviço de GPU leva mais tempo do que para o serviço de CPU.
• A capacidade da GPU não é garantida ao escalar para zero. Os pontos de extremidade da GPU podem esperar uma latência extra alta para a primeira solicitação após a escala para zero.
• Essa funcionalidade não está disponível no northcentralus.

Atualização de licenciamento do Anaconda

O aviso a seguir destina-se aos clientes que dependem do Anaconda.

Importante

O Anaconda Inc. atualizou os termos de serviço dos canais de anaconda.org. Com base nos novos termos de serviço, você poderá precisar de uma licença comercial se depender do empacotamento e da distribuição do Anaconda. Confira Perguntas frequentes sobre a Edição Comercial do Anaconda para obter mais informações. O uso de qualquer canal do Anaconda é regido pelos termos de serviço.

Os modelos de MLflow registrados antes da v1.18 (Databricks Runtime 8.3 ML ou anterior) eram registrados por padrão com o canal conda defaults (https://repo.anaconda.com/pkgs/) como uma dependência. Devido a essa alteração de licença, o Databricks interrompeu o uso do canal defaults para modelos registrados usando o MLflow v1.18 e superior. O canal padrão registrado agora é conda-forge, o que aponta para a comunidade gerenciada https://conda-forge.org/.

Se você registrou um modelo antes do MLflow v1.18 sem excluir o canal defaults do ambiente conda para o modelo, esse modelo poderá ter uma dependência no canal defaults que talvez você não tenha pretendido. Para confirmar manualmente se um modelo tem essa dependência, você pode examinar o valor channel no arquivo conda.yaml que está empacotado com o modelo registrado. Por exemplo, um conda.yaml de modelo com uma dependência de canal defaults pode ser assim:

channels:
- defaults
dependencies:
- python=3.8.8
- pip
- pip:
    - mlflow
    - scikit-learn==0.23.2
    - cloudpickle==1.6.0
      name: mlflow-env

Como o Databricks não pode determinar se o uso do repositório do Anaconda para interagir com seus modelos é permitido em seu relacionamento com o Anaconda, o Databricks não está forçando seus clientes a fazer alterações. Se o uso do repositório do Anaconda.com por meio do Databricks for permitido nos termos do Anaconda, você não precisará tomar nenhuma medida.

Caso você queira alterar o canal usado no ambiente de um modelo, é possível registrar novamente o modelo no registro de modelo com um novo conda.yaml. Você pode fazer isso especificando o canal no parâmetro conda_env de log_model().

Para obter mais informações sobre a API log_model(), consulte a documentação do MLflow para o sabor do modelo com o qual você está trabalhando, por exemplo, log_model para scikit-learn.

Para obter mais informações sobre os arquivos conda.yaml, consulte a Documentação do MLflow.

Recursos adicionais

• Tutorial: Implantar e consultar um modelo personalizado
• Criar pontos de extremidade de serviço de modelo personalizados
• Consultar pontos de extremidade de serviço para modelos personalizados
• Usar bibliotecas do Python personalizadas com Serviço de Modelo
• Empacotar artefatos personalizados para Serviço de Modelo
• Implantar código Python com o Serviço de Modelo
• Fornecer vários modelos para um ponto de extremidade de Serviço de Modelo
• Configurar o acesso aos recursos dos pontos de extremidade do serviço de modelo
• Configurar a otimização de rota em pontos de extremidade de serviço