La carrera por entrenar modelos de lenguaje cada vez más grandes enfrenta un desafío menos visible que el tamaño de los parámetros o la calidad de los datos: la logística del hardware. En la práctica, implementar infraestructura de machine learning a gran escala ya no consiste solo en “comprar más GPUs”, sino en conseguirlas, integrarlas y hacer que trabajen juntas sin convertir el sistema en un rompecabezas de compatibilidades.
Ahí es donde entra HetCCL, una nueva biblioteca de comunicación colectiva presentada por un equipo de investigadores afiliados a la Universidad Nacional de Seúl y Samsung Research. Su propuesta apunta a un cuello de botella concreto: la dificultad de usar, de manera eficiente y transparente, clústeres heterogéneos con GPUs de diferentes fabricantes para entrenar modelos de lenguaje y otras cargas masivas de aprendizaje profundo.
El problema real: la comunicación, no el cómputo
En el entrenamiento distribuido, gran parte del tiempo no se dedica a “calcular”, sino a sincronizar. Operaciones como all-reduce, all-gather o reduce-scatter son esenciales para combinar gradientes y mantener la coherencia entre nodos. En entornos homogéneos, el sector ya cuenta con herramientas muy afinadas: NVIDIA promueve NCCL como estándar de facto para sus GPUs, mientras AMD ofrece RCCL en su ecosistema ROCm.
El problema surge cuando el clúster deja de ser homogéneo. A medida que las organizaciones combinan diferentes generaciones, modelos y proveedores para ampliar capacidad, la capa de comunicación se convierte en un muro: los backends están optimizados para “su” hardware, y la interoperabilidad entre fabricantes no está completamente resuelta en muchos flujos de trabajo habituales. El resultado, conocido por estos equipos, son costes mayores, infrautilización de recursos y, en el peor de los casos, renunciar a parte del hardware instalado porque “no encaja” en el mismo proceso de entrenamiento.
Qué propone HetCCL
HetCCL se presenta como una biblioteca de comunicación colectiva diseñada para funcionar entre GPUs NVIDIA y AMD en un mismo clúster, apoyándose en RDMA para transferencias directas y rápidas, sin requerir modificaciones en los controladores. En lugar de “reinventar” toda la comunicación, su enfoque integra y aprovecha librerías optimizadas ya existentes (NCCL y RCCL) mediante mecanismos que coordinan operaciones colectivas en entornos heterogéneos.
El objetivo práctico es ambicioso pero muy definido: que cargas distribuidas (por ejemplo, en PyTorch) puedan usar GPUs de distintos proveedores sin reescribir el código del entrenamiento ni rediseñar desde cero la pila de comunicación. En otras palabras, transformar la heterogeneidad en una decisión de compra y capacidad —no en un problema de ingeniería sin fin.
RDMA como atajo: saltarse el CPU (cuando procede)
La clave técnica está en RDMA (Remote Direct Memory Access), una tecnología que permite acceder a memoria remota con baja latencia y con menor intervención del sistema operativo. En el ámbito GPU, esto resulta especialmente valioso: que una NIC con capacidades RDMA pueda interactuar con memoria de GPU evitando copias intermedias innecesarias y reduciendo la carga sobre el CPU.
Según los autores, HetCCL establece comunicación directa punto a punto usando RDMA y mecanismos de registro de memoria que permiten a la red “ver” regiones de memoria de GPU mediante APIs específicas (CUDA/HIP) y el stack habitual de redes RDMA (como IB Verbs). En la práctica, esto encaja con los tipos de redes que predominan en IA a escala: InfiniBand y también RoCE (RDMA sobre Ethernet convergente) en ciertos despliegues.
Rendimiento: acercarse a los “nativos” sin pagar el precio del bloqueo
En sus evaluaciones, el equipo informa que HetCCL logra rendimientos comparables a NCCL y RCCL en entornos homogéneos, además de escalar en escenarios heterogéneos. Describen eficiencias altas frente a ejecuciones de referencia, con valores cercanos al 90% de media y picos que alcanzan el 97% en ciertos casos, además de un escalado casi lineal al aumentar de 8 a 16 GPUs en sus pruebas.
Otra preocupación habitual en estas integraciones es la “calidad”: al cambiar la capa de comunicación, ¿se altera el entrenamiento? En este aspecto, el trabajo asegura que las diferencias numéricas en la pérdida final permanecen dentro de pequeñas tolerancias (errores relativos por debajo de 7×10⁻³ en sus comparaciones), un dato importante para quienes no pueden permitirse sorpresas en la convergencia por un cambio en el backend.
Por qué esto importa a sysadmins y equipos de plataforma
Para profesionales de administración de sistemas y desarrollo, HetCCL resulta atractivo por su impacto operativo:
- Menos dependencia de un solo proveedor: si la comunicación deja de ser un freno, la estrategia de compra puede priorizar disponibilidad, costo total y plazos.
- Reutilización de inventario: GPUs “no idénticas” dejan de ser hardware de segunda categoría y pueden integrarse en el mismo clúster con un objetivo común.
- Escalado más realista: en la práctica, los clústeres crecen en oleadas y presupuestos, no en compras perfectas y homogéneas.
- Eficiencia en el despliegue: si el código no requiere modificaciones, la adopción se facilita, especialmente en organizaciones con pipelines ya maduros.
Eso sí, conviene destacar el reverso: estas soluciones dependen en gran medida de la infraestructura RDMA (red, NICs, compatibilidades, configuración) y requieren un riguroso aislamiento y monitorización. En clústeres de IA, la red no es un accesorio, sino una parte esencial del sistema. Cualquier capa de comunicación debe incluir monitorización, pruebas controladas y expectativas realistas.
El contexto: la “heterogeneidad” ya no es una excepción
La presión para entrenar modelos cada vez más grandes con presupuestos que no crecen a la misma velocidad impulsa a las infraestructuras híbridas por pragmatismo. HetCCL se alinea con esa tendencia: aceptar que la heterogeneidad será norma, no excepción, y que el software —no solo el hardware— determinará cuánta capacidad puede explotarse en un centro de datos.
Si este enfoque se consolida más allá del ámbito académico, podría facilitar que empresas medianas y laboratorios reduzcan la fricción para construir clústeres potentes sin caer en el bloqueo total de un stack único. Y, sobre todo, puede cambiar una conversación delicada en muchas organizaciones: “Tenemos GPUs, pero no podemos usarlas juntas”.
Preguntas frecuentes
¿Qué es una biblioteca de comunicación colectiva (CCL) y por qué impacta tanto en el entrenamiento de grandes modelos de lenguaje?
Una CCL acelera operaciones como all-reduce o all-gather, fundamentales para sincronizar gradientes y parámetros entre GPUs. Si esa comunicación es lenta o ineficiente, el rendimiento del clúster se reduce a la espera, disparando costos por iteración.
¿Es posible entrenar un LLM con GPUs AMD y NVIDIA en el mismo clúster sin modificar el código en PyTorch?
HetCCL busca precisamente eso: permitirlo sin cambios en el código de entrenamiento, sustituyendo la capa de comunicación por un backend que funcione en entornos heterogéneos. La adopción real dependerá de su integración en cada stack y del soporte RDMA disponible.
¿Qué requisitos de red son necesarios para que RDMA marque la diferencia en IA?
Se requiere una red con capacidades RDMA (como InfiniBand o RoCE), NICs compatibles y una configuración adecuada para minimizar pérdidas, latencias y cuellos de botella. En despliegues de IA, la red y su ajuste (incluyendo tuning y monitorización) son tan críticos como la elección de GPU.
¿Qué ventajas aporta la comunicación directa a memoria GPU (tipo GPUDirect RDMA) en entrenamientos distribuidos?
Reduce copias intermedias y la intervención del CPU, disminuyendo latencia y liberando recursos del sistema. En entrenamiento distribuido, esto puede mejorar el rendimiento global y la escalabilidad cuando aumenta el número de nodos.
vía: quantum zeitgeist y HetCCL: Accelerating LLM Training with Heterogeneous GPUs