Infraestructura de entrenamiento de modelos de aprendizaje automático

La conversación sobre la infraestructura del aprendizaje automático se centra inmediatamente en las GPU. NVIDIA A100, H100, instancias de GPU en la nube. Ese enfoque es adecuado para una categoría específica de trabajo: el entrenamiento de grandes redes neuronales, en particular transformadores y grandes modelos de visión, en los que el rendimiento de la multiplicación de matrices determina el tiempo de finalización del trabajo.

No es adecuado para una parte importante del trabajo de ML en el mundo real. La ingeniería de características, el ML clásico, el ajuste de hiperparámetros, el servicio de inferencia y el refuerzo de gradientes no necesitan aceleración por GPU. Necesitan CPU rápidas, mucha RAM y E/S de almacenamiento que no se ralentice durante el trabajo. Ese es precisamente el perfil de un servidor físico dedicado.

La decisión entre GPU y CPU para cargas de trabajo de ML

Cuándo la GPU es la opción adecuada

El entrenamiento de redes neuronales con un gran número de parámetros se beneficia del paralelismo de las GPU, ya que los marcos de aprendizaje profundo modernos descomponen el entrenamiento en operaciones matriciales que las GPU ejecutan miles de veces más rápido que las CPU. El entrenamiento de una red neuronal convolucional en ImageNet, el ajuste fino de BERT en un corpus grande, un modelo de difusión para la generación de imágenes: todas estas son cargas de trabajo de GPU. Ejecutarlas en la CPU es técnicamente posible, pero prácticamente inutilizable para cualquier cosa que supere el tamaño de un conjunto de datos de juguete.

Las instancias de GPU en la nube tienen sentido cuando los trabajos de GPU son poco frecuentes y no se justifica la adquisición de hardware de GPU dedicado. Las instancias A100, con un coste de entre 3 y 10 dólares por hora, funcionan bien para ejecuciones de entrenamiento ocasionales.

Cuando ganan los servidores dedicados con CPU

Varias categorías de cargas de trabajo de ML se ejecutan más rápido en CPU con un elevado número de núcleos que en instancias de GPU en la nube, y son mucho más económicas:

• Potenciamiento de gradientes (XGBoost, LightGBM, CatBoost): estos marcos están muy optimizados para el paralelismo de la CPU. El entrenamiento de XGBoost en 16 núcleos con OpenMP es realmente rápido. La aceleración de la GPU para el potenciamiento de gradientes es beneficiosa para conjuntos de datos muy grandes, pero añade complejidad y costes que rara vez compensan para conjuntos de datos de menos de 10 GB.
• scikit-learn a gran escala: los bosques aleatorios , las máquinas de vector de soporte (SVM) y los métodos de conjunto se paralelizan en todos los núcleos de la CPU. Un EPYC de 16 núcleos gestiona la búsqueda por cuadrícula validada cruzadamente entre cientos de combinaciones de parámetros en el tiempo que una instancia en la nube de un solo núcleo tardaría en completar una fracción de ellas.
• Canales de ingeniería de características: el cálculo de características basado en Pandas , Polars y Spark consume mucha memoria y está limitado por la E/S. 192 GB de RAM significan que toda la matriz de características permanece en la memoria. NVMe significa que la carga de datos desde archivos Parquet no se convierte en un cuello de botella.
• Ajuste de hiperparámetros: la ejecución de 16 pruebas Optuna en paralelo, cada una como una tarea de entrenamiento de un solo subproceso, utiliza los 16 núcleos simultáneamente. Esto es mejor que pagar por una instancia de GPU que permanece inactiva durante la fase de evaluación de cada prueba.
• Servicio de inferencia de ML: la mayoría de los puntos finales de inferencia de producción para ML clásico, modelos tabulares y redes neuronales pequeñas se ejecutan en la CPU. Los requisitos de latencia suelen ser de decenas de milisegundos, lo que la inferencia de la CPU maneja cómodamente.

AMD EPYC 4545P para aprendizaje automático

Ventajas arquitectónicas

El AMD EPYC 4545P es un procesador de 16 núcleos y 32 hilos basado en la arquitectura Zen 4 de AMD. Para las cargas de trabajo de ML, hay tres características arquitectónicas que son importantes:

• Compatibilidad con AVX-512: permite operaciones vectorizadas en coma flotante para bibliotecas numéricas como NumPy e Intel MKL. Los marcos de ML compilados con compatibilidad con AVX-512 se ejecutan entre un 20 % y un 40 % más rápido en CPU compatibles en comparación con sistemas limitados a AVX-256.
• Caché L3 grande: reduce la latencia de acceso a la memoria para los parámetros del modelo y los datos de características a los que se accede con frecuencia durante los bucles de entrenamiento. El entrenamiento con XGBoost se beneficia especialmente de las estructuras de datos residentes en la caché.
• Ancho de banda de memoria DDR5: DDR5 proporciona aproximadamente 1,5 veces el ancho de banda teórico de DDR4. Para operaciones limitadas por el ancho de banda de la memoria, como multiplicaciones de matrices grandes en una CPU, ese ancho de banda se traduce directamente en un cálculo más rápido.

No se trata de diferencias marginales. En el entrenamiento con XGBoost con un conjunto de datos de 5 GB, la combinación de 16 núcleos, AVX-512 y ancho de banda DDR5 en un sistema EPYC produce resultados competitivos con el entrenamiento acelerado por GPU para esta clase de carga de trabajo específica.

Capacidad de memoria para la carga de conjuntos de datos

El cuello de botella práctico más común en el aprendizaje automático basado en CPU es la carga de datos. Una matriz de características con 50 millones de filas y 200 características en formato float32 ocupa aproximadamente 40 GB de RAM. En un sistema con 32 GB, ese conjunto de datos requiere una carga por fragmentos, lo que añade complejidad a cada paso del proceso de entrenamiento.

En un sistema de 192 GB, esa matriz de características de 40 GB se carga una vez y permanece en la memoria a lo largo de los pliegues de validación cruzada, las comparaciones de múltiples algoritmos y el análisis de importancia de las características. Sin fragmentación. Sin recargas entre experimentos. La mejora en la velocidad de iteración de los experimentos es sustancial, especialmente durante las fases exploratorias.

TensorFlow y PyTorch en CPU

Entrenamiento de CPU para redes neuronales más pequeñas

No todo el entrenamiento de redes neuronales requiere una GPU. Las redes poco profundas, las redes neuronales tabulares (TabNet, SAINT) y los modelos de secuencias pequeñas entrenados con conjuntos de datos de tamaño moderado funcionan aceptablemente en la CPU cuando el número de parámetros del modelo se mantiene por debajo de aproximadamente 10-50 millones de parámetros.

PyTorch utiliza OpenMP para el paralelismo de la CPU. Al configurar OMP_NUM_THREADS=16 y torch.set_num_threads(16) en un sistema de 16 núcleos, se garantiza que el entrenamiento de PyTorch utilice todos los núcleos disponibles. Para tamaños de lote que caben en la caché de la CPU (modelos pequeños, capas densas), el rendimiento del entrenamiento es mayor de lo que se suele suponer.

La optimización de CPU de TensorFlow utiliza Intel MKL-DNN (oneDNN), que se beneficia de AVX-512 en hardware compatible. Las compilaciones de TensorFlow con AVX-512 se ejecutan de forma notablemente más rápida en EPYC que en sistemas Xeon más antiguos que no son compatibles con AVX-512.

La carga de datos como verdadero cuello de botella

En los bucles de entrenamiento de la CPU, el cargador de datos suele ser más lento que la pasada hacia adelante del modelo. Los PyTorch DataLoaders con num_workers=8 o superior en un sistema de 16 núcleos pueden precargar lotes con la suficiente rapidez como para evitar que el bucle de entrenamiento se quede sin recursos.

NVMe cambia aún más este cálculo. La lectura de archivos Parquet para el entrenamiento por lotes en un SSD SATA se detiene con frecuencia. En NVMe una lectura secuencial NVMe 5 GB/s, los subprocesos del cargador de datos se mantienen por delante del bucle de entrenamiento incluso con lotes de gran tamaño. Esto es importante para los modelos entrenados con datos de imágenes, texto tokenizado desde el disco o datos tabulares de grandes particiones Parquet.

Ajuste de hiperparámetros Paralelismo

La búsqueda de hiperparámetros es paralela de forma vergonzosa. Cada prueba es independiente. En un sistema de 16 núcleos, puedes ejecutar 16 pruebas simultáneamente sin ninguna sobrecarga de comunicación entre procesos.

Optuna, Ray Tune y GridSearchCV de scikit-learn admiten la ejecución paralela de pruebas a través del multiprocesamiento de Python. Una búsqueda por cuadrícula de 256 combinaciones de parámetros que tarda 8 horas en un solo subproceso se completa en aproximadamente 30 minutos en 16 núcleos. Esa compresión cambia la forma en que los equipos de ML iteran.

Las alternativas en la nube para este caso de uso cobran por núcleo, lo que se acumula rápidamente en búsquedas largas, o requieren poner en marcha clústeres Ray distribuidos con los gastos de gestión asociados. Un servidor dedicado que ejecute los 16 núcleos para una búsqueda de 30 minutos no tiene ningún coste de coordinación de clústeres.

Infraestructura de servicio de inferencia

Latencia y rendimiento para terminales de producción

La mayoría de los puntos finales de inferencia de ML de producción no necesitan una GPU. Los modelos tabulares, los motores de recomendación, los clasificadores de detección de fraudes y los modelos de PLN con menos de 100 millones de parámetros atienden las solicitudes en 1-20 ms en las CPU modernas. La inferencia con GPU añade un coste y una complejidad de infraestructura que no se justifica a menos que se utilicen modelos de lenguaje grandes o generación de imágenes.

Un servidor dedicado que ejecuta FastAPI o TorchServe gestiona entre varios cientos y varios miles de solicitudes de inferencia por segundo para modelos típicos de aprendizaje automático tabular, dependiendo de la complejidad del modelo y la sobrecarga de cálculo de las características. Para los equipos que actualmente pagan por instancias de inferencia de GPU que sirven modelos relativamente pequeños, la migración a la inferencia de CPU en hardware dedicado suele reducir los costes de infraestructura de inferencia entre un 60 % y un 80 %.

Almacenamiento en caché de modelos y memoria

Mantener varias versiones de modelos cargadas en la memoria simultáneamente requiere RAM. Una plataforma de ML que ofrece 10 versiones de modelos diferentes, cada una con un tamaño de entre 2 y 4 GB, necesita entre 20 y 40 GB de memoria solo para el almacenamiento en caché de los modelos, sin contar la sobrecarga de la gestión de solicitudes. Con 192 GB, tienes espacio para un registro completo de modelos en la memoria, además de la capa de aplicación y el sistema operativo, sin conflictos.

Comparación de costes: opciones de infraestructura de ML

Caso práctico	Opción en la nube	Coste de la nube	InMotion Hosting	InMotion Hosting
XGBoost / refuerzo de gradiente	c5.4xlarge (16 vCPU)	~480 $ al mes	Dedicado extremo (16 núcleos)	349,99 $ al mes
Ajuste de hiperparámetros (paralelo)	c5.4xlarge spot	~150 $ al mes + riesgo	Dedicado avanzado	149,99 $ al mes
Servicio de inferencia de CPU	c5.2xlarge x2	~480 $ al mes	Esencial Dedicado	99,99 $ al mes
Ingeniería de características de gran tamaño en memoria	r5.4xlarge (128 GB)	~780 $ al mes	Extreme Dedicated (192 GB)	349,99 $ al mes

Lo que permanece en la GPU en la nube

Los servidores con CPU dedicados no sustituyen a las GPU en la nube para todas las cargas de trabajo. El ajuste fino de modelos lingüísticos de gran tamaño, el entrenamiento de transformadores de visión desde cero y el entrenamiento de difusión estable siguen estando limitados por las GPU. El enfoque práctico para la mayoría de los equipos de aprendizaje automático:

• Ejecuta ingeniería de características, EDA, refuerzo de gradientes e inferencia en una infraestructura de CPU dedicada.
• Utiliza instancias puntuales de GPU en la nube para tareas periódicas de entrenamiento de aprendizaje profundo.
• Utiliza la inferencia de CPU dedicada para todos los modelos, excepto para redes neuronales muy grandes.
• Procesamiento previo de datos en etapas en canalizaciones de almacenamiento dedicado NVMe en lugar de almacenamiento de objetos en la nube.

Este enfoque híbrido aprovecha las ventajas en cuanto a costes y rendimiento de ambas opciones sin imponer una única infraestructura a cargas de trabajo con requisitos diferentes.

Preparación

El servidor dedicado ExtremeInMotion Hosting incluye AMD EPYC 4545P, 192 GB de RAM DDR5 ECC y dos NVMe de 3,84 TB gestionados por el equipo APS InMotion Hosting. La configuración del entorno Python, CUDA (si más adelante añades una GPU externa) y la instalación del marco ML forman parte de la configuración estándar del servidor, en la que InMotion Solutions puede ayudaros con Premier Care.

• Explora los servidores dedicados: inmotionhosting .com/dedicated-servers
• Compara los niveles de precios: inmotionhosting .com/dedicated-servers/dedicated-server-price
• Detalles de Premier Care: inmotionhosting .com/blog/inmotion-premier-care/

Para los equipos que gastan más de 300 dólares al mes en instancias de CPU en la nube para cargas de trabajo de ML, la transición a hardware dedicado se amortiza en el primer ciclo de facturación.