HBM en CPUs: Cuando la memoria entra en el paquete

Qué cambia realmente HBM en una CPU

Definamos el objeto del que hablamos: HBM es DRAM apilada (múltiples dies apilados verticalmente) conectada al paquete del procesador usando una interfaz extremadamente ancha.
No es memoria mágica. Es DRAM con mejor empaquetado, buses más anchos y un perfil de coste distinto.

Cuando HBM se ubica “en” una CPU—típicamente en el mismo paquete, conectada con interconexiones cortas—tres cosas cambian de forma que los operadores notan:

1) El ancho de banda se vuelve menos escaso (hasta que alcanzas la siguiente pared)

Los canales DDR tradicionales han mejorado, pero no al ritmo de los conteos de núcleos y las unidades vectoriales. HBM te da mucho más ancho de banda agregado, lo que ayuda a cargas
acotadas por ancho de banda: analítica por streaming, álgebra lineal esparcida, grandes escaneos en memoria, búsqueda vectorial y muchos patrones de inferencia AI que no encajan bien en cachés.

2) La capacidad se vuelve más valiosa

La capacidad HBM por socket suele ser mucho menor que la capacidad DDR. Cambias “GB relativamente baratos” por “GB muy rápidos.”
Eso te obliga a decisiones de estratificación: qué vive en HBM, qué derrama a DDR y qué se envía al almacenamiento.

3) NUMA se vuelve más extraño y más importante

El SO a menudo expone HBM como un nodo NUMA separado (o múltiples nodos). Eso es bueno: es visible y controlable.
También es malo: ahora puedes poner por accidente tus páginas calientes en la capa lenta mientras la capa rápida está inactiva, como CPU reservadas en un clúster Kubernetes que nadie pidió.

Por qué esto sucede ahora (y por qué DDR no está “fallando”)

DDR no está rota. Simplemente está sujeta a física honesta y economía honesta. Los pines son caros, el ruteo es difícil y la integridad de señal es un hobby para quienes disfrutan el dolor.
Mientras tanto, las CPUs siguen ganando núcleos, SIMD más amplios y aceleradores que pueden procesar datos a tasas que DDR no siempre puede suministrar.

La tecnología de empaquetado ha mejorado lo suficiente como para que acercar la memoria no solo sea posible, sino comercialmente sensato para ciertos mercados:
HPC, AI, analítica y algunos servicios sensibles a latencia donde “simplemente añadir nodos” ya no es una frase respetable.

Aquí está la conclusión operativa: HBM en CPUs no es un reemplazo de memoria por capacidad. Es una admisión de que el ancho de banda es un recurso de primera clase.
Trátalo como tratas las IOPS en un host de base de datos: medible, agotable y fácil de malgastar.

Hechos e historia interesantes para reuniones de planificación

• Hecho 1: El problema de la “pared de memoria”—la velocidad de la CPU superando la velocidad de la memoria—se discute desde los años 90, y nunca dejó de ser verdad; solo se ocultó mejor gracias a las cachés.
• Hecho 2: HBM es “DRAM apilada 3D” conectada mediante through-silicon vias (TSVs), por eso puede exponer una interfaz muy ancha sin un desastre de conectores.
• Hecho 3: Las GPUs adoptaron HBM temprano porque su rendimiento hace que las carencias de ancho de banda sean dolorosamente obvias; las CPUs llegan tarde en parte porque necesitaban mayores capacidades y compatibilidad con cargas más variadas.
• Hecho 4: Los sistemas de memoria multinivel no son nuevos—mainframes y algunos sistemas vectoriales usaron jerarquías de memoria explícitas mucho antes de que los servidores modernos fingieran que todo es plano.
• Hecho 5: Experimentos tempranos de “memoria en paquete” mostraron un tema recurrente: las ganancias de rendimiento eran reales, pero el ecosistema de software tardó años en ponerse al día con la asignación y el afinamiento.
• Hecho 6: Linux moderno puede exponer memoria heterogénea como nodos NUMA, permitiendo control de políticas vía numactl y políticas de memoria; lo difícil es elegir políticas que no colapsen bajo carga.
• Hecho 7: Las cargas pesadas en ancho de banda a menudo parecen “CPU al 40% de utilización,” lo que engaña a la gente para escalar cómputo en lugar de arreglar la colocación de memoria.
• Hecho 8: Las elecciones de empaquetado y memoria están cada vez más ligadas a la energía: mover bits a través de una placa cuesta más energía que moverlos dentro de un paquete.
• Hecho 9: La industria también impulsa CXL para expansión y agrupamiento de memoria; HBM y CXL no son tanto competidores como distintas respuestas a “rápido” versus “grande.”

¿La memoria será parte del paquete de la CPU?

Para algunos niveles de cómputo, sí—y no como proyecto de feria científica. Verás más CPUs enviadas con cierta cantidad de memoria de alto ancho de banda en paquete, porque resuelve un problema específico:
mantener mucho cómputo alimentado sin convertir cada placa madre en una escena de crimen de señal de alta velocidad.

Pero “la memoria se convierte en parte del paquete” no significa “los DIMM desaparecen.” Significa que la historia de la memoria se estratifica:

• HBM en paquete: capacidad relativamente pequeña, ancho de banda enorme, relativamente eficiente en energía por bit movido, caro por GB.
• DDR fuera del paquete: gran capacidad, buen rendimiento general, más barato por GB, limitado por el número de canales y las restricciones a nivel de placa.
• Memoria fuera del host o agrupada (CXL): grande y flexible, pero con mayor latencia; ideal para consolidación, no para alimentar unidades vectoriales a máxima velocidad.

Desde el ángulo de sistemas: es menos como “la memoria se mudó a la CPU” y más como “la CPU creció una despensa privada.” Aún necesitas el almacén (DDR).

Broma #1: Si alguna vez viste una CPU detenerse por la memoria, ya sabes que el componente más rápido en el servidor es la factura.

Latencia vs ancho de banda: la parte que la gente mezcla

A los operadores les encanta un solo número. La memoria se niega a cooperar. El gran argumento de venta de HBM es el ancho de banda, no necesariamente una latencia más baja que DDR en todos los casos.
En la práctica, el panorama de latencia depende de la implementación, los controladores de memoria y cómo el SO mapea las páginas.

Dos patrones de fallo aparecen repetidamente:

Cargas limitadas por ancho de banda que parecen limitadas por CPU

La tubería de la CPU está ocupada “haciendo algo,” pero las instrucciones retiradas por ciclo son bajas. Añades núcleos y ves casi ningún aumento de rendimiento.
HBM puede arreglar esto—si los datos calientes aterrizan en HBM. Si no, compraste un coche de carreras y le echaste gasolina de cortacésped.

Cargas sensibles a latencia que apenas se benefician

Si tu carga es una cadena de búsquedas por punteros dependientes, código con muchas bifurcaciones o accesos aleatorios pequeños, el ancho de banda no es el limitador.
Puedes ver una mejora mínima. A veces ves regresión si las políticas de memoria del sistema empujan páginas críticas a una capa de “alto ancho de banda” con peor latencia efectiva bajo contención.

La frase que quiero que recuerdes: HBM arregla “no suficientes bytes por segundo”, no “demasiados nanosegundos por acceso”.

Una cita, porque es el corazón del asunto: “The fastest code is the code that doesn’t run.” —Jeff Atwood. Si HBM te hace ignorar el desperdicio algorítmico, seguirás perdiendo.

Modelos de tiering HBM+DDR: caché, nodo NUMA o asignación explícita

Los proveedores y plataformas tienden a presentar HBM de una de varias maneras. Tu postura operativa cambia según lo que tengas.
No adivines. Verifica qué expone el SO.

Modelo A: HBM como caché transparente

El sistema usa HBM como caché para DDR. Esto reduce el control del operador y reduce la culpa del operador—hasta que no lo hace.
La ventaja es la simplicidad; la desventaja es la impredecibilidad con cargas mixtas y el clásico problema de caché: lo que está caliente para una carga expulsa lo que está caliente para otra.

Modelo B: HBM como nodo NUMA distinto (“modo plano”)

Linux ve HBM como nodos NUMA separados. Este es el modo amigable para el operador porque puedes enlazar procesos, establecer la política de memoria y diagnosticar la colocación.
También es el modo donde puedes crear tu propio outage con un solo numactl copiado y pegado.

Modelo C: Colocación gestionada por la aplicación

Algunos runtimes, asignadores o frameworks pueden dirigir asignaciones a nodos de memoria específicos.
Este es el más poderoso y el menos indulgente, porque ahora la corrección incluye “¿tu asignador sigue haciendo lo que piensas que hace bajo fragmentación?”

Broma #2: El tiering de memoria es como la asignación de asientos en una oficina—todos están de acuerdo en que debería ser justo hasta que aparecen los asientos junto a la ventana.

Qué cargas se benefician realmente (y cuáles no)

Grandes candidatos

• Escaneos y analítica por streaming: escaneos columnarios, tuberías de descompresión, transformaciones ETL que leen muchos bytes y hacen trabajo moderado por byte.
• Búsqueda vectorial y operaciones con embeddings: especialmente cuando el conjunto de trabajo es más grande que la caché y el acceso es semi-estructurado.
• Núcleos científicos/HPC: códigos stencil, FFTs, variantes de álgebra lineal y todo lo que históricamente se quejó por el ancho de banda de memoria.
• Inferencia AI en CPU (casos selectos): no porque la CPU supere a la GPU, sino porque el ancho de banda puede ser el factor que limita cuando el modelo o las activaciones son pesadas en memoria.

Candidatos marginales

• Microservicios persiguiendo latencia: si ya dependes en gran medida de L3 y la red/serialización domina, HBM no te salvará.
• Búsquedas aleatorias de claves pequeñas: el pointer chasing suele chocar con límites de latencia y comportamiento de caché más que con ancho de banda puro.
• Sistemas limitados por disco: si esperas en almacenamiento, arregla el almacenamiento. HBM no hará sentir vergüenza a un SSD lento.

Malos candidatos

• Todo lo que necesita mucha RAM por host pero no ancho de banda: la capacidad HBM es demasiado pequeña; acabarás en DDR de todos modos.
• Cajas multi-tenant sin control: si no puedes fijar o controlar políticas de memoria, la capa rápida se convierte en una tragedia compartida.

Implicaciones SRE: nuevos cuellos de botella, nuevas mentiras, nuevos paneles

HBM no elimina cuellos de botella. Los reubica. Cuando aumentas el ancho de banda de memoria, a menudo expones el siguiente limitador:
ejecución del núcleo, tráfico de coherencia de caché, enlaces inter-socket, PCIe, o simplemente un lock en tu código que nadie tocó porque “estaba bien.”

Cambios en la planificación de capacidad

Ahora planificas dos capacidades: RAM total (DDR+HBM) y “RAM rápida” (HBM).
Un servicio puede estar “dentro de los límites de memoria” y aun así estar “fuera de HBM,” lo que parece una regresión de rendimiento sin saturación obvia de recursos.

Cambios en la observabilidad

Necesitas uso de memoria por nodo NUMA, contadores de ancho de banda (uncore/IMC) y estadísticas de migración de páginas si tu plataforma lo soporta.
La utilización de CPU ya no es siquiera ligeramente suficiente.

Cambios en la fiabilidad

Más complejidad de empaquetado significa superficies de fallo diferentes: térmicas en paquete, diferencias en el reporte de ECC y peculiaridades de firmware.
También: un host puede estar “saludable” y aun así estar “mal colocado,” donde las páginas calientes viven en DDR porque el proceso arrancó antes de aplicar la política.

Guion rápido de diagnóstico

Usa esto cuando una carga sea más lenta de lo esperado en un host CPU con capacidad HBM. El objetivo es localizar el cuello de botella en minutos, no escribir una tesis.

Primero: verifica qué expone el sistema

• ¿HBM está presente y visible como nodos NUMA, o está configurado como caché?
• ¿La carga realmente asigna desde HBM, o solo “se ejecuta en la CPU que tiene HBM cerca”?

Segundo: decide si estás limitado por ancho de banda

• Revisa los contadores de ancho de banda de memoria y los fallos de LLC.
• Busca low IPC con altas stalls por memoria.
• Confirma que añadir núcleos no escala el rendimiento.

Tercero: confirma colocación y política

• Revisa el uso de memoria por nodo NUMA para el proceso.
• Comprueba si el balanceo NUMA automático migró páginas fuera de HBM.
• Verifica afinidad: fijar CPUs sin fijar memoria es media solución.

Cuarto: busca la “siguiente pared”

• Tráfico inter-socket (NUMA remoto), tormentas de coherencia de caché, contención por locks, cuellos en PCIe.
• Si HBM ayuda un poco pero no lo suficiente, puede que tengas limitadores mixtos.

Tareas prácticas: comandos, salidas y la decisión que tomas

Estas son tareas prácticas en on-call. Cada una incluye un comando, salida realista, qué significa y qué decisión tomas.
Supuesto: host Linux con root o sudo. Las herramientas pueden requerir paquetes, pero los comandos mismos son estándar y ejecutables donde estén instaladas.

Task 1: Confirmar topología NUMA (¿tenemos siquiera nodos de memoria distintos?)

cr0x@server:~$ numactl --hardware
available: 4 nodes (0-3)
node 0 cpus: 0 1 2 3 4 5 6 7
node 0 size: 256000 MB
node 0 free: 194321 MB
node 1 cpus: 8 9 10 11 12 13 14 15
node 1 size: 256000 MB
node 1 free: 200114 MB
node 2 cpus: 16 17 18 19 20 21 22 23
node 2 size: 64000 MB
node 2 free: 61222 MB
node 3 cpus: 24 25 26 27 28 29 30 31
node 3 size: 64000 MB
node 3 free: 63001 MB
node distances:
node   0   1   2   3
  0:  10  12  20  20
  1:  12  10  20  20
  2:  20  20  10  12
  3:  20  20  12  10

Qué significa: Dos nodos grandes y dos nodos más pequeños sugieren una capa rápida/pequeña (a menudo HBM) y una capa grande (DDR), dependiendo de la plataforma.

Decisión: Identifica qué nodos son HBM vs DDR antes de afinar. No te enlaces ciegamente al “nodo 0” por costumbre.

Task 2: Mapear nodos NUMA a tipos de memoria (DAX/pmem vs DRAM vs parecido a HBM)

cr0x@server:~$ for n in /sys/devices/system/node/node*; do echo "$n"; cat $n/meminfo | head -n 5; done
/sys/devices/system/node/node0
Node 0 MemTotal:       262144000 kB
Node 0 MemFree:        198930432 kB
Node 0 MemUsed:         63213568 kB
Node 0 Active:          21011200 kB
Node 0 Inactive:        18400320 kB
/sys/devices/system/node/node1
Node 1 MemTotal:       262144000 kB
Node 1 MemFree:        205019136 kB
Node 1 MemUsed:         57124864 kB
Node 1 Active:          20122304 kB
Node 1 Inactive:        17633280 kB
/sys/devices/system/node/node2
Node 2 MemTotal:        65536000 kB
Node 2 MemFree:         62691328 kB
Node 2 MemUsed:          2844672 kB
Node 2 Active:            412160 kB
Node 2 Inactive:          671744 kB
/sys/devices/system/node/node3
Node 3 MemTotal:        65536000 kB
Node 3 MemFree:         64513024 kB
Node 3 MemUsed:          1022976 kB
Node 3 Active:            210944 kB
Node 3 Inactive:          312320 kB

Qué significa: Los nodos más pequeños probablemente representan la capa “rápida”; verifica vía documentación de la plataforma, firmware o pruebas de rendimiento.

Decisión: Trata node2/node3 como nodos candidatos a HBM. Planea fijar cargas de prueba a ellos y medir.

Task 3: Verificar la política NUMA actual de un proceso en ejecución

cr0x@server:~$ sudo cat /proc/12345/numa_maps | head -n 5
00400000 default file=/usr/bin/myservice mapped=4 N0=4
00a00000 default heap anon=512 N0=320 N2=192
7f2c84000000 default anon=2048 N1=2048
7f2c8c000000 interleave anon=4096 N2=2048 N3=2048

Qué significa: El heap está dividido entre nodos, incluyendo N2/N3. Algunas asignaciones están intercaladas.

Decisión: Si la asignación caliente no está en la capa prevista, ajusta la política de lanzamiento o el asignador. No “optimices” solo fijando CPUs.

Task 4: Confirmar si el balanceo NUMA automático está migrando páginas

cr0x@server:~$ cat /proc/sys/kernel/numa_balancing
1

Qué significa: El kernel puede migrar páginas según patrones de acceso observados, a veces lejos de HBM dependiendo de las heurísticas.

Decisión: Para benchmarking controlado, desactívalo temporalmente; para producción, decide por servicio. Si HBM es capa objetivo, quizás prefieras políticas explícitas.

Task 5: Lanzar una carga vinculada explícitamente a nodos tipo HBM (memoria + CPU)

cr0x@server:~$ numactl --cpunodebind=2 --membind=2 -- bash -lc 'python3 -c "a=bytearray(8*1024*1024*1024); print(len(a))"'
8589934592

Qué significa: La asignación tuvo éxito en el nodo 2. Si falla con ENOMEM, la capacidad HBM es menor de lo que asumías.

Decisión: Si cabe, mide el rendimiento. Si no cabe, elige interleave o un diseño por niveles (caliente en HBM, frío en DDR).

Task 6: Medir ancho de banda de memoria rápidamente (prueba de cordura tipo stream)

cr0x@server:~$ sudo perf stat -e cycles,instructions,cache-misses,LLC-load-misses -a -- sleep 10
 Performance counter stats for 'system wide':

  42,118,443,002      cycles
  55,220,114,887      instructions              #    1.31  insn per cycle
     1,220,443,119      cache-misses
       410,221,009      LLC-load-misses

      10.003857036 seconds time elapsed

Qué significa: IPC ~1.31 con misses substanciales de LLC sugiere presión de memoria. No es concluyente, pero es un olor a sospecha.

Decisión: Si ves bajo IPC con altas misses de LLC durante el periodo lento, enfócate en colocación/ancho de banda de memoria, no en escalar CPU.

Task 7: Detectar acceso NUMA remoto (el impuesto silencioso de latencia)

cr0x@server:~$ numastat -p 12345
Per-node process memory usage (in MBs) for PID 12345 (myservice)
Node 0          1200.45
Node 1          1188.20
Node 2           256.10
Node 3            12.05
Total           2656.80

Qué significa: La mayor parte de la memoria está en Node0/Node1. Si los hilos corren en CPUs de Node2, estás pagando acceso remoto.

Decisión: Alinea afinidad de CPU y memoria. O mueves hilos para que coincidan con la memoria, o migras la memoria para que coincida con los hilos.

Task 8: Comprobar afinidad de CPU del proceso (¿nos estamos encajonando?)

cr0x@server:~$ taskset -pc 12345
pid 12345's current affinity list: 16-23

Qué significa: El proceso está fijado a CPUs 16–23 (probablemente node2). Si la memoria está en node0/1, el tráfico remoto está garantizado.

Decisión: O ajustas la afinidad para nodos DDR locales, o estableces --membind/--preferred a node2 si ese es tu tier HBM y la capacidad cabe.

Task 9: Comprobar contadores de ancho de banda/uncore vía pcm (si está instalado)

cr0x@server:~$ sudo pcm-memory 1 -csv=/tmp/pcm.csv
PCM Memory Bandwidth Monitoring Utility
Time elapsed: 1.00 seconds
System Read Throughput(MB/s): 182400.12
System Write Throughput(MB/s): 62211.55

Qué significa: El ancho de banda es extremadamente alto; puedes estar saturando canales DDR o la interconexión. HBM debería reducir la presión si se usa.

Decisión: Si el ancho de banda está cerca de los límites de la plataforma, prioriza mantener datos calientes en HBM y reducir el ruido cross-socket.

Task 10: Detectar fallos de página y fallos mayores (¿estamos haciendo swap o thrashing entre tiers?)

cr0x@server:~$ pidstat -r -p 12345 1 5
Linux 6.5.0 (server)  01/12/2026  _x86_64_  (32 CPU)

12:01:11      UID       PID  minflt/s  majflt/s     VSZ     RSS   %MEM  Command
12:01:12     1000     12345   5020.00      0.00 28934144 2638820  8.12  myservice
12:01:13     1000     12345   4870.00      0.00 28934144 2638900  8.12  myservice

Qué significa: Altos minor faults son normales durante la asignación/first-touch; los major faults indicarían paging.

Decisión: Si los major faults aumentan en estado estable, tienes problemas de capacidad; HBM no ayudará y podría empeorar la situación.

Task 11: Verificar el estado de transparent hugepages (THP puede ayudar o perjudicar)

cr0x@server:~$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

Qué significa: THP está siempre activado. Eso puede mejorar el comportamiento de la TLB en escaneos grandes, pero también puede causar picos de latencia por compactación.

Decisión: Para servicios sensibles a latencia, considera madvise y estrategias de hugepage explícitas; para batch pesado en ancho de banda, always puede estar bien.

Task 12: Comprobar actividad de migración de páginas (¿las páginas rebotan entre tiers?)

cr0x@server:~$ grep -E 'pgmigrate|numa' /proc/vmstat | head
numa_pte_updates 18422011
numa_huge_pte_updates 11201
numa_hint_faults 920110
numa_hint_faults_local 610022
numa_pages_migrated 188440
pgmigrate_success 188102
pgmigrate_fail 338

Qué significa: Se están migrando páginas. Algo es normal; mucho puede indicar que el kernel está peleando con tu colocación o que la carga es inestable.

Decisión: Si las migraciones se correlacionan con picos de p99, reduce el balanceo automático o haz la colocación explícita. La migración no es gratuita.

Task 13: Validar memoria libre por nodo antes de forzar membind (evita sorpresas OOM)

cr0x@server:~$ grep -H "MemFree" /sys/devices/system/node/node*/meminfo
/sys/devices/system/node/node0/meminfo:Node 0 MemFree:        198930432 kB
/sys/devices/system/node/node1/meminfo:Node 1 MemFree:        205019136 kB
/sys/devices/system/node/node2/meminfo:Node 2 MemFree:         62691328 kB
/sys/devices/system/node/node3/meminfo:Node 3 MemFree:         64513024 kB

Qué significa: Los nodos rápidos tienen mucha menos memoria libre. Un --membind estricto puede fallar bajo carga incluso cuando la caja tiene montones de DDR libre.

Decisión: Usa --preferred o interleave para resiliencia a menos que estés absolutamente seguro de que las asignaciones caben en el margen HBM.

Task 14: Comparar rendimiento rápidamente: preferred vs interleave

cr0x@server:~$ /usr/bin/time -f "elapsed=%e cpu=%P" numactl --preferred=2 -- bash -lc 'dd if=/dev/zero of=/dev/null bs=1M count=4096 status=none'
elapsed=0.34 cpu=99%

cr0x@server:~$ /usr/bin/time -f "elapsed=%e cpu=%P" numactl --interleave=all -- bash -lc 'dd if=/dev/zero of=/dev/null bs=1M count=4096 status=none'
elapsed=0.52 cpu=99%

Qué significa: La asignación preferida a node2 fue más rápida para este patrón de streaming, lo que sugiere que node2 tiene memoria de mayor ancho de banda.

Decisión: Usa preferencia HBM para asignaciones intensivas en ancho de banda, pero valida la estabilidad bajo presión real de memoria.

Tres microhistorias corporativas desde el campo

Microhistoria 1: El incidente causado por una suposición errónea

Una empresa mediana movió un servicio de ranking sensible a latencia a hosts CPU nuevos anunciados como “con soporte HBM.”
El plan de migración fue simple: mismos límites de contenedor, misma política de pinning de CPU, misma plantilla de despliegue. Hardware más rápido, mismo software. ¿Qué podría salir mal?

Las primeras horas se vieron bien. Luego el p99 empezó a subir durante los picos de tráfico, pero la utilización de CPU se mantuvo moderada.
El equipo escaló horizontalmente. Ayudó un poco. Escalaron más. Ayudó menos. Mientras tanto, el uso de memoria parecía “dentro de límites,” y nadie vio swap.

La suposición equivocada: creyeron que HBM era una caché transparente. En esa plataforma se exponía como nodos NUMA separados,
y su despliegue fijaba CPUs al nodo “adyacente a HBM” mientras las asignaciones de memoria quedaban por defecto en el gran nodo DDR debido al comportamiento de first-touch en un hilo de calentamiento.
Las páginas calientes vivían lejos, cada petición pagaba acceso remoto y la interconexión quedó saturada.

Arreglarlo fue casi aburrido: alinear CPU y colocación de memoria, cambiar el calentamiento para ejecutarlo en el mismo nodo que los hilos de servicio, y usar --preferred en lugar de membind estricto.
El rendimiento se estabilizó de inmediato. La gran lección no fue “HBM es complicado.” Fue “las suposiciones sobre la topología son bugs en producción.”

Microhistoria 2: La optimización que salió mal

Otra organización ejecutó un trabajo analítico intensivo en memoria. Consiguieron nodos con capacidad HBM y quisieron máximo ancho de banda, así que lanzaron el trabajo con binding estricto:
CPU fijadas al nodo HBM y --membind para forzar todas las asignaciones en HBM.

En benchmarks rindió de forma espléndida para un solo trabajo. Luego ejecutaron dos trabajos por host y todo se vino abajo.
Algunas ejecuciones fallaron por out-of-memory a pesar de que el host tenía mucho DDR libre. Otras “funcionaron” pero eran más lentas que en los hosts antiguos solo con DDR.

Qué pasó: la capacidad HBM era menor que su conjunto de trabajo, y el membind estricto convirtió “capa rápida llena” en “fallo de asignación.”
Cuando no fallaba, el kernel y el asignador pelearon contra la fragmentación; grandes asignaciones se partían, empezó la migración de páginas y el sistema gastó tiempo real solo moviendo páginas.

La solución fue tratar HBM como un tier caliente, no como toda la casa.
Mantuvieron el conjunto más caliente en HBM usando asignación preferida y ajustaron la concurrencia para que el conjunto caliente agregado cupiera.
El trabajo quedó un poco más lento en benchmarks de ejecución única pero mucho más rápido y fiable en rendimiento por nodo en producción.

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

Un equipo de plataforma tenía una costumbre que a los ingenieros les encanta burlarse: cada nueva clase de hardware pasaba por una suite de aceptación “aburrida.”
No una batería de benchmarks elegante. Una lista repetible: verificar topología NUMA, verificar sanity de ancho de banda por nodo, verificar comportamiento de migración de páginas, verificar reporte de ECC,
y registrar líneas base con una versión fija de SO y firmware.

Cuando llegó su primer lote de servidores con HBM, la suite marcó inmediatamente algo raro: el ancho de banda de un nodo NUMA estaba muy por debajo de lo esperado.
El host no parecía “roto.” Sin errores de kernel. Sin alarmas térmicas obvias. Simplemente rendía menos.

Profundizaron y encontraron un problema de configuración de firmware que efectivamente deshabilitaba parte del modo de memoria previsto.
Nada dramático—solo una configuración desigual entre racks. Pero sin la suite de aceptación, el problema habría surgido como una queja vaga y de meses “esta flota está más lenta.”

Arreglaron la configuración antes del despliegue general. Sin heroísmos, sin llamadas de incidente, sin postmortem incómodo sobre por qué nadie lo notó durante ocho semanas.
La práctica que los salvó no fue genialidad; fue repetición.

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

1) Síntoma: Utilización de CPU baja, pero el rendimiento no aumenta con más hilos

Causa raíz: Carga limitada por ancho de banda; los cores están bloqueados por memoria o tráfico de coherencia.

Solución: Mide contadores de ancho de banda de memoria; mueve datos calientes a HBM; reduce el intercambio entre sockets; prefiere páginas grandes cuando corresponda.

2) Síntoma: El nodo HBM muestra mucha memoria libre, pero el rendimiento no mejora

Causa raíz: Las páginas se asignan en DDR debido a first-touch o comportamiento del asignador; HBM está sin usar.

Solución: Aplica numactl --preferred/--membind al lanzar; asegúrate de que el calentamiento corra en el nodo previsto; valida vía /proc/<pid>/numa_maps.

3) Síntoma: Fallos de asignación súbitos (OOM) a pesar de tener mucha RAM libre

Causa raíz: Binding estricto a una tier HBM pequeña; el nodo local se queda sin memoria aunque DDR tenga margen.

Solución: Usa asignación preferida en vez de membind estricto; limita la concurrencia; rediseña para mantener solo el conjunto caliente en HBM.

4) Síntoma: Picos de p99 aparecen tras habilitar NUMA balancing

Causa raíz: Sobrecoste de migración de páginas, especialmente con heaps grandes; kernel moviendo páginas entre tiers bajo carga.

Solución: Ajusta o desactiva NUMA balancing por servicio; haz la colocación explícita; reduce migraciones alineando afinidad de CPU y política de memoria.

5) Síntoma: Gran benchmark para un trabajo, pésimo comportamiento multi-tenant

Causa raíz: HBM es un tier escaso compartido; múltiples trabajos se golpean entre sí o se expulsan las páginas calientes de unos a otros.

Solución: Particiona HBM por cgroup/política NUMA; programa menos trabajos intensivos por host; separa vecinos ruidosos.

6) Síntoma: El rendimiento empeora tras cambiar a huge pages

Causa raíz: Mayor coste de compactación/migración; fragmentación del asignador; estrategia de hugepage inadecuada para el patrón de acceso.

Solución: Usa madvise para THP; fija huge pages solo para regiones que se benefician; valida con histogramas de latencia, no con promedios.

7) Síntoma: El acceso remoto a memoria crece con el tiempo aunque la afinidad esté configurada

Causa raíz: Los hilos migran, se crean nuevos hilos sin fijar, o la política de memoria se hereda de forma inconsistente entre exec/fork.

Solución: Haz cumplir la afinidad en el gestor de servicios; audita la creación de hilos; revisa después de despliegues; verifica con numastat -p.

Listas de verificación / plan paso a paso

Plan paso a paso: evaluar hosts CPU con capacidad HBM para una carga

1. Clasifica la carga: ¿flujo pesado en ancho de banda? ¿latencia aleatoria? ¿mixto? Si no puedes decirlo, no estás listo para comprar hardware.
2. Verifica exposición del hardware: confirma si HBM está en modo caché o como nodo(s) NUMA plano. Regístralo.
3. Establece línea base con colocación solo en DDR: ejecuta la carga con memoria limitada a nodos DDR para obtener una referencia justa.
4. Prueba colocación preferida en HBM: usa --preferred antes de usar --membind.
5. Prueba comportamiento ante fallos: ejecuta dos instancias por host, luego tres. Observa ENOMEM y explosiones de migración de páginas.
6. Comprueba acceso remoto: confirma que la afinidad de CPU y la colocación de memoria permanecen alineadas en estado estable.
7. Vigila latencia de cola (tail): acepta que el rendimiento medio no es tu SLA. Si la migración causa picos p99, considéralo regresión.
8. Operacionaliza: integra verificaciones de topología y validación de colocación en pipelines de aprovisionamiento y despliegue.
9. Decide política de scheduling: los trabajos intensivos en ancho de banda deben limitarse por host; trata HBM como un recurso con cuota.
10. Entrega el panel: uso de memoria por nodo, migraciones, señales de acceso remoto y contadores de ancho de banda deben ser visibles antes del primer incidente.

Lista de hacer y no hacer para producción

• Haz: trata la capacidad HBM como una restricción dura en producción. Haz seguimiento como del espacio en disco.
• Haz: verifica la colocación con /proc/<pid>/numa_maps y numastat después del despliegue.
• Haz: comienza con --preferred para evitar fallos de asignación frágiles.
• No hagas: asumas que HBM es “siempre más rápido.” Algunas cargas están limitadas por latencia, no por ancho de banda.
• No hagas: fijes CPU sin fijar memoria. Así es como manufacturas acceso remoto.
• No hagas: benchmarks single-tenant y desplegar multi-tenant sin volver a probar. HBM cambia la dinámica de contención.

Preguntas frecuentes

1) ¿HBM en CPUs es lo mismo que “memoria unificada” en GPUs?

No. Las GPUs hablan de memoria unificada como un modelo de programación entre espacios de direcciones CPU/GPU. HBM en CPUs es una capa de memoria física con distinto ancho de banda/capacidad,
usualmente gestionada por políticas del SO o por asignadores.

2) ¿HBM reemplazará DDR en servidores?

No de forma general. HBM es demasiado caro por GB y demasiado pequeño por socket para flotas generales. Espera sistemas híbridos: algo de HBM en paquete más DDR para capacidad.

3) ¿HBM siempre tiene menor latencia que DDR?

No como regla en la que basar producción. La ventaja de HBM es el ancho de banda. La latencia efectiva depende de la plataforma, la contención y si accedes localmente.

4) Si tengo HBM, ¿debería desactivar las cachés de CPU o cambiar ajustes de caché?

No. Las cachés siguen importando. HBM no reemplaza L1/L2/L3; reduce la presión del subsistema de memoria para datos que fallan en caché.
Enfócate en la colocación y los patrones de acceso, no en supersticiones sobre cachés.

5) ¿Cuál es la política más segura y simple para empezar?

Comienza con numactl --preferred=<nodo HBM> en lugar de un --membind estricto.
Preferred usa HBM cuando está disponible pero recurre a DDR en vez de fallar asignaciones.

6) ¿Cómo interactúa esto con contenedores y Kubernetes?

El pinning de CPU es común; el pinning de memoria lo es menos. Si programas pods en “nodos HBM” sin aplicar política de memoria, puedes obtener regresiones por memoria remota.
Trata HBM como un recurso programable o usa wrappers a nivel de nodo que establezcan la política de memoria al lanzar servicios.

7) ¿Hace CXL a HBM irrelevante?

No. CXL es excelente para expandir y agrupar memoria con mayor latencia. HBM es para ancho de banda cerca del cómputo.
En un futuro jerárquico puedes tener HBM (rápido), DDR (grande) y CXL (más grande) simultáneamente.

8) ¿Cuál es el mayor riesgo operacional con hosts CPU equipados con HBM?

Mal colocación: páginas calientes aterrizando en la tier lenta mientras la tier rápida está inactiva, o binding estricto causando fallos de asignación.
El síntoma es “lentitud misteriosa” sin saturación obvia. La solución es conciencia de topología y verificación de políticas.

9) ¿Qué debo poner en paneles para una flota con HBM?

Uso de memoria por nodo NUMA, indicadores de memoria remota, contadores de ancho de banda de memoria (uncore), migración de páginas y latencia p99.
La utilización de CPU sola es básicamente decorativa.

Pasos prácticos siguientes

Si estás decidiendo si HBM en CPUs pertenece a tu flota, no empieces con las diapositivas del vendedor. Empieza con tus cuellos de botella.
Prueba que estás limitado por ancho de banda y luego prueba que puedes mantener los datos calientes en la capa rápida sin políticas frágiles.

• Esta semana: ejecuta el “Guion rápido de diagnóstico” en una carga lenta y determina si el limitador es ancho de banda, latencia o NUMA remoto.
• Este mes: construye una suite de aceptación repetible para nuevas clases de hardware: topología, sanity de ancho de banda, comportamiento de migración y p99 base bajo carga controlada.
• Antes de comprar hardware: modela HBM como un recurso de cuota escaso y decide cómo lo programarás, observarás y evitarás que se convierta en una tragedia compartida.

La memoria moviéndose al paquete no es un argumento de ciencia ficción distante. Es la industria admitiendo que el ancho de banda es un presupuesto que puedes gastar.
Trátalo como tal, y las CPUs con HBM son una herramienta afilada. Trátalo como “RAM más rápida,” y te encontrarás con ello durante un incidente.