
NVIDIA ha presentado nuevos resultados de Vera, una CPU diseñada para el trabajo que rodea a los agentes de inteligencia artificial. La idea es importante porque un agente no vive solo en la GPU: consulta bases de datos, ejecuta código, abre entornos aislados, llama a herramientas y coordina muchos pasos antes de responder. En esas pausas, la CPU puede convertirse en el cuello de botella que deja al acelerador esperando.
Vera intenta resolver ese problema con 88 núcleos Olympus, memoria LPDDR5X de gran ancho de banda y enlaces coherentes con las GPU Rubin. NVIDIA sostiene que el resultado combina rapidez por tarea y capacidad para atender muchos agentes a la vez. Conviene, sin embargo, separar lo confirmado de lo que aún necesita medición independiente: las cifras publicadas el 5 de noviembre de 2026 proceden del fabricante y de socios tempranos, no de una comparativa neutral y reproducible para cualquier centro de datos.
Qué ha anunciado NVIDIA sobre Vera
En su publicación oficial del 5 de noviembre, NVIDIA afirma que Vera puede completar trabajo de agentes con mayor velocidad y con más capacidad por vatio que dos referencias x86 seleccionadas. En una simulación de un centro de datos de 100 megavatios, la compañía atribuye a Vera 1,6 veces más agentes por vatio frente a la CPU x86 más rápida de su comparación y el doble de velocidad por agente frente al procesador x86 más eficiente energéticamente.
Esas dos cifras describen objetivos distintos. La latencia indica cuánto tarda un agente concreto en terminar una tarea; el rendimiento agregado expresa cuántas tareas puede completar el sistema en un periodo. Una infraestructura puede ser buena en uno y mediocre en el otro. La propuesta de NVIDIA es conseguir ambos sin obligar al operador a mezclar servidores especializados para trabajos rápidos y servidores densos para grandes volúmenes.
La compañía añade resultados de socios en cargas de producción o similares a producción: Perplexity comunica una ejecución 1,5 veces más rápida en tareas de programación; DeepInfra, hasta 2,2 veces la velocidad de su mejor procesador x86 en orquestación; y Daytona dice haber levantado mil entornos aislados en 10,8 segundos frente a 88,4 segundos en x86. Modal, ClickHouse y DuckLabs aportan otras mediciones. Son señales interesantes, pero no sustituyen a una batería independiente con configuraciones, consumo, versiones y costes equivalentes.
Por qué los agentes también necesitan una CPU rápida
Un modelo generativo ejecuta sus cálculos principales en la GPU, pero un agente encadena mucho trabajo externo. Puede interpretar una petición, buscar documentos, lanzar una consulta SQL, ejecutar Python en un contenedor, verificar el resultado y volver a preguntar al modelo. Cada salto añade latencia. Si la llamada a una herramienta tarda más, también se prolonga el tiempo durante el cual el estado de la conversación ocupa memoria.
Esto cambia el diseño de la infraestructura. En inferencia convencional importa producir tokens con rapidez. En un sistema agéntico importa además que las herramientas respondan deprisa, que los entornos aislados arranquen sin demora y que la cola de tareas no bloquee el siguiente paso. Una GPU muy rápida puede quedar infrautilizada si el servidor anfitrión no alimenta datos o no termina el trabajo auxiliar a tiempo.
La explicación técnica de NVIDIA describe trayectorias muy variables: algunas tareas avanzan de forma secuencial y otras abren ráfagas de llamadas paralelas. El fabricante dice haber analizado 163.594 sesiones y haber encontrado perfiles de trayectoria únicos en más del 97 %. Su conclusión es que la CPU debe mantener buen rendimiento por hilo cuando el socket está ocupado y, al mismo tiempo, absorber picos de concurrencia.
Para una empresa que evalúa dónde ejecutar estas cargas, el contexto físico sigue siendo decisivo. La latencia de red, la ubicación y el coste energético pueden pesar tanto como el procesador. En nuestro análisis sobre centros de datos, nube y latencia de IA explicamos por qué el rendimiento de laboratorio no se traslada automáticamente a una aplicación real.
La arquitectura: 88 núcleos, memoria rápida y coherencia
Vera utiliza 88 núcleos Olympus diseñados por NVIDIA sobre arquitectura Arm. Según la ficha oficial de la CPU, el chip incorpora una segunda generación de Scalable Coherency Fabric con 3,4 TB/s de ancho de banda biseccional. Esa malla conecta núcleos, caché, memoria, entrada y salida y el enlace con la GPU dentro de una arquitectura coherente.
La memoria LPDDR5X alcanza hasta 1,5 TB en determinadas configuraciones. NVIDIA señala hasta 1,2 TB/s de ancho de banda en la presentación del producto y hasta 1,8 TB/s de ancho de banda coherente entre CPU y GPU mediante NVLink-C2C. Las cifras corresponden a rutas distintas: una describe el subsistema de memoria y otra la comunicación coherente con el acelerador. No deben sumarse como si fueran una sola medida de rendimiento.
La coherencia permite que CPU y GPU compartan datos con menos copias explícitas. En teoría, eso ayuda a mover cachés, lotes y estados de ejecución sin pasar por trayectos más lentos. En la plataforma Vera Rubin, la CPU actúa además como anfitriona de las GPU y se ocupa de la orquestación, el movimiento de datos y parte de la gestión de memoria. El blog técnico de la plataforma Rubin presenta Vera como un componente del sistema completo, no como una pieza aislada.
Hay dos formatos principales. Vera puede instalarse como CPU independiente para análisis, código, entornos aislados y orquestación, o integrarse con Rubin en sistemas acelerados. También habrá configuraciones refrigeradas por aire y bastidores densos con refrigeración líquida. La elección afecta a potencia, densidad, mantenimiento y coste total, por lo que una cifra de rendimiento por chip cuenta solo una parte de la historia.
Qué significan realmente los resultados publicados
Las cifras de velocidad no son universales. El resultado depende del número de agentes concurrentes, el tamaño de las herramientas, la duración de cada llamada, la base de datos, el lenguaje y la proporción entre trabajo de CPU y GPU. Un agente que pasa casi todo el tiempo esperando una API externa no mejorará de forma proporcional al cambiar de procesador. Otro que compila código, analiza grandes tablas o crea miles de contenedores sí puede notar una diferencia considerable.
También importa la línea base. “X86” no identifica un único producto: abarca generaciones, configuraciones de memoria, límites térmicos y perfiles de energía diferentes. Para valorar una ventaja de 1,5 o 2,2 veces hay que conocer el modelo comparado, el consumo medido en la pared, la cantidad de memoria, el compilador, el sistema operativo y el precio del servidor completo.
El propio material técnico distingue entre resultados medidos y estimaciones. Algunas comparativas de rendimiento por núcleo utilizan estimaciones de SPEC CPU 2026. Las pruebas de socios se acercan más a cargas concretas, pero han sido seleccionadas para el lanzamiento. Hasta que haya análisis de laboratorios independientes y acceso general a sistemas equivalentes, las cifras deben leerse como afirmaciones del fabricante respaldadas por ensayos iniciales.
Impacto para empresas y desarrolladores
Para un equipo pequeño, la noticia no significa que deba comprar un servidor. La primera consecuencia práctica será indirecta: proveedores de nube y plataformas de inferencia podrían ofrecer instancias con Vera y trasladar parte de la mejora a tiempos de respuesta o precios. La decisión sensata es medir el coste por tarea completada, no el coste por hora ni los tokens por segundo de forma aislada.
Una prueba útil debería registrar al menos cinco métricas: latencia total de la tarea, percentil 95, número de tareas completadas por vatio, utilización de GPU y coste por resultado correcto. También conviene separar el tiempo del modelo, el de las herramientas y el de las dependencias externas. Sin esa instrumentación, una mejora aparente puede ocultar un cuello de botella distinto.
Los desarrolladores que crean aplicaciones con herramientas visuales también necesitan entender esta cadena, aunque no administren servidores. Nuestro análisis de un curso para crear aplicaciones de IA sin programar puede ayudar a situar la capa de producto; la infraestructura que ejecuta la aplicación sigue requiriendo decisiones sobre latencia, privacidad y coste.
En ámbitos como arquitectura y renderizado, el reparto entre CPU, GPU y nube es especialmente visible. La guía sobre Revit, BIM y renderizado en la nube muestra un caso comercial donde la utilidad depende de un flujo completo, no de un solo componente. Esa misma lógica sirve para evaluar los agentes: importa cuánto tarda y cuesta el proceso de principio a fin.
IA local frente a infraestructura de centro de datos
Vera está pensada para centros de datos, no para sustituir un portátil o una estación de trabajo. Ejecutar un modelo local ofrece control, privacidad y ausencia de dependencia de red, pero está limitado por memoria, potencia y refrigeración. Un sistema de centro de datos puede atender miles de entornos simultáneos y compartir aceleradores entre usuarios, a cambio de mayor complejidad y dependencia del proveedor.
La comparación correcta no es “local o nube” en abstracto, sino qué parte del flujo conviene colocar en cada sitio. Datos sensibles o tareas pequeñas pueden permanecer en el equipo; entrenamiento, renderizado o inferencia intensiva pueden ir a infraestructura remota. Si te interesa esa decisión, el artículo sobre IA local, memoria, privacidad y coste ofrece criterios complementarios.
Lo confirmado y lo que todavía es una previsión
Hechos publicados
- NVIDIA anunció Vera en mayo de 2026 y la presenta como una CPU de 88 núcleos Olympus orientada a agentes, aprendizaje por refuerzo y procesamiento de datos.
- La plataforma admite memoria LPDDR5X de gran ancho de banda y conexión coherente NVLink-C2C con GPU Rubin.
- El 5 de noviembre, NVIDIA publicó comparativas propias y resultados de socios en programación, orquestación, bases de datos y entornos aislados.
- Fabricantes como Dell, HPE, Lenovo y Supermicro han anunciado sistemas basados en Vera.
Predicciones que deben comprobarse
- Que la ventaja de velocidad se mantenga en todas las cargas, configuraciones y proveedores.
- Que el ahorro energético compense el precio de adquisición, la refrigeración y la migración de software.
- Que la arquitectura Arm no introduzca costes de compatibilidad relevantes en herramientas internas.
- Que una sola clase de CPU simplifique de verdad las flotas sin perder eficiencia en cargas especializadas.
Qué conviene comprobar antes de adoptar Vera
- Compatibilidad. Revisa imágenes de contenedor, bibliotecas nativas, extensiones y agentes compilados para Arm.
- Carga representativa. Prueba tus herramientas, bases de datos y entornos, no solo un benchmark sintético.
- Coste total. Incluye servidor, red, electricidad, refrigeración, soporte y tiempo de migración.
- Consumo real. Mide energía del sistema completo y no únicamente el TDP del procesador.
- Calidad del resultado. Una tarea más rápida no aporta valor si aumenta los fallos o reduce la precisión.
- Portabilidad. Mantén una ruta de salida para evitar que la aplicación dependa de una sola arquitectura o nube.
Conclusión
Vera pone el foco en una limitación que suele quedar eclipsada por las GPU: un agente es una cadena de razonamiento, datos, código y herramientas, y cada eslabón puede frenar el conjunto. Los 88 núcleos, el ancho de banda de memoria y la conexión coherente con Rubin forman una propuesta técnicamente coherente para reducir esas esperas.
La novedad no demuestra todavía que Vera sea la mejor opción para cualquier organización. Los resultados disponibles son prometedores, pero proceden de NVIDIA y de socios tempranos. La decisión debería esperar a precios comparables, pruebas independientes y mediciones con cargas reales. La pregunta útil no es cuántos núcleos tiene el servidor, sino cuántas tareas correctas completa, con qué latencia, consumo y coste total.
