Compartir a través de

Implementación de modelos personalizados

  • Artículo

En este artículo se describe la compatibilidad con la implementación de un modelo personalizado mediante servicio de modelos de Mosaic AI. También proporciona detalles sobre los tipos de proceso y las opciones de registro de modelos compatibles, cómo empaquetar las dependencias del modelo para servir, y la creación y escalado del punto de conexión.

¿Qué son los modelos personalizados?

Model Serving puede implementar cualquier modelo de Python como API de nivel de producción. Databricks hace referencia a modelos como modelos personalizados. Estos modelos de APRENDIZAJE automático se pueden entrenar mediante bibliotecas de ML estándar, como scikit-learn, XGBoost, PyTorch y Transformadores HuggingFace, y pueden incluir cualquier código de Python.

Para implementar un modelo personalizado,

  1. Registre el modelo o el código en el formato MLflow, usando los tipos de integrados de MLflow nativos o pyfunc.
  2. Una vez registrado el modelo, regístrelo en el Catálogo de Unity (recomendado) o en el registro del área de trabajo.
  3. Desde aquí puede crear un modelo que sirva de punto de conexión para implementar y consultar el modelo.
    1. Consulte Creación de un modelo personalizado que atiende puntos de conexión
    2. Vea Puntos de conexión de servicio de consulta para modelos personalizados.

Para obtener un tutorial completo sobre cómo servir modelos personalizados en Databricks, consulte Tutorial de servicio de modelos.

Databricks también admite el servicio de modelos básicos para aplicaciones de inteligencia artificial generativa, consulte Foundation Model API y Modelos externos para modelos y ofertas de proceso compatibles.

Importante

Si confía en Anaconda, revise los términos de servicio para obtener información adicional.

Modelos del registro de Machine Learning

Hay diferentes métodos para registrar el Machine Learning automático para el servicio de modelos. En la lista siguiente se resumen los métodos y ejemplos admitidos.

  • Registro automático Este método se habilita automáticamente al usar 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)

  • Registro mediante los tipos integrados de MLflow’. Puede usar este método si desea registrar manualmente el modelo para obtener un control más detallado.

    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 con pyfunc. Puede usar este método para implementar modelos arbitrarios de código de Python o implementar código adicional junto con el 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())

  • Descargar desde HuggingFace. Puede descargar un modelo directamente desde Hugging Face y registrarlo para su uso. Para obtener ejemplos, vea Ejemplos de Notebook.

Ejemplos de firma y entrada

Se recomienda agregar un ejemplo de firma y entrada a MLflow. Las firmas son necesarias para registrar modelos en el catálogo de Unity.

A continuación se muestra un ejemplo de la firma:

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 continuación se muestra un ejemplo de Input:


input_example = {"feature1": 0.5, "feature2": 3}
mlflow.sklearn.log_model(model, "model", input_example=input_example)

Compute type (Tipo de proceso)

Nota:

El servicio de modelos de GPU está en versión preliminar pública.

Servicio de modelos de Mosaic AI proporciona una variedad de opciones de CPU y GPU para implementar el modelo. Al implementar con una GPU, es esencial asegurarse de que el código está configurado para que las predicciones se ejecuten en la GPU mediante los métodos proporcionados por el marco. MLflow lo hace automáticamente para los modelos registrados con los tipos de PyTorch o Transformers.

Tipo de carga de trabajo Instancia de GPU memoria
CPU 4 GB por simultaneidad
GPU_SMALL 1xT4 16 GB
GPU_LARGE 1xA100 80GB
GPU_LARGE_2 2xA100 160GB

Contenedor de implementación y dependencias

Durante la implementación, se crea e implementa un contenedor de nivel de producción como punto de conexión. Este contenedor incluye bibliotecas capturadas o especificadas automáticamente en el modelo de MLflow.

El contenedor de servicio de modelos no contiene dependencias preinstaladas, lo que podría provocar errores de dependencia si no todas las dependencias necesarias se incluyen en el modelo. Al encontrarse con problemas de implementación de modelos, Databricks recomienda probar el modelo localmente.

Dependencias de código y paquetes

Las bibliotecas personalizadas o privadas se pueden agregar a la implementación. Consulte Usar bibliotecas personalizadas de Python con el Servicio de modelos.

En el caso de los modelos de tipo nativo de MLflow, las dependencias de paquete necesarias se capturan automáticamente.

En el caso de los modelos de pyfunc personalizados, se pueden agregar dependencias explícitamente.

Puede agregar dependencias de paquete mediante:

  • El pip_requirements parámetro:

    mlflow.sklearn.log_model(model, "sklearn-model", pip_requirements = ["scikit-learn", "numpy"])

  • El 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 adicionales más allá de lo que se captura automáticamente, use extra_pip_requirements.

    mlflow.sklearn.log_model(model, "sklearn-model", extra_pip_requirements = ["sklearn_req"])

Si tiene dependencias de código, se pueden especificar mediante code_path.

  mlflow.sklearn.log_model(model, "sklearn-model", code_path=["path/to/helper_functions.py"],)

Validación de dependencias

Antes de implementar modelos de MLflow personalizados, resulta beneficioso comprobar que los modelos se puedan servir. MLflow proporciona una API que permite la validación del artefacto del modelo que simula el entorno de implementación y permite probar las dependencias modificadas.

Hay dos API de validación previas a la implementación, la API de Python de MLflow y la CLI de MLflow.

Es posible especificar lo siguiente mediante cualquiera de estas API.

  • El model_uri del modelo que se implementa en el servicio de modelos.
  • Uno de los siguientes:
    • El input_data en el formato esperado para la llamada mlflow.pyfunc.PyFuncModel.predict() del modelo.
    • El input_path que define un archivo que contiene datos de entrada que se cargarán y usarán para la llamada a predict.
  • El content_type en formato csv o json.
  • Un output_path opcional para escribir las predicciones en un archivo. Si se omitiera este parámetro, las predicciones se imprimirán en stdout.
  • Un administrador de entornos, env_manager, que se usa para compilar el entorno para servir:
    • El valor predeterminado es virtualenv. Se recomienda para servir la validación.
    • local está disponible, pero es potencialmente propenso a errores a la hora de servir la validación. Por lo general, solo se usa para la depuración rápida.
  • Si se instalará la versión actual de MLflow del entorno con el entorno virtual mediante install_mlflow. Esta configuración tiene como valor predeterminado False.
  • Si se actualizarán y probarán diferentes versiones de las dependencias del paquete para solucionar problemas o depurar. Especifíquelo como una lista de adiciones o invalidaciones de dependencia de cadena mediante el argumento override, pip_requirements_override.

Por ejemplo:

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

Actualizaciones de dependencias

Si hubiera algún problema con las dependencias especificadas con un modelo registrado, actualice los requisitos mediante la CLI de MLflow o mlflow.models.model.update_model_requirements() en la API de Python de MLflow sin tener que registrar otro modelo.

En el ejemplo siguiente, se muestra cómo actualizar la pip_requirements.txt de un modelo registrado en contexto.

Actualice las definiciones existentes con versiones de paquete especificadas o agregando requisitos inexistentes al archivo pip_requirements.txt. Este archivo está dentro del artefacto del modelo de MLflow en la ubicación model_uri especificada.

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 y limitaciones

En las siguientes secciones se describen las expectativas y limitaciones conocidas para atender modelos personalizados mediante Model Serving.

Expectativas de creación y actualización de puntos de conexión

Nota:

La información de esta sección no se aplica a los puntos de conexión que sirven a los modelos de base.

La implementación de una versión de modelo recién registrada implica empaquetar el modelo y su entorno de modelo y aprovisionar el propio punto de conexión del modelo. Este proceso puede durar aproximadamente 10 minutos.

Azure Databricks realiza una actualización sin tiempo de inactividad de los puntos de conexión manteniendo la configuración del punto de conexión existente hasta que el nuevo esté listo. Al hacerlo, se reduce el riesgo de interrupción de los puntos de conexión que están en uso.

Si el cálculo del modelo tarda más de 120 segundos, las solicitudes agotarán el tiempo de espera. Si cree que el cálculo del modelo tardará más de 120 segundos, póngase en contacto con el equipo de cuentas de Azure Databricks.

Databricks realiza actualizaciones ocasionales del sistema de tiempo de inactividad cero y mantenimiento en los puntos de conexión existentes de Model Serving. Durante el mantenimiento, Databricks vuelve a cargar modelos y marca un punto de conexión como Fallido si un modelo no se puede volver a cargar. Asegúrese de que los modelos personalizados son sólidos y pueden volver a cargarse en cualquier momento.

Expectativas de escalado de puntos de conexión

Nota:

La información de esta sección no se aplica a los puntos de conexión que sirven a los modelos de base.

El servicio de puntos de conexión se escala automáticamente en función del tráfico y de la capacidad de las unidades de simultaneidad aprovisionadas.

  • La simultaneidad aprovisionada:: es el número máximo de solicitudes paralelas que el sistema puede controlar. Calcule la simultaneidad necesaria mediante la fórmula: simultaneidad aprovisionada = consultas por segundo (QPS) * tiempo de ejecución del modelo (s).
  • comportamiento de escalado: Los puntos de conexión de escalan verticalmente casi inmediatamente con un mayor tráfico y se reducen verticalmente cada cinco minutos para que coincidan con el tráfico reducido.
  • Escalar a cero: Los puntos de conexión pueden reducirse a cero tras 30 minutos de inactividad. La primera solicitud después de escalar a cero experimenta un “inicio en frío,” lo que conduce a una mayor latencia. En el caso de las aplicaciones sensibles a la latencia, considere las estrategias para administrar esta característica de forma eficaz.

Limitaciones de la carga de trabajo de GPU

Las siguientes son limitaciones para atender puntos de conexión con cargas de trabajo de GPU:

  • La creación de imágenes de contenedor para el servicio en la GPU lleva más tiempo que la creación de imágenes para el servicio en la CPU debido al tamaño del modelo y a los mayores requisitos de instalación para los modelos servidos en la GPU.
  • Al implementar modelos muy grandes, el proceso de implementación puede agotarse si la creación del contenedor y la implementación del modelo duran más de 60 minutos. Si esto ocurriera, al reintentar el proceso, el modelo se desplegaría correctamente.
  • El autoescalado para el servicio de GPU tarda más que para el servicio de CPU.
  • No se garantiza la capacidad de GPU al escalar a cero. Los puntos de conexión de GPU pueden sufrir una latencia adicional alta para la primera solicitud después de escalar a cero.
  • Esta funcionalidad no está disponible en northcentralus.

Actualización de licencias de Anaconda

El siguiente aviso es para los clientes que dependen de Anaconda.

Importante

Anaconda Inc. actualizó sus términos del servicio para los canales de anaconda.org. Según los nuevos términos del servicio, puede necesitar una licencia comercial si depende del empaquetado y la distribución de Anaconda. Consulte las preguntas más frecuentes sobre Anaconda Commercial Edition para obtener más información. El uso de cualquier canal de Anaconda se rige por sus términos del servicio.

Los modelos de MLflow registrados antes de la versión 1.18 (Databricks Runtime 8.3 ML o versiones anteriores) se registraron de forma predeterminada con el canal de Conda defaults (https://repo.anaconda.com/pkgs/) como dependencia. Debido a este cambio de licencia, Databricks ha detenido el uso del canal defaults para los modelos registrados mediante MLflow v1.18 y versiones posteriores. El canal predeterminado registrado es ahora conda-forge, que apunta a la comunidad administrada https://conda-forge.org/.

Si registró un modelo antes de MLflow v1.18 sin excluir el canal defaults del entorno de Conda para el modelo, es posible que ese modelo tenga una dependencia en el defaults canal que no haya previsto. Para confirmar manualmente si un modelo tiene esta dependencia, puede examinar el valor channel en el archivo conda.yaml que se empaqueta con el modelo registrado. Por ejemplo, un modelo conda.yaml con una dependencia de canal defaults puede tener este aspecto:

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

Dado que Databricks no puede determinar si el uso del repositorio de Anaconda para interactuar con los modelos está permitido en su relación con Anaconda, Databricks no obliga a sus clientes a realizar ningún cambio. Si el uso del repositorio de Anaconda.com mediante el uso de Databricks está permitido en los términos de Anaconda, no es necesario realizar ninguna acción.

Si desea cambiar el canal usado en el entorno de un modelo, puede volver a registrar el modelo en el registro de modelos con un nuevo conda.yaml. Para ello, especifique el canal en el parámetro conda_env de log_model().

Para más información sobre la log_model() API, consulte la documentación de MLflow para el tipo de modelo con el que está trabajando, por ejemplo, log_model para scikit-learn.

Para más información sobre los archivos conda.yaml, consulte la documentación de MLflow.

Recursos adicionales