Visão geral dos modelos personalizados

Este artigo descreve o suporte para modelos personalizados usando o Mosaic AI Model Serving. Fornece informações detalhadas sobre opções de logging de modelos suportadas e tipos de computação suportados, como empacotar dependências de modelo para implementação e diretrizes para criação e escalonamento de endpoints.

O que são modelos personalizados?

O Model Serving pode implantar qualquer modelo Python ou código personalizado como uma API de nível de produção usando recursos de computação de CPU ou GPU. 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 Catálogo Unity (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.

Registrar modelos de ML

Existem diferentes métodos para registrar seu modelo de ML para servir o modelo. A lista a seguir 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)
  

• Registe usando as funcionalidades integradas 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 Catálogo Unity.

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 esteja configurado 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.

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

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

Para informações sobre validação e atualização de dependências antes da implementação, veja validação pré-implementação para Servidor de Modelos.

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 endpoints e expectativas de atualização

• Tempo de implantação: 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. Esse processo pode levar aproximadamente 10 minutos, mas pode levar mais tempo, dependendo da complexidade, tamanho e dependências do modelo.
• Atualizações de tempo de inatividade zero: o Azure Databricks executa uma atualização de ponto 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. Durante esse processo de atualização, você será cobrado pelas configurações de ponto de extremidade antigo e novo até que a transição seja concluída.
• Tempo limite de solicitação: se o cálculo do modelo demorar mais de 297 segundos, as solicitações expirarão.

Expectativas de dimensionamento 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 processar. Estime a simultaneidade necessária usando a fórmula: simultaneidade provisionada = consultas por segundo (QPS) * tempo de execução do modelo (s). Para validar a sua configuração de concorrência, consulte Teste de carga para servir pontos de extremidade.
• 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.
• Dimensionar para zero: Dimensionar para zero é um recurso opcional para pontos de extremidade que permite que eles reduzam 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. O escalonamento a partir de zero geralmente leva de 10 a 20 segundos, mas às vezes pode demorar alguns minutos. Não há SLA para escalonamento a partir de latência zero.
• Otimização de rotas: 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.
• Implementações otimizadas para serverless: Para uma velocidade de implementação mais rápida nos endpoints, utilize implementações otimizadas para serverless.

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 implementar modelos muito grandes, o processo de implementação pode expirar se a construção do contentor e a implementação do modelo excederem uma duração de 60 minutos, ou a construção do contentor pode falhar com o erro "Sem espaço disponível no dispositivo" devido a limitações de armazenamento. Para grandes modelos de linguagem, use as APIs de Foundation Model em vez disso.
• 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.

Aviso de licenciamento da Anaconda para modelos legados

O seguinte aviso é para clientes que confiam na Anaconda com modelos legados.

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 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
• Otimização de rotas em pontos finais de serviço
• Implementações serverless otimizadas para pontos de entrega de modelos
• Configurar o acesso a recursos a partir de pontos de extremidade de serviço de modelo