La idea de fondo es sencilla de entender si pensamos en una cocina con varias estaciones. Tener un horno más potente ayuda, sí, pero si los platos se atascan en el paso o en los pasillos, el restaurante sigue yendo lento. Nvidia está diciendo que el cuello de botella, cada vez más, no es solo “cocinar” (calcular en GPU), sino mover ingredientes (datos) a tiempo y sin colas.
Del protagonismo de la GPU a un elenco de seis chips
En el centro de la plataforma aparece la GPU Rubinque Nvidia sitúa en torno a 50 petaFLOPS en cómputo de 4 bits para cargas típicas de transformadores en inferenciasfrente a unos 10 petaFLOPS en Blackwell para esa métrica, siempre según IEEE Spectrum. Es una mejora contundente en el papel y, en escenarios donde el 4-bit encaja bien, puede marcar la diferencia.
Lo interesante es que Nvidia insiste en no mirar solo la GPU. La propuesta Rubin se apoya en seis chips: la CPU Verala GPU Rubin y cuatro chips dedicados a redes. Esta elección revela una prioridad: si el trabajo de IA se reparte entre muchas GPU, el rendimiento real depende tanto de la autopista como del motor. Gilad Shainer, responsable de networking en Nvidia, lo resume con una frase que suena a mantra de ingeniería de sistemas: el mismo hardware conectado de otra forma puede rendir de manera muy distinta. El termino que usan es co-diseño extremoy sugiere que el “producto” es la suma coordinada de piezas, no una sola.
Inferencia distribuida: el cambio silencioso que fuerza a repensar el cableado
Hace no tanto, muchas inferencias se resolvían en una única GPU dentro de un servidor. Ese patrón se está moviendo hacia la inferencias distribuidasprimero dentro de un rack y, cada vez más, entre racks completos. El motivo es práctico: los modelos crecen, las ventanas de contexto se ensanchan, se sirven más peticiones en paralelo y aparecen arquitecturas donde un solo acelerador no basta, o no sale rentable por latencia y costo.
Cuando una tarea se reparte entre decenas o centenares de GPU, el gran objetivo es que “se sientan” como una sola máquina. En esa película, la interconexión deja de ser un accesorio y pasa a ser parte del cómputo. Si los datos llegan tarde, las GPU se quedan esperando; y una GPU esperando es como un taxi caro con el motor encendido en un semáforo eterno.
Ampliación: NVLink6 y el auge del computación en red
Dentro de un rack, Nvidia llama ampliar a la red que conecta GPU con GPU. aquí aparece NVLink6la nueva generación del switch, con el doble de ancho de banda frente a NVLink5: 3.600 GB/s en conexiones GPU-a-GPU, comparado con 1.800 GB/s en la generación previa, según la información recogida por IEEE Spectrum.
Ese salto de ancho de banda no viene solo. Nvidia también incrementa el número de SerDes (los bloques que convierten señales para enviar datos por menos hilos) y, lo más relevante, amplía el abanico de operaciones que pueden ejecutarse dentro de la propia red. Este enfoque, conocido como computación en redpersigue dos beneficios.
El primero es evitar repetir trabajo en cada GPU. Un ejemplo clásico en entrenamiento es el todo reducido: cada GPU calcula gradientes con su lote de datos y luego hay que promediar esos gradientes para mantener el entrenamiento coherente. Si cada GPU tuviera que enviar su resultado a todos los demás y repetir el promedio, el sistema perdería tiempo y energía en una tarea “administrativa”. Si la red hace parte de ese trabajo una sola vez, el conjunto respira.
El segundo beneficio es aún más intuitivo con una metáfora cotidiana que se ha usado desde Nvidia: imagina que una pizzería quiere reducir el tiempo de entrega. Contratar más cocineros aumenta cuántas pizzas salen por hora, pero no acelera la pizza concreta que va a tu casa. La forma radical de recortar minutos es “hornear mientras viajas”: mover parte del proceso al trayecto. En computación, eso se traduce en realizar mientras los datos están en tránsito, para que al llegar al destino ya vengan “medio preparados”.
Nvidia no inventó el computación en red ahora; se emplea desde hace años (la cifra que circula es desde alrededor de 2016). La novedad en Rubin, según Shainer vía IEEE Spectrum, es ampliar el tipo de cálculos soportados para adaptarse mejor a diferentes cargas y formatos numéricos, algo clave cuando conviven inferencia, entrenamiento, afinado y tareas mixtas.
Escalamiento horizontal: ConnectX-9, BlueField-4 y Spectrum-6 para que varios racks actúen como uno
Si el ampliar vive dentro del rack, el escalamiento horizontal conecta racks entre sí dentro del centro de datos. En Rubin entra en juego de tres piezas: ConectarX-9 (tarjeta de red), campo azul-4 (DPU) y el conmutador Ethernet Espectro-6 estafa co-empaquetadas para enlaces entre bastidores.
La campo azul-4 se plantea como una forma de descargar tareas que, de otro modo, comerían ciclos valiosos de CPU y GPU: funciones de rojo, almacenamiento y seguridad. Es el equivalente a tener un “conserje” especializado que gestiona llaves, paquetes y accesorios, para que los “cirujanos” (GPU/CPU) se concentren en lo suyo. En el diseño descrito por IEEE Spectrum, la DPU se acompaña de dos CPU Vera y una ConectarX-9formando un bloque pensado para sostener el tráfico y la gestión del sistema sin frenar el cálculo.
Por su parte, Espectro-6 dobla el ancho de banda frente a la generación anterior y pone el acento en reducir el estar nerviosoesa variación en los tiempos de llegada de paquetes. Aquí la explicación económica es directa: si un trabajo distribuido requiere que todos los nodos terminen una fase antes de pasar a la siguiente, el nodo que recibe tarde marca el ritmo. Las demás máquinas, aunque sean carísimas, quedan ociosas esperando al rezagado. En palabras atribuidas a Shainer por IEEE Spectrum, el jitter se traduce en dinero perdido, porque paga por capacidad que no está produciendo.
Scale-across: el siguiente paso será unir centros de datos completos
Curiosamente, entre los nuevos chips de Rubin no aparece uno “dedicado” a unir centros de datos entre sí. Nvidia sí verbaliza el concepto, al que se refiere como escala transversal: conectar múltiples centros de datos para sobrepasar límites de capacidad dentro de una sola instalación. El motivo vuelve a ser la tendencia de tamaño: hay cargas de trabajo donde 100.000 GPU empiezan a quedarse cortas, según el argumento que recoge IEEE Spectrum.
Esto no significa que mañana todas las empresas vayan a cablear centros de datos a escala continental, pero sí sugiere hacia dónde se mueve la conversación en IA avanzada: no se trata solo de comprar aceleradores, sino de construir sistemas donde la distancia, la sincronización y el transporte de datos sean parte del diseño desde el primer plano.
Qué debería mirar una empresa: rendimiento real, eficiencia y “tiempo de espera”
Para quien evalúa infraestructura, Rubin plantea una pregunta más útil que “¿cuántos FLOPS tiene?”: ¿cuánto tiempo pasan mis GPU esperando a que llegue información oa que otros nudos terminen? En modelos grandes, ese tiempo muerto puede convertirse en el coste invisible que arruina cualquier promesa de eficiencia.
Si la arquitectura cumple lo que insinúa, la mejora vendría por una mezcla de potencia en GPU Rubincoordinación con CPU Vera y una red capaz de mover y procesar datos con menos fricción. No es glamuroso como una cifra de teraflops, pero en producción es lo que separa un sistema “que funciona” de un sistema que escala sin disparar la factura.
