Visão geral de modelos personalizados

Este artigo descreve o suporte para modelos personalizados usando Mosaic AI Model Serving. Ele fornece detalhes sobre opções de registro de modelo e tipos compute suportados, como empacotar dependências de modelo para atendimento e expectativas para criação e dimensionamento endpoint .

O que são modelos personalizados?

O modelo de abastecimento pode implementar qualquer modelo Python ou código personalizado como uma API de nível de produção usando recurso compute de CPU ou GPU. Databricks se refere a esses modelos como modelos personalizados . Esses modelos ML podem ser treinados usando bibliotecas 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 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 AI generativa. Consulte Modelos de base com suporte no Mosaic AI Model Serving.

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	1xL4	24 GB

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

Durante a implantação, um contêiner de nível de produção é criado e distribuído como endpoint. Este contêiner inclui bibliotecas capturadas ou especificadas automaticamente no modelo MLflow . A imagem base pode incluir algumas dependências no nível do sistema, mas as dependências no nível do aplicativo devem ser explicitamente especificadas no seu modelo MLflow.

Se nem todas as dependências necessárias estiverem incluídas no modelo, você poderá encontrar erros de dependência durante a implantação. Ao encontrar problemas de implantação do modelo, a Databricks recomenda que você 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, dependências podem ser adicionadas explicitamente. Para obter informações detalhadas sobre requisitos de registro e práticas recomendadas, consulte a documentação dos modelosMLflow e a referência API Python MLflow.

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"],)

Para obter informações sobre como validar e atualizar dependências antes da implantação, consulte Antes das verificações de validação da implantação do modelo.

Expectativas e limitações

nota

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

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

• Tempo de implantação : implantar uma versão de modelo recém-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, mas pode demorar mais dependendo da complexidade, do tamanho e das dependências do modelo.
• Atualizações sem tempo de inatividade : Databricks executa uma atualização sem tempo de inatividade do endpoint, mantendo a configuração endpoint existente até que o novo esteja pronto. Isso reduz o risco de interrupção dos endpoints em uso. Durante esse processo de atualização, você será cobrado pelas configurações de endpoint antigas e novas até que a transição seja concluída.
• Tempo limite da solicitação : se o cálculo do modelo demorar mais de 297 segundos, as solicitações expirarão.

important

Databricks realiza atualizações e manutenções ocasionais do sistema com tempo de inatividade zero no ponto de extremidade do modelo de posto existente. Durante a manutenção, o Databricks recarrega os modelos. Se um modelo não for recarregado, a atualização do endpoint será marcada como falha e a configuração do endpoint existente continuará atendendo às solicitações. Certifique-se de que seus modelos personalizados sejam robustos e possam ser recarregados a qualquer momento.

expectativas de escalonamento de endpoints

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 requisições paralelas que o sistema pode manipular. Estime a simultaneidade necessária usando a fórmula: provisionamento concurrency = consultas por segundo (QPS) * tempo de execução do modelo (s). Para validar sua configuração de simultaneidade, consulte Teste de carga para o endpoint de serviço.
• 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.
• escalar para zero: escalar para zero é um recurso opcional para endpoint que permite que eles sejam reduzidos para zero após 30 minutos de inatividade. A primeira solicitação após o dimensionamento para zero sofre um "início frio", resultando em maior latência. Aumentar a escala do zero geralmente leva de 10 a 20 segundos, mas às vezes pode levar minutos. Não há SLA em escala a partir de latência zero.
• Otimização de rota: para casos de uso de alto QPS e baixa latência, a otimização de rota é a opção ideal e recomendada para melhorar o desempenho.

atenção

A escala para zero não deve ser usada para cargas de trabalho de produção que exigem tempo de atividade consistente ou tempos de resposta garantidos. Para aplicativos sensíveis à latência ou endpoints que exigem disponibilidade contínua, desabilite a escala para zero.

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 expirar se a construção do contêiner e a implantação do modelo excederem a duração de 60 minutos.
• 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.

Aviso de licenciamento do Anaconda para modelos legados

nota

Esta seção se aplica somente a logs de modelos com MLflow v1.17 ou anterior (Databricks Runtime 8.3 ML ou anterior). Se estiver usando uma versão mais recente, você pode pular esta seção.

O aviso a seguir é para clientes que dependem do Anaconda com modelos legados.

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 da Anaconda é regido pelos respectivos 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 em seu relacionamento com o Anaconda, a Databricks não está forçando seus clientes a fazer alterações. 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