implantado modelos personalizados

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 suportadas 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?

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

Para implantar um modelo customizado,

1. registra o modelo ou código no formato MLflow, usando sabores nativos do MLflow integrado ou pyfunc.

2. Depois que o modelo for registrado, registre-o no Unity Catalog (recomendado) ou no registro do workspace .

3. A partir daí, o senhor pode criar um endpoint servindo modelo 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 no Databricks, consulte tutorialde modelo de instalação.

Databricks O Foundation Model APIs e External models para modelos compatíveis e ofertas do compute.

Importante

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

registra modelos de ML

Existem diferentes métodos para registrar seu modelo de ML para o modelo de operação. A lista a seguir resume os métodos e exemplos suportados.

• Registro automático Este método é habilitado 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)
  

• logs usando os sabores integrados do MLflow. Você pode usar esse método se quiser registrar manualmente o modelo 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 personalizado com pyfunc. Você pode usar este método para implantar modelos de código Python arbitrários ou implantar código adicional junto 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())
  

• Faça o download em HuggingFace. O senhor pode acessar download um modelo diretamente de Hugging Face e log esse modelo para servir. Para obter exemplos, consulte Notebook examples.

Exemplos de assinatura e entrada

Recomenda-se adicionar uma assinatura e um exemplo de entrada ao MLflow. As assinaturas são necessárias para registrar modelos no Unity Catalog.

A seguir está 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)

A seguir está 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

Mosaic AI Model Serving oferece uma variedade de opções de CPU e GPU para implantar seu modelo. Quando implantado com uma GPU, é essencial certificar-se de que seu código esteja configurado para que as previsões sejam executadas na GPU, usando os métodos fornecidos por 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_SMALL	1xT4	16 GB
GPU_MEDIUM	1xA10G	24 GB
MULTIGPU_MEDIUM	4xA10G	96 GB
GPU_MEDIUM_8	8xA10G	192 GB
GPU_LARGE_8	8xA100-80GB	320 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 endpoint. Este contêiner inclui biblioteca capturada automaticamente ou especificada no modelo MLflow.

O contêiner do modelo oferecido 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 estiverem incluídas no modelo. Ao se deparar com problemas de implantação de modelo, a Databricks recomenda que você teste o modelo localmente.

Dependências de pacote e código

Biblioteca personalizada ou privada pode ser adicionada à sua implantação. Consulte Usar biblioteca Python personalizada com modelo prático.

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

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

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

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 model_uri do modelo que é 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 na chamada para predict.

• O content_type no formato csv ou json.

• Um output_path opcional para gravar as previsões em um arquivo. Se o senhor omitir esse parâmetro, as previsões serão impressas em stdout.

• Um gerenciador de ambiente, env_manager, que é usado para criar o ambiente para servir:

  • O endereço default é virtualenv. Recomendado para validação da porção.

  • local está disponível, mas é potencialmente propenso a erros na validação de serviços. Geralmente usado apenas para depuração rápida.

• Se deve 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:

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ências

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 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 model_uri especificado.

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 customizados usando o modelo instalado.

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

Observação

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 o cálculo do modelo demorar mais de 120 segundos, as solicitações expirarão. Se você acredita que o cálculo do seu modelo levará mais de 120 segundos, entre em contato com a equipe da sua account do Databricks.

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 escalabilidade de endpoint

Observação

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 serviço é escalonado automaticamente com base no tráfego e na capacidade das unidades de simultaneidade de provisionamento.

• simultaneidade de provisionamento: O número máximo de solicitações paralelas que o sistema pode manipular. Estime a simultaneidade necessária usando a fórmula: simultaneidade de provisionamento = consultas por segundo (QPS) * tempo(s) de execução do modelo.

• Comportamento de escalabilidade: 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: o endpoint pode escalar para zero após 30 minutos de inatividade. A primeira solicitação após o dimensionamento para zero experimenta um “começo frio”, levando a uma latência mais alta. Para aplicações sensíveis à latência, considere estratégias para gerenciar esse recurso de forma eficaz.

Limitações de carga de trabalho da GPU

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

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

• Quando implementados 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 a duração de 60 minutos. Caso isso ocorra, iniciar uma nova tentativa do processo deverá implantar o modelo com sucesso.

• o dimensionamento automático para veiculação de GPU leva mais tempo do que para veiculação de CPU.

• A capacidade da GPU não é garantida quando a escala é zero. O ponto de extremidade da GPU pode esperar uma latência extra alta para a primeira solicitação após o escalonamento para zero.

• Esta funcionalidade não está disponível em ap-southeast-1.

Atualização de licenciamento Anaconda

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

Importante

atualizou os termos de serviço do canal anaconda.org. Com base nos novos termos de serviço, você poderá exigir uma licença comercial se confiar na embalagem e distribuição do Anaconda. Consulte as Perguntas frequentes do Anaconda Commercial Edition para obter mais informações. O uso de qualquer canal Anaconda é regido pelos termos de serviço.

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

Se você registrar um modelo antes do MLflow v1.18 sem excluir o canal defaults do ambiente conda do modelo, esse modelo poderá ter uma dependência do canal defaults que você pode não ter pretendido. Para confirmar manualmente se um modelo tem essa dependência, você pode examinar o valor channel no arquivo conda.yaml que acompanha os modelos registrados. Por exemplo, conda.yaml de um modelo com uma dependência de canal defaults pode ter esta 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 o Databricks não pode determinar se o uso dos repositórios Anaconda para interagir com seus modelos é permitido em seu relacionamento com o Anaconda, o Databricks não está forçando seus clientes a fazer quaisquer alterações. Se o seu uso do repo Anaconda.com por meio do uso de Databricks for permitido sob os termos do Anaconda, você não precisará tomar nenhuma ação.

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

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

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

Recursos adicionais

• Criar um endpoint de modelo de serviço personalizado
• Ponto de extremidade de serviço de consulta para modelos personalizados
• Use bibliotecas Python personalizadas com o serviço de modelo
• Artefatos personalizados do pacote para serviços de modelo
• Implantei código Python com modelo instalado
• Configurar a otimização de rota no ponto de extremidade de serviço
• Configure o acesso aos recursos de endpoints de serviço de modelo
• Adicionar um perfil de instância a um endpoint de serviço de modelo