Dependencias del modelo de registro

En este artículo, obtendrá información sobre cómo registrar un modelo y sus dependencias como artefactos de modelo, de modo que estén disponibles en su entorno para tareas de producción como el servicio de modelos.

Registro de las dependencias del modelo de paquete de Python

MLflow tiene soporte nativo para algunas bibliotecas Python ML, donde MLflow puede registrar de forma fiable las dependencias de los modelos que utilizan estas bibliotecas. Consulte tipos de modelos incorporados.

Por ejemplo, MLflow admite scikit-learn en el módulo mlflow.sklearn, y el comando mlflow.sklearn.log_modelregistra la versión de sklearn. Lo mismo se aplica a la autologización con esas bibliotecas ML. Consulte el repositorio github de MLflow para ver ejemplos adicionales.

Nota:

Para habilitar el registro de seguimiento para cargas de trabajo de IA generativas, MLflow admite el registro automático de OpenAI.

Para las bibliotecas ML que se pueden instalar con pip install PACKAGE_NAME==VERSION, pero que no tienen tipos de modelos MLflow incorporados, puede registrar esos paquetes utilizando el método mlflow.pyfunc.log_model. Asegúrese de registrar los requisitos con la versión exacta de la biblioteca, por ejemplo, f"nltk=={nltk.__version__}" en lugar de solo nltk.

mlflow.pyfunc.log_model admite el registro de:

• Bibliotecas públicas y personalizadas empaquetadas como archivos egg o wheel de Python.
• Paquetes públicos en PyPI y paquetes privados en su propio servidor PyPI.

Con mlflow.pyfunc.log_model, MLflow intenta inferir las dependencias automáticamente. MLflow infiere las dependencias utilizando mlflow.models.infer_pip_requirements, y las registra en un archivo requirements.txt como un artefacto del modelo.

En versiones anteriores, MLflow a veces no identifica todos los requisitos de Python automáticamente, especialmente si la biblioteca no es un modelo incorporado. En estos casos, puede especificar dependencias adicionales con el parámetro extra_pip_requirements en el comando log_model. Vea un ejemplo del uso del parámetro extra_pip_requirements.

Importante

También puede sobrescribir todo el conjunto de requisitos con los conda_env y parámetros pip_requirements, pero en general se desaconseja hacerlo porque esto anula las dependencias que MLflow recoge automáticamente. Vea un ejemplo de cómo utilizar el parámetro pip_requirements para sobrescribir requisitos .

Registro de modelos personalizados

Para escenarios en los que es necesario un registro de modelos más personalizado, puede:

• Escribir un modelo Python personalizado. Esto le permite subclasificar mlflow.pyfunc.PythonModel para personalizar la inicialización y la predicción. Este enfoque funciona bien para la personalización de modelos basados únicamente en Python.
  • Para ver un ejemplo sencillo, consulte el ejemplo de agregar modelo N.
  • Para ver un ejemplo más complejo, consulte el ejemplo de modelo XGBoost personalizado.
• Escribir un tipo personalizado. En este escenario, puede personalizar el registro más que el tipo genérico pyfunc, pero hacerlo requiere más trabajo de implementación.

Código Python personalizado

Es posible que tenga dependencias de código Python que no se puedan instalar con el comando %pip install, como uno o varios archivos .py.

Al registrar un modelo, puede decirle a MLflow que el modelo puede encontrar esas dependencias en una ruta especificada utilizando el parámetro code_path en mlflow.pyfunc.log_model. MLflow almacena cualquier archivo o directorio pasado usando code_path como artefactos junto con el modelo en un directorio de código. Al cargar el modelo, MLflow agrega estos archivos o directorios a la ruta de Python. Esta ruta también funciona con archivos wheel de Python personalizados, que pueden incluirse en el modelo mediante code_path, al igual que los archivos .py.

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

Registro de dependencias de modelos de paquetes que no son de Python

MLflow no recoge automáticamente las dependencias que no sean de Python, como paquetes Java, paquetes R y paquetes nativos (como paquetes Linux). Para estos paquetes, es necesario registrar datos adicionales.

• Lista de dependencias: Databricks recomienda registrar un artefacto con el modelo especificando estas dependencias que no son de Python. Esto puede ser un simple .txt o archivo .json. mlflow.pyfunc.log_model permite especificar este artefacto adicional utilizando el argumento artifacts.
• Paquetes personalizados: Al igual que para las dependencias personalizadas de Python anteriores, debe asegurarse de que los paquetes estén disponibles en su entorno de implementación. Para paquetes en una ubicación central como Maven Central o su propio repositorio, asegúrese de que la ubicación está disponible en el momento de puntuar o servir. Para los paquetes privados no alojados en otro lugar, puede registrar los paquetes junto con el modelo como artefactos.

Implementar modelos con dependencias

Al implementar un modelo desde el servidor de seguimiento de MLflow o el registro de modelos, debe asegurarse de que el entorno de implementación tiene instaladas las dependencias adecuadas. La ruta más sencilla puede depender de su modo de implementación: lote/transmisión o servicio en línea, y de los tipos de dependencias.

Para todos los modos de implementación, Databricks recomienda ejecutar la inferencia en la misma versión de tiempo de ejecución que utilizó durante el entrenamiento, ya que el tiempo de ejecución de Databricks en el que creó su modelo tiene varias bibliotecas ya instaladas. MLflow en Databricks guarda automáticamente esa versión de tiempo de ejecución en el MLmodel archivo de metadatos en un campodatabricks_runtime, como databricks_runtime: 10.2.x-cpu-ml-scala2.12.

Servicio en línea: servicio de modelos de Mosaic AI

Databricks ofrece Model Serving, donde sus modelos de aprendizaje automático MLflow se exponen como puntos de conexión REST API escalables.

Para las dependencias de Python en el archivo requirements.txt, Databricks y MLflow se encargan de todo para las dependencias públicas de PyPI. Del mismo modo, si especificó archivos .py o archivos wheel de Python al registrar el modelo utilizando el argumento code_path, MLflow carga esas dependencias para usted automáticamente.

Para estos escenarios de servicio de modelos, consulte lo siguiente:

• Usar bibliotecas personalizadas de Servicio de modelos
• Empaquetar artefactos y archivos personalizados para el servicio de modelos

Para las dependencias de Python en el archivo requirements.txt, Databricks y MLflow se encargan de todo para las dependencias públicas de PyPI. Del mismo modo, si especificó archivos .py o archivos wheel de Python al registrar el modelo utilizando el argumento code_path, MLflow carga esas dependencias para usted automáticamente.

Servicio en línea: sistemas de terceros o contenedores Docker

Si su escenario requiere servir a soluciones de servicio de terceros o a su propia solución basada en Docker, puede exportar su modelo como un contenedor Docker.

Databricks recomienda lo siguiente para el servicio de terceros que maneja automáticamente las dependencias de Python. Sin embargo, para las dependencias que no son de Python, es necesario modificar el contenedor para incluirlas.

• Integración Docker de MLflow para solución de servicio basada en Docker: MLflow modela build-docker

• Integración de MLflow de Azure Machine Learning:

  • Implementar en Azure Container Instance (ACI)
  • Implementar en Azure Kubernetes Service (AKS)

Trabajos por lotes y transmisión

La puntuación por lotes y en transmisión debe ejecutarse como trabajos de Databricks. A menudo basta con un trabajo de cuaderno, y la forma más sencilla de preparar el código es utilizar el Registro de modelos de Databricks para generar un bloc de notas de puntuaciones.

A continuación se describe el proceso y los pasos a seguir para garantizar que las dependencias se instalan y se aplican en consecuencia:

1. Inicie su clúster de puntuación con la misma versión de Databricks Runtime utilizada durante el entrenamiento. Lea el campo databricks_runtime del archivo de metadatos MLmodel e inicie un clúster con esa versión de tiempo de ejecución.

   • Esto puede hacerse manualmente en la configuración del clúster o automatizarse con lógica personalizada. Para la automatización, el formato de versión en tiempo de ejecución que se lee del archivo de metadatos en la API de trabajos y la API de clústeres.

2. A continuación, instale las dependencias que no sean de Python. Para asegurarse de que sus dependencias que no son de Python son accesibles a su entorno de implementación, puede:

   • Instale manualmente las dependencias no Python de tu modelo en el clúster Databricks como parte de la configuración del clúster antes de ejecutar la inferencia.
   • Como alternativa, puede escribir una lógica personalizada en la implementación de su trabajo de puntuación para automatizar la instalación de las dependencias en su clúster. Suponiendo que ha guardado sus dependencias que no son de Python como artefactos como se describe en Registro de dependencias del modelo de paquete que no son de Python, esta automatización puede instalar bibliotecas utilizando la API de bibliotecas. O bien, puede escribir código específico para generar un script de inicialización del clúster para instalar las dependencias.

3. Su trabajo de calificación instala las dependencias de Python en el entorno de ejecución del trabajo. En Databricks, el Registro de modelos le permite generar un bloc de notas para la inferencia que hace esto por usted.

   • Cuando se utiliza el Registro de Modelos de Databricks para generar un bloc de notas de puntuación, el bloc de notas contiene código para instalar las dependencias de Python en el archivo del modelo requirements.txt. Este código inicializa el entorno del bloc de notas para que las dependencias del modelo estén instaladas y listas para su modelo.

4. MLflow maneja cualquier código Python personalizado incluido en el parámetro code_path en log_model. Este código se agrega a la ruta de Python cuando se llama al método predict() del modelo. También puede hacerlo manualmente:

   • Llamando a mlflow.pyfunc.spark_udf con el argumento.con el argumento env_manager=['virtualenv'/'conda'].
   • Extraer los requisitos utilizando mlflow.pyfunc.get_model_dependenciese instalarlos utilizando instalar %pip.

   Nota:

   Si especificó .py archivos o archivos wheel de Python al registrar el modelo usando el argumento code_path, MLflow carga esas dependencias por usted automáticamente.