Implantar modelos personalizados

Este artigo descreve o suporte para implantar um modelo personalizado usando o Mosaic AI Model Serving. Ele também fornece detalhes sobre opções de log de modelo suportadas e tipos de computação, como empacotar dependências de modelo para servir e criação e dimensionamento de pontos finais.

O que são modelos personalizados?

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

Para implantar um modelo personalizado,

1. Registre o modelo ou código no formato MLflow, usando sabores internos nativos do MLflow ou pyfunc.
2. Depois que o modelo for registrado, registre-o no Unity Catalog (recomendado) ou no registro do espaço de trabalho.
3. A partir daqui, você pode criar um modelo de ponto de extremidade de serviço para implantar e consultar seu modelo.
   1. Consulte Criar pontos de extremidade de serviço de modelo personalizado
   2. Consulte 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 serviço de modelo.

O Databricks também oferece suporte à disponibilização de modelos de base para aplicativos generativos de IA, consulte APIs de modelo de base e Modelos externos para modelos suportados e ofertas de computação.

Importante

Se você confia na Anaconda, consulte o aviso de termos de serviço para obter informações adicionais.

Registrar modelos de ML

Existem diferentes métodos para registrar seu modelo de ML para servir o modelo. O seguinte list resume os métodos e exemplos suportados.

• Autologging Este método é ativado automaticamente ao usar o Databricks Runtime for 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)
  

• Faça log usando os sabores integrados do MLflow. Você pode usar esse método se quiser registrar manualmente o modelo para obter 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")
  

• Registo personalizado com pyfunc. Você pode usar esse método para implantar modelos de código python arbitrários ou implantar código adicional ao lado do 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())
  

• Faça o download em HuggingFace. Você pode baixar um modelo diretamente do Hugging Face e registrar esse modelo para servir. Para obter exemplos, consulte Exemplos de blocos de anotações.

Exemplos de assinatura e entrada

É recomendável adicionar um exemplo de assinatura e entrada ao MLflow. As assinaturas são necessárias para registrar modelos no Unity Catalog.

Segue-se 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)

Segue-se 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

O Mosaic AI Model Serving fornece uma variedade de opções de CPU e GPU para implantar seu modelo. Ao implantar com uma GPU, você deve certificar-se de que seu código está set para que as previsões sejam executadas na GPU, usando os métodos fornecidos pela sua estrutura. O MLflow faz isso automaticamente para modelos registrados com os sabores PyTorch ou Transformers.

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

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

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 automaticamente ou especificadas no modelo 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 se deparar com 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. Consulte Usar bibliotecas Python personalizadas com o Model Serving.

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

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

Você pode adicionar dependências de pacote usando:

• O pip_requirements parâmetro:

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

• O conda_env parâmetro:

  
  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 podem 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 MLflow personalizado, é benéfico verificar se o modelo é capaz de ser servido. MLflow fornece uma API que permite a validação do artefato de modelo que simula o ambiente de implantação e permite o teste de dependências modificadas.

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

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

• O model_uri do modelo que é implantado para servir o modelo.
• Um dos seguintes:
  • O input_data no formato esperado para a mlflow.pyfunc.PyFuncModel.predict() chamada do modelo.
  • O input_path que define um arquivo contendo dados de entrada que serão carregados e usados para a chamada para predict.
• O content_type em csv ou json formato.
• Um opcional output_path 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 construir o ambiente para servir:
  • A predefinição é virtualenv. Recomendado para validação de serviço.
  • local está disponível, mas potencialmente propenso a erros para servir a validaçã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_mlflowo . O padrão dessa configuração é .False
• Se deseja update e testar diferentes versões de dependências de pacote para solução de problemas ou depuração. Você pode especificar isso como uma list de substituições ou adições de dependência de cadeia de caracteres usando o argumento override, 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 algum problema com as dependências especificadas com um modelo registrado, você poderá os requisitos usando o da CLI MLflow ou na API Python do MLflow sem registrar outro modelo.

O exemplo a seguir ilustra como update o pip_requirements.txt de um modelo registrado localmente.

Você pode update 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 especificado model_uri .

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 as expectativas e limitações conhecidas para servir modelos personalizados usando o Model Serving.

Criação de ponto de extremidade e expectativas update

Nota

As informações nesta seção não se aplicam a pontos de extremidade que servem modelos de base ou modelos externos.

A implantação de uma versão de modelo recém-registrada envolve o empacotamento do modelo e seu ambiente de modelo e o provisionamento do próprio ponto de extremidade do modelo. Este processo pode demorar aproximadamente 10 minutos.

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

Se a computação do modelo demorar mais de 120 segundos, as solicitações expirarão. 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 realiza atualizações ocasionais do sistema sem tempo de inatividade e manutenção em pontos de extremidade de serviço de modelo existentes. Durante a manutenção, o Databricks recarrega modelos e marca um ponto de extremidade como Falha se um modelo falhar ao recarregar. Certifique-se de que os seus modelos personalizados são robustos e podem ser recarregados a qualquer momento.

Expectativas de dimensionamento de endpoint

Nota

As informações nesta seção não se aplicam a pontos de extremidade que servem modelos de base ou modelos externos.

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

• Simultaneidade provisionada: o número máximo de solicitações paralelas que o sistema pode processar. 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: os endpoints aumentam quase imediatamente com o aumento do tráfego e diminuem a cada cinco minutos para corresponder ao tráfego reduzido.
• Escala até zero: os pontos finais podem ser reduzidos para zero após 30 minutos de inatividade. A primeira solicitação após o dimensionamento para zero experimenta um "arranque a frio", levando a uma latência mais alta. Para aplicativos sensíveis à latência, considere estratégias para gerenciar esse recurso de forma eficaz.

Limitações da carga de trabalho da GPU

A seguir estão as limitações para servir pontos de extremidade com cargas de trabalho de GPU:

• A criação de imagens de contêiner para serviço de GPU leva mais tempo do que a criação de imagem para serviço de CPU devido ao tamanho do modelo e ao aumento dos requisitos de instalação para modelos servidos em GPU.

• Ao implantar modelos muito grandes, o processo de implantação pode atingir o tempo limite se a compilação do contêiner e a implantação do modelo excederem uma duração de 60 minutos. Se isso ocorrer, inicie uma nova tentativa do processo. Uma nova tentativa 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 dimensionar para zero. Os endpoints de GPU podem esperar latência extra alta para a primeira solicitação após o dimensionamento para zero.

• Esta funcionalidade não está disponível no northcentralus.

Licenciamento Anaconda update

O seguinte aviso é para clientes que dependem da Anaconda.

Importante

atualizou seus termos de serviço para anaconda.org canais. Com base nos novos termos de serviço, você pode precisar de uma licença comercial se depender da embalagem e distribuição da Anaconda. Consulte Anaconda Commercial Edition FAQ para obter mais informações. Seu uso de qualquer canal Anaconda é regido por seus termos de serviço.

Os modelos MLflow registrados antes da v1.18 (Databricks Runtime 8.3 ML ou anterior) eram, por padrão, registrados com o canal conda defaults (https://repo.anaconda.com/pkgs/) como dependência. Devido a essa alteração de licença, o Databricks interrompeu o defaults uso do canal para modelos registrados usando 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 defaults canal do ambiente conda para o modelo, esse modelo pode ter uma dependência do defaults canal que você pode não ter pretendido. Para confirmar manualmente se um modelo tem essa dependência, você pode examinar channel o valor no arquivo que é empacotado conda.yaml com o modelo registrado. Por exemplo, um modelo com uma dependência de conda.yaml canal pode ter esta defaults aparência:

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

Como a Databricks não pode determinar se seu uso do repositório Anaconda para interagir com seus modelos é permitido sob seu relacionamento com a Anaconda, a Databricks não está forçando seus clientes a fazer alterações. Se o seu uso do repositório de Anaconda.com através do uso do Databricks for permitido sob os termos da Anaconda, você não precisará tomar nenhuma ação.

Se desejar alterar o canal usado no ambiente de um modelo, você pode registrar novamente o modelo no registro do modelo com um novo conda.yamlarquivo . Você pode fazer isso especificando o conda_env canal no parâmetro de log_model().

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

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

Recursos adicionais

• Criar pontos de extremidade de serviço de modelo personalizado
• Pontos de extremidade de serviço de consulta para modelos personalizados
• Guia de depuração para o Model Serving
• Use bibliotecas Python personalizadas com o Model Serving
• Empacotar artefatos personalizados para o Model Serving
• Implante código Python com o Model Serving
• Configurar a otimização de rotas em pontos de extremidade de serviço
• Configurar o acesso a recursos a partir de pontos de extremidade de serviço de modelo