Visão geral de modelos personalizados

Este artigo descreve o suporte para modelos personalizados usando o Mosaic AI Model Serving. Ele fornece detalhes sobre opções de registro de logs de modelos com suporte e tipos de computação, como empacotar as dependências dos modelos para disponibilização, e expectativas para criação e escalonamento de endpoints.

O que são modelos personalizados?

O Serviço de Modelo pode implantar qualquer modelo do Python ou código personalizado como uma API de nível de produção usando recursos de computação de CPU ou GPU. O Databricks refere-se a esses 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 sabores nativos integrados do MLflow 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. Consulte 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 o tutorial de serviço de modelo.

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

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)
  

• Registre usando as funcionalidades 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 Bloco de Anotações.

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

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, você deve verificar se o código está 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.

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. A imagem base pode incluir algumas dependências no nível do sistema, mas as dependências no nível do aplicativo devem ser especificadas explicitamente em seu modelo de MLflow.

Se nem todas as dependências necessárias forem incluídas no modelo, você poderá encontrar erros de dependência durante a implantação. 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. Consulte Usar bibliotecas personalizadas do Python com o Model Serving.

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. Para obter informações detalhadas sobre requisitos de registro em log e práticas recomendadas, consulte a documentação de Modelos do MLflow e a referência da API do Python do MLflow.

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

Para obter informações sobre como validar e atualizar dependências antes da implantação, consulte a validação de pré-implantação para Model Serving.

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

• 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 ponto de extremidade do modelo em si. Esse processo pode levar aproximadamente 10 minutos, mas pode levar mais tempo dependendo da complexidade, do tamanho e das dependências do modelo.
• Atualizações de tempo de inatividade zero: 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 atualizada até que a nova fique pronta. Isso reduz o risco de interrupção para pontos de extremidade que estão em uso. Durante esse processo de atualização, você será cobrado por ambas as configurações de endpoint antigas e novas até que a transição seja concluída.
• Tempo limite da solicitação: se a computação de modelo levar mais de 297 segundos, as solicitações terão tempo limite.

Expectativas de escalabilidade de endpoint

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 manipular. Estime a simultaneidade necessária usando a fórmula: simultaneidade provisionada = consultas por segundo (QPS) * tempo de execução do modelo (s). Para validar sua configuração de simultaneidade, consulte Teste de carga para pontos de extremidade de serviço.
• 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.
• Dimensionar para zero: Dimensionar para zero é um recurso opcional para endpoints que permite que eles abaixem para zero após 30 minutos de inatividade. A primeira solicitação após o dimensionamento para zero experimenta um "início frio", levando a uma latência maior. O aumento a partir do zero geralmente leva de 10 a 20 segundos, mas às vezes pode levar minutos. Não há nenhum SLA em escala de latência zero.
• Otimização de rota: Para casos de uso de alta QPS e baixa latência, a otimização de rota é a opção ideal e recomendada para melhorar o desempenho.
• Implantações otimizadas sem servidor: Para obter uma velocidade de implantação de endpoints mais rápida, use implantações otimizadas sem servidor.

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 poderá atingir o tempo limite se a construção do contêiner e a implantação do modelo excederem uma duração de 60 minutos, ou a construção do contêiner poderá falhar com o erro "Sem espaço disponível no dispositivo" devido a limitações de armazenamento. Para modelos de linguagem grandes, use em vez disso APIs do Modelo Fundamental.
• 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.

Aviso de licenciamento da Anaconda para modelos herdados

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

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

Recursos adicionais

• Criar pontos de extremidade do serviço de modelo personalizados
• Consultar pontos de extremidade de serviço para modelos personalizados
• Guia de depuração para Serviço de Modelo
• Usar bibliotecas personalizadas do Python com o Serviço de Modelo
• Empacotar artefatos personalizados para Model Serving
• Implantar código Python com Serviço de Modelo
• Otimização de rota em pontos de extremidade do serviço
• Implantações otimizadas sem servidor para endpoints de serviço de modelo
• Configurar o acesso aos recursos dos pontos de extremidade do serviço de modelo