Nvidia ha vuelto a poner el foco en la infraestructura para IA con el anuncio de su nueva arquitectura Vera Rubin, presentada por sorpresa durante CES en Las Vegas y prevista para llegar a clientes a lo largo de este año, según ha contado IEEE Spectrum. La compañía acompaña el anuncio con dos cifras ambiciosas: una reducción de hasta diez veces en el coste de inferencia y la posibilidad de entrenar ciertos modelos con cuatro veces menos GPU que en la generación Blackwell. Conviene leer esas promesas con lupa: no hablan solo de una tarjeta más rápida, sino de un sistema diseñado para que muchas piezas trabajen como si fueran un único cerebro.
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 pase 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 Rubin, que Nvidia sitúa en torno a 50 petaFLOPS en cómputo de 4 bits para cargas típicas de transformers en inferencias, frente 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 Vera, la 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 término que usan es co-diseño extremo, y 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 distribuidas, primero 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 coste.
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.
Scale-up: NVLink6 y el auge del in-network compute
Dentro de un rack, Nvidia llama scale-up a la red que conecta GPU con GPU. Aquí aparece NVLink6, la 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 in-network compute, persigue dos beneficios.
El primero es evitar repetir trabajo en cada GPU. Un ejemplo clásico en entrenamiento es el all-reduce: 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 todas las 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 operaciones mientras los datos están en tránsito, para que al llegar al destino ya vengan “medio preparados”.
Nvidia no inventa el in-network compute 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.
Scale-out: ConnectX-9, BlueField-4 y Spectrum-6 para que varios racks actúen como uno
Si el scale-up vive dentro del rack, el scale-out conecta racks entre sí dentro del centro de datos. En Rubin entran en juego tres piezas: ConnectX-9 (tarjeta de red), BlueField-4 (DPU) y el switch Ethernet Spectrum-6 con ópticas co-empaquetadas para enlaces entre racks.
La BlueField-4 se plantea como una forma de descargar tareas que, de otro modo, comerían ciclos valiosos de CPU y GPU: funciones de red, almacenamiento y seguridad. Es el equivalente a tener un “conserje” especializado que gestiona llaves, paquetes y accesos, 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 ConnectX-9, formando un bloque pensado para sostener el tráfico y la gestión del sistema sin frenar el cálculo.
Por su parte, Spectrum-6 dobla el ancho de banda frente a la generación anterior y pone el acento en reducir el jitter, esa 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 scale-across: 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 o a que otros nodos 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 Rubin, coordinació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.