La carrera por entrenar modelos de lenguaje cada vez más grandes está chocando con un problema 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, levantar 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 que el sistema se convierta en un rompecabezas de compatibilidades.

Ahí es donde entra HetCCL, una nueva biblioteca de comunicación colectiva presentada por un equipo de investigadores con afiliaciones a Seoul National University y Samsung Research. Su propuesta apunta a un cuello de botella concreto: la dificultad de usar, de forma eficiente y transparente, clústeres heterogéneos con GPUs de distintos fabricantes para entrenar modelos de lenguaje y otras cargas masivas de aprendizaje profundo.

El problema real: la comunicación, no el cómputo

En entrenamiento distribuido, gran parte del tiempo no se va en “calcular”, sino en sincronizar. Operaciones como all-reduce, all-gather o reduce-scatter son esenciales para combinar gradientes y mantener coherencia entre nodos. En entornos homogéneos, el sector ya tiene herramientas muy afinadas: NVIDIA empuja NCCL como estándar de facto para sus GPUs, mientras AMD ofrece RCCL en su ecosistema ROCm.

El choque aparece cuando el clúster deja de ser homogéneo. A medida que las organizaciones combinan generaciones, modelos y proveedores para ampliar capacidad, la capa de comunicación se vuelve un muro: los backends están optimizados para “su” hardware, y la interoperabilidad entre vendors no está resuelta de forma limpia en muchos flujos de trabajo habituales. El resultado es conocido por equipos de infraestructura: costes más altos, infrautilización de recursos y, en el peor caso, renunciar a parte del parque instalado porque “no encaja” en el mismo entrenamiento.

Qué propone HetCCL

HetCCL se presenta como una biblioteca de comunicación colectiva pensada para funcionar entre GPUs NVIDIA y AMD en un mismo clúster, apoyándose en RDMA para transferencias directas y rápidas, y sin requerir modificaciones de drivers. En lugar de “reinventar” toda la comunicación, el enfoque integra y aprovecha librerías optimizadas ya existentes (NCCL y RCCL) mediante mecanismos que coordinan operaciones colectivas en un entorno heterogéneo.

El objetivo práctico es ambicioso pero muy concreto: que cargas distribuidas (por ejemplo, sobre PyTorch) puedan utilizar GPUs de distintos vendors sin reescribir el código del entrenamiento ni rediseñar el stack de comunicación desde cero. En otras palabras, convertir la heterogeneidad en una decisión de compra y capacidad —no en un problema de ingeniería interminable.

RDMA como atajo: saltarse al CPU (cuando toca)

La clave técnica está en RDMA (Remote Direct Memory Access), una familia de tecnologías que permite acceder a memoria remota con latencias bajas y menos intervención del sistema operativo. En el mundo GPU, esto se traduce en algo especialmente valioso: que una NIC con capacidades RDMA pueda interactuar con memoria GPU evitando copias intermedias innecesarias y reduciendo la carga del CPU.

Según describen los autores, HetCCL establece comunicación directa punto a punto aprovechando 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 el tipo de redes que ya dominan en IA a escala: InfiniBand y también RoCE (RDMA sobre Ethernet convergente) en determinados despliegues.

Rendimiento: acercarse a los “nativos” sin pagar el precio del bloqueo

En sus evaluaciones, el equipo reporta que HetCCL logra rendimientos comparables a NCCL y RCCL en entornos homogéneos, y que además escala en escenarios heterogéneos. En cifras, describen eficiencias altas frente a ejecuciones base, con valores cercanos al 90% de media y picos que se aproximan al 97% en determinados casos, además de un escalado cercano al lineal al pasar de 8 a 16 GPUs en sus pruebas.

La otra preocupación habitual en estas integraciones es la “calidad”: cuando se cambia la comunicación, ¿se altera el entrenamiento? En este punto, el trabajo afirma que las diferencias numéricas observadas en la pérdida final se mantienen dentro de tolerancias pequeñas (con errores relativos reportados por debajo de 7 × 10⁻³ en sus comparaciones), un detalle relevante para quienes no se pueden permitir sorpresas en convergencia por un cambio de backend.

Por qué esto importa a sysadmins y equipos de plataforma

Para un medio orientado a administración de sistemas y desarrollo, HetCCL es interesante por lo que sugiere a nivel operativo:

• Menos dependencia de un único proveedor: si la comunicación deja de ser un freno, la estrategia de compra puede priorizar disponibilidad, coste total y plazos.
• Reutilización de inventario: GPUs “no idénticas” dejan de ser hardware de segunda clase y pueden entrar en el mismo clúster con un objetivo común.
• Escalado más realista: en la vida real, los clústeres crecen por oleadas y presupuestos, no en compras perfectas y homogéneas.
• Eficiencia en el despliegue: si el código no requiere cambios, la barrera de adopción baja, especialmente en organizaciones con pipelines maduros.

Eso sí, conviene subrayar el reverso: este tipo de enfoque vive o muere por la infraestructura RDMA (red, NICs, compatibilidades, configuración) y por el rigor del aislamiento y observabilidad. En clústeres de IA, la red no es un accesorio: es parte del motor. Y cualquier capa que toque comunicación debe entrar con monitorización, pruebas controladas y expectativas realistas.

El contexto: la “heterogeneidad” ya no es una excepción

La presión por entrenar modelos más grandes, con presupuestos que no crecen al mismo ritmo que las ambiciones, empuja a infraestructuras híbridas por puro pragmatismo. HetCCL se alinea con esa tendencia: asumir que la heterogeneidad va a ser norma y no anomalía, y que el software —no solo el silicio— decidirá cuánta capacidad real se puede exprimir de un centro de datos.

Si el enfoque se consolida más allá del entorno académico, podría abrir una vía para que empresas medianas y laboratorios reduzcan la fricción de construir clústeres potentes sin caer en el bloqueo total de un único stack. Y, sobre todo, puede cambiar una conversación incómoda en muchas organizaciones: “tenemos GPUs, pero no podemos usarlas juntas”.

---

Preguntas frecuentes

¿Qué es una biblioteca de comunicación colectiva (CCL) y por qué afecta tanto al entrenamiento de modelos de lenguaje grandes?
Una CCL acelera operaciones como all-reduce o all-gather, claves para sincronizar gradientes y parámetros entre GPUs. Si esa comunicación es lenta o ineficiente, el clúster “espera” más de lo que calcula, y el coste por iteración se dispara.

¿Se puede entrenar un LLM con GPUs AMD y NVIDIA en el mismo clúster sin tocar el código en PyTorch?
HetCCL se plantea precisamente como una vía para hacerlo sin modificar el código del entrenamiento, sustituyendo la capa de comunicación por un backend capaz de operar en entornos heterogéneos. En cualquier caso, su adopción real dependerá de cómo se integre en cada stack y del entorno RDMA disponible.

¿Qué requisitos de red suelen ser necesarios para que RDMA marque la diferencia en IA?
Normalmente se necesita una red con capacidades RDMA (InfiniBand o RoCE), NICs compatibles y una configuración correcta para minimizar pérdidas, latencia y cuellos de botella. En despliegues de IA, la red y su ajuste (incluyendo tuning y observabilidad) suelen ser tan importantes como la elección de GPU.

¿Qué ventajas aporta la comunicación directa a memoria GPU (tipo GPUDirect RDMA) en cargas distribuidas?
Reduce copias intermedias y la intervención del CPU, lo que disminuye latencia y libera recursos del sistema. En entrenamiento distribuido, esto puede mejorar el rendimiento efectivo del clúster y estabilizar la escalabilidad cuando crece el número de nodos.

vía: quantum zeitgeist y HetCCL: Accelerating LLM Training with Heterogeneous GPUs