Estás leyendo la publicación: Configuración independiente del proveedor para ejecutar experimentos de ML y DL con compatibilidad con GPU: hacia la IA
Publicado originalmente en Hacia la IA, la empresa líder mundial en noticias y medios de IA y tecnología. Si está creando un producto o servicio relacionado con la IA, lo invitamos a considerar convertirse en patrocinador de la IA. En Hacia la IA, ayudamos a escalar las empresas emergentes de IA y tecnología. Permítanos ayudarlo a dar rienda suelta a su tecnología a las masas.
Configuración independiente del proveedor para ejecutar experimentos de ML y DL con compatibilidad con GPU
Con muchas soluciones emergentes como AWS Sagemaker, Microsoft Azure Machine Learning Studio, Google Cloud AI Platform, etc., puede ser abrumador elegir una solución dada la restricción de costos y el caso de uso.
Hay algunos pros y contras cuando se trata de usar una solución de proveedor de nube:
Ventajas:
– Una plataforma estrechamente integrada para el acceso a datos, IAM, capacitación, pruebas e implementación de cargas de trabajo de ML y DL
– Las soluciones como AWS Sagemaker admiten múltiples configuraciones de kernel listas para usar que se pueden usar para ejecutar el mismo portátil en diferentes configuraciones de entorno
– El soporte en la nube puede ser útil para resolver problemas con la plataforma
– Servicio de creación y administración de entornos con un solo clic, estas plataformas generalmente tienen muy pocos problemas con la administración de infraestructura
Contras:
– El precio de tales soluciones administradas puede ser más alto que el de una máquina virtual de hardware acelerado (GPU).
– Las soluciones y las canalizaciones creadas dependerán principalmente del proveedor en función de los servicios administrados o las herramientas utilizadas. Esto introduce el bloqueo del proveedor, lo que dificulta la evaluación o el cambio a un proveedor diferente para las soluciones en la nube.
LA CONFIGURACIÓN AGNÓSTICA DEL VENDEDOR
Podemos ejecutar múltiples cargas de trabajo utilizando Docker Containers en la misma máquina con volumen montado, lo que puede ayudar en la creación rápida de prototipos y la experimentación. Esta configuración puede evolucionar al sistematizar e integrarse con varias soluciones de código abierto como Kubeflow, Flytelab para orquestación, MLFlow para repositorio de modelos y control de versiones, Horovod o Ray para capacitación distribuida, etc.
Ventajas:
– Las cargas de trabajo más pequeñas pueden compartir la misma VM y sus recursos (incluida la GPU).
– Con el volumen montado, se puede acceder a los mismos archivos en todos los contenedores alojados en la misma VM.
-Separación de preocupaciones para las bibliotecas ML y DL. También podemos usar administradores de entornos como venv o conda, pero generalmente administrar paquetes dentro de estos entornos puede ser complicado. También podemos personalizar la versión de python de cada contenedor sin tener ninguna consecuencia en la VM base u otros contenedores.
– Período de espera único para extraer imágenes base a la máquina virtual: una vez que se descargan todas las dependencias, la generación de otro contenedor lleva menos de segundos en comparación con las instancias de AWS Sagemaker, que tardan aproximadamente 2 minutos en asignar los recursos cada vez.
– El costo de una máquina virtual acelerada por GPU suele ser menor que el de las plataformas administradas, lo que puede generar beneficios significativos a largo plazo.
– Sin bloqueo de proveedor: mueva libremente sus cargas de trabajo al enviar imágenes de la ventana acoplable a registros privados y llevarlas a máquinas virtuales en diferentes proveedores de nube.
Contras:
– Los científicos de datos que no son expertos en infraestructura pueden preferir plataformas administradas en lugar de administrar infraestructura para experimentación e implementaciones.
– La configuración de alertas, el servicio y el monitoreo de la infraestructura requiere un esfuerzo adicional que es imprescindible para cualquier sistema de producción.
Pasos para configurar una configuración independiente del proveedor:
Paso 1 :
De acuerdo con el requisito de carga de trabajo respectivo, aprovisione cualquier máquina virtual basada en Linux con recursos según sea necesario. Para el ejemplo, supondremos que queremos configurar una plataforma de experimentación acelerada por GPU. Necesitaremos una máquina virtual con una GPU aprovisionada, por ejemplo, la serie G4 en AWS o la serie NCaT4_v3 o un motor informático GCP con Nvidia t4 con 16 GB de memoria, 4 vCPU y almacenamiento persistente de 125 GB.
Paso 2 :
Instale y actualice todas las dependencias de desarrollo que necesita el sistema operativo para funcionar correctamente.
Paso 3:
Instalación del kit de herramientas CUDA para acceder a los controladores para usar la GPU de manera eficiente
Omita este paso en caso de que:
– VM no tiene una GPU Nvidia aprovisionada
– Base Image OS es personalizado y ya tiene soporte CUDA
Dirigirse a https://developer.nvidia.com/cuda-downloads y elige las opciones adecuadas
Para usuarios avanzados, siéntase libre de dirigirse a los archivos y cambiar la versión de CUDA e instalarla en caso de dependencias o casos de uso específicos. En caso de que no haya preferencias para la versión CUDA, el proceso anterior debería funcionar bien.
Ejecute el comando Nvidia-smi para verificar la instalación correcta de Cuda
Solución de problemas de instalación de CUDA:
Asegúrese de que CUDA_HOME y LD_LIBRARY_PATH se agreguen a la ruta que invocará el comando nvidia-smi correctamente
Instalación de Nvidia cuDNN (opcional):
CuDNN de NVIDIA es una biblioteca acelerada por GPU de primitivas para redes neuronales profundas. En caso de que necesitemos ejecutar cargas de trabajo basadas en aprendizaje profundo y redes neuronales, se recomienda tener instalado cuDNN en la máquina virtual base.
Dirigirse a https://developer.nvidia.com/rdp/cudnn-download y acepto los términos y condiciones. Descargue la última en caso de que no haya requisitos congelados para las cargas de trabajo.
Nota: Para la instalación de cuDNN siga la documentación: Enlace
asegúrese de hacer coincidir las versiones del paquete deb CUDA y cuDNN descargado del sitio al instalar las dependencias
8.xxx-1+cudaX.Y <- 8.xxx-1 se refiere a la versión de cuDNN descargada y cudaX.Y se refiere a la versión de CUDA instalada previamente. Para confirmar la versión de Cuda, ejecute el comando Nvidia-smi. (La versión anterior es 11.6)
Ejecute el siguiente comando para asegurarse de que cuDNN esté correctamente instalado:
Etapa 4:
Instalación de Docker y Docker-compose –
#Instalación de Docker
rizo https://get.docker.com | sh
&& sudo systemctl –ahora habilite la instalación de docker #Docker-compose
cd /usr/local/bin && sudo rm -rf docker-compose
sudo rizo -L “https://github.com/docker/compose/releases/download/v2.2.3/docker-compose-linux-x86_64“-o /usr/local/bin/docker-compose
sudo chmod +x docker-compose
Podemos usar docker-compose para configurar múltiples dependencias como base de datos simulada para nuestros contenedores de entrenamiento. Esto puede resultar útil al evaluar nuevas soluciones a través de la creación rápida de prototipos con docker-compose.
Instalación de Nvidia-Docker2:
En el caso de tener cargas de trabajo aceleradas por GPU, necesitamos que el sistema cumpla con las siguientes configuraciones:
1. Docker Engine requiere controladores adicionales para ejecutar cargas de trabajo en GPU.
2. Los contenedores de cargas de trabajo aceleradas requieren controladores Cuda instalados en los contenedores para aprovechar el procesamiento de la GPU.
Ejecute lo siguiente para instalar nvidia-docker2 en la instancia de VM.
#agrega la distribución al sistema operativo para instalar controladores para docker
distribución=$(. /etc/os-release;echo $ID$VERSION_ID)
&& rizo -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key agregar –
&& rizo -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list #Actualizar e instalar nvidia-docker2
sudo apt-obtener actualización
sudo apt-get install -y nvidia-docker2 #restart docker engine para cargar la nueva configuración
sudo systemctl reiniciar ventana acoplable
Podemos verificar la instalación mediante el siguiente comando:
sudo docker run -rm -gpus todos nvidia/cuda:11.0-base nvidia-smi
Con esto, hemos completado la configuración básica necesaria para ejecutar y administrar cargas de trabajo de GPU en máquinas virtuales independientes de la plataforma.
Creación de imágenes acoplables personalizadas según los requisitos:
Como se indicó anteriormente, si queremos ejecutar cargas de trabajo aceleradas por GPU, el contenedor debe tener un kit de herramientas y controladores de Cuda para comunicarse con la GPU.
Esto se puede lograr obteniendo una imagen base para la compilación de la ventana acoplable que ya tiene los controladores Cuda preinstalados, que podemos personalizar aún más instalando paquetes para python y OS. Para obtener más información sobre el uso de contenedores para cargas de trabajo de ciencia de datos, consulte el blog: Enlace.
Nota: Para ejecutar cargas de trabajo en contenedores que usan GPU en VM para la aceleración, el comando de ejecución de la ventana acoplable se vería así
# Aquí: todas las gpus especifican que todas las GPU disponibles se usarán para # acelerar la carga de trabajo
sudo docker run — gpus all tensorflow/tensorflow:latest-gpu-jupyter
Entonces, ahora que tenemos la configuración básica, ¿hacia dónde nos dirigimos?
Ahora que puede ejecutar cargas de trabajo aceleradas independientes de la plataforma solo con una VM dentro de los contenedores acoplables, finalmente puede evolucionar hacia sistemas más obstinados basados en requisitos personalizados y casos de uso. Recuerde que estos pueden integrarse nuevamente con ofertas administradas de código abierto o incluso con herramientas específicas de la nube si es necesario.
Por ejemplo (consulte la figura 1), los contenedores pueden acceder a los datos que residen en cualquier base de datos estructurada o no estructurada a través de una VPC privada habilitada para la red de clústeres de VM o Kubernetes. Podríamos tener una sola VM con aceleración de GPU para ejecutar múltiples cargas de trabajo más pequeñas o una poderosa instancia de múltiples GPU que ejecute entrenamiento distribuido en una gran cantidad de datos. Luego, estos pueden integrarse con MLFlow para almacenar y administrar artefactos de ML y sus métricas de capacitación y evaluación. Además, podemos configurar el almacén de artefactos para que sea un depósito s3, un almacenamiento de blobs de Azure o un depósito de GCP según el entorno de nube preferido.
Avanzando más (ver Fig. 2) después de la implementación del modelo, usando soluciones MLOps como whylogs, nannyml, etc., podemos activar la canalización de kubeflow en función de la depreciación de las métricas de inferencia del modelo y las métricas de deriva. La canalización se puede configurar para generar un pod de instancias puntuales (más económico que un pod de instancias bajo demanda) en Kubernetes, que luego se puede usar para repetir el proceso de capacitación con datos nuevos o modificados en el mismo entorno en un clúster de Ray para capacitación distribuida. Después de completar la capacitación, se liberan recursos que pueden ayudar a reducir los costos a largo plazo.
Todos estos sistemas necesitan un esfuerzo de configuración único. También es necesario configurar el monitoreo y las alertas personalizadas para mejorar la transparencia de las canalizaciones.
Suma y sustancia
ML Architects tendrá que evaluar la situación para el escenario típico de “construir vs comprar”. Si planeamos realizar experimentos más pequeños durante menos tiempo a corto plazo, la compra y el uso de los servicios administrados proporcionarían un mejor retorno de la inversión, ya que la creación de una plataforma personalizada debe estar justificada por sus esfuerzos. En el caso de ejecutar experimentos más grandes y más largos a largo plazo donde se requieren soluciones personalizadas; después de un análisis de costos y esfuerzos, la creación de una plataforma podría ser más adecuada para la capacitación, implementación, monitoreo y mantenimiento de modelos ML en producción durante un período prolongado.
La configuración independiente del proveedor para ejecutar experimentos de ML y DL con compatibilidad con GPU se publicó originalmente en Hacia la IA en Medium, donde las personas continúan la conversación destacando y respondiendo a esta historia.
Publicado a través de Hacia la IA
