OpenAI SemiAnalysis Lens: Vera Rubin NVL72 supera a GB200, pero el caso de TCO es más acotado
Vera Rubin NVL72 de NVIDIA ha publicado sus primeros resultados medidos en silicio y afirma ofrecer diez veces el rendimiento por megavatio de GB200 NVL72 con el mismo nivel de interactividad. La conexión con OpenAI SemiAnalysis llega a través de Triton, cuyo soporte para Rubin ayuda a exponer la arquitectura al software de IA ampliamente utilizado.
El titular resulta convincente, pero compara Rubin con una base de software de GB200 de principios de 2025. SemiAnalysis encontró una ventaja menor frente a los resultados de Blackwell de julio de 2026, aunque Rubin siguió liderando en todo el rango de interactividad evaluado.
Esa distinción define la verdadera competencia. Rubin no es simplemente una GPU más rápida que sustituye a otra más antigua. Es un sistema a escala de rack diseñado para mantener una inferencia ágil cuando el tamaño de los modelos, el tráfico de memoria y la demanda de tokens crecen al mismo tiempo.
El resultado presiona a los operadores de GB200, a los proveedores de aceleradores competidores y a los desarrolladores que mantienen kernels personalizados. También deja una importante brecha de verificación. La prueba inicial utilizó un rack de muestra de ingeniería, un modelo de razonamiento anterior y una carga de trabajo de un solo turno.
El primer resultado de Rubin cambia la comparación con NVL72
La ventaja inicial de Rubin parece real, pero la cifra de diez veces corresponde a una comparación en el mejor escenario, no a una proporción de rendimiento universal.
CoreWeave publicó el primer benchmark medido en silicio de Vera Rubin NVL72 el 21 de julio de 2026. Sus ingenieros ejecutaron DeepSeek R1 en Rubin y GB200 NVL72 con las mismas optimizaciones principales de inferencia habilitadas.
La prueba midió el rendimiento de tokens de salida por megavatio frente a la interactividad, expresada como tokens por segundo para cada usuario. Esto importa porque un servicio de inferencia debe equilibrar la capacidad total con una velocidad de respuesta aceptable.
Con la misma interactividad, los resultados medidos en silicio mostraron hasta diez veces más rendimiento de tokens de salida por megavatio. La comparación utilizó una base de GB200 NVL72 de 2025.
CoreWeave afirma que ambos sistemas utilizaron precisión NVFP4, decodificación especulativa, paralelismo amplio de expertos y prefill y decode desagregados. TensorRT-LLM y NVIDIA Dynamo proporcionaron el software de serving.
NVFP4 es el formato numérico de cuatro bits de NVIDIA para reducir el almacenamiento y el cómputo del modelo. La decodificación especulativa genera tokens candidatos antes de la verificación final, aumentando la velocidad de salida cuando sus predicciones aciertan.
El serving desagregado separa el prefill y el decode entre distintos grupos de GPU. El prefill procesa el prompt, mientras que el decode genera la respuesta un token a la vez.
Esas optimizaciones importan porque los resultados de benchmark suelen medir tanto la calidad del software como la del silicio. Un kernel, programador o estrategia de paralelización más antiguos pueden dejar sin utilizar una gran parte de la capacidad de una GPU.
SemiAnalysis ajustó sus propios datos de InferenceX para que coincidieran con la contabilidad de CoreWeave. El benchmark original contabilizaba la potencia de las GPU de prefill y decode, mientras informaba solo los tokens de salida.
Frente a los resultados de GB300 NVL72 de julio de 2026, Rubin ofreció casi el doble de rendimiento hasta 100 tokens por segundo por usuario. Su ventaja se amplió a aproximadamente cuatro veces en torno a los 200 tokens por segundo.
A 300 tokens por segundo, la proporción reportada alcanzó 5,4 veces. Sin embargo, SemiAnalysis señaló que GB300 operaba en el límite de su curva de rendimiento viable.
GB200 no pudo alcanzar ese nivel de interactividad en la configuración probada. Rubin continuó hasta los 350 tokens por segundo, donde produjo 70.703 tokens de salida por segundo por megavatio.
Esto no invalida la afirmación de CoreWeave. Rubin temprano claramente mantiene una interactividad más alta que los sistemas Blackwell medidos. Sí cambia lo que los compradores deberían deducir del titular.
Una cifra de diez veces describe una carga de trabajo, un punto operativo, una base de software y un método de contabilidad concretos. No significa que cada despliegue de Rubin sustituya de inmediato a diez racks GB200.
La conclusión más sólida es más acotada y útil. Rubin mantiene la eficiencia a medida que el serving avanza hacia lotes más pequeños y respuestas individuales más rápidas, donde el rendimiento de Blackwell cae abruptamente.
Ese comportamiento afecta directamente a los agentes de programación, los sistemas de búsqueda y las aplicaciones de seguridad. Estos servicios generan muchas llamadas secuenciales al modelo, lo que dificulta ocultar la latencia con lotes grandes.
Por qué el rendimiento por megavatio ahora importa más que los FLOPS máximos
La capacidad eléctrica se ha convertido en un límite práctico, por lo que los tokens útiles por megavatio pueden importar más que el rendimiento aritmético teórico.
El número máximo de FLOPS de un acelerador mide sus operaciones de coma flotante máximas bajo condiciones específicas. No describe con qué eficiencia un rack completo sirve un modelo de razonamiento.
La inferencia mueve pesos, activaciones y datos de caché KV entre las unidades de memoria y cómputo. La caché KV almacena información de atención de tokens anteriores, evitando que el modelo recalcule toda la secuencia.
Los contextos más largos amplían esa caché. Los modelos de mezcla de expertos también envían tokens entre subredes especializadas, generando tráfico de comunicación entre GPU.
Rubin aborda esas limitaciones como un sistema NVL72 completo. El rack combina 72 GPU Rubin, 36 CPU Vera, redes ConnectX-9, procesadores BlueField-4 y switches NVLink 6.
NVIDIA indica 20,7 terabytes de memoria HBM4 en todo el rack. También especifica 260 terabytes por segundo de ancho de banda agregado de switches NVLink 6.
Cada GPU recibe 3,6 terabytes por segundo de ancho de banda all-to-all para scale-up. Las redes scale-up conectan aceleradores dentro de un gran dominio de cómputo, permitiéndoles comportarse como un dispositivo unificado.
Por tanto, Rubin ataca la eficiencia de inferencia en varias capas. Las operaciones tensoriales más rápidas manejan las matemáticas matriciales, HBM4 suministra los pesos y NVLink mueve tokens entre expertos.
Las CPU Vera gestionan el movimiento de datos y las tareas de agentes intensivas en CPU. Estas pueden incluir llamadas a herramientas, compilación de código, orquestación y ejecución en entornos aislados.
Las especificaciones de NVL72 de NVIDIA afirman 3.600 petaflops de rendimiento de inferencia NVFP4 a nivel de rack. La empresa también afirma un coste por token equivalente a una décima parte del de GB200 NVL72.
Estas cifras siguen siendo afirmaciones de la empresa dependientes de la carga de trabajo. Aun así, la arquitectura del rack explica por qué la ventaja de Rubin crece cuando aumenta la interactividad.
Los lotes grandes ayudan a que una GPU se mantenga ocupada porque muchos usuarios comparten cada carga de pesos. El servicio interactivo rápido reduce las oportunidades de agrupar solicitudes, aumentando la presión sobre el ancho de banda de memoria y la planificación.
Los 22 terabytes por segundo de ancho de banda HBM4 por GPU de Rubin le dan más margen en esas condiciones. SemiAnalysis estima 2,8 veces el ancho de banda de memoria global de Blackwell Ultra.
Un mayor ancho de banda no reduce automáticamente la latencia de memoria. Mueve más datos por segundo, pero un acceso individual puede seguir tardando un tiempo similar.
Por ello, la ventaja más amplia de Rubin con alta interactividad refleja varios mecanismos que trabajan en conjunto. Ninguna especificación máxima aislada la explica por completo.
La métrica de potencia también incluye decisiones de infraestructura. Los equipos de refrigeración, las redes, los procesadores host, el almacenamiento y las pérdidas de conversión consumen electricidad más allá del paquete de GPU.
NVIDIA diseñó Rubin para refrigerante líquido que entra a 45 grados Celsius. En instalaciones compatibles, esa temperatura permite refrigeración en seco sin enfriadores tradicionales.
La empresa afirma que su enfoque de circuito cerrado puede reducir el consumo de agua y la sobrecarga de refrigeración. Esas ganancias dependen del diseño de la instalación y no deberían asumirse para todos los centros de datos existentes.
SemiAnalysis utilizó la misma suposición de efectividad de uso de energía en todos los sistemas refrigerados por líquido. Esta elección conservadora evita que el diseño de las instalaciones de Rubin infle la comparación de silicio.
El resultado sigue favoreciendo a Rubin. Más importante aún, muestra por qué la arquitectura de rack se ha vuelto inseparable de la economía de los aceleradores.
Un comprador no puede evaluar Rubin comparando únicamente los FLOPS de las GPU. La unidad relevante es el sistema de serving que ofrece una velocidad de respuesta requerida dentro de un presupuesto de potencia fijo.
El soporte de software de OpenAI SemiAnalysis da a Rubin una línea de partida más temprana
Rubin puede reutilizar importantes kernels de Blackwell, acortando el trabajo de despliegue antes de que los desarrolladores inicien el ajuste específico para la arquitectura.
El ángulo OpenAI SemiAnalysis no es una asociación de hardware con OpenAI. Se refiere a la aparición del soporte para Rubin en OpenAI Triton junto con PyTorch, vLLM, CUDA y otros proyectos públicos.
Triton es un lenguaje y compilador de código abierto para escribir kernels de GPU con sintaxis similar a Python. Un kernel es un programa especializado que ejecuta una operación de cómputo en la GPU.
OpenAI introdujo la programación con Triton para hacer que el desarrollo de kernels de alto rendimiento fuera más accesible que el código CUDA de bajo nivel. Los compiladores de PyTorch y los proyectos de inferencia ahora dependen de kernels generados por Triton para muchas operaciones.
NVIDIA ha lanzado una vista previa para desarrolladores de CUDA 13.4 con soporte para Rubin e instrucciones PTX actualizadas. PTX es el lenguaje de instrucciones intermedio de NVIDIA para describir operaciones de GPU.
La vista previa de CUDA permite a los desarrolladores inspeccionar las nuevas capacidades de Rubin y comenzar a portar software. NVIDIA advierte que esta vista previa es software de prelanzamiento y no es apta para benchmarks de producción.
SemiAnalysis informa que los cambios para Rubin también han llegado a los repositorios de PyTorch, vLLM y OpenAI Triton. Esa exposición pública da a los desarrolladores de frameworks tiempo para adaptarse antes de la disponibilidad generalizada en la nube.
El multiprocesador de streaming de Rubin utiliza el objetivo SM107. Más importante aún, puede ejecutar los principales kernels de la familia SM100 de Blackwell en bibliotecas como CUTLASS, DeepGEMM y FlashMLA.
Blackwell no heredó la misma comodidad de Hopper. Su modelo de programación Tensor Core requirió reescrituras sustanciales de kernels antes de que los desarrolladores pudieran acercarse al potencial del hardware.
Rubin conserva una mayor parte de esa inversión. Los equipos pueden comenzar con kernels funcionales de Blackwell, desplegar antes y optimizar después las operaciones más valiosas.
La compatibilidad no debe confundirse con el rendimiento máximo. SemiAnalysis afirma que el ajuste específico para la arquitectura sigue siendo necesario para alcanzar el límite práctico de velocidad.
Rubin aumenta la memoria compartida de los 228 KiB de Blackwell a un modo opcional de 328 KiB. La memoria Tensor también crece a 256 KiB, dando a los kernels más espacio para acumuladores e información de escalado.
La arquitectura añade actualizaciones integradas de descriptores de Tensor Memory Accelerator. TMA es un mecanismo de hardware que mueve datos multidimensionales sin requerir que las unidades de ejecución normales gestionen cada transferencia.
En una capa de mezcla de expertos, cada experto posee una matriz de pesos independiente. Blackwell puede necesitar reescribir y sincronizar un descriptor cuando cambia el experto activo.
Rubin puede pasar la nueva dirección con la instrucción de transferencia. Un descriptor puede entonces servir a varios expertos sin una reescritura de memoria intermedia.
Eso reduce la sobrecarga de despacho durante la decodificación con lotes pequeños. También ilustra por qué las ganancias reales de inferencia provienen de pequeñas mejoras en el movimiento de datos, no solo de motores matriciales más grandes.
Rubin duplica el rendimiento de Tensor Core FP8 y FP4 frente a Blackwell, según las divulgaciones de arquitectura de NVIDIA. También añade una sincronización más precisa entre bloques de hilos dependientes.
Estas características ayudan a los desarrolladores a crear kernels fusionados más grandes. La fusión combina múltiples operaciones, reduciendo lanzamientos repetidos y movimientos innecesarios a través de la memoria.
La ventaja de software va más allá de estar listo para el lanzamiento. Las herramientas compatibles permiten que más desarrolladores examinen el comportamiento de Rubin, informen defectos y optimicen arquitecturas de modelos comunes.
Sin embargo, el soporte público sigue siendo incipiente. Las restricciones de vista previa de CUDA muestran que el código disponible no equivale a una pila de producción madura.
La integración con PyTorch y vLLM puede establecer funcionalidad mientras deja una optimización sustancial sin terminar. Los operadores deben distinguir entre «se ejecuta en Rubin» y «usa Rubin de forma eficiente».
El patrón histórico respalda esa cautela. La inferencia de GB200 mejoró durante su primer año a medida que maduraban los kernels, los planificadores y las recetas de serving distribuido.
Rubin parte de una posición de compatibilidad más sólida. Su ventaja final seguirá dependiendo de que los mantenedores de los frameworks conviertan las nuevas instrucciones en mejoras fiables a nivel de modelo.
El Tensor Core LUT de 3 bits apunta al cuello de botella de memoria
La función de inferencia más interesante de Rubin comprime los pesos dentro del Tensor Core, reduciendo el tráfico de memoria sin una fase independiente de descuantización.
Rubin añade un modo de operando B con tabla de consulta a su instrucción de multiplicación-acumulación de matrices. SemiAnalysis lo describe como el primer formato Tensor Core de NVIDIA que utiliza un libro de códigos interno no uniforme.
En este modo, cada peso almacenado se convierte en un índice de tres bits. Ese índice selecciona uno de ocho valores E4M3 de ocho bits de una tabla de consulta compartida por un bloque de pesos.
El Tensor Core reconstruye el valor seleccionado dentro de la operación matricial. El software no necesita generar una matriz de pesos descomprimida independiente antes de la multiplicación.
Incluido el libro de códigos compartido, SemiAnalysis calcula una huella de almacenamiento de 3,125 bits por peso. El libro de códigos contiene 64 bits compartidos entre 512 pesos.
El diseño difiere de los formatos NVFP4 y MXFP. Esos formatos utilizan escalado por bloques, aplicando una escala uniforme a un grupo de valores de baja precisión.
Una tabla de consulta puede distribuir sus ocho valores de forma desigual. Puede concentrar entradas cerca de grupos densos de pesos o representar distribuciones positivas y negativas asimétricas.
Esa flexibilidad puede preservar más información que el redondeo uniforme con un número de bits similar. No garantiza una mejor calidad del modelo.
Un libro de códigos cubre 512 pesos, mientras que NVFP4 puede adaptar su escala en grupos mucho más pequeños. Los resultados dependerán de los datos de calibración, el ajuste del libro de códigos y la sensibilidad del modelo.
Algunas capas también pueden necesitar una precisión mayor. Una receta de cuantización agresiva puede ahorrar memoria a costa de dañar la precisión de razonamiento o desestabilizar la salida.
El mecanismo de hardware sigue abordando una restricción central de la inferencia. Durante la decodificación con lotes pequeños, las GPU con frecuencia esperan a que los pesos del modelo lleguen desde HBM.
Reducir el tamaño almacenado de cada peso permite que la memoria entregue más pesos por segundo. También reduce la energía dedicada a mover esos bits por el sistema.
SemiAnalysis utilizó un modelo hipotético de 2,8 billones de parámetros para ilustrar el efecto sobre la capacidad. Su cálculo situó la carga útil bruta de pesos cerca de 1,09 terabytes con el formato de Rubin.
La comparación excluyó la caché KV, las activaciones, la replicación y la sobrecarga de serving. Por tanto, demuestra el almacenamiento de pesos, no la memoria total de despliegue.
Con 288 gigabytes de HBM4 por GPU Rubin, los pesos comprimidos requerirían aproximadamente cuatro paquetes. Una representación alternativa de baja precisión requería alrededor de seis en el ejemplo.
Menos GPU participantes pueden reducir la comunicación y la replicación. También pueden dejar más memoria para contextos más largos, lotes más grandes o la caché KV.
Sin embargo, el modo LUT tiene restricciones de implementación. SemiAnalysis señala que no puede transponer la matriz B, lo que limita las operaciones que pueden usarlo directamente.
El benchmark público tampoco parece utilizar esta función. Por tanto, la ventaja inicial de Rubin no puede atribuirse a la inferencia mediante tablas de consulta de tres bits.
Esto es a la vez alentador e incierto. Rubin tiene capacidad adicional de silicio que el software futuro puede aprovechar, pero su precisión y valor en producción siguen sin verificarse.
NVIDIA también ha añadido dispersidad de activaciones 2:4 en tiempo de ejecución. Este método conserva dos valores en cada grupo de cuatro y omite los otros dos durante las operaciones compatibles.
A diferencia de la dispersidad de pesos anterior, la dispersidad de activaciones en tiempo de ejecución no requiere podar y reentrenar permanentemente el modelo. El hardware puede comprimir valores intermedios mientras se ejecuta el modelo.
Sin embargo, NVIDIA no ha publicado evidencia de precisión sobre descartar la mitad de los valores de activación seleccionados antes de operaciones posteriores. El resultado de CoreWeave tampoco parece utilizar esta función.
Estas capacidades no utilizadas representan el margen de optimización de Rubin. No deberían incluirse en los cálculos actuales de TCO como ganancias futuras garantizadas.
Los compradores deben exigir pruebas de calidad a nivel de modelo junto con el rendimiento. Un formato de menor número de bits solo reduce los costes de serving si el modelo resultante cumple el mismo objetivo de precisión y fiabilidad.
Rubin gana la prueba de TCO, pero la referencia cambia el margen
Rubin parece más barato por token entregado pese a tener costes de propiedad más altos, aunque su ventaja se reduce frente a sistemas Blackwell plenamente optimizados.
El coste total de propiedad combina hardware, electricidad, instalaciones, redes, mantenimiento y gastos operativos. Ofrece una visión más amplia que el rendimiento por vatio por sí solo.
SemiAnalysis aplicó su modelo de propiedad del operador al rendimiento de salida normalizado. El análisis evitó las tarifas de alquiler en la nube, que pueden incluir escasez, términos contractuales y márgenes del proveedor.
El análisis concluyó que Rubin era más barato por token de salida en todos los niveles de interactividad medidos frente a los resultados de GB200 y GB300 de julio de 2026. La ventaja aumentaba a medida que crecía la velocidad de respuesta.
Frente a la referencia actual de GB200, Rubin era aproximadamente 1,5 veces más barato hasta 100 tokens por segundo por usuario. La ventaja relativa alcanzaba cerca de tres veces entre 200 y 250 tokens.
Comparar Rubin con la referencia de software de GB200 de 2025 produjo un resultado mayor. Rubin alcanzó un máximo de cerca de ocho veces más barato alrededor de 150 tokens por segundo por usuario.
Esa referencia antigua explica gran parte de la diferencia entre el titular de marketing de NVIDIA y una comparación práctica de compra. Un GB200 ajustado en 2026 es más capaz que en su estado inicial de despliegue.
SemiAnalysis también estima que Rubin tiene un coste de propiedad por GPU superior al de GB200 o GB300. Su ganancia de rendimiento debe compensar esa mayor carga de sistema.
Lo hace en la carga de trabajo examinada, especialmente con objetivos exigentes de interactividad. La economía es menos decisiva a velocidades de respuesta más lentas, donde Blackwell puede utilizar lotes más grandes de forma eficaz.
Esto crea una decisión de compra específica para cada carga de trabajo.
Para inferencia altamente interactiva
Rubin mantiene velocidades de respuesta que GB200 no puede alcanzar en la configuración probada.
Su ancho de banda de memoria y su tejido de rack se vuelven más valiosos a medida que disminuye el tamaño de lote.
Los agentes de programación y los servicios de búsqueda en tiempo real se ajustan a este perfil.
Para inferencia centrada en el rendimiento
El software maduro de Blackwell puede reducir la ganancia relativa de Rubin.
La infraestructura existente y la capacidad reservada pueden pesar más que una ventaja teórica de eficiencia.
Los costes de migración merecen incluirse en el modelo de TCO del operador.
Para modelos de contexto largo
El mayor pool de memoria de Rubin da a los operadores más espacio para los pesos y la caché KV.
El benchmark inicial de un solo turno no mide directamente esa ventaja.
Las pruebas de agentes de varios turnos ofrecerán una señal más representativa.
El benchmark utilizó DeepSeek R1 671B con una entrada de 8.000 tokens y una salida de 1.000 tokens. Ese modelo y esa forma de secuencia no representan todas las cargas de trabajo de producción de 2026.
SemiAnalysis sostiene que los modelos más nuevos de varios billones de parámetros deberían favorecer la capacidad y el ancho de banda de Rubin. Esa afirmación sigue siendo una expectativa técnica hasta que lleguen resultados comparativos.
CoreWeave también ejecutó la prueba en un rack de muestra de ingeniería de Dell sin un tejido de escalado horizontal. El escalado horizontal conecta varios racks, mientras que el backplane interno NVLink proporciona conectividad de escalado vertical.
La prueba satisfactoria respalda la operación interna de paralelismo de expertos del rack. No establece el rendimiento, la fiabilidad ni la eficiencia en un despliegue grande de varios racks.
La competencia añade otra restricción. MI455X de AMD ofrece 432 gigabytes de HBM4 por acelerador, frente a los 288 gigabytes de Rubin.
En 72 aceleradores, el diseño Helios de AMD proporciona 31,1 terabytes de memoria. Rubin suministra 20,7 terabytes en su rack NVL72.
La ventaja de capacidad de AMD puede importar para modelos grandes y contextos largos. NVIDIA responde con su ecosistema de software establecido, el tejido NVLink y una experiencia anterior de operación a escala de rack.
Los sistemas TPU de Google ofrecen otra vía integrada. Combinan aceleradores personalizados, interconexiones, compiladores y servicios en la nube bajo un único operador.
Por tanto, la competencia de TCO no se limita a Rubin y GB200. Los compradores deben comparar recetas completas de serving utilizando el mismo modelo, objetivo de precisión, latencia, longitud de contexto y contabilidad energética.
Rubin mantiene actualmente el resultado temprano público más sólido. La evidencia todavía no establece una proporción de costes fija para la inferencia de producción.
Lo que deben demostrar los próximos benchmarks
Tres señales determinarán si el resultado inicial de ingeniería de Rubin se convierte en una ventaja de producción duradera.
La primera señal es la prometida presentación de NVIDIA a InferenceX en el tercer trimestre de 2026. SemiAnalysis afirma que NVIDIA se ha comprometido a proporcionar cifras de Rubin verificables de forma independiente mediante ese benchmark.
Una presentación creíble debería probar modelos actuales con configuraciones de serving documentadas. Debería informar conjuntamente la interactividad, el rendimiento de salida, los límites de potencia y los ajustes de optimización.
Los resultados frente a sistemas GB200 y GB300 de julio de 2026 reforzarían la comparación actual. Repetir la referencia más antigua de GB200 dejaría sin resolver la preocupación metodológica central.
La segunda señal es una carga de trabajo de agentes de varios turnos. La inferencia de un solo turno no puede reproducir llamadas repetidas a herramientas, cachés KV crecientes y longitudes de prompt cambiantes durante una sesión de agente.
SemiAnalysis está desarrollando un escenario AgentX con colaboradores de infraestructura y serving de código abierto. Su análisis de Rubin identifica el trabajo agéntico de contexto largo como una probable fortaleza arquitectónica.
Rubin debería ampliar su ventaja cuando dominen la capacidad de memoria y el ancho de banda. Si la ventaja se mantiene sin cambios o se contrae, el argumento del rack para contextos largos será menos convincente.
La tercera señal es un software público maduro. Los desarrolladores deberían seguir las versiones de producción de CUDA, PyTorch, vLLM, Triton, TensorRT-LLM y Dynamo.
La compatibilidad funcional llegará antes que el rendimiento optimizado. La evidencia decisiva procederá de kernels estables que utilicen las funciones específicas de Rubin para movimiento de memoria, sincronización y baja precisión.
La inferencia LUT de tres bits merece un escrutinio particular. Las pruebas publicadas deben informar la precisión, los métodos de calibración, las capas afectadas y el rendimiento de extremo a extremo frente a NVFP4.
La dispersidad de activaciones necesita el mismo tratamiento. Mayores tasas aritméticas significan poco si la pérdida de calidad obliga a los operadores a utilizar un modelo mayor o repetir solicitudes fallidas.
Feynman también plantea una cuestión de software a más largo plazo. NVIDIA ha identificado su próxima arquitectura como SM140, mientras que Rubin utiliza SM107.
SemiAnalysis espera que Feynman requiera reescrituras más amplias de kernels, similares a la difícil transición de Hopper a Blackwell. Por tanto, la ventaja de compatibilidad de Rubin podría durar solo una generación.
Para los compradores de infraestructura, la decisión inmediata no es si Rubin tiene mejores especificaciones. Las tiene.
La pregunta más difícil es si una carga de trabajo específica se beneficia lo suficiente como para justificar cambios en el despliegue. Los operadores necesitan pruebas basadas en su modelo, distribución de contextos, objetivo de respuesta y capacidad eléctrica existente.
Para los desarrolladores, la acción útil es seguir ahora el soporte de kernels y las recetas de benchmark. El perfilado temprano puede revelar si una aplicación está limitada por el cómputo, el tráfico de HBM, las redes o la planificación.
Para los equipos de productos de IA, conviene vigilar los resultados a nivel de usuario. Un mayor rendimiento de tokens solo importa cuando reduce el tiempo de finalización de tareas, mejora la fiabilidad de los agentes o permite atender a más clientes simultáneamente.
El hilo de OpenAI SemiAnalysis conecta, en última instancia, tres capas: herramientas de kernel abiertas, análisis de rendimiento independiente y hardware de NVIDIA a escala de rack. Ninguna de esas capas puede validar Rubin por sí sola.
¿Mantendrá Rubin su ventaja en modelos modernos, agentes de múltiples turnos y pruebas reproducibles de forma independiente? Esa evidencia, y no un único múltiplo de titulares, debería determinar el próximo compromiso de infraestructura de inferencia.
