Apilamiento 3D y el futuro de los chiplets: hacia dónde van las CPU

Por qué cambiaron las CPU: física, dinero y el fin de “simplemente reducir tamaño”

Durante décadas, podías tratar el progreso de las CPU como una suscripción predecible: cada generación era más densa, más rápida y (en su mayoría) más barata por unidad de cómputo. Esa era no terminó con un comunicado espectacular. Terminó con mil compromisos pequeños: corriente de fuga, coste de litografía, variabilidad y la incómoda verdad de que los cables no escalan como lo hacen los transistores.

Cuando escuches “chiplets” y “apilamiento 3D”, no lo traduzcas como “ingeniería ingeniosa”. Tradúcelo como: las viejas suposiciones económicas y físicas se rompieron, así que el empaquetado se convirtió en la nueva arquitectura. Movemos la innovación del interior de un dado hacia entre dados.

Hechos y contexto histórico (lo que realmente te ayuda a razonar)

• Hecho 1: El escalado de Dennard (densidad de potencia constante al reducir transistores) se detuvo a mediados de los 2000, forzando la paralización del crecimiento de frecuencia y empujando diseños multicore.
• Hecho 2: La latencia de interconexión ha sido un cuello de botella principal durante años; los cables en el chip no se vuelven proporcionalmente más rápidos con cada nodo, así que “dado más grande” significa más tiempo moviendo bits.
• Hecho 3: Los límites de retícula limitan cuán grande puede ser una exposición de litografía; los dados muy grandes se convierten en pesadillas de rendimiento salvo que los dividas o los hilvanes.
• Hecho 4: La industria ha usado módulos multi-dado durante mucho tiempo (piensa: paquetes de dos dados tempranos, módulos para servidores), pero los chiplets actuales están mucho más estandarizados y son críticos para el rendimiento.
• Hecho 5: High Bandwidth Memory (HBM) se volvió práctica apilando dados DRAM y conectándolos con TSVs, demostrando que la integración vertical puede vencer al ancho de banda tradicional de DIMM.
• Hecho 6: El apilamiento de caché 3D en CPUs de consumo mostró una lección concreta: añadir SRAM verticalmente puede mejorar el rendimiento sin agrandar el dado lógico más caliente.
• Hecho 7: Núcleos heterogéneos (concepto big/little) han existido en móviles por años; ahora son comunes en servidores porque la potencia y las térmicas —no la frecuencia máxima— definen el rendimiento sostenido.
• Hecho 8: El empaquetado avanzado (interposers 2.5D, puentes de silicio, fan-out) es hoy un diferenciador competitivo, no un detalle de fabricación en el backend.

Conclusión operativa: la próxima ganancia de rendimiento del 10–15 % es menos probable que provenga de una nueva instrucción y más probable que provenga de mejor localidad, jerarquías de memoria más inteligentes y enlaces entre dados más apretados. Si tu carga es sensible a la varianza de latencia, necesitas tratar el empaquetado y la topología como tratas el enrutamiento de red.

Chiplets, interconexiones y por qué “socket” ya no significa lo que crees

Una CPU chiplet es un paquete que contiene múltiples dados, cada uno especializándose en algo: núcleos, caché, controladores de memoria, E/S, aceleradores, a veces incluso procesadores de seguridad. El paquete es el producto. La “CPU” ya no es una losa única; es un pequeño sistema distribuido que vive bajo un disipador.

Los chiplets existen por tres razones directas:

1. Rendimiento de fabricación (yield): los dados más pequeños tienen mejor yield; los defectos no matan un dado gigante entero.
2. Mezcla de nodos de proceso: lógica rápida en un nodo avanzado, E/S en un nodo más económico y maduro.
3. Agilidad de producto: reutilizar un dado de IO válido en varios SKUs; variar conteos de núcleos y mosaicos de caché sin rehacerlo todo.

La interconexión es ahora arquitectura

En un dado monolítico, los caminos núcleo–caché y núcleo–memoria son mayormente “internos”. En chiplets, esos caminos pueden atravesar una tela entre dados. La interconexión tiene ancho de banda, latencia y características de congestión, y puede introducir efectos topológicos que se parecen sospechosamente a un problema de red —excepto que no puedes tcpdumpear para solucionarlo.

Los paquetes modernos usan telas propietarias, y hay un empuje industrial hacia estándares interoperables die‑to‑die como UCIe. El punto clave no es el acrónimo. Es que los enlaces entre dados se tratan como E/S de alta velocidad: serializados, sincronizados, gestionados en potencia, entrenados, a veces reintentados. Eso significa que el estado del enlace, contadores de error y estados de energía pueden afectar el rendimiento de maneras que parecen “aleatorias” a menos que las midas.

Broma #1: Los chiplets son como microservicios: a todos les encanta la flexibilidad hasta que tienes que depurar la latencia a través de fronteras que creaste a propósito.

NUMA no era nuevo. Simplemente dejaste de respetarlo.

Las CPU chiplet convierten cada servidor en una máquina NUMA más matizada. A veces los “nodos NUMA” mapean a controladores de memoria; a veces a complejos de núcleos; a veces a ambos. En cualquier caso, la localidad importa: qué núcleo accede a qué memoria, qué porción de la caché de último nivel está más cerca y con qué frecuencia cruzas la interconexión.

Si tu playbook de rendimiento todavía empieza y termina con “añadir núcleos” y “fijar hilos”, chocarás con el nuevo muro: contención de interconexión y jerarquía de memoria. El paquete de la CPU ahora tiene patrones de tráfico internos, y tu carga puede crear puntos calientes.

Apilamiento 3D: ancho de banda vertical, problemas verticales

El apilamiento 3D es el uso de múltiples dados apilados verticalmente con conexiones densas (a menudo through‑silicon vias, micro-bumps o hybrid bonding). Se usa para caché, DRAM (HBM) y cada vez más para arreglos lógica‑sobre‑lógica.

¿Por qué apilar?

• Ancho de banda: las conexiones verticales pueden ser mucho más densas que el enrutamiento borde‑a‑borde en el paquete.
• Latencia: la menor distancia física puede reducir el tiempo de acceso para ciertas estructuras (especialmente caché).
• Eficiencia de área: puedes añadir capacidad sin crecer la huella 2D de un dado lógico caliente.

Pero no obtienes algo por nada. El apilamiento 3D introduce un triángulo operativo feo: térmicas, yield y fiabilidad.

Caché apilada: por qué funciona

Apilar SRAM sobre un dado de cómputo te da una gran caché de último nivel sin hacer el dado de cómputo enorme. Eso puede ser una ganancia masiva para cargas con conjuntos de trabajo justo por encima de los tamaños de caché tradicionales: muchos juegos, algunos flujos EDA, ciertas bases de datos en memoria, almacenes clave‑valor con claves calientes y canalizaciones analíticas con escaneos repetidos.

Desde la perspectiva operativa, la caché apilada cambia dos cosas:

1. El rendimiento se vuelve más bimodal. Si tu carga cabe en caché, eres un héroe. Si no, vuelves a DRAM y la mejora se evapora.
2. El margen térmico se vuelve precioso. El silicio extra encima del dado de cómputo afecta el flujo de calor; el comportamiento turbo y las frecuencias sostenidas pueden cambiar de maneras que aparecen como varianza en la latencia.

HBM: el truco de ancho de banda con costo

HBM apila dados DRAM y los coloca cerca del dado de cómputo (a menudo vía interposer). Esto entrega un ancho de banda enorme comparado con DIMMs tradicionales, pero la capacidad por pila es limitada y el coste es alto. También cambia fallos y observabilidad: los errores de memoria pueden mostrarse de forma distinta y la planificación de capacidad se vuelve otro deporte.

El empaquetado 3D y 2.5D también está forzando una nueva regla de diseño: tu software debe entender niveles. HBM vs DDR, memoria cercana vs memoria lejana, caché en paquete vs caché en dado. “Simplemente asigna memoria” se convierte en una decisión de rendimiento.

Broma #2: Apilar dados es genial hasta que recuerdas que el calor también se apila, y a diferencia de tu backlog no puede posponerse.

El verdadero enemigo: bytes, no flops

La mayoría de los sistemas de producción no están limitados por el rendimiento aritmético bruto. Están limitados por mover datos: de memoria a caché, de caché al núcleo, del núcleo al NIC, del almacenamiento a la memoria y de vuelta. Los chiplets y el apilamiento 3D son reconocimientos industriales de que la memoria y la interconexión son el evento principal.

Aquí es donde los instintos de SRE ayudan. Cuando el paquete de la CPU se convierte en una tela, los cuellos de botella parecen:

• Alta IPC pero bajo rendimiento (esperando memoria o por contención de locks).
• CPU no ocupada pero latencia alta (stalls, fallos de caché, memoria remota).
• El rendimiento cae tras escalar (el tráfico entre chiplets crece superlinealmente).

Qué cambia con chiplets y apilamiento

La localidad de memoria ya no es opcional. En un dado monolítico grande, el acceso “remoto” aún puede ser bastante rápido. En chiplets, el acceso remoto puede atravesar saltos de tela y competir con otro tráfico. En un SKU con caché apilada, la caché “local” puede ser mayor pero la penalización por fallarla puede ser más visible debido al cambio en frecuencia/térmicas.

El ancho de banda no es uniforme. Algunos dados tienen acceso más cercano a ciertos controladores de memoria. Algunos núcleos comparten slices de caché más estrechamente. La topología puede recompensar una buena planificación y castigar una programación ingenua.

La varianza de latencia se vuelve normal. Estados de gestión de energía, clock gating en la tela y algoritmos de boost pueden cambiar las latencias internas. Tu p99 lo notará antes que los promedios.

Térmicas y energía: el paquete es el nuevo campo de batalla

En el papel, compras una CPU con un TDP y una frecuencia boost y das el asunto por cerrado. En realidad, las CPUs modernas son sistemas gestionados por energía que negocian constantemente las frecuencias basadas en temperatura, corriente y características de la carga. Los chiplets y los apilamientos 3D complican esa negociación.

Puntos calientes y gradientes térmicos

Con chiplets, no tienes un perfil térmico uniforme. Tienes puntos calientes donde los núcleos son densos, dados de IO separados que corren más fríos y a veces dados apilados que impiden la extracción de calor del dado de cómputo debajo. En cargas de producción de larga duración, las frecuencias sostenidas importan más que los picos.

Dos consecuencias operativas:

• Los benchmarks mienten con más frecuencia. Los benchmarks cortos alcanzan el boost; la producción llega al estado estable y a los límites de potencia.
• La refrigeración es rendimiento. Un disipador o flujo de aire marginal no solo causará throttling; causará varianza, que es más difícil de depurar.

Fiabilidad: más conexiones, más lugares para echarse a perder

Más dados y más interconexiones significan más puntos potenciales de fallo: micro-bumps, TSVs, sustratos de paquete y entrenamiento de enlaces. Los proveedores diseñan para esto, por supuesto. Pero en campo lo verás como errores corregidos, enlaces degradados o incidentes de “un host está raro”.

Un aforismo operativo útil, parafraseando una idea de una voz notable en fiabilidad: Los sistemas complejos fallan de formas complejas; reduce lo desconocido y mide las cosas correctas. (idea parafraseada, inspirada en el pensamiento de ingeniería de fiabilidad a menudo atribuido a John Allspaw)

Traducción: no asumas uniformidad entre hosts, y no asumas que dos sockets se comportan igual solo porque el SKU coincide.

Qué significa esto para SREs: rendimiento, fiabilidad y vecinos ruidosos

No necesitas convertirte en ingeniero de empaquetado. Necesitas dejar de tratar la “CPU” como un recurso escalar único. En un mundo chiplet + apilamiento, gestionas:

• Cómputo topológico (los núcleos no están a igual distancia de memoria y caché)
• Capacidad de interconexión (la tela interna puede saturarse)
• Margen térmico (frecuencias sostenidas, throttling y p99)
• Política de energía (limitación, turbo e interacciones con el scheduler)

La observabilidad debe ampliarse

El monitoreo tradicional del host —%CPU, load average, memoria usada— cada vez fallará más al explicar cuellos de botella. Necesitas al menos un manejo básico de:

• Localidad NUMA (¿están alineados hilos y memoria?)
• Comportamiento de caché (fallos LLC, presión de ancho de banda)
• Frecuencia y throttling (¿estás limitado por potencia?)
• Colocación del scheduler (¿Kubernetes o systemd movieron tu carga entre nodos?)

Y sí, esto es molesto. Pero es menos molesto que un cuarto de los casos de “actualizamos CPUs y empeoró”.

Guion de diagnóstico rápido: encuentra el cuello de botella en minutos

Este es el flujo de triaje que uso cuando un servicio se vuelve más lento en una nueva plataforma chiplet/apilada, o se vuelve más lento después de escalar. El objetivo no es la causa raíz perfecta. El objetivo es tomar la decisión siguiente correcta rápidamente.

Primero: determina si estás limitado por cómputo, memoria o “tela”

1. Revisa la frecuencia de CPU y el throttling: si los relojes están bajos bajo carga, estás limitado por potencia/térmicas.
2. Revisa el ancho de banda de memoria y la presión de fallos de caché: si los fallos LLC y el ancho de banda son altos, estás limitado por memoria.
3. Revisa la localidad NUMA: si el acceso a memoria remota es alto, probablemente estás limitado por topología/scheduler.

Segundo: confirma topología y colocación

1. Verifica nodos NUMA y mapeo CPU‑a‑nodo.
2. Verifica afinidad de procesos y política de memoria.
3. Comprueba si la carga está rebotando entre nodos (migraciones del scheduler).

Tercero: aísla una variable y vuelve a ejecutar

1. Fija la carga a un nodo NUMA; compara p95/p99.
2. Forza la asignación de memoria local; compara rendimiento.
3. Aplica una política de energía conservadora; compara la varianza.

Si no puedes reproducir un cambio significativo controlando colocación y estado de energía, el problema probablemente sea de capa superior (locks, GC, E/S), y deberías dejar de culpar al paquete de la CPU. Las CPUs modernas son complicadas, pero no mágicas.

Tareas prácticas con comandos: qué ejecutar, qué significa, qué decidir

Estas son tareas reales que puedes ejecutar en hosts Linux para entender comportamientos relacionados con chiplets/apilamiento 3D. Los comandos son deliberadamente aburridos. Las herramientas aburridas te mantienen honesto.

Tarea 1: Mapea la topología NUMA rápidamente

cr0x@server:~$ lscpu | egrep 'Model name|Socket|Thread|Core|NUMA|CPU\(s\)'
CPU(s):                               128
Model name:                           AMD EPYC 9xx4
Thread(s) per core:                   2
Core(s) per socket:                   64
Socket(s):                            1
NUMA node(s):                         8

Qué significa la salida: Tienes 8 nodos NUMA en un solo socket. Eso es una topología tipo chiplet: múltiples dominios de memoria y saltos de interconexión dentro de un paquete.

Decisión: Si la latencia importa, planifica fijar servicios clave dentro de un nodo NUMA y mantener la memoria local. El scheduling por defecto puede ser “aceptable”, pero “aceptable” es como muere el p99.

Tarea 2: Ver qué CPUs pertenecen a cada nodo NUMA

cr0x@server:~$ numactl --hardware
available: 8 nodes (0-7)
node 0 cpus: 0-15
node 0 size: 64000 MB
node 0 free: 61234 MB
node 1 cpus: 16-31
node 1 size: 64000 MB
node 1 free: 60110 MB
node 2 cpus: 32-47
node 2 size: 64000 MB
node 2 free: 59872 MB
node 3 cpus: 48-63
node 3 size: 64000 MB
node 3 free: 62155 MB
node 4 cpus: 64-79
node 4 size: 64000 MB
node 4 free: 60990 MB
node 5 cpus: 80-95
node 5 size: 64000 MB
node 5 free: 61801 MB
node 6 cpus: 96-111
node 6 size: 64000 MB
node 6 free: 61644 MB
node 7 cpus: 112-127
node 7 size: 64000 MB
node 7 free: 62002 MB

Qué significa la salida: Cada nodo NUMA tiene un rango de CPU y una porción de memoria. Si tu proceso corre en CPUs del nodo 0 pero asigna memoria desde el nodo 6, pagará un peaje de tela en cada acceso remoto.

Decisión: Para servicios sensibles a la latencia, alinea la afinidad de CPU y la política de memoria. Para trabajos de throughput, puede que prefieras intercalar para ancho de banda.

Tarea 3: Comprueba si el kernel está registrando problemas de localidad NUMA

cr0x@server:~$ numastat -p 1 3
Per-node process memory usage (in MBs) for PID 1 (systemd)
Node 0 Node 1 Node 2 Node 3 Node 4 Node 5 Node 6 Node 7 Total
----- ----- ----- ----- ----- ----- ----- ----- -----
Numa_Hit      12     10      9      8      9     10      8      9    75
Numa_Miss      1      0      0      0      0      0      0      0     1
Numa_Foreign   0      0      0      0      0      0      0      0     0
Interleave_Hit 0      0      0      0      0      0      0      0     0
Local_Node    12     10      9      8      9     10      8      9    75
Other_Node     1      0      0      0      0      0      0      0     1

Qué significa la salida: Para PID 1 está bien. Para tu servicio real, si Other_Node es grande, estás pagando penalizaciones remotas.

Decisión: Si el acceso remoto es alto y la latencia tail es mala, fija y localiza. Si tu objetivo es throughput y estás limitado por ancho de banda, considera intercalar.

Tarea 4: Verifica el comportamiento de la frecuencia de CPU bajo carga

cr0x@server:~$ sudo turbostat --Summary --quiet --show CPU,Avg_MHz,Busy%,Bzy_MHz,PkgTmp,PkgWatt --interval 5
CPU  Avg_MHz  Busy%  Bzy_MHz  PkgTmp  PkgWatt
-    2850     62.10  4588     86      310.12

Qué significa la salida: Los núcleos ocupados están corriendo alto (Bzy_MHz), la temperatura del paquete es alta y la potencia es sustancial. Si Bzy_MHz colapsa con el tiempo mientras Busy% se mantiene alto, probablemente estés limitado por potencia/térmicas.

Decisión: Para cargas sostenidas, ajusta capado de potencia, refrigeración o reduce la concurrencia. No persigas números de boost de una sola ejecución.

Tarea 5: Confirma que la política de energía (governor) no te sabotea

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

Qué significa la salida: El governor está en performance. Si está en powersave en un host sensible a la latencia, básicamente estás pidiendo jitter.

Decisión: Ajusta la política apropiada por rol de clúster. Un clúster batch puede ahorrar energía; un clúster OLTP no debe disfrazarse de portátil.

Tarea 6: Medir migraciones del scheduler (un silencioso asesino NUMA)

cr0x@server:~$ pidstat -w -p $(pgrep -n myservice) 1 5
Linux 6.5.0 (server)  01/12/2026  _x86_64_  (128 CPU)

01:10:01 PM   UID       PID   cswch/s nvcswch/s  Command
01:10:02 PM  1001     43210   120.00     15.00  myservice
01:10:03 PM  1001     43210   135.00     20.00  myservice
01:10:04 PM  1001     43210   128.00     18.00  myservice

Qué significa la salida: Los cambios de contexto son moderados. Si además ves migraciones frecuentes de CPU (vía perf o schedstat), puedes perder localidad de caché entre chiplets.

Decisión: Considera fijar CPUs para los hilos más calientes, o ajusta tu runtime (hilos de GC, conteos de workers) para reducir churn.

Tarea 7: Comprobar presión de ancho de banda de memoria con pcm-memory (si está instalado)

cr0x@server:~$ sudo pcm-memory 1 -csv
Time,Ch0Read,Ch0Write,Ch1Read,Ch1Write,SystemRead,SystemWrite
1.00,12.3,5.1,11.8,4.9,198.4,82.1
2.00,12.5,5.0,12.1,4.8,201.0,80.9

Qué significa la salida: El ancho de banda de lectura/escritura del sistema es alto. Si está cerca de los límites de la plataforma durante tu incidente, estás atascado por memoria, no por CPU.

Decisión: Reduce el tráfico de memoria: arregla el layout de datos, disminuye copias, aumenta la tasa de aciertos de caché o migra a una plataforma con caché apilada/HBM si tu conjunto de trabajo encaja.

Tarea 8: Observar señales de fallos de caché y stalls con perf

cr0x@server:~$ sudo perf stat -p $(pgrep -n myservice) -e cycles,instructions,cache-misses,branches,branch-misses -a -- sleep 10
 Performance counter stats for 'system wide':

    38,112,001,220      cycles
    52,880,441,900      instructions              #    1.39  insn per cycle
       902,110,332      cache-misses
     9,221,001,004      branches
       112,210,991      branch-misses

      10.002113349 seconds time elapsed

Qué significa la salida: Muchos fallos de caché. La IPC es decente, pero los fallos aún pueden dominar el tiempo de muro según la carga. En CPUs chiplet, los fallos pueden convertirse en tráfico de tela y accesos a memoria remota.

Decisión: Si los fallos de caché correlacionan con picos de latencia, prioriza localidad: fija hilos, reduce contención de estado compartido y prueba SKUs con caché apilada cuando el conjunto de trabajo esté justo por encima del LLC.

Tarea 9: Comprobar errores de memoria y tormentas de errores corregidos

cr0x@server:~$ sudo ras-mc-ctl --summary
Memory controller events summary:
  Corrected errors: 24
  Uncorrected errors: 0
  No DIMM labels were found

Qué significa la salida: Hay errores corregidos. Una tasa creciente puede causar degradación del rendimiento y comportamiento impredecible, y en plataformas de empaquetado avanzado quieres notarlo pronto.

Decisión: Si los errores corregidos aumentan, programa mantenimiento: volver a asentar o reemplazar DIMMs, actualizar firmware o retirar el host. No esperes a que los errores no corregidos te enseñen humildad.

Tarea 10: Validar salud de enlaces/PCIe (el dado de IO también forma parte del relato)

cr0x@server:~$ sudo lspci -vv | sed -n '/Ethernet controller/,+25p' | egrep 'LnkSta:|LnkCap:'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s (ok), Width x16 (ok)

Qué significa la salida: El enlace está funcionando a la velocidad/ancho esperados. Si ves enlaces downtrained, el rendimiento de E/S cae y los ciclos de CPU se desperdician en overhead de interrupciones/paquetes.

Decisión: Los enlaces downtrained provocan: revisa risers, configuraciones BIOS, firmware y el asiento físico. No “optimices” software alrededor de hardware roto.

Tarea 11: Confirmar distribución de interrupciones (evita congestión IRQ en un solo núcleo)

cr0x@server:~$ cat /proc/interrupts | egrep 'eth0|mlx|ens' | head
  55:   10223342          0          0          0   IR-PCI-MSI 524288-edge      ens3f0-TxRx-0
  56:          0    9981221          0          0   IR-PCI-MSI 524289-edge      ens3f0-TxRx-1
  57:          0          0    9875522          0   IR-PCI-MSI 524290-edge      ens3f0-TxRx-2

Qué significa la salida: Las interrupciones están repartidas entre CPUs. Si todas las interrupciones caen en una CPU de un nodo NUMA mientras tu carga corre en otro lugar, tendrás tráfico entre nodos y jitter.

Decisión: Fija las IRQs cerca del nodo NUMA del NIC y cerca de los hilos del servicio que consumen paquetes. La localidad también aplica para E/S.

Tarea 12: Comprobar la política de memoria y ejecutar una prueba localmente

cr0x@server:~$ numactl --cpunodebind=2 --membind=2 ./bench --duration 30
throughput=118223 ops/s
p99_latency_ms=3.4

Qué significa la salida: Forzaste CPU y memoria al nodo 2. Compara esto con resultados sin fijar. Un delta grande indica penalizaciones NUMA/tela.

Decisión: Si fijar mejora el p99 de forma material, implementa colocación (CPUAffinity en systemd, topology manager de Kubernetes o fijación a nivel de carga) en lugar de perseguir micro‑optimizaciones.

Tarea 13: Inspeccionar hugepages e indicadores de presión TLB

cr0x@server:~$ grep -E 'HugePages_Total|HugePages_Free|Hugepagesize' /proc/meminfo
HugePages_Total:    4096
HugePages_Free:     3900
Hugepagesize:       2048 kB

Qué significa la salida: Hay hugepages disponibles. En cargas intensivas de memoria, las hugepages pueden reducir fallos de TLB, lo cual importa más cuando la latencia de memoria ya es mayor por accesos remotos.

Decisión: Si el profiling muestra presión TLB, activa hugepages y valida el impacto. No hagas cargo‑cult: mide.

Tarea 14: Detectar throttling y razones de límite de potencia (ejemplo Intel via RAPL)

cr0x@server:~$ dmesg | egrep -i 'thrott|powercap|rapl' | tail -n 5
[ 8123.221901] intel_rapl: power limit changed to 210W
[ 8123.222110] CPU0: Package power limit exceeded, capping frequency

Qué significa la salida: El sistema está capando potencia. Tu benchmark puede haber corrido antes del cap; las ejecuciones de producción durante él.

Decisión: Alinea configuraciones BIOS/firmware de potencia con la intención de la carga. Si limitas por presupuesto de centro de datos, ajusta los SLOs y afina la concurrencia.

Tres mini-historias corporativas de la era chiplet

Mini‑historia 1: El incidente causado por una suposición errónea

Una compañía SaaS de tamaño medio migró una capa API sensible a latencia a servidores nuevos. Mismo conteo de cores que antes, frecuencias boost anunciadas más altas y una cifra llamativa de L3 que parecía dinero gratis. El despliegue fue conservador: canary al 5 %, métricas bien, luego 25 %, luego 50 %.

Alrededor de la mitad de la flota, la latencia p99 comenzó a oscilar. No subir de forma suave: oscilaba. Las gráficas tenían un patrón en sierra que hacía a la gente discutir sobre patrones de tráfico y GC. La utilización de CPU se mantuvo moderada. La red parecía limpia. El almacenamiento estaba tranquilo. El canal de incidentes se llenó con la peor frase en operaciones: “Nada parece estar mal”.

La suposición errónea: trataron la CPU como uniforme y asumieron que si la CPU% promedio estaba bien, la CPU no era el cuello de botella. En realidad, la carga se estaba programando a través de nodos NUMA y asignando memoria de forma remota frecuentemente debido al comportamiento del runtime y la libertad del scheduler de contenedores para mover tareas. Los accesos remotos no eran catastróficos; eran variables, lo que destruyó la latencia tail.

Lo probaron fijando el servicio a un solo nodo NUMA y forzando asignación local en una prueba. El p99 se estabilizó de inmediato y la sierra desapareció. La solución no fue glamurosa: scheduling consciente de topología, fijado de CPU para los pods más calientes y una política de memoria deliberada. También dejaron de sobrecargar pods sensibles a latencia y batch en el mismo socket. “Más utilización” no era el objetivo; la latencia predecible sí lo era.

Mini‑historia 2: La optimización que salió mal

Una fintech ejecutaba un motor de riesgo que escaneaba un gran dataset en memoria repetidamente. Compraron un SKU con caché apilada porque un benchmark del proveedor mostró una gran mejora. Las pruebas tempranas fueron prometedoras. El throughput mejoró. Todos celebraron. Entonces hicieron lo que las empresas hacen: “optimizaron”.

El equipo aumentó agresivamente el paralelismo, asumiendo que la caché extra mantendría la escalabilidad. También activaron una política turbo más agresiva en BIOS para perseguir aceleraciones de corta duración. En staging, la carga terminó más rápido—la mayoría de las veces.

En producción, la optimización falló de dos maneras. Primero, los hilos extra aumentaron el tráfico entre chiplets porque la carga tenía una estructura compartida que no estaba particionada limpiamente. La interconexión se congestinó. Segundo, la política turbo elevó las temperaturas rápido, causando throttling térmico a mitad de ejecución. El sistema no solo se ralentizó; se volvió impredecible. Algunas ejecuciones terminaron rápido; otras golpearon throttling y se arrastraron.

La solución fue casi aburrida: reducir el paralelismo hasta un punto donde la localidad se mantuviera alta, particionar el dataset con más cuidado y establecer una política de energía optimizada para frecuencia sostenida en lugar de pico boost. La caché apilada aún ayudó—pero solo cuando el software respetó la topología y el envelope térmico. La lección: más caché no excusa un mal escalado.

Mini‑historia 3: La práctica aburrida pero correcta que salvó el día

Un gran equipo de plataforma corporativa estandarizó una “checklist de bring‑up de hardware” para nuevas generaciones de CPU. Incluía baselines de BIOS/firmware, versiones de microcode, verificación de topología NUMA y un conjunto fijo de pruebas smoke de perf/latencia fijadas a nodos específicos.

Cuando llegó un lote de nuevos servidores, las pruebas detectaron una regresión sutil: el ancho de banda de memoria era menor de lo esperado en un nodo NUMA y la latencia p99 bajo una carga sintética mixta era peor. Nada fallaba abiertamente. La mayoría de equipos lo habría declarado “dentro de la varianza” y seguido.

La checklist forzó la escalada. Resultó que una configuración BIOS relacionada con interleaving de memoria y gestión de potencia difería del baseline por un cambio en el valor por defecto del proveedor. Los servidores estaban técnicamente “funcionando”, pero no funcionaban igual que el resto de la flota. Esa discrepancia se habría convertido en una pesadilla de guardia más tarde, porque el comportamiento heterogéneo dentro de un grupo autoscalado convierte incidentes en juegos de probabilidad.

Arreglaron el baseline, reimaginizaron los hosts, volvieron a ejecutar las mismas pruebas fijadas y obtuvieron los resultados esperados. Sin heroicidades. Sin incidentes nocturnos. Solo disciplina operativa: medir, estandarizar y negarse a aceptar variancia silenciosa en un mundo donde los paquetes son pequeños sistemas distribuidos.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: p99 sube al escalar a más cores

Causa raíz: Contención entre chiplets y aumento de accesos a memoria remota al dispersar hilos entre nodos NUMA; estructuras de datos compartidas amplifican el tráfico.

Solución: Particionar estado, reducir compartición entre hilos, fijar workers críticos dentro de un nodo NUMA y usar scheduling consciente de topología.

2) Síntoma: Utilización de CPU moderada pero throughput bajo

Causa raíz: Stalls de memoria (fallos LLC, latencia DRAM), congestión de la tela o migraciones frecuentes se ocultan detrás de “no ocupado”.

Solución: Usa perf stat y herramientas de ancho de banda de memoria; revisa numastat; fija y localiza; reduce churn del asignador y las copias.

3) Síntoma: Nuevos servidores son más rápidos en benchmarks pero peores en producción

Causa raíz: Los benchmarks alcanzan boost clocks y estados de caché caliente; la producción alcanza límites de potencia sostenida y cargas mixtas.

Solución: Prueba con ejecuciones en estado estable, incluye métricas p99 y valida bajo concurrencia y condiciones térmicas realistas.

4) Síntoma: Un host en la pool es consistentemente raro

Causa raíz: Enlace PCIe downtrained, canal de memoria degradado, tormenta de errores corregidos o deriva de BIOS afectando potencia/topología.

Solución: Revisa lspci -vv, resúmenes RAS, versiones de microcode/BIOS; pone en cuarentena y remedia en lugar de ajustar alrededor del problema.

5) Síntoma: Jitter de latencia aparece tras habilitar funciones “ahorro de energía”

Causa raíz: C‑states agresivos, clock gating en la tela, escalado de frecuencia o límites de paquete causan comportamiento variable de wake/boost.

Solución: Usa governor de performance para tiers de latencia, ajusta estados de energía en BIOS y valida con turbostat bajo carga real.

6) Síntoma: Rendimiento pps de red cae tras refresco de hardware

Causa raíz: IRQs y threads están en diferentes nodos NUMA; el dado de IO y la localidad del NIC importan, y el tráfico entre nodos añade latencia.

Solución: Alinea afinidad de IRQs y threads de aplicación al nodo NUMA del NIC; confirma ancho/velocidad de enlace; evita la sobreconsolidación.

7) Síntoma: “Añadimos caché apilada pero no vimos mejora”

Causa raíz: El conjunto de trabajo no cabe, o la carga está limitada por ancho de banda en lugar de latencia de caché; la ganancia es específica de la carga.

Solución: Perfila tasas de fallos de caché y ancho de banda; prueba tamaños de datos representativos; considera HBM o cambios algorítmicos si estás limitado por ancho de banda.

8) Síntoma: Tras contenerizar, el rendimiento regresó en CPUs chiplet

Causa raíz: El scheduler de contenedores movió hilos entre CPUs/nodos NUMA; las cuotas cgroup CPU introdujeron ráfagas; la localidad del page cache empeoró.

Solución: Usa CPU manager/topology manager, establece requests/limits explícitos adecuadamente y fija pods con uso intensivo de memoria a nodos NUMA.

Listas de verificación / plan paso a paso para nuevas plataformas

Plan paso a paso: llevar una nueva plataforma chiplet/apilada a producción

1. Topología baseline: registra lscpu y numactl --hardware para el SKU; almacénalo con tus artefactos de build.
2. Estandariza firmware: configuraciones BIOS, microcode y políticas de potencia deben ser consistentes en la pool.
3. Elige postura de energía por tier: clusters de latencia obtienen policy performance; clusters batch pueden estar intencionalmente con capado de potencia.
4. Ejecuta pruebas smoke fijadas: mide throughput y p99 con CPU+memoria ligadas a un nodo; luego ejecuta sin fijar; compara deltas.
5. Valida margen de ancho de banda de memoria: si tu carga es limitada por memoria, la planificación de capacidad es planificación de ancho de banda.
6. Valida localidad de E/S: revisa salud de enlaces PCIe y distribución de IRQ; asegura que la afinidad del NIC coincida con la colocación de CPU.
7. Decide política de colocación: acepta NUMA (fijar y localizar) o intercalar explícitamente para ancho de banda. No hagas “híbrido accidental”.
8. Despliega con detección de varianza: vigila no solo medianas sino dispersión entre hosts; alerta temprano sobre “un host raro”.
9. Documenta modos de fallo: firmas de throttling, umbrales de errores corregidos y cómo poner en cuarentena un host.
10. Vuelve a probar tras actualizaciones de kernel: cambios en el scheduler pueden ayudar o perjudicar el manejo de topología; valida periódicamente.

Checklist: decidir entre caché apilada vs más ancho de banda de memoria

• Si tu conjunto de trabajo es ligeramente mayor que el LLC y ves muchos fallos de LLC: la caché apilada puede ser una gran ganancia.
• Si el ancho de banda de memoria está cerca del máximo y los stalls dominan: la caché apilada puede no salvarte; prioriza ancho de banda (plataformas HBM, más canales) o reduce tráfico.
• Si la latencia tail importa: prefiere soluciones que reduzcan la varianza (localidad, política de potencia estable) sobre picos máximos.

Checklist: qué evitar al adoptar CPUs con muchos chiplets

• No asumas “un socket = uniforme.” Mide comportamiento NUMA.
• No aceptes deriva de BIOS en un grupo autoscalado.
• No optimices aplicaciones sin primero verificar comportamiento de potencia y throttling.
• No mezcles cargas de latencia y batch en el mismo socket a menos que tengas aislamiento estricto.

FAQ

1) ¿Los chiplets siempre son más rápidos que los dados monolíticos?

No. Los chiplets son principalmente una estrategia económica y de velocidad de producto, con beneficios de rendimiento cuando la interconexión y la topología están bien gestionadas. La mala localidad puede borrar la ganancia.

2) ¿El apilamiento 3D hará que las CPU funcionen más calientes?

A menudo, sí en la práctica. Las pilas pueden impedir la salida de calor y crear puntos calientes. Los proveedores diseñan alrededor de esto, pero las cargas sostenidas pueden ver throttling más temprano o más varianza.

3) ¿Es obligatorio afinar NUMA ahora?

Para servicios sensibles a latencia en CPUs con muchos chiplets, está casi al borde de ser obligatorio. Para trabajo embarrassingly parallel en batch, a menudo puedes prescindir—hasta que no puedas.

4) ¿Qué cargas se benefician más de caché apilada?

Cargas con un conjunto de trabajo mayor que la caché normal pero más pequeño que patrones de streaming DRAM: workloads clave‑valor calientes, algunas analíticas, ciertas simulaciones y estructuras de datos en memoria con muchas lecturas.

5) ¿Cuál es el riesgo operativo de empaquetado más avanzado?

Más componentes y enlaces pueden significar degradaciones sutiles: tormentas de errores corregidos, downtraining de enlaces o varianza de plataforma. Tus prácticas de monitoreo y cuarentena importan más.

6) ¿Los chiplets significan que “más cores” dejará de ayudar?

Más cores seguirán ayudando para cargas paralelas, pero el escalado será más sensible al ancho de banda de memoria, la congestión de interconexión y la contención de estado compartido. Las ganancias fáciles se acabaron.

7) ¿Cómo cambia HBM la planificación de capacidad?

HBM te empuja hacia un modelo escalonado: ancho de banda muy alto pero capacidad limitada. Planifica qué debe quedarse en HBM, qué puede volcarse a DDR y cómo se comporta tu asignador/runtime.

8) ¿UCIe hará que los paquetes CPU sean modulares como piezas de PC?

Eventualmente, más modulares que hoy—pero no esperes plug‑and‑play. Integridad de señal, suministro de potencia, térmicas y validación siguen siendo difíciles, y el “estándar” no eliminará la física.

9) ¿Cuál es el cambio más simple y “suficientemente bueno” para reducir latencia tail en CPUs chiplet?

Fija tus hilos más calientes a un nodo NUMA y mantén su memoria local. Luego verifica con una prueba A/B fijada. Si ayuda, invierte en scheduling consciente de topología.

10) ¿Debería comprar SKUs con caché apilada para todo?

No. Cómpralas para cargas que demuestren sensibilidad a caché en el profiling. Si no, pagas por silicio que mayormente solo adorna tu hoja de procurement.

Próximos pasos prácticos

El apilamiento 3D y los chiplets no son una tendencia; son la forma del camino por delante. La CPU se está convirtiendo en un sistema distribuido a nivel de paquete con restricciones térmicas y topológicas. Tu software y tu operación deben comportarse en consecuencia.

Qué hacer la próxima semana (no el próximo trimestre)

1. Elige un servicio con SLOs de latencia y ejecuta la prueba NUMA fijada vs no fijada (numactl) para cuantificar sensibilidad.
2. Añade dos paneles a nivel host: frecuencia/throttling de CPU (derivado de turbostat) y accesos remotos NUMA (numastat/derivado de PMU si lo tienes).
3. Estandariza baselines BIOS/microcode para cada pool de hardware; alerta sobre deriva.
4. Escribe un runbook de una página usando el Guion de diagnóstico rápido arriba para que la guardia no culpe a la red por reflejo.
5. Decide tu filosofía de colocación: localidad‑first para tiers de latencia; interleave/ancho‑de‑banda‑first para tiers de throughput—luego aplícalo.

Si no haces nada más, haz esto: deja de tratar el %CPU como la verdad. En chiplets y diseños apilados, %CPU es una vibra. Mide localidad, mide ancho de banda y mide throttling. Entonces podrás discutir con confianza, que es el único tipo de discusión que las operaciones pueden permitirse.