RDMA, RoCE, InfiniBand, pérdida de paquetes y almacenamiento en IA

RDMA, RoCE, InfiniBand, la calidad de la red y el rendimiento del almacenamiento determinan el éxito del entrenamiento de IA porque el entrenamiento distribuido es un reto de movimiento de datos tanto como de potencia de cálculo. Las GPU pueden estar perfectamente operativas y disponibles mientras pasan un tiempo considerable esperando a otros nodos o aguardando a que los datos lleguen desde el almacenamiento.

La norma práctica consiste en analizar computación, red y almacenamiento sobre una misma línea temporal. Una curva descendente en el uso de la GPU no demuestra un fallo en la GPU. Puede ser el síntoma visible de pérdidas de paquetes, retrasos en las comunicaciones, latencias de almacenamiento o entregas lentas de datos en cualquier otro punto de la cadena de entrenamiento.

¿Qué es RDMA?

Remote Direct Memory Access, o RDMA, es un modelo de transferencia de datos que permite la comunicación directa de memoria a memoria reduciendo la intervención de la CPU y de la pila de red del kernel. La documentación de NVIDIA Network Operator describe RDMA como una transferencia directa entre memorias que elude la CPU y la pila de red del sistema operativo, con soporte para entornos InfiniBand y RoCE.

Esto resulta determinante porque el entrenamiento distribuido mueve información entre nodos de trabajo de manera constante. Si la CPU tuviera que procesar cada tramo de ese movimiento a través de una pila de red convencional, la sobrecarga de comunicación se volvería inasumible a gran escala. RDMA contribuye a que el canal de comunicación sea mucho más directo.

Ahora bien, no hace que la red sea inmune a la congestión, a las malas configuraciones, a los errores físicos o a los problemas de topología. RDMA es una capacidad de transporte y no ofrece por sí sola ninguna garantía de que el entrenamiento vaya a ser rápido.

¿Qué es InfiniBand?

InfiniBand es una tecnología de red de alto rendimiento, baja latencia y preparada para RDMA, utilizada ampliamente en HPC y en entornos de IA a gran escala. La documentación de referencia de NVIDIA DGX SuperPOD describe InfiniBand como una tecnología de red de alto rendimiento y baja latencia compatible con RDMA para entornos de computación. En un clúster de IA, InfiniBand proporciona el fabric de escalado horizontal que interconecta los nodos que participan en el entrenamiento distribuido.

La red necesita bastante más que cifras llamativas de ancho de banda nominal. El equipo de operaciones debe vigilar puertos, estado de enlaces, errores, congestión, latencia, tasa de transferencia, topología y la relación entre los eventos del fabric y las tareas en ejecución. Una red puede figurar como activa y aun así ralentizar el entrenamiento, por lo que la disponibilidad y el rendimiento deben abordarse como cuestiones independientes.

¿Qué es RoCE?

RDMA over Converged Ethernet, o RoCE, transporta el tráfico RDMA sobre redes Ethernet. Esto permite a las organizaciones desplegar fabrics de IA compatibles con RDMA aprovechando infraestructura Ethernet, siempre que el diseño, los adaptadores, los switches, la configuración y la operativa respalden el comportamiento requerido.

RoCE e InfiniBand no deben reducirse a una simple decisión de compra de Ethernet frente a no Ethernet. Las preguntas operativas que conviene formular son estas:

• ¿Puede el fabric suministrar el ancho de banda que exige la carga de trabajo?
• ¿Es capaz de controlar la congestión?
• ¿Puede evitar la pérdida de paquetes o recuperarse de ella según las expectativas del despliegue?
• ¿Tienen los operadores visibilidad sobre la telemetría relevante de NICs y switches?
• ¿Puede la topología respaldar las decisiones de ubicación del planificador?
• ¿Puede el equipo diagnosticar el fabric durante una caída de rendimiento del entrenamiento?

Las respuestas a estas preguntas importan mucho más que las siglas empleadas.

¿Qué papel cumple NCCL en el entrenamiento distribuido?

La biblioteca NVIDIA Collective Communications Library, o NCCL, proporciona primitivas de comunicación colectiva optimizadas para cargas de trabajo con múltiples GPU y múltiples nodos. NCCL incluye operaciones como all-reduce, all-gather, reduce-scatter, broadcast y patrones de comunicación punto a punto. Estas operaciones colectivas son fundamentales en muchas variantes de aprendizaje profundo distribuido.

Durante el entrenamiento con paralelismo de datos, por ejemplo, los nodos necesitan intercambiar o consolidar gradientes de forma continua, de modo que la ruta de comunicación más lenta frena el paso de entrenamiento global. La GPU puede terminar su cómputo local y quedarse bloqueada esperando a que concluya la operación colectiva.

En la gráfica de la GPU, esa espera se refleja como un menor uso. En la gráfica de red, puede manifestarse como congestión, retransmisiones o desequilibrios entre enlaces. Ambas perspectivas deben analizarse de forma conjunta.

¿Cómo afecta la pérdida de paquetes de red al entrenamiento?

La pérdida de paquetes eleva el tiempo de comunicación y obliga a los nodos distribuidos a esperarse unos a otros durante más tiempo. El efecto exacto depende de la tecnología de red, del protocolo de transporte, de la biblioteca de colectivas, del control de congestión y de la propia carga de trabajo.

A nivel operativo, un problema de red mínimo puede perjudicar a un conjunto mucho mayor de GPUs. Si un nodo participa en una colectiva de ocho nodos y su enlace de red se ralentiza, el resto de nodos esperará en los puntos de sincronización. Esto genera un efecto multiplicador donde una sola ruta defectuosa desperdicia capacidad de cómputo en nodos completamente sanos.

Monitorea los contadores de pérdidas y errores en las capas de NIC y switch donde estén disponibles, junto con indicadores de retransmisión o congestión propios del fabric. Luego vincula los puertos afectados con los nodos físicos y la tarea de entrenamiento. Una alarma de pérdida de paquetes sin contexto de tarea solo indica al equipo de red que algo ha ocurrido. Una alarma de pérdida de paquetes asociada a un trabajo de entrenamiento de 256 GPUs indica al equipo de operaciones por qué es un problema urgente.

¿Cómo afecta la latencia al entrenamiento de IA?

La latencia penaliza el entrenamiento cuando las cargas de trabajo realizan comunicaciones o sincronizaciones frecuentes que no se pueden solapar con computación útil.

Un ancho de banda elevado resulta esencial para transferir grandes volúmenes de datos, mientras que una latencia baja y predecible resulta clave para coordinaciones continuas. El equilibrio depende del patrón de la tarea: operaciones all-reduce grandes demandan sobre todo ancho de banda, mientras que operaciones pequeñas y recurrentes son mucho más sensibles a la latencia.

La latencia de cola también es determinante. Si la mayoría de los nodos se comunica con rapidez pero una ruta se vuelve periódicamente mucho más lenta, los pasos distribuidos esperarán a ese participante rezagado. Por este motivo, el análisis de percentiles y valores atípicos aporta mucho más valor que una simple media aritmética. El mismo principio se aplica a la latencia de almacenamiento, donde los promedios ocultan las pausas puntuales que dejan a las GPU en espera.

¿Cómo afecta el rendimiento del almacenamiento al entrenamiento?

El almacenamiento influye en el entrenamiento a través de la lectura de conjuntos de datos, el acceso a metadatos, la carga inicial de modelos, la escritura de checkpoints y la restauración ante fallos. La capacidad disponible es solo una de las variables relevantes. Conviene monitorizar el rendimiento sostenido (throughput), las IOPS, la latencia, el estado de las colas y la actividad de lectura o escritura a nivel de tarea.

Una carga de trabajo con conjuntos de datos secuenciales grandes dependerá fuertemente del throughput, mientras que una que acceda a millones de archivos pequeños será muy sensible a los metadatos y a las IOPS. La creación de checkpoints genera ráfagas masivas de escritura, y la recuperación produce grandes lecturas.

Si varias tareas guardan checkpoints a la vez, el almacenamiento puede encontrarse sano en términos generales y provocar suficiente contención como para ralentizar el entrenamiento. Por eso conviene vincular el comportamiento del almacenamiento con el del planificador. El sistema puede amortiguar la contención escalonando los checkpoints o conociendo qué cargas comparten el mismo grupo de discos.

¿Puede el almacenamiento causar un bajo uso de la GPU?

Sí. Un almacenamiento lento puede dejar a las GPU esperando la llegada del siguiente lote de datos.

La manera más directa de verificar esta hipótesis es la correlación. Representa el uso de la GPU y la duración del paso de entrenamiento, superpón el rendimiento y la latencia del almacenamiento y añade la carga de datos del lado de la CPU si dispones de esa métrica. Si el uso de la GPU desciende mientras la latencia de almacenamiento aumenta y el lote siguiente tarda más en llegar, el almacenamiento pasa a ser el principal sospechoso. Si las métricas de disco son normales pero el tiempo de red sube, examina el fabric. Si ambas capas están bien y la preparación de datos en la CPU está saturada, revisa la carga de datos del software.

Este método transversal se explica también en por qué el uso de la GPU puede ser bajo. El objetivo es evitar alterar parámetros de la GPU antes de demostrar que el acelerador es realmente la limitación.

¿Por qué computación, red y almacenamiento deben compartir una misma línea temporal?

Una línea temporal común permite a los operadores observar la secuencia de los hechos. Supongamos que una tarea se ralentiza a las 11:42:15. A las 11:42:10, el puerto de un switch comienza a registrar errores. A las 11:42:12, la duración de la comunicación colectiva aumenta. A las 11:42:15, el uso de la GPU cae en picado, y a las 11:42:18, el tiempo del paso de entrenamiento se duplica. Esa secuencia temporal aporta pruebas infinitamente más sólidas que cuatro paneles de control separados.

El mismo principio sirve para el almacenamiento. Un incremento en la latencia de disco seguido por un retraso en el cargador de datos y rematado por tiempo ocioso en la GPU compone una cadena perfectamente rastreable.

La sincronización horaria se convierte así en un requisito de operaciones ineludible. Switches, tarjetas de red NIC, servidores, cabinas de almacenamiento, planificadores y métricas de aplicaciones necesitan marcas de tiempo con precisión suficiente para sustentar el diagnóstico.

¿Qué conviene monitorizar en la red de entrenamiento?

Vigila las señales que explican la disponibilidad, la capacidad y la degradación del servicio. Las áreas clave incluyen el estado y la velocidad de los enlaces, el rendimiento, los errores de paquetes o símbolos cuando se expongan, los indicadores de descarte, las retransmisiones o reintentos, la telemetría de congestión, la latencia, el estado de salud de las NIC, la integridad de la óptica cuando corresponda, la saturación de puertos, la topología y la duración de las comunicaciones colectivas.

Los contadores concretos varían según la tecnología, de modo que no conviene crear una lista fija de métricas asumiendo que servirá igual para InfiniBand y para RoCE. Estandariza el significado operativo manteniendo el detalle específico de cada entorno. Por ejemplo, ambos fabrics necesitan supervisar la salud del enlace, pero los contadores subyacentes son distintos.

¿Cómo debe influir la topología en la planificación de tareas?

La topología debe condicionar la asignación de recursos siempre que el coste de comunicación sea relevante. Ocho GPU en un único servidor no equivalen a ocho GPU dispersas en nodos distantes si la carga de trabajo requiere intercambios intensivos. Del mismo modo, un grupo de nodos dentro del mismo dominio de red rápida ofrece una ubicación mucho más ventajosa que la misma cantidad de nodos comunicados por un enlace secundario.

El planificador debe tratar la topología como una restricción asociada a la solicitud de recursos. Los usuarios no tendrían por qué memorizar identificadores de switches; deberían poder solicitar una clase de recursos de entrenamiento y dejar que la plataforma resuelva los requisitos topológicos.

Esto se aborda con mayor profundidad en agrupación y planificación de recursos GPU en Kubernetes.

¿Cómo distinguir un cuello de botella de red de uno de almacenamiento?

Apóyate en las fases de la carga de trabajo y en métricas correlacionadas. Si la degradación coincide con la sincronización del modelo o con operaciones colectivas y los indicadores de red cambian en ese instante, investiga la red. Si el parón ocurre durante la lectura de datos o la escritura de checkpoints y la latencia de disco varía, investiga el almacenamiento. Si ambos parámetros empeoran a la vez, comprueba si la ruta de almacenamiento comparte switches o cableado con la red de entrenamiento, ya que un fallo de almacenamiento puede tener su origen en la red cuando los volúmenes son remotos.

No te detengas en las fronteras departamentales. El equipo de almacenamiento puede gestionar la cabina y el de red la infraestructura de transporte, pero la tarea de entrenamiento experimenta una única cadena de suministro de datos.

¿Cómo es una operativa eficiente?

Una operativa eficaz permite pasar de una tarea de entrenamiento lenta al dominio causante en poco tiempo y con datos concluyentes. Quien administra el entorno debería poder responder:

• ¿Qué GPU intervienen en la tarea?
• ¿Qué nodos las alojan?
• ¿Qué rutas de red las interconectan?
• ¿Qué sistema de almacenamiento suministra los datos?
• ¿Qué varió exactamente cuando cayó el rendimiento?
• ¿El cuello de botella está en computación, red, almacenamiento o carga de datos?
• ¿Qué ocurrió tras aplicar los ajustes?

Un ejemplo de plataforma que correlaciona estos dominios es Sensaka.

Ante una ralentización en un entrenamiento distribuido, conviene dejar a un lado qué equipo de infraestructura asume la titularidad del problema. La mejor vía consiste en partir de una línea de tiempo sincronizada que abarque la actividad de la GPU, la comunicación colectiva, la telemetría de NIC y switch, el throughput de almacenamiento, su latencia y la duración del paso de entrenamiento. El primer componente cuyo comportamiento se altere antes de la caída es el punto exacto por donde iniciar la investigación.