dependências registradas de modelos

Neste artigo, você aprenderá como logs um modelo e suas dependências como artefatos de modelo, para que estejam disponíveis em seu ambiente para tarefas de produção, como serviço de modelo.

logs as dependências do modelo de pacote Python

O MLflow tem suporte nativo para algumas bibliotecas Python ML, onde o MLflow pode logs dependências de forma confiável para modelos que usam essas bibliotecas. Veja os sabores do modelo integrado.

Por exemplo, MLflow suporta Scikit-Learn no módulo mlflow.sklearn e o comando mlflow.sklearn.logs logs a versão do sklearn. O mesmo se aplica ao registro automático com essas bibliotecas de ML. Consulte o repositório github do MLflow para obter exemplos adicionais.

Observação

Para habilitar o registro de rastreamento para cargas de trabalho de IA generativa, o MLflow oferece suporte ao autologging do OpenAI.

Para bibliotecas de ML que podem ser instaladas com pip install PACKAGE_NAME==VERSION, mas não têm variações de modelo MLflow integradas, você pode logs esses pacotes usando mlflow.pyfunc.logss método. Certifique-se de logs os requisitos com a versão exata da biblioteca, por exemplo, f"nltk=={nltk.__version__}" em vez de apenas nltk.

mlflow.pyfunc.log_model suporta registro para:

Biblioteca pública e personalizada pacote como Python egg ou Python wheel files.
Pacotes públicos em PyPI e pacotes hospedados de forma privada em seu próprio servidor PyPI.

Com mlflow.pyfunc.logs, O MLflow tenta inferir as dependências automaticamente. MLflow infere as dependências usando mlflow.models.infer_pip_requirements, e os logs em um arquivo requirements.txt como um artefato de modelo.

Em versões mais antigas, o MLflow às vezes não identifica automaticamente todos os requisitos do Python, especialmente se a biblioteca não for uma variante de modelo integrada. Nesses casos, o senhor pode especificar dependências adicionais com o parâmetro extra_pip_requirements no comando log_model. Veja um exemplo de uso do parâmetro extra_pip_requirements.

Importante

O senhor também pode sobrescrever todo o conjunto de requisitos com os parâmetros conda_env e pip_requirements, mas isso geralmente não é recomendável, pois substitui as dependências que o MLflow capta automaticamente. Veja um exemplo de como usar o parâmetro `pip_requirements` para substituir os requisitos.

Registro de modelo personalizado

Para cenários em que é necessário um registro de modelo mais personalizado, você pode:

Escreva um modelo Python personalizado. Isso permite criar uma subclasse mlflow.pyfunc.PythonModel para personalizar a inicialização e a previsão. Essa abordagem funciona bem para customização de modelos somente Python.
- Para obter um exemplo simples, consulte o exemplo de modelo add N.
- Para obter um exemplo mais complexo, consulte o exemplo de modelo XGBoost personalizado.
Escreva um sabor personalizado. Neste cenário, você pode personalizar o log mais do que o tipo pyfunc genérico, mas isso requer mais trabalho para implementar.

Código Python personalizado

Você pode ter dependências de código Python que não podem ser instaladas usando o comando %pip install , como um ou mais arquivos .py .

Ao registrar um modelo, o senhor pode informar ao MLflow que o modelo pode encontrar essas dependências em um caminho especificado usando o parâmetro code_path em mlflow.pyfunc.logs. O MLflow armazena todos os arquivos ou diretórios passados usando code_path como artefatos junto com o modelo em um diretório de código. Ao carregar o modelo, o MLflow adiciona esses arquivos ou diretórios ao caminho do Python. Essa rota também funciona com arquivos Python wheel personalizados, que podem ser incluídos no modelo usando code_path, assim como os arquivos .py.

mlflow.pyfunc.log_model( artifact_path=artifact_path,
                         code_path=[filename.py],
                         data_path=data_path,
                         conda_env=conda_env,
                       )

logs dependências de modelo de pacote não-Python

O MLflow não seleciona automaticamente dependências não Python, como pacotes Java, pacotes R e pacotes nativos (como pacotes Linux). Para esses pacotes, você precisa logs dados adicionais.

Lista de dependências: Databricks recomenda registrar um artefato com o modelo especificando essas dependências não Python. Pode ser um arquivo .txt ou .json simples. mlflow.pyfunc.logs permite que você especifique esse artefato adicional usando o argumento artifacts .
Pacotes personalizados: Assim como para as dependências personalizadas do Python acima, você precisa garantir que os pacotes estejam disponíveis em seu ambiente de implantação. Para pacotes em um local central, como o Maven Central ou seu próprio repositório, certifique-se de que o local esteja disponível no momento da pontuação ou da veiculação. Para pacotes privados não hospedados em outro lugar, você pode logs os pacotes junto com o modelo como artefatos.

modelos aprimorados com dependências

Ao atualizar um modelo do MLflow Tracking Server ou Model Registry, você precisa garantir que o ambiente de implantação tenha as dependências corretas instaladas. O caminho mais simples pode depender do seu modo de implantação: lotes/transmissão ou atendimento online, e dos tipos de dependências.

Para todos os modos de implantação, o Databricks recomenda executar a inferência na mesma versão de tempo de execução que você usou durante o treinamento, pois o Databricks Runtime no qual você criou seu modelo já possui várias bibliotecas instaladas. O MLflow no Databricks salva automaticamente essa versão Runtime no arquivo de metadados MLmodel em um campo databricks_runtime, como databricks_runtime: 10.2.x-cpu-ml-scala2.12.

Serviço online: Mosaic AI Model Serving

Databricks oferece Model Serving, onde sua versão MLflow do machine learning é exposta como endpoint de API REST escalável.

Para as dependências do Python no arquivo requirements.txt, o Databricks e o MLflow cuidam de tudo para as dependências públicas do PyPI. Da mesma forma, se o senhor especificou os arquivos .py ou Python wheel ao registrar o modelo usando o argumento code_path, o site MLflow carrega essas dependências automaticamente.

Para esses cenários de veiculação de modelo, consulte o seguinte:

Para as dependências do Python no arquivo requirements.txt, o Databricks e o MLflow cuidam de tudo para as dependências públicas do PyPI. Da mesma forma, se o senhor especificou os arquivos .py ou Python wheel ao registrar o modelo usando o argumento code_path, o site MLflow carrega essas dependências automaticamente.

Serviço online: sistemas de terceiros ou contêineres Docker

Se o seu cenário exigir a exibição de soluções de exibição de terceiros ou sua própria solução baseada em Docker, você poderá exportar seu modelo como um contêiner do Docker.

Databricks recomenda o seguinte para serviço de terceiros que lida automaticamente com as dependências do Python. No entanto, para dependências não Python, o contêiner precisa ser modificado para incluí-las.

Integração do Docker do MLflow para servidores baseados em Docker soluções: Modelos do MLflow build-docker

lotes e transmissão Job

lotes e a pontuação de transmissão devem ser executados como Databricks Jobs. Um Notebook Job geralmente é suficiente, e a maneira mais simples de preparar o código é usar o Databricks Model Registry para gerar um Notebook de pontuação.

O seguinte descreve o processo e as passos a seguir para garantir que as dependências sejam instaladas e aplicadas adequadamente:

comece seus clusters de pontuação com a mesma versão do Databricks Runtime usada durante o treinamento. Leia o campo databricks_runtime do arquivo de metadados MLmodel e comece a clusters com essa versão Runtime .
- Isso pode ser feito manualmente na configuração clusters ou automatizado com lógica customizada. Para automação, o formato da versão do tempo de execução que você lê no arquivo de metadados na API Jobs e na API Clusters.
Em seguida, instale todas as dependências não Python. Para garantir que suas dependências não Python sejam acessíveis ao seu ambiente de implantação, você pode:
- Instale manualmente as dependências não Python do seu modelo nos clusters Databricks como parte da configuração dos clusters antes de executar a inferência.
- Alternativamente, você pode escrever uma lógica customizada em sua implantação Job de pontuação para automatizar a instalação das dependências em seus clusters. Supondo que você salvou suas dependências não-Python como artefatos, conforme descrito em logs non-Python package model dependencies, esta automação pode instalar a biblioteca usando a biblioteca API. Ou você pode escrever um código específico para gerar um script de inicialização com escopoclusters para instalar as dependências.
Seu Job de pontuação instala as dependências do Python no ambiente de execução Job . No Databricks, o registro de modelo permite gerar um Notebook para inferência que faz isso para você.
- Quando você usa o Databricks Model Registry para gerar um Notebook de pontuação, o Notebook contém código para instalar as dependências do Python no arquivo requirements.txt do modelo. Para seu Notebook Job para lotes ou pontuação de transmissão, este código inicializa seu ambiente Notebook , para que as dependências do modelo estejam instaladas e prontas para o seu modelo.
O MLflow lida com qualquer código Python personalizado incluído no parâmetro code_path em log_model. Esse código é adicionado ao caminho do Python quando o método predict() do modelo é chamado. Você também pode fazer isso manualmente:
- Chamando mlflow.pyfunc.spark_udf com o argumento env_manager=['virtualenv'/'conda'] .
- Extraindo os requisitos usando mlflow.pyfunc.get_model_dependencies e instalá-los usando %pip install.
Observação

Se o senhor especificou arquivos .py ou Python wheel ao registrar o modelo usando o argumento code_path, o site MLflow carrega essas dependências automaticamente.