En los últimos días se ha viralizado un argumento contundente: que NVIDIA “ha admitido” que su arquitectura está “rota” porque ha presentado un chip para Inteligencia Artificial que prescinde de HBM y recurre a memoria GDDR. La frase suena a titular perfecto para redes sociales, pero la realidad es más interesante —y, sobre todo, más matizada—: NVIDIA está reaccionando a un cambio de fondo en cómo se consume la Inteligencia Artificial en producción, donde la batalla ya no es solo entrenar modelos, sino servirlos de forma rentable cuando el contexto se dispara a cientos de miles o millones de tokens.

La pieza que explica este giro es Rubin CPX, un acelerador diseñado específicamente para una parte concreta de la inferencia: el procesamiento del contexto (prefill). En lugar de intentar ser “el chip para todo”, su propuesta es separar fases y, con ello, separar también costes.

Qué es Rubin CPX y por qué llama tanto la atención

Según la propia NVIDIA, Rubin CPX está orientado a escenarios de inferencia con contextos masivos, donde el sistema “lee” grandes volúmenes de información (documentos, repositorios de código, historiales largos, vídeo transcrito, etc.) antes de generar respuesta. Para ese trabajo, el cuello de botella no siempre es el mismo que en la generación token a token (decode), y ahí aparece el incentivo económico: usar una memoria distinta a HBM.

NVIDIA posiciona Rubin CPX dentro de una plataforma a escala de rack, Vera Rubin NVL144, donde conviven aceleradores pensados para diferentes necesidades de inferencia. La compañía insiste en el mensaje de eficiencia: hacer que el hardware se parezca más al patrón real de uso.

En términos simples: si una parte del trabajo necesita mucha computación y otra depende más del movimiento de datos, intentar resolver ambas con el mismo “martillo” puede acabar saliendo caro. Rubin CPX es el síntoma de que NVIDIA ve un mercado donde el prefill ya no es marginal, sino un bloque de coste que puede dominar en ciertas cargas.

La clave: prefill y decode ya no se comportan igual

El detonante de este cambio es el auge de la Inteligencia Artificial en producción con contextos largos. En una interacción moderna —especialmente en asistentes empresariales, agentes, análisis documental o programación— el sistema puede dedicar un tiempo notable a “absorber” información antes incluso de empezar a contestar.

En ese flujo aparecen dos etapas:

• Prefill (procesado de contexto): el modelo ingiere el prompt completo y construye estados internos (como la KV cache) para poder razonar sobre lo leído.
• Decode (generación): el modelo produce salida token a token, reutilizando esos estados.

La industria lleva años agrupándolo todo bajo “inferencia”, pero el salto de contexto ha hecho que, para ciertos casos, ya no sea razonable optimizar como si todo fuese decode. Este enfoque de “separar fases” no es nuevo: trabajos académicos y de ingeniería de sistemas llevan tiempo planteando servir prefill y decode con estrategias distintas para aumentar rendimiento útil y reducir interferencias entre solicitudes largas y cortas.

Aquí es donde el relato de “arquitectura rota” se queda corto. Lo que se observa es otra cosa: los patrones de uso están cambiando y el hardware se está adaptando.

El software importa tanto como el silicio: Dynamo y el transporte de estado

Separar fases suena bien en un diagrama, pero tiene un coste técnico enorme: hay que mover estado (por ejemplo, KV cache) y coordinar qué nodo hace qué parte del trabajo sin disparar latencias. Si el “peaje” de coordinación se come el ahorro, la idea se hunde.

NVIDIA lleva tiempo preparando el terreno con Dynamo, una capa de orquestación para escalar la inferencia y gestionar componentes como enrutado, cacheado y transferencia de datos entre etapas y nodos. La propia NVIDIA lo presenta como una pieza para “desagregar” y optimizar el servicio de modelos en producción, apoyándose en librerías y mecanismos pensados para reducir ese coste operativo.

Visto así, Rubin CPX no es solo “un chip raro sin HBM”, sino parte de un paquete donde arquitectura + software + plataforma intentan encajar con el nuevo patrón: contextos grandes, multiagente, multimodal y con más sesiones largas.

Presión competitiva: TPUs, Trainium y el “hazlo en casa” de los hiperescalares

Este giro no sucede en el vacío. Los grandes proveedores cloud llevan años empujando su propio silicio para reducir dependencia, controlar costes y ajustar mejor el hardware al trabajo real.

• Google ha ido reforzando su apuesta por TPUs, y ha presentado Ironwood como un paso en eficiencia y escalado para cargas modernas de Inteligencia Artificial.
• AWS ha seguido la misma lógica con Trainium, y Trainium 3 se ha comunicado como disponible de forma general para quien quiera entrenar o servir modelos en su ecosistema.
• A nivel de mercado, también pesan los movimientos de demanda: se ha publicado que Meta ha explorado acuerdos para usar TPUs de Google en parte de su capacidad de cómputo, una señal de que incluso quien invierte en GPU no descarta diversificar si la economía lo justifica.
• Y acuerdos de gran escala entre actores de modelos y proveedores de infraestructura han reforzado la idea de que el “silicio alternativo” ya no es anecdótico.

En paralelo, las previsiones de crecimiento del mercado de inferencia —con cifras muy elevadas a final de década— alimentan la carrera por controlar el coste por token.

Entonces, ¿NVIDIA “admite” que estaba equivocada?

Lo que se puede afirmar con rigor es esto: NVIDIA está aceptando públicamente que hay cargas donde la inferencia se beneficia de separar recursos y de optimizar de manera distinta el procesamiento de contexto frente a la generación. Eso es un cambio de énfasis importante.

Pero de ahí a concluir que “todo lo anterior estaba mal” hay un salto. Las GPU con HBM siguen siendo críticas para entrenamiento, para muchas inferencias dominadas por ancho de banda, y para escenarios donde la integración y la latencia interna (incluyendo interconexiones avanzadas) son parte del valor.

Lo que sí parece claro es que el mercado se mueve hacia un mundo donde:

1. el contexto largo deja de ser excepción,
2. la rentabilidad se calcula por fases, y
3. los clientes —sobre todo los hiperescalares— exigen opciones para no pagar “lujo” donde no lo necesitan.

Rubin CPX encaja como respuesta a esa presión. Y, como suele ocurrir, la confirmación real llegará menos por discursos y más por despliegues, métricas y resultados operativos.

---

Preguntas frecuentes

¿Para qué tipo de empresas tiene sentido un enfoque “prefill/decode” separado?
Para organizaciones con mucha analítica documental, asistentes internos con bases de conocimiento grandes, agentes que consultan sistemas durante minutos u horas, o flujos donde el usuario aporta contextos enormes (legal, compliance, ingeniería, soporte técnico).

¿Por qué es relevante que Rubin CPX use GDDR en vez de HBM?
Porque cambia la estructura de costes del acelerador y su disponibilidad industrial. La idea es ajustar el hardware a cargas donde la HBM no aporta la misma ventaja relativa que en otros escenarios.

¿Esto hará que la inferencia sea más barata en el cloud?
Puede contribuir, pero no es automático: depende de cómo se empaquete (servicios gestionados, precios por token, reservas), de la competencia (TPUs/Trainium) y del coste operativo (red, energía, refrigeración).

¿Qué debería vigilar un equipo de IT que evalúa infraestructura para Inteligencia Artificial?
Más que el “modelo ganador”, conviene mirar coste por token en producción, latencia real con contextos largos, capacidad de escalar sesiones simultáneas, y compatibilidad con arquitecturas híbridas (GPU + silicio propio del proveedor).

Fuente: Shanaka Anslem Perera