modelos personalizados implantados

info

Visualização

O Mosaic AI Model Serving está em Public Preview e é compatível com os sites us-east1 e us-central1.

Este artigo descreve o suporte para a implantação de um modelo personalizado usando Mosaic AI Model Serving. Ele também fornece detalhes sobre as opções de registro de modelo compatíveis e os tipos de compute, como empacotar dependências de modelo para servir e criação e dimensionamento de endpoint.

O que são modelos personalizados?

servindo modelo pode implantar qualquer modelo Python como um grau de produção API. A Databricks se refere a esses modelos como modelos personalizados . Esses modelos ML podem ser treinados usando a biblioteca ML padrão, como os transformadores scikit-learn, XGBoost, PyTorch e HuggingFace, e podem incluir qualquer código Python.

Para implantar um modelo personalizado ,

1. registre o modelo ou o código no MLflow formato, usando os sabores na MLflow tivos da integrada ou o pyfunc.
2. Depois que o modelo for registrado, registre-o no site Unity Catalog.
3. A partir daqui, o senhor pode criar um modelo de serviço endpoint para implantar e consultar seu modelo.
   1. Consulte Criar endpoint de modelo de serviço personalizado
   2. Consulte Ponto de extremidade de serviço de consulta para modelos personalizados.

Para obter um tutorial completo sobre como servir modelos personalizados em Databricks, consulte servindo modelo tutorial.

Databricks também oferece suporte ao fornecimento de modelos de base para aplicativos generativos AI. Consulte Modelos externos para conhecer os modelos compatíveis e as ofertas do compute.

important

Se o senhor confiar na Anaconda, consulte o aviso de termos de serviço para obter informações adicionais.

log ML models

Há diferentes métodos para log seu modelo ML para servir de modelo. A lista a seguir resume os métodos e exemplos suportados.

• Autologging Esse método é ativado automaticamente ao usar o Databricks Runtime for ML.

  Python

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

• log usando os sabores integrados do MLflow . O senhor pode usar esse método se quiser log manualmente o modelo para obter um controle mais detalhado.

  Python

  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 personalizado com pyfunc . O senhor pode usar esse método para implantar modelos de código Python arbitrários ou implantar código adicional junto com o seu modelo.

  Python

    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())

Exemplos de assinatura e entrada

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

Veja a seguir um exemplo de assinatura:

Python

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:

Python

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

tipo de cálculo

Mosaic AI Model Serving oferece uma variedade de opções de CPU e GPU para implantar seu modelo. Quando implantado com uma GPU, o senhor deve certificar-se de que seu código esteja configurado para que as previsões sejam executadas na GPU, usando os métodos fornecidos pela sua estrutura. MLflow faz isso automaticamente para os registros de modelos com os sabores PyTorch ou Transformers.

tipo de carga de trabalho	Instância de GPU	memória
CPU		4 GB por simultaneidade
GPU_MEDIUM	L4

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

Durante a implementação, um contêiner de nível de produção é criado e implantado como o endpoint. Esse contêiner inclui a biblioteca capturada automaticamente ou especificada no modelo MLflow.

O contêiner servindo 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 modelos, a Databricks recomenda que o senhor teste o modelo localmente.

pacote e dependências de código

A biblioteca personalizada ou privada pode ser adicionada à sua implantação. Consulte Usar Python biblioteca personalizada com o modelo servindo.

Para os 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.

O senhor pode adicionar dependências do pacote usando:

• O parâmetro pip_requirements:

  Python

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

• O parâmetro conda_env:

  Python

  
  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.

  Python

  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.

Python

  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 pré-implantação: a API Python do MLflow e a CLI do MLflow.

O senhor pode especificar o seguinte usando qualquer uma dessas APIs.

• O site model_uri do modelo que está implantado para servir de 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 contendo 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 gerente de ambiente, env_manager, que é usado para criar o ambiente para servir:

  • O endereço default é virtualenv. Recomendado para validação de serviços.
  • local está disponível, mas é potencialmente suscetível a erros para servir de validação. Geralmente usado apenas para depuração rápida.

• Se o senhor deseja instalar a versão atual do MLflow que está em seu ambiente com o ambiente virtual usando install_mlflow. Essa configuração tem como padrão False.

• Se deve atualizar e testar diferentes versões das dependências do pacote para solução de problemas ou depuração. O senhor pode especificar isso como uma lista de substituições ou adições de dependências de strings usando o argumento override, pip_requirements_override.

Por exemplo:

Python

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, o senhor poderá atualizar os requisitos usando o MLflow CLI ou mlflow.models.model.update_model_requirements() no site MLflow Python API sem precisar log outro modelo.

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

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

Python

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 servindo modelo.

expectativas de criação e atualização de endpoints

nota

As informações desta seção não se aplicam a endpoints que atendem a modelos de fundação ou modelos externos.

A implantação de uma nova versão de modelo registrada envolve empacotar o modelo e seu ambiente de modelo e provisionar o próprio endpoint do modelo. Esse processo pode levar aproximadamente 10 minutos.

O Databricks executa uma atualização sem tempo de inatividade dos endpoints, mantendo a configuração existente do endpoint até que a nova fique pronta. Isso reduz o risco de interrupção dos endpoints que estão em uso.

Se a computação do modelo demorar mais de 120 segundos, as solicitações atingirão o tempo limite. Se o senhor acredita que o cálculo do modelo levará mais de 120 segundos, entre em contato com a equipe Databricks account .

Databricks realiza atualizações e manutenção ocasionais do sistema sem tempo de inatividade no endpoint modelo servindo existente. Durante a manutenção, o site Databricks recarrega os modelos e marca um endpoint como Failed se um modelo não conseguir recarregar. Certifique-se de que seus modelos personalizados sejam robustos e possam ser recarregados a qualquer momento.

expectativas de escalonamento de endpoints

nota

As informações desta seção não se aplicam a endpoints que atendem a modelos de fundação ou modelos externos.

O endpoint de atendimento escala automaticamente com base no tráfego e na capacidade das unidades de simultaneidade de provisionamento.

• provisionamento concurrency: O número máximo de solicitações paralelas que o sistema pode manipular. Estimar a simultaneidade necessária usando a fórmula: simultaneidade de provisionamento = consultas por segundo (QPS) * tempo de execução do modelo (s).
• Comportamento de dimensionamento: o endpoint aumenta quase imediatamente com o aumento do tráfego e diminui a cada cinco minutos para corresponder à redução do tráfego.
• escala para zero: o ponto de extremidade pode escalar para zero após 30 minutos de inatividade. A primeira solicitação após o escalonamento para zero passa por um "início frio", o que leva a uma latência maior. 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 atender ao endpoint com cargas de trabalho de GPU:

• A criação de imagens de contêiner para serviços de GPU leva mais tempo do que a criação de imagens para serviços de CPU devido ao tamanho do modelo e aos maiores requisitos de instalação para modelos fornecidos em GPU.
• Ao implantar modelos muito grandes, o processo de implantação pode ter um tempo limite se a construçã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 sucesso.
• A autoescala 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. O endpoint da GPU pode esperar uma latência extra alta para a primeira solicitação após o escalonamento para zero.

Atualização de licenciamento do Anaconda

O aviso a seguir é para clientes que confiam no Anaconda.

important

A Anaconda Inc. atualizou seus termos de serviço para o canal anaconda.org. Com base nos novos termos de serviço, o senhor pode precisar de uma licença comercial se depender do empacotamento e da distribuição do Anaconda. Para obter mais informações, consulte as Perguntas frequentes sobre o Anaconda Commercial Edition. Seu uso de qualquer canal do Anaconda é regido pelos termos de serviço.

MLflow Os registros de modelos anteriores à v1.18 (Databricks Runtime 8.3 ML ou anterior) eram por registros default com o canal conda defaults (https://repo.anaconda.com/pkgs/) como uma dependência. Devido a essa alteração de licença, o site Databricks interrompeu o uso do canal defaults para registros de modelos que usam MLflow v1.18 e acima. Os registros do canal default agora são conda-forge, que apontam para a comunidade gerenciar https://conda-forge.org/.

Se o senhor fizer o logon de um modelo antes de MLflow v1.18 sem excluir o canal defaults do ambiente conda para o modelo, esse modelo poderá ter uma dependência do canal defaults que o senhor talvez não tenha pretendido. Para confirmar manualmente se um modelo tem essa dependência, o senhor pode examinar o valor channel no arquivo conda.yaml que é empacotado com os modelos registrados. Por exemplo, o site conda.yaml de um modelo com uma dependência de canal defaults pode ter a seguinte aparência:

YAML

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 o uso do repositório do Anaconda para interagir com seus modelos é permitido de acordo com seu relacionamento com o Anaconda, a Databricks não está forçando seus clientes a fazer nenhuma alteração. Se o seu uso do repositório Anaconda.com por meio do uso do Databricks for permitido de acordo com os termos do Anaconda, o senhor não precisará tomar nenhuma medida.

Se quiser alterar o canal usado no ambiente de um modelo, o senhor pode registrar novamente o modelo no registro de modelo com um novo conda.yaml. O senhor pode fazer isso especificando o canal no parâmetro conda_env de log_model().

Para obter mais informações sobre log_model() API, consulte a documentação MLflow da variante de modelo com a qual o senhor está trabalhando, por exemplo, os logs de scikit-learn.

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

Recurso adicional

• Criar um endpoint de modelo de serviço personalizado
• Ponto de extremidade de serviço de consulta para modelos personalizados
• guia de depuração para manutenção do modelo
• Use bibliotecas Python personalizadas com o serviço de modelo
• Artefatos personalizados do pacote para serviços de modelo
• implantado Python code with servindo modelo
• Configure o acesso aos recursos de endpoints de serviço de modelo