Introducción
Cuando NVIDIA publicó su whitepaper técnico sobre la CPU Vera (basada en la arquitectura Olive con núcleos Olympus), incluyó benchmarks que comparaban su rendimiento contra AMD EPYC Turin (familia Genoa, 2024). Pero esas comparaciones iniciales usaban denominadores desiguales: 128 núcleos para EPYC 9755 (Turin) frente a 88 núcleos para Vera, lo que distorsionaba métricas como ancho de banda por núcleo o latencia. El problema no era solo técnico, sino de framing: un CPU de 2026 con memoria LPDDR5X-9600 se comparaba con uno de 2024 que usa DDR5-6400, pero con un conteo de núcleos inflado artificialmente.
Este artículo propone un marco normalizado para esas comparaciones, enfocado en equipos de DevOps e infraestructura que necesitan evaluar hardware para cargas de trabajo híbridas (AI/ML, contenedores, bases de datos). Cubriremos métricas clave como ancho de banda de memoria, latencia inter-núcleo y el impacto del Simultaneous Multithreading (SMT), con ejemplos prácticos para ajustar benchmarks y evitar sesgos en evaluaciones de proveedores.
Qué ocurrió
1. La comparación inicial de NVIDIA: un sesgo estructural
En el whitepaper de Vera (2025), NVIDIA presentó un gráfico donde Vera superaba a Turin en ancho de banda por núcleo (12.7 GB/s vs. 3.1 GB/s). El truco: dividió el ancho de banda total de EPYC 9755 (0.6 TB/s con 12 canales DDR5-6400) por 128 núcleos (su SKU tope), mientras que Vera (88 núcleos) usaba un denominador más pequeño. Pero incluso ajustando a 96 núcleos (EPYC 9655), la comparación seguía favoreciendo a Vera porque:
- Numerador desactualizado: Turin usa DDR5-6400 (2024), mientras que Vera usa LPDDR5X-9600 (2026).
- Denominador inflado: EPYC 9755 tiene 128 núcleos, pero el CCX (Core Complex) máximo es de 8 núcleos. Los 128 núcleos en realidad son 16 CCDs de 8 núcleos cada uno, con latencias intra-CCD vs. inter-CCD.
2. El engaño de la latencia «por núcleo»
NVIDIA mostró un heatmap de latencia inter-núcleo donde Vera aparecía en verde (baja latencia) y Turin en rojo (alta latencia). La explicación técnica:
- Chiplets vs. monolítico: Los EPYC Turin usan múltiples CCDs conectados por Infinity Fabric, lo que añade hops (saltos de comunicación) entre núcleos en diferentes CCDs.
- Pero… ¿importa? Para cargas de trabajo típicas de AI/ML (VMs, contenedores, micro-servicios), los núcleos suelen ejecutarse en un solo CCX (8 núcleos máximo). Incluso en cargas de 4 núcleos, un scheduler moderno (como el de Kubernetes o Docker) los agrupa en el mismo CCX. La latencia solo importa si:
– Usas cargas highly threaded que requieren comunicación inter-CCX (ej.: bases de datos distribuidas como Cassandra).
3. El mito del SMT: ¿»por núcleo» o «por hilo»?
NVIDIA y otros vendedores suelen publicar benchmarks usando «por núcleo» para CPUs con SMT (como Zen 5 de AMD o Golden Cove de Intel). Pero esto es engañoso:
| Arquitectura | Cores | Threads por core | Boost SMT (%) | Notas |
|---|---|---|---|---|
| Intel Skylake | 1 | 2 | +12% | Mitigaciones activas |
| Intel Sapphire R. | 1 | 2 | +23-25% | AVX-512 afectado |
| AMD Zen 5 | 1 | 2 | +29-32% | Latencia en L3 mitigada |
| AMD Zen 5c | 1 | 1 | +30% | Menos L3, más latencia |
Si un benchmark muestra «1.0 ops/núcleo» en Vera con SMT activado, en realidad es:
- 1.3 ops/núcleo (con SMT).
- 0.65 ops/hilo (sin SMT).
Para comparaciones justas, deberías usar:
- Sin SMT:
taskset -c 0-<N> ./benchmark(limita a un hilo por núcleo). - Con SMT:
taskset -c 0-<2N> ./benchmark(usa ambos hilos).
Impacto para DevOps / Infraestructura / Cloud
1. Decisiones de arquitectura: ¿monolítico o chiplet?
| Escenario | Recomendación | Herramienta para validar |
|---|---|---|
| Micro-servicios (K8s) | EPYC Turin (mejor SMT, menor latencia intra-CCX) |
