5 Ejecución distribuida de modelos IA

• Data Parallelism: consiste en replicar todo el modelo en múltiples nodos (o GPUs), repartir los datos entre ellos, hacer forward+backward y al final sincronizar los gradientes. Es sencillo de implementar, tiene buen escalado si la comunicación entre nodos no se convierte en cuello de botella.
  Un estudio reciente que compara frameworks como Horovod, PyTorch-DDP y DeepSpeed muestra que para redes convolucionales (ResNet50, ResNet101, ResNet152) entrenadas sobre ImageNet, se puede obtener una eficiencia de paralelización (“parallel efficiency”) de más del 0.85 usando hasta 256 GPUs, y alrededor de 0.75-0.80 con 1024 GPUs, dependiendo del tamaño del modelo y del loader de datos. 

• Model Parallelism / Mixture of Experts (MoE): cuando el modelo es demasiado grande para caber en una GPU, o cuando ciertas partes pueden paralelizarse de manera especializada. Por ejemplo, el trabajo DeepSpeed-MoE muestra que se puede entrenar modelos MoE mucho más grandes con mejoras en costo de inferencia y de entrenamiento comparado a modelos densos de equivalente calidad: mejoras de hasta 4.5× más rápidos y 9× más económicos en inferencia para ciertos modelos grandes. 
  Otro artículo, Hybrid Tensor-Expert-Data Parallelism in MoE Training, presenta un algoritmo híbrido (combinando paralelismo de datos, de tensores y de expertos) para entrenar modelos MoE gigantes, con optimizaciones de comunicación que reducen el movimiento de datos innecesario.

Federated Learning (FL): permite entrenar modelos de forma distribuida en múltiples dispositivos finales (edge, IoT, móviles), evitando la centralización de los datos. Este enfoque presenta ventajas claras en términos de privacidad y cumplimiento normativo, pero no es universalmente eficiente ni recomendable en todos los escenarios. Su idoneidad depende de múltiples factores técnicos, operativos y energéticos.

Cuándo Federated Learning sí es recomendable

FL resulta adecuado principalmente cuando se cumplen una o varias de las siguientes condiciones:

1. Datos altamente sensibles o sujetos a restricciones regulatorias

FL es especialmente útil cuando:

• Los datos no pueden abandonar el dispositivo o dominio local (por ejemplo, datos sanitarios, financieros, industriales).
• Existen restricciones legales o contractuales que limitan la transferencia de datos (GDPR, soberanía del dato).

En estos casos, el coste energético adicional del entrenamiento distribuido puede estar justificado por los beneficios en privacidad y cumplimiento.

2. Gran volumen de datos distribuidos y alto coste de transferencia

FL es eficiente cuando:

• El volumen de datos crudos es elevado.
• El envío de datos al servidor central tendría un coste energético y de red superior al envío periódico de parámetros o gradientes del modelo.

Este escenario es típico en dispositivos móviles o sensores con generación continua de datos.

3. Modelos relativamente ligeros o con actualizaciones parciales

FL es más viable cuando:

• Los modelos son compactos (pocos parámetros).
• Se utilizan técnicas como actualización de capas parciales, compresión de gradientes o aprendizaje incremental.

Esto reduce el coste computacional y el consumo energético en los nodos participantes.

4. Entrenamiento no crítico en tiempo real

FL funciona mejor cuando:

• No se requiere convergencia rápida.
• Se tolera latencia en la sincronización de modelos.
• El entrenamiento se realiza en ventanas temporales amplias (por ejemplo, nocturnas).

Esto permite programar ejecuciones en periodos de menor carga energética o mayor disponibilidad de energía renovable.

Cuándo Federated Learning no es recomendable

Existen escenarios donde FL puede resultar claramente ineficiente o contraproducente:

1. Alta heterogeneidad de dispositivos

FL se vuelve problemático cuando:

• Los dispositivos participantes tienen capacidades muy dispares (CPU, memoria, batería).
• Algunos nodos se convierten en stragglers, ralentizando el proceso global.

Esto incrementa el tiempo de entrenamiento, el número de rondas necesarias y el consumo energético total.

2. Modelos grandes o muy profundos

FL no es eficiente cuando:

• El modelo tiene millones o miles de millones de parámetros.
• El coste de transmitir gradientes o pesos supera al coste de mover los datos.

En estos casos, la comunicación se convierte en el principal cuello de botella energético.

3.  Redes de comunicación inestables o costosas

FL es poco recomendable si:

• La conectividad es intermitente.
• El ancho de banda es limitado.
• El coste energético de la comunicación es alto (por ejemplo, redes móviles de baja eficiencia).

La sobrecarga de comunicación puede anular cualquier ventaja de evitar la centralización de datos.

4. Necesidad de control estricto o trazabilidad completa

FL complica:

• La auditoría completa del proceso de entrenamiento.
• La reproducibilidad exacta de resultados.
• El control fino de la calidad de los datos.

En entornos donde la trazabilidad y la reproducibilidad son críticas (por ejemplo, validaciones regulatorias estrictas), FL puede introducir complejidad excesiva.

• DeepSpeed, desde su módulo MoE, ha demostrado no sólo escalabilidad sino también reducción del coste de inferencia y de entrenamiento comparado con modelos densos equivalentes, gracias a su uso de experto-capacidades, sparsidad y optimización de memoria.
• Frameworks comparativos: como se menciona en Large scale performance analysis of distributed deep learning frameworks … se ha comparado Horovod, DeepSpeed y PyTorch-DDP en entrenamiento de redes grandes, midiendo throughput, eficiencia de escalado, rendimiento en validación vs tamaño de batch, etc.
• Algunas implementaciones de federated learning integran compresión de comunicación, selección adaptativa de clientes, offloading, etc., para mejorar la eficiencia energética Ejemplo: AutoFL optimiza tiempo de convergencia y eficiencia energética considerando heterogeneidad del sistema.

Antes de escalar la ejecución de modelos de IA en entornos distribuidos es fundamental realizar benchmarking y perfilado sistemático del sistema, con el objetivo de identificar cuellos de botella y evaluar la eficiencia real del paralelismo introducido.

La literatura sobre sistemas paralelos destaca que un escalado eficiente no depende únicamente del número de nodos o aceleradores disponibles, sino de una correcta caracterización previa del comportamiento computacional y de comunicación del algoritmo y su entorno de ejecución. En particular, se recomienda medir:

• Uso de CPU, GPU y memoria en cada nodo.
• Latencia de ejecución y tiempos de sincronización.
• Ancho de banda efectivo y volumen de datos intercambiados entre nodos.
• Impacto de la comunicación frente al cómputo en el rendimiento global.

Tal como se describe en estudios clásicos sobre planificación de tareas en sistemas paralelos, la ausencia de este análisis previo puede provocar escalados ineficientes, donde el incremento de recursos no se traduce en mejoras proporcionales de rendimiento, e incluso incrementa el consumo energético total debido a sobrecostes de sincronización y comunicación.

Por tanto, las buenas prácticas recomiendan:

• Analizar el patrón de paralelismo del modelo (data parallelism, model parallelism, híbrido).
• Identificar fases dominadas por cómputo frente a fases dominadas por comunicación.
• Ajustar la granularidad de las tareas y la estrategia de planificación antes de aumentar el número de nodos.

Este enfoque permite tomar decisiones informadas sobre el escalado, maximizando el rendimiento y evitando configuraciones que resulten energéticamente ineficientes.