Cómo se hablan las GPUs: RDMA, InfiniBand y RoCE explicados desde la trinchera

De todos los artículos de esta serie, este es el que llevo esperando escribir. No porque sea el más difícil, sino porque es el único donde no estoy explicando algo que estudié: estoy contando un problema que ya viví, quince años antes de que alguien lo llamara inteligencia artificial.

Trabajé en la integración telefónica de la fusión de dos bancos. Mi responsabilidad incluía un número: el MOS, que mide la calidad de las llamadas. Cada mes tenía que reportarlo. Si bajaba, la pregunta venía hacia mí.

El problema es que yo no podía tocar la calidad de servicio que lo habría arreglado. El mismo router tenía dos partes: los diseños de las políticas eran del carrier, y a nosotros solo nos dejaban ver las interfaces. Equipos separados, empresas separadas. Podía medir el problema con precisión, explicarlo con detalle, señalar exactamente dónde estaba — y nada más. Y cuando la falla venía del lado del tercero, ese lado no nos dejaba ver nada. Ciegos justo donde importaba, y aun así dando la cara.

Responsable de un número que no tenía permiso de mover. Si alguna vez has estado ahí, sabes que no es un problema técnico: es un problema de contrato.

Cuento esto porque RoCE es exactamente ese problema, con otro nombre y con muchos más ceros.

Por qué las GPUs necesitan una red distinta

En el primer artículo de esta serie quedó plantada la frase que sostiene todo: en un centro de datos de IA, la red deja de ser plomería y se vuelve parte del procesador. Toca cobrarla.

Cuando un modelo se reparte entre muchas GPUs, esas GPUs se sincronizan constantemente. No se mandan un archivo de vez en cuando: se intercambian resultados intermedios miles de veces por segundo, y ninguna puede avanzar hasta que todas terminaron. Es un trabajo en equipo obligatorio.

Con la red tradicional eso sería imposible, y no por el ancho de banda. El problema es el camino: cada dato tendría que pasar por el sistema operativo, ser copiado varias veces en memoria e interrumpir a la CPU en cada paso. Con miles de intercambios por segundo, el procesador se convertiría en el cuello de botella de un trabajo que ni siquiera es suyo.

RDMA: pasar el ingrediente sin molestar al chef

De ahí viene RDMA, que en español sería “acceso directo a memoria remota”. La idea es simple de contar y difícil de implementar: la tarjeta de red de una máquina escribe directamente en la memoria de otra, sin pasar por el sistema operativo y sin interrumpir a la CPU.

Con la cocina de los artículos anteriores: RDMA es tener un carril directo entre dos cocinas por el que los ingredientes pasan de una mesa a otra sin que ningún chef tenga que dejar lo que está haciendo para recibirlos. El chef ni se entera. Cuando voltea, el ingrediente ya está en su mesa.

Eso es lo que hace viable entrenar con miles de GPUs. Y también explica por qué esta red no se parece a la de tu oficina: no está optimizada para mover muchos datos en promedio, sino para que ningún intercambio se retrase. La media no importa. Importa el peor caso, porque el peor caso detiene a todos los demás.

Los dos caminos, y en qué se diferencian de verdad

En el artículo sobre los servidores dejé abierto que al salir del rack hay dos caminos. Aquí están, y la diferencia real no es la velocidad: es cómo evitan perder paquetes.

InfiniBand: nadie envía sin permiso

InfiniBand usa control de flujo por créditos. En cristiano: el que envía no manda nada hasta que el receptor le avisa que tiene espacio libre en el búfer. Como no se envía sin permiso, no se desborda nada, y si no se desborda nada, no se pierde nada.

Es una red que nació para este problema y no pierde paquetes por diseño. El precio: es una tecnología aparte, con su propio equipamiento, su propio ecosistema y gente que sepa operarla.

RoCE: Ethernet obligado a comportarse

RoCE hace lo mismo sobre Ethernet, que es la red que todo el mundo ya tiene y sabe operar. Suena a la opción obvia, y por eso está ganando terreno. Pero hay una trampa: Ethernet fue diseñado para perder paquetes. Perder un paquete y retransmitirlo es parte de su naturaleza, y para RDMA eso es veneno.

Así que hay que forzarlo a no perder nada, y eso se hace con tres mecanismos que trabajan juntos:

Mecanismos de RoCEv2 y control de flujo por créditos de InfiniBand: IP Infusion, RoCE contra InfiniBand para clústeres de IA y IP Infusion sobre RoCEv2 y Ethernet sin pérdidas. Comportamiento de DCQCN: análisis de WWT.

Y aquí es donde yo ya había estado

Mira la columna de la derecha de esa tabla y dime si no es el mismo problema.

Cuando peleabas la calidad de una llamada hacías esto: clasificabas el tráfico, decidías qué iba en la cola de prioridad, y descubrías que las colas eran pocas — así que había que meter cosas distintas en la misma clase y rezar. Si metías algo pesado junto a la voz, la voz se degradaba. No se caía. Se degradaba, que es peor, porque nadie sabe a quién reclamarle.

En RoCE pasa exactamente eso, y hasta tiene nombre técnico: bloqueo de cabeza de línea. Cuando un flujo congestionado y otros flujos comparten la misma clase de prioridad, el congestionado bloquea a todos los demás, aunque esos no tengan ningún problema. Y como el número de clases de prioridad que el hardware soporta es limitado, no siempre puedes separarlos.

Peor todavía: esas pausas de PFC se propagan hacia atrás. Un punto congestionado en un extremo del clúster puede terminar frenando switches que no tenían nada que ver, hasta contagiar a la red completa. Cualquiera que haya visto una tormenta de tráfico reconoce la escena.

La pregunta que aprendí a la mala

Pero la lección que de verdad me dejó aquel banco no es técnica, y es la que quiero que te lleves si estás evaluando un proyecto de estos.

Yo respondía por el MOS y no podía tocar el QoS. En un fabric de RoCE la estructura es idéntica: el rendimiento del clúster depende de una afinación fina, y hay que decidir de quién es esa afinación. Si el fabric lo diseña y opera un integrador, y tú eres quien responde ante el negocio por el tiempo que tardan los entrenamientos, acabas exactamente donde yo estaba: dueño de un número que no controlas.

No digo que esté mal tercerizarlo. Digo que quién afina y quién responde tienen que ser la misma persona, o estar unidos por un contrato que lo diga. Porque el día que el rendimiento caiga a la mitad, “yo solo veo las interfaces” no le sirve a nadie.

Y hay un corolario incómodo para toda mi industria: ver no es poder arreglar. Los fabricantes venden visibilidad como si visibilidad fuera solución. Yo veía el problema perfectamente. El bloqueo era del otro lado del contrato.

El número que debería estar en toda propuesta

Si te queda una sola cifra de este artículo, que sea esta.

Es el mismo hardware. El mismo cable, el mismo switch, la misma tarjeta. Lo único que cambia es si alguien afinó bien PFC, ECN y DCQCN. Cuando no está afinado, la congestión provoca retransmisiones y el rendimiento se desploma a una fracción.

Cifras de rendimiento con y sin afinación correcta: guía de decisión de redes para GPU de Spheron (2026).

Traducido a lenguaje de negocio: puedes comprar un clúster de decenas de millones y recibir una fracción de lo que pagaste, sin que nada aparezca como averiado. No hay alarma para eso. Hay que ir a buscarlo.

Por eso, cuando alguien me presenta una arquitectura basada en RoCE, mi primera pregunta no es de rendimiento máximo. Es: ¿quién va a afinar esto, y cómo vamos a saber que sigue bien afinado dentro de seis meses?

Cómo elegir sin repetir opiniones ajenas

La respuesta honesta es que depende, pero “depende” no ayuda a nadie. Depende de qué:

Fíjate que ninguna fila habla de velocidad máxima. Con la afinación correcta, un fabric de RoCE bien hecho queda por debajo del umbral que afecta al tiempo de un trabajo de entrenamiento — y por eso hoy la decisión se toma casi siempre por razones operativas y económicas, no por rendimiento bruto.

Qué preguntar antes de firmar

Preguntas frecuentes

Lo que me llevo de esto

Llevo veinte años oyendo que las redes son la parte aburrida, la plomería, lo que nadie mira hasta que falla. Y resulta que la tecnología más cara y más moderna que existe hoy depende de que alguien sepa configurar colas de prioridad.

Hay algo profundamente justo en eso. Toda esa gente que se pasó años peleando por unos milisegundos de retardo para que una llamada no sonara mal tiene, sin saberlo, el músculo exacto que hace falta aquí. No es un tema nuevo. Es un tema viejo con presupuesto nuevo.

La próxima semana subimos un nivel: cómo se conecta todo. Porque saber que dos GPUs se hablan es una cosa, y armar la topología para que se hablen diez mil es otra muy distinta. 🕸️

Que los sistemas estén con ustedes. ✦

Imagen destacada generada con inteligencia artificial.