El debut de NVIDIA Vera Rubin en MLPerf marca el ritmo, pero su condición de vista previa importa
NVIDIA entró en MLPerf Inference v6.1 con Vera Rubin NVL72 y reportó hasta 3,7 veces el rendimiento de su predecesor GB300 NVL72. El debut de NVIDIA Vera Rubin en MLPerf ofrece a los compradores de infraestructura su primera visión revisada por pares de la próxima plataforma de IA a escala de rack de la compañía. También añade una limitación importante al titular: Vera Rubin sigue siendo un sistema en vista previa.
Esta distinción define la verdadera competencia. NVIDIA no se limita a comparar una generación de GPU con otra. Sostiene que los racks estrechamente integrados pueden convertir el nuevo silicio, las redes y el software de serving en una mejor economía de inferencia.
La presentación más amplia de AMD en MLPerf hasta la fecha demuestra por qué ese argumento enfrenta ahora presión. AMD publicó resultados competitivos con hardware disponible, amplió su cobertura de cargas de trabajo y destacó implementaciones que alcanzan los 512 aceleradores. NVIDIA lidera las comparaciones seleccionadas de Vera Rubin, pero los clientes deben decidir si esa ventaja en vista previa se traduce en valor desplegable.
Los resultados de NVIDIA Vera Rubin en MLPerf establecen una ventaja inicial
El debut demuestra una gran mejora generacional de rendimiento en dos modelos exigentes, aunque todavía no representa una plataforma de producción comercializada.
Los resultados llegaron el 16 de septiembre de 2026 como parte de la publicación de MLPerf v6.1. MLPerf Inference mide cómo los sistemas sirven modelos de IA entrenados bajo condiciones estandarizadas de precisión y latencia.
MLCommons informó de un récord de 30 organizaciones participantes en esta ronda. Aparecieron cinco nuevos procesadores o aceleradores, incluidos el MI350P disponible de AMD y el Arc Pro B70 de Intel. NVIDIA Rubin y Vera Rubin NVL72 participaron en vista previa.
NVIDIA presentó resultados de Vera Rubin para DeepSeek-R1 y Qwen3-VL-235B. DeepSeek-R1 evalúa el serving de modelos de razonamiento, mientras que Qwen3-VL combina entradas de lenguaje y visuales para tareas como la clasificación de productos.
Los resultados de Vera Rubin de la compañía muestran la mayor mejora relativa en el escenario interactivo de Qwen3-VL. Allí, un Vera Rubin NVL72 entregó 1.307 consultas por segundo. Un resultado comparable de GB300 NVL72 alcanzó 349 consultas por segundo.
Eso produce el aumento destacado de aproximadamente 3,7 veces. El escenario interactivo también impone un límite de latencia de 1,5 segundos, lo que hace que el resultado sea más relevante para aplicaciones receptivas que el rendimiento por lotes sin restricciones.
La ventaja fue menor, pero aún sustancial, en otros escenarios de Qwen3-VL. Vera Rubin alcanzó 2.393 muestras por segundo sin conexión, frente a 1.305 de GB300. Su resultado de servidor llegó a 2.323 consultas por segundo, frente a 1.210.
Estos resultados equivalen a aproximadamente 1,8 veces más rendimiento sin conexión y 1,9 veces más rendimiento de servidor. La diferencia demuestra por qué un único multiplicador máximo no puede describir todo el sistema.
En DeepSeek-R1, Vera Rubin registró 652.750 tokens por segundo en el escenario interactivo. Un resultado de GB300 NVL72 con 72 GPU alcanzó 260.098 tokens por segundo bajo las mismas restricciones de latencia publicadas.
Esta comparación respalda la afirmación de NVIDIA de hasta 2,5 veces más rendimiento de DeepSeek-R1. NVIDIA utilizó TensorRT-LLM para esta carga de trabajo, mientras que su presentación de Qwen3-VL empleó vLLM con NVIDIA Dynamo.
La tabla de rendimiento publicada también informa umbrales de precisión junto a cada resultado. La entrada de Vera Rubin para DeepSeek-R1 apunta al 99 por ciento de la precisión FP16, con una puntuación de coincidencia exacta del 81,9132 por ciento.
Para Qwen3-VL, el objetivo era el 99 por ciento de calidad BF16. El benchmark exigía una puntuación F1 jerárquica por categorías de al menos 0,7824 utilizando un conjunto de datos del catálogo de productos de Shopify.
Estos controles importan porque una inferencia más rápida tiene un valor limitado si una compresión numérica agresiva deteriora la salida del modelo. MLPerf exige que las presentaciones cumplan umbrales de calidad definidos antes de que sus cifras de rendimiento cuenten.
Aun así, el debut cubre solo dos modelos de benchmark. No establece liderazgo en todas las cargas de trabajo de lenguaje, recomendación, vídeo, voz o recuperación de información de MLPerf Inference v6.1.
Este alcance más limitado no es inusual para hardware en vista previa. Sí significa que los compradores deben interpretar el resultado como una señal temprana del sistema, no como un veredicto universal.
Por qué un mayor rendimiento cambia la economía de la inferencia de IA
El rendimiento de inferencia importa financieramente cuando un mayor rendimiento atiende más solicitudes útiles sin aumentar de forma proporcional el hardware, la energía o la complejidad operativa.
El entrenamiento produce un modelo, pero la inferencia se ejecuta cada vez que ese modelo responde a un usuario. Un asistente para consumidores, un agente de programación, un servicio de búsqueda o un sistema documental pueden activar muchas llamadas de inferencia durante una sola tarea.
Los agentes de razonamiento intensifican este patrón. Generan tokens intermedios, llaman herramientas, examinan resultados y revisan sus planes. Una respuesta visible puede requerir varios pases por el modelo detrás de la interfaz.
Este comportamiento hace que los tokens por segundo sean económicamente importantes. Un sistema más rápido puede atender más solicitudes simultáneas, reducir colas o entregar trazas de razonamiento más largas dentro de la misma ventana de tiempo.
Sin embargo, el rendimiento máximo es solo una parte del cálculo. Los compradores también necesitan una latencia de respuesta aceptable, precisión consistente, alta utilización, una demanda energética manejable y software fiable.
MLPerf separa varios escenarios de despliegue por esta razón. El escenario sin conexión enfatiza el procesamiento masivo. El escenario de servidor modela solicitudes entrantes variables, mientras que el escenario interactivo impone requisitos de capacidad de respuesta más estrictos.
La mejor demostración relativa de Vera Rubin aparece en ese entorno interactivo sensible a la latencia. Esto sugiere que sus mejoras arquitectónicas se vuelven especialmente valiosas cuando un sistema no puede ocultar retrasos tras lotes grandes.
El resultado es importante para productos que cobran por acceso, consumo o trabajo completado. Si un rack gestiona más solicitudes a un nivel de servicio requerido, el operador obtiene más capacidad de esa infraestructura.
Sin embargo, el rendimiento no equivale automáticamente a ingresos. Debe existir demanda, el software debe mantener ocupados los aceleradores y el servicio completo debe evitar cuellos de botella fuera del servidor de modelos.
El almacenamiento, las redes, las bases de datos, los filtros de seguridad y la lógica de aplicación pueden limitar el rendimiento entregado. Un benchmark aísla el sistema evaluado con mayor limpieza de la que permiten la mayoría de entornos de producción.
El coste por token también es más complejo que dividir el coste del equipo por el rendimiento máximo. Incluye electricidad, refrigeración, redes, mantenimiento, financiación, ingeniería de software, tiempo de inactividad y depreciación.
NVIDIA afirma que Vera Rubin reduce los costes por token, pero la publicación v6.1 no ofrece una comparación completa del coste total de propiedad en producción. El benchmark aporta evidencia de rendimiento, no un modelo de compra integral.
Por ello, los equipos de infraestructura deberían traducir estos resultados a sus propios perfiles de tráfico. Un servicio visual de búsqueda de productos podría valorar el rendimiento de servidor de Qwen3-VL. Una plataforma de razonamiento podría priorizar la latencia y la generación de tokens de DeepSeek-R1.
El resultado adquiere más valor cuando el benchmark se parece a la carga de trabajo del comprador. Se vuelve menos decisivo cuando la arquitectura del modelo, la longitud de las solicitudes, el comportamiento de agrupamiento o las restricciones del servicio difieren sustancialmente.
Esta es la presión económica a la que se enfrentan los competidores de NVIDIA. No necesitan ganar todos los gráficos, pero deben ofrecer suficiente rendimiento desplegable, madurez de software y flexibilidad para crear un mejor caso de negocio general.
El codesarrollo a escala de rack es el mecanismo de rendimiento
La ventaja de Vera Rubin procede de tratar 72 GPU, CPU, memoria, redes y software de inferencia como un único sistema coordinado.
Un rack NVL72 conecta 72 aceleradores dentro de un dominio de escalado vertical de gran ancho de banda. Las redes de escalado vertical permiten que esos aceleradores cooperen como partes de un sistema grande, en lugar de comportarse como servidores aislados.
NVIDIA afirma que NVLink de sexta generación y NVLink Switch proporcionan tasas de paquetes 10 veces superiores a las de Ethernet estándar. La compañía también sostiene que ofrecen una latencia tres veces menor en la comparación pertinente.
Estas afirmaciones sobre la interconexión proceden de NVIDIA y no deben tratarse como benchmarks de red independientes. No obstante, explican la decisión de diseño detrás del sistema presentado.
Los grandes modelos de razonamiento y visión-lenguaje mueven cantidades considerables de datos durante la inferencia. Los pesos del modelo, las activaciones, los estados de atención y las decisiones de enrutamiento deben llegar rápidamente a los recursos informáticos adecuados.
Vera Rubin utiliza HBM4, una generación de memoria de gran ancho de banda situada cerca de la GPU. La configuración de rack de NVIDIA incluye 72 GPU Rubin y 36 CPU Vera, según su arquitectura publicada.
El software divide después el trabajo entre estos recursos. El serving desagregado separa el prefill de la decodificación, lo que permite que distintos recursos se especialicen en fases diferentes de la generación de texto.
El prefill procesa la entrada del usuario y construye el estado interno de atención del modelo. La decodificación genera la respuesta token por token, a menudo bajo restricciones de memoria y latencia distintas.
Separar estas fases puede mejorar la utilización cuando el software asigna cada una a recursos adecuados. También puede crear sobrecarga de coordinación, por lo que las interconexiones rápidas y una programación eficaz se vuelven críticas.
Las presentaciones de NVIDIA utilizaron paralelismo experto a gran escala para modelos de mezcla de expertos. Este diseño de modelo activa únicamente capas expertas seleccionadas para cada token, en lugar de ejecutar toda la red cada vez.
El enfoque puede reducir el cómputo, pero crea comunicación irregular. Los tokens deben enrutarse a los expertos correctos, procesarse y devolverse sin que los retrasos de red consuman los ahorros.
La aritmética de menor precisión constituye otra parte del mecanismo. NVIDIA utilizó NVFP4, un formato numérico de cuatro bits diseñado para reducir el uso de memoria y aumentar el rendimiento de cómputo.
El sistema aplicó precisión reducida a los pesos, las operaciones de atención y la caché clave-valor. Una caché clave-valor almacena información de atención previa para que el modelo no recalcule toda la conversación para cada token nuevo.
Una precisión menor permite que quepan más datos en memoria y reduce el movimiento entre unidades de cómputo. Los umbrales de precisión de MLPerf proporcionan una salvaguarda frente a pérdidas de calidad inaceptables.
Por tanto, la cifra final de rendimiento no es una medición pura del silicio Rubin. Refleja procesadores, memoria, redes, formatos numéricos, kernels, frameworks de serving y optimización específica para el benchmark.
Esto es central para la estrategia de NVIDIA. La compañía quiere que los clientes evalúen toda la plataforma porque su ventaja competitiva se extiende más allá de las especificaciones individuales de los aceleradores.
La estrategia puede aportar beneficios a los operadores que buscan una pila única con soporte. También puede aumentar la dependencia del entorno de hardware y software estrechamente conectado de NVIDIA.
Para los compradores, esa dependencia no es automáticamente negativa. Una plataforma coordinada puede reducir el trabajo de integración y producir un rendimiento predecible en sistemas cualificados.
La contrapartida aparece cuando los clientes desean mayor elección de hardware, software portátil o control independiente sobre componentes individuales. Ahí es donde el enfoque competidor de AMD cobra relevancia.
AMD presiona la narrativa de plataforma con hardware disponible
La demostración de AMD en v6.1 no elimina las ventajas seleccionadas de Vera Rubin, pero impide que NVIDIA controle sin oposición la narrativa más amplia de la inferencia.
AMD pasó de tres familias de modelos en MLPerf Inference v6.0 a seis en v6.1. Sus resultados abarcaron cargas de trabajo de lenguaje, razonamiento, recomendación y texto a vídeo en aceleradores MI355X, MI350X y MI350P.
La presentación de MLPerf de la compañía destaca un rendimiento competitivo con ocho GPU en GPT-OSS-120B. AMD afirma que MI355X superó a determinadas configuraciones NVIDIA B200 y B300 en escenarios offline y de servidor.
AMD también informó de mejoras derivadas del trabajo de software con hardware MI355X sin cambios. El rendimiento de servidor de GPT-OSS-120B con ocho GPU mejoró un 38 por ciento respecto a la ronda anterior.
El rendimiento offline aumentó un 28 por ciento, mientras que el rendimiento de flujo único de Wan 2.2 mejoró un 70 por ciento. Estas son comparaciones de AMD entre sus resultados presentados en v6.1 y v6.0.
El mismo patrón respalda uno de los argumentos centrales de NVIDIA. El hardware no determina por sí solo el valor durante la vida útil de un sistema de inferencia. Las mejoras de software pueden desbloquear más trabajo útil después del despliegue.
AMD alcanzó una eficiencia de escalado del 95 por ciento con 72 GPU MI355X en GPT-OSS-120B. La eficiencia de escalado mide hasta qué punto el crecimiento del rendimiento sigue de cerca la incorporación de aceleradores.
Posteriormente, Crusoe presentó un sistema AMD de 512 GPU. Produjo 5,75 millones de tokens offline por segundo en GPT-OSS-120B y 2,90 millones en DeepSeek-R1, según AMD.
En ese momento, era el mayor número de aceleradores presentado a MLPerf Inference. También ilustra una vía competitiva de escalado basada en grandes clústeres y un entorno de software abierto.
La comparación con Vera Rubin no es directa. Las distintas presentaciones pueden usar modelos, tamaños de sistema, escenarios y optimizaciones aprobadas diferentes.
Un resultado agregado de 512 aceleradores no demuestra una mejor economía por rack que un sistema Vera Rubin de 72 GPU. Del mismo modo, el liderazgo de Vera Rubin en Qwen3-VL no resuelve la competitividad de AMD en GPT-OSS-120B.
Este es un desafío habitual al interpretar MLPerf. Cada proveedor puede enfatizar las cargas de trabajo, los escenarios y los tamaños de sistema que mejor respaldan su caso.
MLCommons reduce esa libertad mediante reglas estándar, requisitos de precisión, revisión de resultados y detalles de configuración publicados. No puede hacer idénticos sistemas diferentes.
Las comparaciones más útiles mantienen constantes el modelo, el escenario, el objetivo de latencia, el requisito de precisión, el número de aceleradores y la división. Las diferencias fuera de esas variables deben seguir siendo visibles.
La competencia también va más allá de NVIDIA y AMD. Google participó en v6.1, Intel presentó resultados de Arc Pro B70 y varios proveedores de nube presentaron sistemas de socios.
Los resultados de inferencia de Lambda demuestran cómo los fabricantes de sistemas pueden generar mejoras adicionales utilizando la misma generación de aceleradores. Su sistema Blackwell Ultra de cuatro GPU mejoró casi un 9 por ciento respecto a v6.0.
Lambda también utilizó una presentación de división abierta para ejecutar una carga de trabajo agente en el edge con Kimi K2.6 sobre hardware de centro de datos. El modelo contiene más de un billón de parámetros, según Lambda.
Estas entradas refuerzan una idea más amplia. La unidad competitiva está pasando de un procesador a una pila de servicios configurada que incluye modelos, frameworks, orquestación e infraestructura.
NVIDIA ofrece actualmente la versión más integrada de esa pila. AMD intenta debilitar la suposición de que la integración exige una plataforma exclusiva de NVIDIA.
Por tanto, la presión sobre NVIDIA no consiste simplemente en seguir siendo la más rápida. Debe demostrar que su ventaja de rendimiento genera suficiente valor operativo como para justificar el compromiso con su arquitectura.
Lo que los resultados previos no demuestran
La afirmación más sólida es el rendimiento de referencia verificado, mientras que las afirmaciones sobre costes, ingresos, disponibilidad y liderazgo amplio en cargas de trabajo requieren pruebas adicionales.
MLCommons identifica Vera Rubin y Vera Rubin NVL72 como entradas previas. Esa etiqueta indica a los lectores que la plataforma no se presenta como el AMD MI350P disponible en esta ronda de resultados.
El estado previo no invalida un resultado. MLPerf sigue publicando la configuración y aplicando su proceso de referencia. Sí limita lo que los compradores pueden inferir sobre sistemas desplegados comercialmente.
El hardware de producción puede enfrentarse a limitaciones que no aparecen en una presentación de ingeniería. La madurez del firmware, las tasas de fallo, el suministro de componentes, la refrigeración, el tiempo de instalación y la gestión de flotas afectan a la capacidad real.
La presentación de Vera Rubin también procedía de NVIDIA y su socio Nebius. Una reproducción más amplia entre fabricantes de sistemas independientes proporcionaría pruebas más sólidas de que el rendimiento se transfiere entre despliegues.
El ecosistema de generaciones anteriores de NVIDIA ofrece un precedente favorable. Diecinueve socios participaron con plataformas NVIDIA en v6.1, incluidos ocho que utilizaron sistemas Blackwell NVL72 multinodo.
Esa amplitud sugiere que NVIDIA sabe cómo trasladar diseños optimizados a través de una amplia red de proveedores. No garantiza que la configuración previa de Vera Rubin llegue sin cambios ni a tiempo a todas partes.
La cobertura de cargas de trabajo plantea otra incertidumbre. La plataforma debutó en DeepSeek-R1 y Qwen3-VL, dos cargas adecuadas para su diseño a escala de rack y su pila de software.
No publicó resultados de Vera Rubin para GPT-OSS-120B, recomendación, voz, generación de imágenes, RAG o Wan 2.2 en la división cerrada. Las próximas rondas deberían mostrar si el liderazgo se generaliza.
NVIDIA también citó mejoras de rendimiento posteriores a la fecha límite en GPT-OSS-120B y DLRMv3. La compañía afirmó explícitamente que MLCommons no había verificado esos resultados posteriores.
Esas cifras deben permanecer fuera de las conclusiones directas de referencia hasta que superen el mismo proceso de revisión. Las pruebas del proveedor pueden indicar una dirección, pero no tienen el mismo peso probatorio.
Los datos de energía son otra pieza ausente en la comparación principal. El rendimiento por rack importa, pero los operadores a menudo se enfrentan a una capacidad eléctrica fija antes de agotar el espacio disponible.
Un rack más rápido todavía puede complicar los despliegues si requiere una entrega eléctrica más densa o refrigeración líquida más exigente. El rendimiento por vatio determinará cuánto trabajo útil cabe dentro del límite de una instalación.
NVIDIA sostiene que un mayor rendimiento reduce el coste por token. Esa conclusión es plausible cuando otros factores permanecen estables, pero el resultado publicado no ofrece una contabilidad completa de costes.
Las condiciones de compra, la utilización, la energía, el mantenimiento, la financiación y el trabajo de software pueden modificar la cifra final. Los compradores necesitan datos de producción medidos con sus propias cargas de trabajo.
La referencia tampoco puede garantizar la capacidad de respuesta para el usuario final. El servicio de modelos puede ejecutarse rápidamente mientras la recuperación, las llamadas a herramientas, las bases de datos o las API externas generan la mayor parte del retraso.
MLPerf v6.1 comienza a abordar esta brecha con nuevas pruebas de generación aumentada por recuperación y agentes en el edge. Más de la mitad de los participantes utilizaron su arnés centrado en API, que aplica una arquitectura cliente-servidor.
MLCommons afirma que ese arnés respaldará una transición hacia MLPerf Endpoints para las pruebas de centros de datos. El cambio debería acercar las mediciones a servicios desplegables en lugar de motores de modelos aislados.
Esta evolución podría fortalecer o debilitar el caso de la plataforma de NVIDIA. Una pila estrechamente integrada debería beneficiarse de la medición de servicio completo, pero las dependencias externas pueden diluir las ventajas brutas de los aceleradores.
La interpretación prudente es específica. Vera Rubin registró un notable debut previo revisado en DeepSeek-R1 y Qwen3-VL. Aún no ha demostrado liderazgo universal ni una economía de producción completa.
Tres señales determinarán si se mantiene la ventaja
La ventaja inicial de Vera Rubin solo adquiere importancia estratégica si los sistemas comercializados la reproducen en más cargas de trabajo y bajo restricciones operativas medibles.
La primera señal es una amplia disponibilidad en producción. Los clientes deberían observar instancias en la nube, sistemas de socios y racks instalados que expongan detalles de configuración comparables a los de la presentación previa.
Un lanzamiento exitoso demostraría que NVIDIA puede convertir un resultado de ingeniería optimizado en infraestructura repetible. Los retrasos o configuraciones materialmente distintas debilitarían esa conclusión.
La disponibilidad debe incluir más que anuncios de envíos. Los compradores necesitan versiones de software estables, redes cualificadas, procedimientos de servicio y pruebas de que los sistemas sostienen el rendimiento durante largos periodos de operación.
La segunda señal es la próxima ronda de referencias independientes. Vera Rubin necesita resultados más allá de DeepSeek-R1 y Qwen3-VL, especialmente en recuperación, recomendación, vídeo y modelos de lenguaje adicionales.
Una cobertura más amplia respaldaría la afirmación de NVIDIA de que una plataforma puede gestionar cargas de inferencia diversas. Una cobertura limitada dejaría más espacio para aceleradores especializados y clústeres competidores.
Los futuros resultados de MLPerf Endpoints serán especialmente reveladores. Deberían medir sistemas orientados a API que se parezcan más a los servicios adquiridos y operados por las empresas.
Habrá que observar si el rendimiento bruto de Vera Rubin se mantiene al añadir orquestación de solicitudes, componentes de recuperación y límites de servicio realistas. Una ventaja menor sugeriría que los cuellos de botella se desplazaron a otro lugar.
La tercera señal es el progreso competitivo del software. Las mejoras de AMD en v6.1 muestran que los aceleradores instalados pueden obtener aumentos sustanciales de rendimiento sin una nueva generación de hardware.
Si ROCm, los frameworks abiertos de servicio y los sistemas de socios continúan mejorando rápidamente, los compradores podrían aceptar un rendimiento máximo inferior a cambio de flexibilidad o compatibilidad con infraestructura existente.
Si el software de NVIDIA mejora al mismo ritmo, la ventaja inicial de Vera Rubin puede multiplicarse. La compañía ya informó de una mejora de 1,6 veces en Qwen3-VL con GB300 entre v6.0 y v6.1.
Por tanto, la velocidad del software importa dos veces. Eleva el rendimiento actual y cambia cómo los clientes estiman la vida útil de un sistema costoso.
Los equipos de compras deberían solicitar resultados para sus modelos exactos, longitudes de contexto, patrones de lotes y objetivos de latencia. También deberían probar fallos, actualizaciones y cambios de carga de trabajo.
Los desarrolladores deberían observar qué optimizaciones llegan a los frameworks comunes sin requerir un trabajo personalizado extenso. Una técnica ajustada a una referencia genera un valor limitado si los equipos habituales no pueden desplegarla ni mantenerla.
Los líderes de producto de IA deberían conectar las métricas de infraestructura con los resultados para el usuario. Una inferencia más rápida puede permitir menor latencia, más pasos de razonamiento, mayor concurrencia o solicitudes multimodales más largas.
El resultado de NVIDIA Vera Rubin en MLPerf presenta un caso inicial creíble para el codiseño a escala de rack. Su comparación de pico de 3,7 veces es significativa, pero pertenece a un escenario definido.
La próxima decisión no es si la referencia previa parece rápida. Claramente lo es. La decisión es si los sistemas comercializados conservan esa ventaja cuando la energía, el software, la disponibilidad y las cargas de trabajo reales entran en la ecuación.
Pida a los proveedores que reproduzcan su objetivo de nivel de servicio más exigente antes de elegir una plataforma. Después compare conjuntamente el rendimiento sostenido, la latencia, la precisión, la utilización y el esfuerzo operativo. Esa evaluación revelará si la ventaja de referencia de Vera Rubin se convierte en una economía de inferencia duradera o sigue siendo un impresionante resultado previo.
