Tu canal CI está lento, tu host de VM tiene jitter, los renders de Blender se extienden hasta mañana, y tu “máquina de IA” está inexplicablemente limitada por algo que no es la GPU.
La elección de CPU que hiciste hace dos trimestres ahora es un punto en tus informes de incidentes.
Intel vs AMD no es una guerra de fans. Es un conjunto de compensaciones que se manifiestan como minutos de build, ratios de consolidación de VMs, tormentas de fallos de caché, límites de potencia y “¿por qué este hilo está en el E-core?”.
Tomemos la decisión como adultos que han sido llamados a las 3 a.m.
Qué significa realmente “trabajo real”
“Trabajo real” no es un único benchmark. Es un montón de cuellos de botella que rotan según la hora:
el enlazador convierte tu CPU en un generador de fallos de caché; un render lo convierte en una máquina de calor;
la virtualización lo convierte en un problema de planificación; la IA lo convierte en un alimentador de memoria.
Entonces la pregunta no es “¿cuál es más rápido?” Es:
¿qué CPU hace que tu carga de trabajo sea estable, predecible y rentable bajo carga sostenida? —y cuál crea modos de fallo por los que pasarás fines de semana.
Qué deberías optimizar
- Tiempo hasta resultado: tiempo de compilación en reloj de pared, tiempo de render, rendimiento de entrenamiento o latencia de solicitudes.
- Latencia de cola bajo contención: el 1% más lento es lo que rompe despliegues y SLOs.
- Determinismo: relojes estables y un comportamiento de planificación predecible importan más que el pico de boost en un laboratorio.
- Subsistema de memoria: ancho de banda, latencia, número de canales y topología NUMA a menudo deciden el ganador.
- E/S y PCIe: GPUs, NVMe, NICs y passthrough son decisiones de plataforma, no decisiones de número de núcleos de CPU.
- Realidad de potencia y refrigeración: tu rack no se preocupa por lo que diga el PDF de marketing.
Posicionamiento rápido: quién gana qué
Puedes discutir casos límite para siempre. En producción, la mayoría de las decisiones se reducen a “¿necesitamos muchas líneas de memoria y rendimiento estable?” vs “¿necesitamos la mejor latencia por hilo?” vs “¿necesitamos el comportamiento de plataforma más simple?”.
Compilar grandes bases de código (kernel de Linux, Chromium, LLVM, motores de juego)
- AMD suele ganar por rendimiento por dólar cuando puedes alimentar muchos núcleos con suficiente memoria e I/O de almacenamiento.
- Intel suele ganar en latencia por núcleo y a veces tiene ventajas en toolchains o bibliotecas específicas, pero la planificación con núcleos híbridos puede complicar runners CI.
- Regla de decisión: si tus builds son paralelos y amigables con la caché, los núcleos ayudan; si están dominados por enlaces y latencia de memoria, las frecuencias y comportamiento de caché dominan.
Renderizado (Blender, Arnold, V-Ray, pipelines offline)
- Ambos ganan cuando pueden sostener la potencia. La CPU que mantiene frecuencias al 100% de carga en tu chasis gana, no la que tiene el número más alto de “hasta”.
- El alto recuento de núcleos de AMD puede ser brutal en granjas de render; Intel puede competir con buen comportamiento en todos los núcleos y ciertas características AVX.
- Regla de decisión: compra por la frecuencia sostenida con todos los núcleos dentro de tu envolvente térmica y presupuesto de potencia.
Hosts de VM (KVM/Proxmox/VMware, cargas mixtas)
- AMD EPYC es con frecuencia la elección pragmática para densidad: muchos núcleos, muchos canales de memoria, muchas líneas PCIe, buen perf/W.
- Intel Xeon puede destacar por la madurez de plataforma, ciertos ecosistemas de aceleradores y a veces mejor rendimiento por hilo para tareas de plano de control “ruidosas”.
- Regla de decisión: prioriza capacidad/ancho de banda de memoria y presupuesto de líneas PCIe sobre turbo de núcleos crudo.
IA (entrenamiento e inferencia, respaldada por GPU pero la CPU no es irrelevante)
- La CPU alimenta a la GPU: preprocesado de datos, tokenización, pipeline de entrada, compresión/descompresión, redes y sistema de archivos recaen en la CPU.
- AMD suele ganar en canales de memoria y líneas en servidores, lo que ayuda a mantener ocupadas las GPUs; Intel a veces gana por instrucciones vectoriales específicas y ajuste de bibliotecas en stacks concretos.
- Regla de decisión: si tus GPUs esperan, compra la CPU/memoria/I/O que deje de hacerlas esperar.
Hechos e historia que todavía importan
- x86-64 provino de AMD (AMD64). Intel lo adoptó después, y la industria siguió porque fue la migración menos dolorosa.
- La era “tick-tock” de Intel entrenó a compradores a esperar reducciones de proceso predecibles; cuando ese ritmo se rompió, la estabilidad de plataforma se volvió un diferenciador mayor que la frecuencia cruda.
- Los diseños chiplet se hicieron mainstream con AMD, permitiendo altos recuentos de núcleos y I/O flexible; esto cambió la curva de “más núcleos cuesta más”.
- NUMA nunca desapareció. Los diseños multi-die hacen de la localidad de memoria una característica de primer orden, no un detalle académico.
- AVX-512 se volvió una telenovela de compatibilidad: potente en algunas piezas Intel, ausente o diferente en otras, y en general algo que deberías tratar como “agradable si lo tienes”, no como un plan.
- Las mitigaciones de Spectre/Meltdown enseñaron que las características microarquitectónicas pueden convertirse en pasivos de seguridad con impacto en rendimiento.
- Los núcleos híbridos de Intel trajeron la complejidad de planificación estilo portátil a escritorios/servidores; puede ser genial, pero también es una nueva clase de tickets “¿por qué esto es lento?”.
- Los presupuestos de líneas PCIe han sido un diferenciador silencioso en plataformas workstation/servidor; deciden si puedes ejecutar múltiples GPUs, NVMe rápidas y NICs de alta velocidad sin compromisos.
Compilación: rendimiento, latencia y caché
Compilar es una carga cruel porque parece limitada por CPU hasta que la instrumentas.
Entonces descubres que tu CPU cara está esperando lecturas pequeñas, fallos de page cache, resolución de símbolos o una fase single-threaded en el enlazador.
Qué realmente hace rápidas las compilaciones
- Almacenamiento rápido para código fuente y artefactos (NVMe, suficientes IOPS, no un filesystem de red compartido que tenga un mal día).
- Suficiente RAM para mantener headers, archivos objeto y conjuntos de trabajo del compilador calientes.
- Fuerte rendimiento por hilo para fases seriales (pasos de configure, enlazadores, cuellos de botella de codegen).
- Muchos núcleos para compilación paralela, pero solo si puedes alimentarlos sin thrash de I/O.
- Caché y latencia de memoria porque el front-end del compilador hace mucho puntero- chasing.
Intel vs AMD: patrones de compilación
En la práctica, el “más núcleos por el dinero” de AMD a menudo gana para builds grandes cuando tu sistema de build paraleliza bien.
Intel suele sentirse más ágil para desarrollo interactivo y ciertas fases single-thread, especialmente si las frecuencias se mantienen altas bajo carga.
La trampa: comprar alto recuento de núcleos y luego compilar en un runner con un disco RAM pequeño, SSD lento o un filesystem compartido sobrecargado.
Así es como terminas con 64 núcleos y un build que funciona como si lo movieran hámsters.
Broma #1: Un servidor de build con RAM insuficiente es como una cafetera sin agua—técnicamente impresionante, prácticamente una escena del crimen.
Núcleos híbridos y runners CI
Los diseños de núcleos híbridos de Intel pueden ser excelentes, pero los sistemas CI y las herramientas de build no siempre son corteses sobre dónde aterrizan los hilos.
Si tus hilos de compilación pesados rebotan a núcleos de eficiencia, el tiempo de reloj de pared y la varianza pueden dispararse.
La solución rara vez es “comprar CPUs diferentes” y más a menudo “fijar afinidad, aislar y medir”.
Renderizado: núcleos, frecuencias y potencia sostenida
El renderizado es honesto. Toma la CPU que compraste y la convierte en calor por horas.
La cifra de “boost clock” es principalmente marketing a menos que tu refrigeración y entrega de potencia sean reales.
Qué importa para el renderizado por CPU
- Frecuencia sostenida con todos los núcleos a temperaturas seguras, no el pico de boost single-core.
- Recuento de núcleos para cargas de render embarazosamente paralelas.
- Ancho de banda de memoria para la complejidad de escena y cargas pesadas de texturas (varía según el renderer).
- Estabilidad bajo cargas AVX/vectoriales. Algunas rutas de código reducen frecuencias significativamente bajo instrucciones vectoriales pesadas.
Intel vs AMD: realidad del renderizado
Si construyes una granja de render, la densidad de núcleos de AMD históricamente ha sido atractiva, especialmente cuando va acompañada de configuraciones de memoria sensatas.
Intel puede absolutamente ganar en ventanas de precio/rendimiento específicas y en casos donde el renderer se beneficia de ciertas mezclas de instrucciones o comportamiento de planificación.
Pero el factor decisivo suele ser operativo: límites de potencia, refrigeración de rack y si tu plataforma hace throttling.
El renderizado también convierte la “eficiencia” en una línea presupuestaria. Menos vatios por frame significa más nodos por rack y menos correos enfadados de instalaciones.
VMs y contenedores: NUMA, IOMMU y vecinos ruidosos
La virtualización es donde las CPUs dejan de ser “chips” y se vuelven sistemas. Estás comprando ahora topología: canales de memoria, líneas PCIe, enrutamiento de interrupciones, comportamiento de IOMMU y amabilidad del scheduler.
Por qué AMD suele verse bien para hosts de VM
- Densidad de núcleos ayuda a la consolidación cuando tienes muchas VMs medianas.
- Canales de memoria importan para el rendimiento agregado y para evitar penalizaciones de acceso NUMA remoto.
- Líneas PCIe importan para pools NVMe, NICs y passthrough de GPU sin compromisos.
Por qué Intel puede ser la opción empresarial más segura a veces
- Consistencia de plataforma a través de generaciones en algunas flotas, lo que reduce la varianza operativa.
- Alineación del ecosistema con ciertos proveedores, herramientas de firmware y stacks de drivers.
- Fuerte rendimiento single-thread para servicios de plano de control y cargas mixtas sensibles a latencia.
NUMA: el impuesto invisible
Los problemas NUMA parecen “mi VM es lenta a veces”. El host muestra mucha CPU. El disco parece bien. La red parece bien.
Entonces te das cuenta de que la mitad de los accesos a memoria son remotos.
Multi-socket Intel y AMD, e incluso algunos diseños single-socket chiplet, pueden morderte aquí. La solución es predecible:
alinea la colocación de vCPU y memoria, evita asignaciones cruzadas entre nodos y deja de fingir que “un CPU grande” es una cosa real.
Passthrough PCI y peculiaridades de IOMMU
Para passthrough de GPU o passthrough de NICs de alta velocidad, los agrupamientos IOMMU y las configuraciones de firmware importan más que la marca.
Quieres una placa base/BIOS que se comporte como una herramienta, no como una caja de puzles.
Cargas de IA: la CPU importa más de lo que quieres admitir
Si ejecutas entrenamiento en GPU y piensas “la CPU no importa”, probablemente nunca hayas visto una GPU de 10k$ inactiva porque un hilo del dataloader está bloqueado en descompresión.
Dónde las CPUs limitan sistemas de IA
- Pipeline de entrada: decodificar imágenes, parsear registros, tokenizar, aumentación.
- Almacenamiento y sistema de archivos: lecturas pequeñas, operaciones de metadatos, comportamiento de caché.
- Redes: mover datos a entrenamiento multinodo o capas de serving.
- Matemáticas del lado CPU: preprocesado de embeddings, ingeniería de características, post-procesado.
- Sobrehead de orquestación: runtime de Python, contención de hilos, overhead de contenedores, interrupciones.
Intel vs AMD para máquinas IA
Si construyes servidores GPU, la historia de lanes y memoria de AMD puede ser una victoria clara: más espacio para GPUs y NVMe sin juegos de manos con PCIe.
Intel puede ser excelente cuando tu stack está afinado alrededor de ciertas bibliotecas, cuando necesitas fuerte single-thread para impulsar inferencia de alta QPS, o cuando la solución de tu vendor lo asume.
La mejor métrica práctica no es “puntuación de benchmark de CPU”, es utilización de GPU a lo largo del tiempo y rendimiento de extremo a extremo.
Si tus GPUs no están ocupadas, la elección de CPU/plataforma puede ser la razón.
Compromisos de plataforma: memoria, PCIe, potencia y lo que lamentarás luego
Canales de memoria y capacidad
Para VMs e IA, la capacidad y el ancho de banda de memoria suelen ser el verdadero techo.
Una CPU con “menos núcleos más rápidos” puede perder feo frente a una CPU con “más canales de memoria y suficientes núcleos” cuando la carga es alimentada por memoria.
Si sub-provisionas memoria, terminarás optimizando cosas que no deberían necesitar optimización: controles agresivos de swapping, trucos de caché de sistema de archivos y límites raros de servicios.
No es ingenioso. Es control de daños.
Líneas y topología PCIe
Multi-GPU, pools NVMe RAID/ZFS y NICs 100GbE consumen muchas líneas.
Si compras una plataforma que no puede cablearlas limpiamente, pasarás tiempo depurando por qué una tarjeta está atrapada en x4 o por qué dos dispositivos comparten ancho de banda.
Límites de potencia: la diferencia entre “benchmark” y “martes”
El rendimiento de la CPU es cada vez más “cuánto tiempo puedes mantener las frecuencias antes de que la plataforma se rinda”.
Vigila los ajustes BIOS por defecto que empujan límites de potencia para triunfos de marketing, y luego hacen throttling en cargas reales.
O peor: funcionan tan calientes que reducen la vida útil y aumentan la tasa de errores. Ese es un impuesto de fiabilidad disfrazado de rendimiento.
La fiabilidad es una característica, no una vibra
Aquí tienes una cita, porque es el trabajo:
“La esperanza no es una estrategia.”
— General Gordon R. Sullivan
Aplicado a CPUs: no esperes que tu scheduler haga lo correcto, espera que los valores por defecto del BIOS sean sensatos, espera que tu refrigeración sea suficiente, espera que la disposición NUMA no importe.
Mide, configura y valida.
Tareas prácticas: comandos, salidas y decisiones
No eliges Intel o AMD por sensaciones. Eliges basándote en lo que muestran tus sistemas bajo carga.
A continuación hay tareas concretas que puedes ejecutar en hosts Linux para diagnosticar y decidir.
Tarea 1: Identificar topología de CPU (núcleos, hilos, NUMA)
cr0x@server:~$ lscpu
Architecture: x86_64
CPU(s): 64
Thread(s) per core: 2
Core(s) per socket: 32
Socket(s): 1
NUMA node(s): 2
NUMA node0 CPU(s): 0-31
NUMA node1 CPU(s): 32-63
Qué significa: un socket, pero dos nodos NUMA (común con chiplets). El acceso a memoria entre nodos puede costarte.
Decisión: para pinning de VM o trabajos de render, mantén las asignaciones de CPU y memoria dentro de un nodo NUMA cuando sea posible (o al menos prueba ambas maneras).
Tarea 2: Verificar escalado de frecuencia y governor
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
Qué significa: el governor está puesto en performance, típicamente bueno para granjas de compilación y latencia.
Decisión: si ves powersave en un servidor que hace builds/renders, espera resultados más lentos y con picos; cambia el governor o establece la política BIOS/OS en consecuencia.
Tarea 3: Vigilar throttling en tiempo real y térmicas
cr0x@server:~$ sudo turbostat --Summary --quiet --interval 5
Avg_MHz Busy% Bzy_MHz TSC_MHz PkgTmp PkgWatt
4050 92.10 4395 3600 86 215.3
Qué significa: la CPU está ocupada, la temperatura del paquete es alta y el consumo de potencia es sustancial. Si Avg_MHz o Bzy_MHz colapsa con el tiempo, estás con throttling.
Decisión: si las MHz sostenidas caen durante renders, arregla refrigeración/límites de potencia antes de comprar una CPU “más rápida”.
Tarea 4: Confirmar microcode y mitigaciones del kernel
cr0x@server:~$ dmesg | egrep -i 'microcode|spectre|meltdown' | tail -n 6
[ 0.231] microcode: updated early: 0x2f -> 0x35, date = 2024-02-12
[ 0.873] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
[ 0.873] Spectre V2 : Mitigation: Retpolines; IBPB: conditional; STIBP: always-on; RSB filling
[ 0.873] Meltdown : Mitigation: PTI
Qué significa: estás pagando algún impuesto de rendimiento por mitigaciones de seguridad, y tienes microcode reciente.
Decisión: si una carga regresó después de actualizaciones, mide el coste; no reviertas seguridad a ciegas—considera planificación de renovación de hardware si el impuesto es inaceptable.
Tarea 5: Medir rendimiento de compilación con un build reproducible
cr0x@server:~$ /usr/bin/time -v make -j$(nproc)
...
Elapsed (wall clock) time (h:mm:ss or m:ss): 6:42.11
User time (seconds): 24012.55
System time (seconds): 1120.33
Percent of CPU this job got: 620%
Maximum resident set size (kbytes): 25100432
Qué significa: la utilización de CPU no está cerca de 6400% en una máquina de 64 hilos; estás dejando núcleos ociosos—a menudo por I/O o contención de memoria.
Decisión: si CPU% es baja, deja de comprar núcleos y empieza a arreglar I/O (NVMe, tmpfs para directorio de build, mejor ccache, más RAM).
Tarea 6: Detectar espera de I/O durante builds o entrenamiento
cr0x@server:~$ iostat -xz 2 3
avg-cpu: %user %nice %system %iowait %steal %idle
38.22 0.00 7.10 24.55 0.00 30.13
Device r/s w/s rkB/s wkB/s await svctm %util
nvme0n1 120.0 210.0 9800.0 18200.0 8.40 0.32 10.5
Qué significa: %iowait es alto; la CPU está esperando almacenamiento.
Decisión: si iowait domina, la marca de CPU es irrelevante—arregla la localidad de almacenamiento, problemas de profundidad de cola, filesystem, o mueve artefactos de build fuera de volúmenes congestionados.
Tarea 7: Comprobar presión de memoria e intercambio
cr0x@server:~$ vmstat 2 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
12 0 0 184320 10240 8123456 0 0 120 240 6200 9800 55 8 30 7 0
18 2 524288 20480 11000 620000 0 4096 150 1200 7500 15000 48 12 20 20 0
Qué significa: picos de swap-out (so) y wa se incrementa. Estás paginando.
Decisión: más núcleos no ayudarán; añade RAM, reduce la paralelización o arregla procesos fuera de control. Para hosts de VM, también es señal de overcommit de memoria descontrolado.
Tarea 8: Confirmar localidad NUMA de memoria para un proceso
cr0x@server:~$ numastat -p 12345
Per-node process memory usage (in MBs) for PID 12345 (renderd)
Node 0 18240.12
Node 1 1120.55
Total 19360.67
Qué significa: el proceso está usando mayormente memoria del Nodo 0. Buena localidad si sus hilos están en Nodo 0.
Decisión: si la memoria está dividida pero los hilos no, fija afinidad con numactl o ajusta vNUMA de la VM; el tráfico cross-NUMA puede arruinar rendimiento de render y VM.
Tarea 9: Validar extensiones de virtualización y IOMMU
cr0x@server:~$ egrep -m1 -o 'vmx|svm' /proc/cpuinfo
svm
cr0x@server:~$ dmesg | egrep -i 'iommu|dmar|amd-vi' | head
[ 0.612] AMD-Vi: IOMMU performance counters supported
[ 0.613] AMD-Vi: Interrupt remapping enabled
Qué significa: la virtualización por hardware está presente (svm para AMD, vmx para Intel) y IOMMU está activo.
Decisión: si IOMMU está apagado, el passthrough PCI será doloroso o imposible; arregla BIOS y parámetros del kernel antes de culpar a la elección de CPU.
Tarea 10: Inspeccionar host KVM/QEMU por steal time y contención
cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.6.0 (server) 01/10/2026 _x86_64_ (64 CPU)
12:00:01 AM CPU %usr %nice %sys %iowait %irq %soft %steal %idle
12:00:02 AM all 62.0 0.0 7.5 1.0 0.0 0.5 0.0 29.0
Qué significa: bajo iowait y sin steal en el host; bien. En los guests, el steal es la canaria para sobre-suscripción.
Decisión: si los guests muestran alto steal, reduce overcommit, reserva núcleos para servicios ruidosos o separa VMs sensibles a latencia.
Tarea 11: Comprobar ancho y velocidad de enlace PCIe (GPU/NVMe)
cr0x@server:~$ sudo lspci -s 65:00.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s, Width x16
Qué significa: la GPU está funcionando a ancho y velocidad completos de enlace.
Decisión: si ves x8 o menor inesperadamente, revisa cableado de slot, bifurcación o compartición de líneas. Esto es una “elección de plataforma” que te está mordiendo, no rendimiento bruto de CPU.
Tarea 12: Verificar huge pages y backing de memoria para VMs
cr0x@server:~$ grep -i huge /proc/meminfo | head
AnonHugePages: 12582912 kB
HugePages_Total: 2048
HugePages_Free: 1024
Hugepagesize: 2048 kB
Qué significa: las huge pages están configuradas y parcialmente libres.
Decisión: para VMs de alto rendimiento (bases de datos, NFV), las huge pages pueden reducir la presión TLB. Si tus hosts fragmentan y las huge pages no están disponibles, planea asignación en el arranque y ventanas de mantenimiento.
Tarea 13: Detectar rarezas del scheduler con núcleos híbridos (Intel)
cr0x@server:~$ ps -eo pid,comm,psr,pri,ni,cls --sort=-pri | head
PID COMMAND PSR PRI NI CLS
9421 clang++ 11 139 - TS
9418 clang 37 139 - TS
9416 ld 2 139 - TS
Qué significa: los procesos se ejecutan en IDs de CPU específicos (PSR).
Decisión: si hilos críticos siguen aterrizando en núcleos más lentos (a menudo observable como ciertos rangos de CPU), establece afinidad de CPU para agentes de build o usa cpuset/particionamiento de cgroups.
Tarea 14: Determinar si la GPU está siendo desabastecida (entrenamiento IA)
cr0x@server:~$ nvidia-smi dmon -s pucm -d 2 -c 3
# gpu pwr sm mem enc dec mclk pclk
# Idx W % % % % MHz MHz
0 95 42 18 0 0 8101 1410
0 96 39 17 0 0 8101 1410
0 92 44 19 0 0 8101 1410
Qué significa: la utilización de SM está rondando ~40%. Si tu modelo debería saturar la GPU, probablemente estés limitado por entrada o CPU.
Decisión: perfila el uso de CPU del dataloader, el throughput de almacenamiento y redes; considera más núcleos CPU, almacenamiento más rápido o mejor paralelismo en preprocesado antes de comprar más GPUs.
Guion rápido de diagnóstico
Cuando el rendimiento es malo, no empieces con “Intel vs AMD.” Empieza con el cuello de botella. Aquí está el orden de triaje que ahorra tiempo y dignidad.
Primero: confirma que el sistema no te está mintiendo
- Revisa throttling (térmico/potencia): ¿colapsa la frecuencia bajo carga sostenida?
- Revisa governor/política de energía: ¿estás atascado en
powersaveo en un modo eco agresivo? - Revisa microcode/regresiones BIOS: ¿una actualización reciente cambió el comportamiento?
Segundo: clasifica el cuello de botella en 60 segundos
- CPU-bound: CPU de usuario alto, iowait bajo, frecuencias estables.
- I/O-bound: iowait alto, latencia/await de almacenamiento aumenta, CPU% bajo para el trabajo.
- Memory-bound: fallos de caché altos (si lo mides), fallos de página frecuentes o acceso NUMA remoto.
- Scheduler-bound: colas runnables altas, context switches enormes, hilos migrando, picos en latencia de cola.
Tercero: mapea a la categoría de solución correcta
- Si está limitado por CPU: más núcleos (rendimiento) o núcleos más rápidos (latencia); considera optimizaciones ISA/biblioteca.
- Si está limitado por memoria: más canales, mayor velocidad de memoria, mejor colocación NUMA; reduce tráfico entre nodos.
- Si está limitado por I/O: NVMe local para scratch, ajuste de filesystem, caching, evita FS remotos para artefactos calientes.
- Si está limitado por el scheduler: aisla núcleos, fija afinidad, ajusta cgroups, reduce interferencia de vecinos ruidosos.
Tres micro-historias corporativas desde las trincheras
Micro-historia 1: El incidente causado por una suposición equivocada (NUMA “no importa”)
Una empresa SaaS mediana migró su clúster de virtualización primario. Los hosts antiguos eran modestos: menos núcleos, comportamiento de un solo nodo NUMA y rendimiento “suficiente”.
Los nuevos hosts eran bestias—más núcleos, memoria más rápida, mejor todo—en papel.
En una semana, el canal de incidentes se llenó. Algunas VMs de base de datos tenían picos de latencia durante trabajos de fondo rutinarios.
No siempre, no de forma predecible. Las gráficas de uso de CPU parecían bien. La latencia de almacenamiento parecía bien. La red era aburrida.
La rotación on-call desarrolló una superstición: “no desplegar después de comer”.
La suposición equivocada fue simple: “un socket equivale a memoria uniforme”. La nueva plataforma expuso dos nodos NUMA, y el hipervisor colocaba vCPUs en un nodo mientras las asignaciones de memoria derivaban al otro bajo presión.
El acceso remoto a memoria se convirtió en “jitter aleatorio”, y el jitter se convirtió en latencia de cola.
La solución no fue exótica. Ajustaron vNUMA de las VMs, fijaron las VMs más sensibles a un conjunto de CPU alineado por nodo y dejaron de sobreasignar RAM en esos hosts.
El rendimiento se estabilizó de inmediato. No hubo heroísmos, solo conciencia de topología.
La lección: Intel o AMD no causaron ese incidente. La creencia de que la topología es opcional sí lo hizo.
Micro-historia 2: La optimización que salió mal (tuning de potencia agresivo)
Un estudio creativo ejecutaba nodos de render por CPU durante la noche y quería reducir costes de energía. Alguien se volvió ambicioso y aplicó topes de potencia agresivos en BIOS a toda la flota.
La “prueba rápida” fue un render corto que terminó bien, así que el cambio se desplegó.
Un mes después, los plazos empezaron a retrasarse. Los renders nocturnos no terminaban. La cola se acumuló.
El estudio culpó a la nueva versión del renderer, luego al almacenamiento, luego a “actualizaciones de Windows” porque esa es la tradición.
El problema real: cargas sostenidas con topes nuevos de potencia hicieron que las CPUs se quedaran con frecuencias mucho más bajas que antes.
La prueba corta no lo reveló porque vivía en la ventana de turbo; los renders en producción vivían en la realidad térmica de estado estable.
Peor aún, las frecuencias más bajas aumentaron el tiempo de render lo suficiente como para que los nodos funcionaran más tiempo—el consumo energético total no bajó como se esperaba, y el backlog creó estrés operativo.
Revirtieron a límites sensatos y luego reintrodujeron topes con mediciones en ejecuciones largas y un ajuste por nodo.
La lección: puedes optimizar por vatios, pero debes medir en cargas de estado estable. El turbo es un mentiroso con buenos modales.
Micro-historia 3: La práctica aburrida pero correcta que salvó el día (hosts baseline + canario)
Una compañía financiera ejecutaba cargas mixtas: builds CI, VMs internas y algunos servicios de inferencia. Querían probar una nueva generación de CPU.
Hicieron lo raro: construyeron dos hosts canario con RAM, almacenamiento, ajustes BIOS y versiones de kernel idénticas, y los ejecutaron en paralelo con carga de producción por semanas.
Durante la prueba, una actualización de kernel introdujo un cambio de scheduler que incrementó ligeramente el jitter en una arquitectura para ciertos servicios sensibles a latencia.
No fue catastrófico, pero fue visible en la latencia de cola.
Porque tenían baseline y canario, lo detectaron temprano, lo correlacionaron con la ventana de actualización y retuvieron esa versión de kernel en producción.
No hubo incidentes. No hubo sala de crisis. Solo una tranquila decisión de “hoy no”.
La lección: la herramienta de rendimiento más efectiva es un experimento controlado. También es lo menos glamuroso en la sala, así que la gente lo olvida.
Errores comunes: síntomas → causa raíz → solución
1) Los builds son más lentos después de “actualizar” a más núcleos
Síntomas: el tiempo de build en reloj de pared apenas mejora; uso de CPU bajo; picos de iowait.
Causa raíz: almacenamiento y page cache no pueden alimentar la compilación paralela; escaneo de headers y escrituras de objetos saturan IOPS.
Solución: coloca el directorio de build en NVMe local, aumenta RAM, habilita/tamaño de ccache, reduce -j a un valor que no thrashée y evita filesystems compartidos para artefactos calientes.
2) Jitter de latencia en VM que parece “aleatorio”
Síntomas: picos periódicos en latencia de guest; CPU del host parece subutilizada; sin problema de I/O obvio.
Causa raíz: desalineación NUMA o ballooning de memoria causando acceso remoto a memoria; overcommit causando steal time.
Solución: configura vNUMA, fija vCPUs, vincula memoria, reduce overcommit para VMs sensibles y valida con numastat y métricas de steal en guest.
3) Nodos de render benchmarkean bien pero rinden mal en producción
Síntomas: pruebas cortas son rápidas; renders largos se ralentizan; temperaturas altas; frecuencias bajan.
Causa raíz: throttling térmico/eléctrico, expectativas irreales de boost o rutas AVX pesadas que reducen frecuencias.
Solución: mide frecuencia sostenida, mejora refrigeración, establece límites de potencia sensatos y valida con un render largo de estado estable.
4) Utilización de GPU baja en entrenamiento/inferencia
Síntomas: GPUs ociosas; núcleos CPU ocupados; aparece iowait de disco o esperas de red.
Causa raíz: pipeline de entrada está limitado por CPU o almacenamiento; pocos workers de dataloader; descompresión lenta; latencia de FS remota.
Solución: aumenta paralelismo del dataloader con cuidado, mueve datasets a NVMe local, pre-decodifica/empaqueta datos y monitoriza throughput de extremo a extremo en vez de tiempo solo del modelo.
5) “Mismo servidor, rendimiento diferente”
Síntomas: hosts SKU idéntico se comportan diferente; uno es más lento o con más picos.
Causa raíz: defaults BIOS difieren (potencia, interleaving de memoria, SMT), versiones de microcode difieren, o un host está en desventaja térmica.
Solución: estandariza ajustes de firmware, fija versiones, valida con una carga baseline y trata el BIOS como gestión de configuración, no como folklore.
6) Servicios con muchos hilos regresan en CPUs híbridas
Síntomas: mayor latencia de cola; tiempos de respuesta impredecibles; la CPU parece “no tan ocupada”.
Causa raíz: el scheduler coloca hilos críticos en núcleos más lentos o migra con demasiada agresividad; rendimiento mixto de núcleos crea varianza.
Solución: aisla núcleos de rendimiento para servicios críticos, usa cgroups/cpuset y valida con métricas por núcleo; evita depender de valores por defecto.
Broma #2: Si tu plan de rendimiento es “simplemente autoscalaremos”, felicitaciones—has inventado una disculpa muy cara.
Listas de verificación / plan paso a paso
Paso a paso: elegir Intel vs AMD para una nueva workstation (compilación + render + VMs ocasionales)
- Escribe la carga dominante en horas/semana: compilación, render, VMs, preprocesado IA.
- Elige la clase de cuello de botella: sensible a latencia (single-thread), throughput (todos los núcleos), ancho de banda de memoria o intensivo en I/O.
- Fija un objetivo de RAM: 64–128GB para builds/renders multi-proyecto serios; más si ejecutas múltiples VMs.
- Planifica almacenamiento: un NVMe para OS, uno para scratch/build/cache, opcionalmente otro para datasets/proyectos.
- Decide estrategia de núcleos:
- Si compilas grandes bases de código todo el día: nucleo lean + caché + suficiente RAM y scratch rápido.
- Si el render es primario: prioriza rendimiento sostenido con todos los núcleos y refrigeración.
- Valida lanes de plataforma: necesidades de GPUs + NVMe + NIC. No compres una plataforma que te obligue a compromisos que ya sabes que necesitas.
- Ejecuta un benchmark canario en un repositorio/escena representativa antes de comprar 20 máquinas.
Paso a paso: elegir CPU para host de virtualización (edición “no me paguen de noche”)
- Inventario de perfiles de VM: CPU por VM, RAM por VM, IOPS de almacenamiento por VM y si haces passthrough.
- Decide la política de overcommit por adelantado: overcommit de CPU quizá; overcommit de memoria solo con un plan y monitorización.
- Dimensiona canales y capacidad de memoria antes del recuento de núcleos. Memoria hambrienta vuelve decorativos a los núcleos.
- Modela comportamiento NUMA: planifica colocación alineada por nodo para VMs grandes; evita abarcar nodos a menos que debas.
- Confirma margen de líneas PCIe: NICs, NVMe, HBAs, GPUs. La falta de lanes es un arrepentimiento permanente.
- Estandariza BIOS y microcode: trátalo como configuración de flota; mantén un perfil conocido y bueno.
- Planifica observabilidad: contadores perf por host, steal en guests y latencia de almacenamiento.
Paso a paso: selección de CPU/plataforma para servidor IA (centrado en GPU, pero no ciego a la CPU)
- Empieza por las GPUs: cuenta, generación PCIe, potencia y refrigeración.
- Retrocede hacia las necesidades CPU: ¿puedes alimentar esas GPUs? Considera CPU del dataloader, compresión y redes.
- Prioriza ancho de banda de memoria: suficientes canales y velocidad para preprocesado y trabajo del lado host.
- Prioriza I/O: NVMe local para datasets, suficientes líneas y una NIC real si haces entrenamiento distribuido.
- Mide la utilización de GPU temprano con un pipeline realista; no aceptes “entrena” como condición de aprobado.
Preguntas frecuentes
1) Para servidores de compilación, ¿es mejor comprar más núcleos o núcleos más rápidos?
Si tus builds paralelizan bien y tu almacenamiento/RAM puede seguirles el ritmo, más núcleos ganan. Si el tiempo de enlace o pasos seriales dominan, ganan núcleos más rápidos.
Mide la utilización de CPU durante builds; CPU% bajo sugiere que no estás limitado por núcleos.
2) ¿El diseño de núcleos híbridos de Intel lo hace una mala elección para trabajo real?
No inherentemente. Hace que los valores por defecto sean más riesgosos. Si ejecutas servicios sensibles a latencia o CI predecible, puede que necesites pinning y aislamiento.
Si no quieres pensar en planificación, elige una plataforma con núcleos uniformes.
3) ¿Las CPUs AMD son menos estables para virtualización?
En plataformas de servidor maduras, la estabilidad suele depender de la calidad del firmware, los vendedores de placas y tu disciplina de configuración.
AMD EPYC está ampliamente desplegado para virtualización. Trata el BIOS/microcode como parte del sistema, no como un apéndice.
4) ¿Qué importa más para densidad de VM: núcleos o RAM?
Para la mayoría de flotas reales de VM, la RAM. El overcommit de CPU puede ser sobrevivible; el overcommit de memoria a menudo se vuelve generador de incidentes.
Si haces swapping en el host, ya no estás ejecutando una plataforma VM—estás ejecutando una plataforma decepcionante.
5) ¿Necesito AVX-512 para IA o renderizado?
Usualmente no. Puede ayudar en cierta inferencia ligada a CPU o cargas vectoriales, pero el ecosistema es inconsistente.
Planea alrededor del throughput de extremo a extremo y las bibliotecas que realmente usas, no de trivialidades de conjunto de instrucciones.
6) ¿Por qué mi CPU cara rinde poco en Blender?
El render sostenido expone límites térmicos y de potencia. Revisa frecuencias sostenidas reales y temperaturas.
También asegura que la memoria esté configurada correctamente (canales poblados) y que tu sistema no esté haciendo throttling por VRM o restricciones del chasis.
7) Para un servidor GPU de IA, ¿cómo sé si la CPU es el cuello de botella?
Vigila la utilización de GPU a lo largo del tiempo. Si la utilización de SM es baja y la CPU está ocupada o iowait es alto, la tubería CPU/almacenamiento está limitando el throughput.
Arregla la localidad de datos y el preprocesado primero; luego considera upgrades de CPU.
8) ¿Intel siempre es mejor para latencia single-thread?
A menudo competitivo, a veces líder, pero no “siempre”. AMD también puede ser excelente en rendimiento por hilo, dependiendo de la generación y ajustes de potencia.
El enemigo real es la varianza: throttling, contención de fondo y comportamiento del scheduler.
9) ¿Puedo “resolver” el rendimiento simplemente aumentando -j en builds?
También puedes apagar más ventanas para arreglar un incendio de cocina. Cambia el flujo de aire, no la física.
Más allá de cierto punto, más paralelismo aumenta fallos de caché y contención de I/O; ajusta -j basado en la utilización medida de CPU y iowait.
10) ¿Cuál es la recomendación por defecto más segura si no tengo tiempo para benchmarkear?
Para hosts de VM y servidores multi-GPU: favorece plataformas con abundantes canales de memoria y líneas PCIe (a menudo AMD EPYC en muchas bandas de precio).
Para workstations de desarrollo con tareas interactivas mixtas: favorece fuerte rendimiento por hilo y refrigeración estable, y evita compromisos extraños de plataforma.
Próximos pasos que puedes ejecutar
Aquí está el conjunto de movimientos prácticos. Haz esto y la decisión Intel vs AMD se vuelve obvia en vez de emocional.
- Elige tres cargas representativas: una compilación, un escenario de VM, un render o paso de pipeline de IA.
- Ejecuta los comandos arriba en tu sistema actual durante esas cargas. Clasifica el cuello de botella (CPU, memoria, I/O, scheduler).
- Arregla los cuellos de botella baratos primero: capacidad de RAM, NVMe scratch, ajustes BIOS de potencia/térmico, pinning NUMA.
- Sólo entonces elige hardware:
- Si realmente estás limitado por CPU y es paralelo: compra núcleos (a menudo valor AMD, a veces Intel según precio y plataforma).
- Si estás limitado por serial/latencia: compra rendimiento por hilo y evita varianza de planificación.
- Si estás limitado por memoria/I/O: compra canales, capacidad y líneas; la marca de CPU es secundaria.
- Estandariza firmware y políticas OS como estandarizas configuraciones. Las regresiones de rendimiento adoran los “snowflakes” afinados a mano.