Evolución de la VRAM: de GDDR simple a pura locura

Qué es realmente la VRAM (y qué no es)

La VRAM es la memoria de alta banda ancha directamente conectada a la GPU. No es “RAM de GPU” en el mismo sentido que la DRAM del sistema.
Está diseñada para alimentar procesadores masivamente paralelos con un rendimiento predecible, no para ser un montón de memoria general amigable.
La GPU ahora puede hacer paginación y sobredesuscripción, claro. Pero si tu conjunto de trabajo no cabe, lo vas a pagar en algún sitio doloroso: paradas, copias o picos de latencia.

Piensa en la ruta de memoria de la GPU como lo haría un ingeniero de almacenamiento:
las unidades de cómputo son tus CPUs; la VRAM es tu NVMe local; PCIe es el enlace de red; la RAM del host es un almacenamiento remoto; y el disco es una catástrofe.
Puedes hacer que todo “funcione”. No te gustará la factura.

La jerarquía real: caches, VRAM, memoria del host y el enlace intermedio

La mayoría de los argumentos de rendimiento sobre VRAM mueren porque la gente se salta la jerarquía:

• Caches en chip (L2, a veces L1/memoria compartida) son pequeñas pero rápidas y críticas para la reutilización.
• VRAM (GDDR/HBM) es tu reserva de ancho de banda; la latencia es peor que la cache pero predecible.
• Memoria del host es enorme pero “lejos”; incluso con trucos inteligentes, es otro planeta de latencia.
• PCIe / NVLink es la garganta; cuando es el limitador, todo lo demás es irrelevante.

Tu trabajo en producción no es memorizar esto. Es identificar cuál nivel estás usando accidentalmente como tu ruta caliente.

Una cita que vale la pena tatuar en tu runbook

Idea parafraseada — Gene Amdahl: «La aceleración de un sistema está limitada por la parte que no mejoraste».

Hechos y contexto histórico (concreto, no vaguedades de museo)

1. La “VRAM” temprana era memoria literal de vídeo diseñada para buffers de imagen y pipelines de pantalla; la aceleración 3D la transformó en una línea de alimentación para cómputo.
2. GDDR evolucionó desde DDR SDRAM pero priorizó ancho de banda y señalización sobre latencia absoluta; las GPUs toleran latencia ejecutando otras warps.
3. El ancho de bus se convirtió en campo de marketing: interfaces de 128, 256, 384 e incluso 512 bits se usaron para escalar el ancho de banda sin empaquetado exótico.
4. GDDR5 ayudó a normalizar tasas de datos “efectivas” en las hojas de especificaciones; lo que importa en la práctica es el ancho de banda sostenido según tu patrón de acceso.
5. HBM trasladó la batalla del PCB al paquete: interposers de silicio y dados apilados reemplazaron extensos ruteos y dolores de ruido de potencia.
6. ECC en VRAM se volvió habitual en GPUs de datacenter porque los errores silenciosos a escala no son “raros”, son “semanales”.
7. La compresión de memoria GPU se volvió una característica real para gráficos y a veces para cómputo; depende de la carga y no es gratis.
8. La memoria unificada y la sobredesuscripción existen porque la gente siempre reservará más de lo que posee; el rendimiento es el castigo.

Chiste 1: La VRAM es como el minibar del hotel—técnicamente disponible, pero si sigues recurriendo a él, te cobrarán por la mañana.

De GDDR a GDDR6X: los años del bus ancho

Durante mucho tiempo, la estrategia para más ancho de banda de VRAM fue directa:
acelerar la señal por pin, añadir más pines, ensanchar el bus y rezar para que tu ingeniero de diseño de placa no dimita.
Las generaciones de GDDR son básicamente la historia de «¿hasta qué punto podemos empujar señalización de alta velocidad a través de un PCB antes de que la física presente una orden de restricción?»

Matemática de ancho de banda que realmente importa

El número llamativo es el ancho de banda de memoria:

• Ancho de banda ≈ (tasa de datos por pin) × (ancho del bus) ÷ 8

Ejemplo: 16 Gbps por pin en un bus de 256 bits da ~512 GB/s de ancho de banda teórico pico. El ancho de banda que logres puede ser mucho menor según patrones de acceso, contención y comportamiento del controlador.

Qué hacía “simple” a GDDR (y por qué dejó de serlo)

“Simple” es relativo. GDDR siempre fue exigente:

• Muchos chips discretos alrededor del paquete de la GPU, cada uno con líneas de alta velocidad que deben emparejarse en longitud.
• Mucha complejidad de entrega de potencia porque conmutar esas señales a alta frecuencia es caro.
• Distribución térmica en la placa: los chips de memoria se calientan; están cerca de los VRM; el flujo de aire nunca es tan bueno como el dibujo CAD.

A medida que las tasas de señalización subieron, los problemas se hicieron más ruidosos: diafonía, reflexiones, pérdidas y márgenes de tiempo. GDDR6X fue más allá con esquemas de señalización más agresivos para exprimir más bits por segundo por pin. Eso es genial para ancho de banda, pero aumenta la sensibilidad a la calidad de la placa, térmicas y afinado. En otras palabras: es más rápido y también más temperamental.

Realidad operativa: por qué el “mismo tamaño de VRAM” puede comportarse diferente

Dos GPUs pueden tener ambas “24 GB de VRAM” y aun así comportarse radicalmente distinto:

• Una puede tener un bus de 384 bits, otra de 256 bits.
• Una puede funcionar a mayores tasas de datos efectivas pero reducir reloj por calor.
• Una puede tener mejor programación del controlador de memoria para tu patrón (aleatorio vs streaming).
• Una puede tener un L2 mayor que enmascara la latencia de memoria y reduce el tráfico a VRAM.

Si tratas la capacidad de VRAM como toda la historia, comprarás la GPU equivocada y pasarás meses “optimizando” código que nunca fue el verdadero limitador.

Llega HBM: apilar memoria como si fuera un rack de centro de datos

HBM (High Bandwidth Memory) es la industria admitiendo que empujar señales cada vez más rápidas sobre una placa tradicional se estaba volviendo un crimen contra la calidad de vida.
La alternativa fue salvaje: colocar pilas de memoria justo al lado de la GPU en el mismo paquete, conectarlas con un interposer y usar una interfaz muy ancha a velocidades de reloj más bajas.

Qué cambia HBM en la capa física

HBM apila múltiples dados DRAM verticalmente y los conecta con TSVs (through-silicon vias). En lugar de 8–12 chips discretos alrededor de la GPU, obtienes unas pocas pilas en el paquete.
La interfaz es extremadamente ancha, que es la clave: obtienes gran ancho de banda sin necesitar velocidad por pin insana.

En la práctica esto significa:

• Cables más cortos (en paquete) → mejor integridad de señal.
• Reloj más bajo para un ancho de banda dado → a menudo mejor eficiencia energética por bit.
• La complejidad del empaquetado aumenta → riesgo de rendimiento, coste y restricciones de suministro.

La victoria oculta: menos restricciones a nivel de placa

Con HBM, la placa deja de ser un campo de batalla de ruteo de alta velocidad. Eso puede mejorar la consistencia entre proveedores y reducir problemas de “esta revisión de placa específica está maldita”.
No los elimina: la entrega de potencia y las térmicas aún importan, pero la interfaz de memoria está menos expuesta a la variabilidad del diseño de placa.

El coste oculto: escalado de capacidad y segmentación de producto

La capacidad HBM viene en tamaños de pila y conteos de pilas. No puedes cambiar “unos cuantos chips más” como podrías en diseños GDDR.
Los proveedores pueden (y lo hacen) usar esto para segmentar productos: ancho de banda, capacidad y precio quedan fuertemente ligados. Si necesitas más VRAM, puede que te veas obligado a comprar más ancho de banda del que necesitas—o al revés.

Chiste 2: HBM es lo que pasa cuando le dices a los ingenieros de hardware “el ruteo es difícil” y responden inventando una ciudad 3D.

Por qué ganó el ancho de banda (y por qué la capacidad aún importa)

Las GPUs son máquinas de rendimiento por flujo. Ocultan la latencia ejecutando mucho trabajo en vuelo. Pero no pueden ocultar un techo de ancho de banda para siempre.
Cuando escalas cómputo, debes escalar el suministro de datos o construirás un coche deportivo con una pajita para la gasolina.

Presión de ancho de banda: de dónde viene en cargas reales

• Mayor resolución y shaders más ricos en gráficos impulsaron el tráfico de texturas y buffers de imagen.
• Entrenamiento de IA es esencialmente un generador de tráfico de memoria: activaciones, gradientes, estado del optimizador y lecturas/escrituras frecuentes.
• Inferencia con tamaños de batch pequeños puede ser sensible a la latencia y poco amigable con caches, aumentando la presión sobre VRAM y PCIe.
• Cómputo científico a menudo toca arrays grandes con reutilización limitada; eres tan rápido como tu subsistema de memoria.

Presión de capacidad: por qué “solo añade más VRAM” no es la respuesta completa

La capacidad importa cuando el conjunto de trabajo no cabe. Pero cuando cabe, a menudo estás limitado por la velocidad con la que puedes transmitirlo.
La trampa: la gente compra capacidad de VRAM para resolver problemas de ancho de banda y luego se pregunta por qué el rendimiento cambia poco.

Heurística práctica:

• Si obtienes OOM, tienes un problema de capacidad.
• Si nunca OOM pero la utilización es baja, probablemente tienes un problema de ancho de banda, de lanzamiento/latencia de kernels o de transferencias de datos.
• Si tu GPU está “ocupada” pero lenta, puedes estar limitado por cómputo—o sufriendo patrones de acceso a memoria pobres que aparentan utilización de cómputo pero se comportan como stalls de memoria.

Por qué la “velocidad” de la VRAM no es un solo número

El ancho de banda pico no es el ancho de banda sostenido. Lo sostenido depende de:

• Patrón de acceso: coalescido vs disperso, stride, reutilización.
• Tasa de aciertos en cache: una L2 mayor puede convertir “limitado por VRAM” en “limitado por cache”, que suele ser mejor.
• Concurrencia: muy poca paralelismo y no puedes ocultar la latencia; demasiado y tiznas caches.
• Comportamiento térmico: la reducción de reloj de memoria puede cortar el ancho de banda en silencio y crear regresiones “aleatorias”.

Compromisos de ingeniería: coste, energía, rendimiento y fiabilidad

La evolución de la VRAM no es una línea recta de “mejor”. Es una pelea a cuchillo entre la física, la economía y las operaciones.
Si gestionas flotas de GPUs en producción, vives dentro de estos compromisos te guste o no.

GDDR: más fácil escalar disponibilidad, más difícil domar la placa

• Pros: cadena de suministro modular, a menudo más barato por GB, fabricación madura, configuraciones de capacidad flexibles.
• Contras: complejidad de ruteo en la placa, desafíos por mayor velocidad por pin, potencia de memoria y calor repartidos por el PCB.

HBM: ancho de banda elegante, empaquetado complicado

• Pros: ancho de banda enorme, a menudo buena eficiencia energética por bit, menos dolor a nivel de ruteo de placa.
• Contras: empaquetado caro, sensibilidad al rendimiento, menos opciones de configuración y suministro ajustado cuando sube la demanda.

Fiabilidad en el mundo real: ECC, manejo de errores y fallos “blandos”

Si haces entrenamiento de ML o HPC de larga duración, la corrupción silenciosa es un enemigo mayor que los crashes. Un crash es ruidoso; la corrupción cuesta y es silenciosa.
ECC en VRAM ayuda, pero no te hace inmortal. Aún necesitas:

• Monitoreo de errores (correctables en tendencia al alza es una advertencia).
• Monitoreo térmico (el calor acelera fallos y desencadena throttling).
• Políticas de cuarentena para GPUs que empiezan a comportarse mal bajo carga.

Nota de producción: “El trabajo terminó” no es lo mismo que “la salida es correcta”. Trata los errores de memoria GPU como eventos de integridad de datos, no como eventos de rendimiento.

Tres microhistorias corporativas desde las trincheras

Microhistoria 1: El incidente causado por una suposición errónea (capacidad ≠ localidad)

Un equipo desplegó un nuevo servicio de inferencia en una flota de GPUs con abundante VRAM. El modelo cabía cómodamente. Nadie esperaba que la memoria fuera la historia.
La latencia en staging se veía bien. La producción empezó bien también, luego se degradó durante las ventanas de pico. No fue un acantilado; una descomposición lenta.

El instinto inicial del on-call fue el tamaño de batch. Lo redujeron, vieron alguna mejora y declararon victoria. Dos días después el mismo patrón volvió.
El síntoma real era que la utilización de GPU oscilaba mientras el uso de CPU del host se disparaba. El sistema estaba haciendo trabajo—simplemente no el trabajo por el que pagabas.

La suposición errónea: “Si el modelo cabe en VRAM, entonces la memoria no es el cuello de botella.” En realidad, la ruta de la petición hacía tokenización dinámica y ocasional ingeniería de características en CPU. Cada petición provocaba múltiples pequeñas transferencias host→device. Bajo carga, esas transferencias se serializaron detrás de un PCIe saturado y un montón de puntos de sincronización.

Arreglarlo no fue glamoroso: fusionar el preprocesado, agrupar transferencias, usar memoria del host pinned para DMA estable y eliminar sincronizaciones implícitas en el manejador de peticiones.
La capacidad de VRAM no era la limitación. Era la localidad y el comportamiento de las transferencias.

La lección que retuvieron: la capacidad te dice “¿se va a estrellar?”; no “¿va a escalar?”. Si no perfilas la ruta end-to-end, el enlace se convierte en tu red de almacenamiento oculta—excepto que es PCIe y no perdona.

Microhistoria 2: La optimización que salió mal (reutilización inteligente conoce a la fragmentación)

Otra organización intentó reducir la sobrecarga de asignación introduciendo un pool de buffers GPU personalizado. La intención era buena: menos allocs, menos frees, menos sobrecarga, latencia más estable.
Se lanzó como una librería compartida usada por múltiples servicios. “Funcionaba” en benchmarks.

En producción, un subconjunto de cargas empezó a fallar con errores out-of-memory aunque nvidia-smi mostraba mucha VRAM libre.
Peor, las fallas eran ruidosas e intermitentes. Reiniciar el servicio normalmente “lo arreglaba” hasta que dejó de hacerlo. Rara especie de comportamiento de allocator, pero en GPU.

El pool retenía grandes bloques y su estrategia de reutilización no coincidía con la distribución real de tamaños de asignación. Con el tiempo, convirtió la VRAM en un chatarrero de fragmentos inutilizables.
El allocator interno del framework podría haber manejado esto mejor, pero el pool personalizado se situó encima, luchando con él.

El rollback fue doloroso porque otras mejoras de latencia se habían empaquetado en la misma release. Acabaron manteniendo un pool pequeño para unos pocos buffers calientes y dejando que el framework gestionara el resto.
También añadieron una ventana de mantenimiento periódica de “defrag mediante reinicio” para los peores casos—aburrido, sí, pero mejor que fatiga del pager.

Conclusión: el pooling de memoria puede ayudar. Pero si no mides la fragmentación y el comportamiento a largo plazo bajo tráfico realista, tu “optimización” es solo un apagón diferido.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día (presupuestos de error para la salud de la VRAM)

Un clúster GPU usado para jobs de entrenamiento de larga duración tenía una política que sonaba a papeleo: seguir errores corregibles de memoria por GPU y poner en cuarentena dispositivos que cruzaran un umbral.
Los ingenieros se quejaban porque ocasionalmente retiraba hardware caro “que aún funcionaba”.

Luego un nuevo entrenamiento empezó a producir métricas sutilmente peores. No catastrófico. Simplemente consistentemente peor. La gente discutía sobre drift de datos, seeds aleatorios y ajustes del optimizador.
Mientras tanto, un nodo mostró un repunte en errores correctables de VRAM durante períodos de alta temperatura. El scheduler había colocado múltiples ejecuciones en ese nodo durante semanas.

Porque la organización tenía la práctica aburrida, el nodo fue drenado automáticamente y la GPU puesta en cuarentena. El job de entrenamiento se reinició en otro lado.
Las métricas volvieron a rangos esperados. Sin depuraciones heroicas, sin cazas de brujas.

El postmortem fue corto e insatisfactorio en el mejor sentido: “detectamos degradación de hardware temprano y evitamos corrupción silenciosa.” Eso es lo que quieres en producción: menos historias emocionantes.

Tareas prácticas: comandos, significado de la salida y la decisión que tomas

Estas son las comprobaciones que puedes ejecutar durante un incidente sin convertirlo en un proyecto científico.
Los comandos son orientados a Linux y suponen herramientas NVIDIA cuando procede. Adapta según sea necesario.

Tarea 1: Identificar GPUs, drivers y si el SO ve lo que crees que ve

cr0x@server:~$ nvidia-smi
Tue Jan 13 10:41:05 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14    Driver Version: 550.54.14    CUDA Version: 12.4              |
|-----------------------------------------+----------------------+----------------------|
| GPU  Name                  Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf            Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|  0  NVIDIA A100-PCIE-40GB           On  | 00000000:17:00.0 Off | 0                    |
|  1  NVIDIA A100-PCIE-40GB           On  | 00000000:65:00.0 Off | 0                    |
+-----------------------------------------+----------------------+----------------------|

Qué significa: Confirma inventario de GPUs, versión del driver y señales básicas de salud.

Decisión: Si faltan GPUs o hay un desajuste driver/CUDA evidente, deja de tunear cargas y arregla la plataforma primero.

Tarea 2: Vigilar uso de VRAM y utilización en el tiempo (detectar thrash, picos e inactividad)

cr0x@server:~$ nvidia-smi dmon -s pucm -d 1
# gpu   pwr  ut   mem   sm   enc  dec  mclk  pclk
# Idx     W   %     %    %     %    %   MHz   MHz
    0   210  35    88   34     0    0  1215  1410
    1   115   5    12    3     0    0   405   585

Qué significa: La GPU 0 está centrada en memoria (88% mem usado) con utilización moderada; GPU 1 está mayormente ociosa.

Decisión: Si la utilización es baja mientras el uso de memoria es alto, sospecha stalls de memoria, sincronización o problemas de pipeline de entrada en lugar de “necesitar más GPUs”.

Tarea 3: Confirmar ancho y generación del enlace PCIe (un asesino silencioso de throughput)

cr0x@server:~$ nvidia-smi -q | sed -n '/PCI/,+12p'
    PCI
        Bus                             : 0x17
        Device                          : 0x00
        Domain                          : 0x0000
        Bus Id                          : 00000000:17:00.0
        PCIe Generation
            Max                         : 4
            Current                     : 3
        Link Width
            Max                         : 16x
            Current                     : 8x

Qué significa: Esperabas Gen4 x16; obtuviste Gen3 x8. Eso es un verdadero cuello de botella para transferencias.

Decisión: Trata esto como un problema de hardware/plataforma (slot, BIOS, riser, bifurcación). No pierdas tiempo “optimizando” kernels mientras el bus está cojo.

Tarea 4: Validar localidad NUMA (la colocación de memoria CPU afecta transferencias host→device)

cr0x@server:~$ nvidia-smi topo -m
        GPU0    GPU1    CPU Affinity    NUMA Affinity
GPU0     X      PHB     0-31            0
GPU1    PHB      X      32-63           1

Qué significa: GPU0 es local al nodo NUMA 0, GPU1 al nodo 1. “PHB” indica que el tráfico cruza un PCIe Host Bridge.

Decisión: Fija hilos de CPU y asigna memoria del host en el nodo NUMA correcto. Si ignoras esto, manufacturarás latencia.

Tarea 5: Detectar problemas ECC en VRAM (tendencias en correctables son advertencias tempranas)

cr0x@server:~$ nvidia-smi -q -d ECC | sed -n '1,120p'
ECC Mode
    Current                         : Enabled
    Pending                         : Enabled
ECC Errors
    Volatile
        Single Bit
            Device Memory           : 12
        Double Bit
            Device Memory           : 0
    Aggregate
        Single Bit
            Device Memory           : 893
        Double Bit
            Device Memory           : 0

Qué significa: Existen errores corregibles y pueden estar en tendencia. Double-bit (incorregible) es cero, bien.

Decisión: Si los correctables agregados suben rápidamente o se correlacionan con temperatura/carga, pon la GPU en cuarentena antes de que se convierta en un problema de integridad de datos.

Tarea 6: Revisar uso de VRAM por proceso (encuentra al verdadero consumidor)

cr0x@server:~$ nvidia-smi --query-compute-apps=pid,process_name,used_memory --format=csv
pid, process_name, used_memory [MiB]
18422, python, 31748 MiB
19103, python,  6020 MiB

Qué significa: El PID 18422 posee la VRAM. Ahora tienes un objetivo.

Decisión: Si un proceso “sidecar” o un notebook despistado está acaparando, mátalo o muévelo. Si es el servicio principal, investiga comportamiento de asignación y caching.

Tarea 7: Buscar razones de throttling (tu ancho de banda podría estar derritiéndose)

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | sed -n '1,140p'
Performance State                    : P2
Clocks Throttle Reasons
    Idle                            : Not Active
    Applications Clocks Setting     : Not Active
    SW Power Cap                    : Active
    HW Slowdown                     : Not Active
    HW Thermal Slowdown             : Not Active

Qué significa: Un límite de potencia por software está activo; los relojes pueden estar retenidos.

Decisión: Si el power cap es inesperado, revisa límites de potencia, térmicas y políticas del datacenter. Una GPU capada puede parecer “misteriosamente lenta” bajo carga de ancho de banda.

Tarea 8: Correlacionar actividad GPU con presión de CPU e I/O (no culpes a la VRAM por stalls de almacenamiento)

cr0x@server:~$ pidstat -dru -p 18422 1 5
Linux 6.5.0 (server)  01/13/2026  _x86_64_  (64 CPU)

10:41:18 PM   UID       PID   %usr %system  %CPU   RSS   kB_rd/s kB_wr/s  iodelay  Command
10:41:19 PM  1001     18422  220.0     8.0 228.0  18G    5120.0    120.0        8  python

Qué significa: Alta actividad de CPU y lecturas significativas. Si tu GPU está infrautilizada, es posible que tu pipeline de entrada sea el verdadero cuello de botella.

Decisión: Incrementa prefetching, usa almacenamiento local más rápido o etapa datasets. No persigas ancho de banda VRAM cuando estás hambriento de datos en la GPU.

Tarea 9: Verificar hugepages y límites de memoria bloqueada (pinned memory necesita soporte OS)

cr0x@server:~$ ulimit -l
64

Qué significa: El proceso puede bloquear solo 64 KB de memoria. Las asignaciones de memoria pinned del host pueden fallar o degradarse.

Decisión: Para servicios que dependen de memoria pinned, aumenta límites memlock (con cuidado) vía systemd o política de seguridad, y luego valida el comportamiento.

Tarea 10: Inspeccionar logs del sistema por eventos PCIe/NVRM (problemas hardware disfrazados de “código lento”)

cr0x@server:~$ journalctl -k -S -2h | egrep -i 'nvrm|pcie|aer|xid' | tail -n 20
Jan 13 08:55:02 server kernel: pcieport 0000:00:03.1: AER: Corrected error received: id=00e1
Jan 13 08:55:02 server kernel: pcieport 0000:00:03.1: PCIe Bus Error: severity=Corrected, type=Physical Layer
Jan 13 08:55:02 server kernel: NVRM: Xid (PCI:0000:17:00): 79, GPU has fallen off the bus.

Qué significa: Errores PCIe y un Xid indicando que la GPU se cayó del bus. Eso no es un problema de “optimización”.

Decisión: Drena el nodo, revisa cableado/risers/asiento del slot, firmware, entrega de potencia y considera reemplazo de hardware.

Tarea 11: Comprobar reloj real de memoria GPU durante carga

cr0x@server:~$ nvidia-smi --query-gpu=clocks.mem,clocks.gr,temperature.gpu,power.draw --format=csv -l 1
clocks.mem [MHz], clocks.gr [MHz], temperature.gpu, power.draw [W]
1215, 1410, 78, 232.45
405,  585,  60, 115.10

Qué significa: Si el reloj de memoria baja bajo carga inesperadamente, probablemente estás sufriendo throttling (potencia/térmico) o estás en un estado de rendimiento inferior.

Decisión: Arregla refrigeración, límites de potencia o políticas de clocks persistentes/aplicación. Si no, los gráficos de ancho de banda te engañarán.

Tarea 12: Confirmar que el contenedor ve las mismas capacidades GPU (mismas cgroups y runtime)

cr0x@server:~$ docker exec -it ml-infer bash -lc 'nvidia-smi -L'
GPU 0: NVIDIA A100-PCIE-40GB (UUID: GPU-2c1b0f0a-1a7c-9c1a-bd73-3b0b62f4d2b2)

Qué significa: El contenedor tiene acceso a la GPU. Si no lo tiene, verás fallos en CPU y terrible “rendimiento VRAM” (porque no estás usando VRAM).

Decisión: Arregla la configuración del runtime antes de tocar el código del modelo.

Tarea 13: Medir throughput PCIe durante transferencias (detectar dominio de copias host-device)

cr0x@server:~$ nvidia-smi dmon -s t -d 1
# gpu    rxpci   txpci
# Idx   MB/s    MB/s
    0    9800    2100

Qué significa: Tráfico PCIe de recepción significativo. Si tu tiempo de kernel es pequeño, las copias pueden dominar la latencia.

Decisión: Reduce transferencias (batching, fusión), usa memoria pinned y evita puntos de sincronización que serialicen copias y cómputo.

Tarea 14: Inspeccionar asignación de memoria NUMA del CPU mientras la GPU está ocupada

cr0x@server:~$ numastat -p 18422
Per-node process memory usage (in MBs) for PID 18422 (python)
Node 0          14820.5
Node 1           120.0
Total          14940.5

Qué significa: La memoria del proceso está mayormente en el Nodo 0. Si alimenta la GPU1 en el Nodo 1, fuerzas tráfico cruzado entre sockets.

Decisión: Fija el proceso al CPU cercano a su GPU y asigna memoria localmente (numactl o pinning a nivel de servicio).

Guía de diagnóstico rápido: encuentra el cuello de botella en minutos

Cuando una carga GPU es lenta, no te toca adivinar. Triasea. El objetivo es identificar la capa limitante—cómputo, ancho de banda VRAM, capacidad VRAM, transferencia PCIe/NVLink, pipeline de entrada CPU o throttling—antes de tocar código.

Primero: establece si la GPU está realmente ocupada

• Ejecuta nvidia-smi y nvidia-smi dmon.
• Si la utilización de GPU es baja: sospecha hambre de datos, sincronización, pipeline CPU o sobrecarga de transferencias.
• Si la utilización de GPU es alta: podrías estar limitado por cómputo o por ancho de banda de memoria; continúa.

Segundo: revisa las “mentiras fáciles” (throttling y problemas de bus)

• Confirma generación y ancho del enlace PCIe: nvidia-smi -q.
• Revisa razones de throttling: nvidia-smi -q -d PERFORMANCE.
• Escanea logs del kernel por AER/Xid: journalctl -k.

Si alguno de esos está mal, para. Arregla la salud de la plataforma. Optimizar rendimiento sobre tuberías rotas es solo teatro de rendimiento.

Tercero: decide si es presión de capacidad o de ancho de banda

• Presión de capacidad: OOMs, expulsiones frecuentes/sobredesuscripción, VRAM cerca del 100% con churn.
• Presión de ancho de banda: la VRAM cabe pero la velocidad es baja; los kernels muestran alta carga de memoria y baja intensidad aritmética; relojes de memoria y patrones de utilización coinciden.

Cuarto: valida transferencias y localidad

• Usa nvidia-smi dmon -s t para ver niveles de tráfico PCIe.
• Usa nvidia-smi topo -m y numastat para chequear colocación NUMA.
• Si el servicio está en contenedor, confirma visibilidad GPU dentro del contenedor.

Quinto: solo ahora perfila a fondo

Una vez que hayas establecido que la GPU está sana, el enlace correcto, sin throttling y sin hambre de datos, entonces recurre a herramientas de perfilado más profundas.
De lo contrario generarás gráficos que no explican nada.

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

1) Síntoma: “La VRAM está llena, pero el rendimiento está bien… hasta que no”

Causa raíz: fragmentación del allocator o comportamiento de caching que reduce lentamente el espacio contiguo usable.

Solución: reduce la variedad de buffers de larga vida, evita pools personalizados salvo que puedas medir fragmentación y programa reinicios controlados para fugas conocidas.

2) Síntoma: baja utilización GPU, alta latencia y gran tráfico PCIe

Causa raíz: copias host-device dominan; sincronización excesiva fuerza ejecución serial.

Solución: agrupa transferencias, usa memoria pinned con criterio, solapa copias y cómputo, y elimina puntos de sincronización implícitos en el código de petición.

3) Síntoma: regresión súbita tras migrar a GPU con “VRAM más rápida”

Causa raíz: throttling térmico/de potencia o menor ancho de banda efectivo debido a downclocking de memoria bajo carga sostenida.

Solución: valida relojes bajo carga; mejora refrigeración; ajusta límites de potencia si la política lo permite; asegúrate de que el flujo de aire no esté bloqueado por cableado.

4) Síntoma: “hangs” intermitentes de GPU o trabajos que fallan en varios modelos

Causa raíz: errores PCIe, riser/slot defectuoso, entrega de potencia marginal o una GPU empezando a fallar.

Solución: revisa logs del kernel por AER/Xid; reasienta hardware; actualiza firmware; pon GPUs sospechosas en cuarentena según tendencia de errores.

5) Síntoma: trabajo multi-GPU más lento que en una sola GPU

Causa raíz: limitación de interconexión (topología PCIe, falta de caminos NVLink), o el overhead de sincronización de gradientes domina.

Solución: verifica la topología con nvidia-smi topo -m; fija procesos; usa la estrategia de paralelismo adecuada; evita emparejamientos de GPUs entre sockets.

6) Síntoma: OOM aunque haya “memoria libre”

Causa raíz: fragmentación, pools reservados o múltiples procesos con allocators separados pueden hacer que lo “libre” sea inútil para una asignación contigua grande.

Solución: identifica uso por proceso; consolida procesos o limita concurrencia; reduce el tamaño pico de asignación; reinicia para limpiar fragmentación cuando sea necesario.

7) Síntoma: métricas de entrenamiento se vuelven “raras” sin crashes

Causa raíz: riesgo de corrupción silenciosa, hardware inestable o nondeterminismo expuesto por precisión mixta y kernels agresivos.

Solución: monitorea tendencias ECC; aísla hardware; ejecuta checks de reproducibilidad; desactiva caminos de fast-math riesgosos temporalmente para validar.

8) Síntoma: “Añadimos capacidad VRAM; el rendimiento no cambió”

Causa raíz: estabas limitado por ancho de banda o por transferencias, no por capacidad.

Solución: mide el ancho de banda logrado, revisa tráfico PCIe, mejora localidad y patrones de acceso, y considera GPUs con mayor ancho de banda o caches más grandes.

Listas de verificación / plan paso a paso

Checklist A: Elegir entre GDDR y HBM (qué hacer, no qué debatir)

1. Clasifica la carga: intensiva en streaming (ancho de banda), con mucha reutilización (cache) o intensiva en capacidad (gran working set).
2. Mide comportamiento de transferencias: throughput host↔device y frecuencia bajo tráfico real.
3. Decide por qué pagas:
   • Elige HBM cuando el ancho de banda es el limitador y puedes justificar empaquetado premium.
   • Elige GDDR cuando la capacidad/€ y la flexibilidad de suministro importan más, y tus cargas toleran menor ancho de banda.
4. Presupuesta térmicas: si no puedes mantener relojes de memoria estables, el ancho de banda teórico es fantasía.
5. Planifica fiabilidad: exige ECC donde la corrección importe; fija umbrales de cuarentena y automatiza el drenado.

Checklist B: Despliegue en producción de una carga GPU (evita los gatillos clásicos)

1. Valida ancho/gen del enlace PCIe y la topología en cada clase de nodo.
2. Habilita persistence mode si tu entorno se beneficia de una inicialización estable y menor jitter.
3. Configura y documenta límites de potencia y políticas de application clocks; no lo dejes al folclore.
4. Fija hilos de CPU y memoria del host al dominio NUMA de la GPU para servicios sensibles a latencia.
5. Instrumenta: utilización GPU, memoria usada, reloj de memoria, RX/TX PCIe, eventos ECC y latencia tail.
6. Prueba carga con distribuciones de peticiones realistas (no solo throughput en steady-state).
7. Define una respuesta operativa: qué desencadena un drenado, qué desencadena un rollback, qué desencadena cuarentena de hardware.

Checklist C: Cuando el rendimiento empeora tras una actualización de driver o kernel

1. Compara salida de nvidia-smi (driver, compatibilidad CUDA) pre/post.
2. Revisa nuevo comportamiento de throttling bajo carga sostenida.
3. Verifica que la negociación del enlace PCIe no cambió (regresiones Gen/ancho ocurren).
4. Revalida acceso GPU del runtime de contenedores y montajes de librerías.
5. Solo entonces perfila kernels y tráfico de memoria; no asumas que el compilador empeoró.

Preguntas frecuentes

1) ¿La velocidad de la VRAM es principalmente MHz?

No. El ancho de banda es producto de la tasa por pin y el ancho del bus (y la arquitectura). Los MHz solos ignoran método de señalización, ancho y eficiencia del controlador.

2) ¿Por qué las GPUs toleran mayor latencia de memoria que las CPUs?

Las GPUs ocultan la latencia con concurrencia masiva: cuando una warp se bloquea, otras corren. Eso funciona hasta que golpeas un techo de ancho de banda o tu carga carece de paralelismo.

3) Si mi modelo cabe en VRAM, ¿puedo ignorar PCIe?

No puedes. Muchos caminos de inferencia aún copian entradas/salidas con frecuencia, y pipelines de preprocesado pueden forzar sincronización. PCIe se vuelve el cuello de botella de forma silenciosa y fiable.

4) ¿HBM siempre es mejor que GDDR?

Mejor para ancho de banda por paquete, y a menudo mejor eficiencia, sí. Pero es más caro y las configuraciones de capacidad pueden estar limitadas. Elige según cuellos de botella medidos, no por sensaciones.

5) ¿Por qué veo errores out-of-memory cuando nvidia-smi muestra VRAM libre?

Fragmentación, pools reservados o múltiples procesos con allocators separados pueden hacer que lo “libre” sea inutilizable para una asignación contigua grande. Identifica uso por proceso y patrones de asignación.

6) ¿ECC reduce el rendimiento?

A veces ligeramente, según arquitectura y carga. A cambio obtienes menos corrupciones silenciosas. Para entrenamiento o inferencia crítica, ese intercambio suele valer la pena.

7) ¿Cómo sé si estoy limitado por ancho de banda o por cómputo?

Señales rápidas: alta utilización/tráfico de memoria con utilización de SM moderada sugiere presión de ancho de banda; alta utilización de SM con tráfico de memoria estable sugiere bound por cómputo.
Confírmalo con perfilado una vez que las comprobaciones de salud de la plataforma pasen.

8) ¿Cuál es la diferencia práctica entre capacidad VRAM y ancho de banda VRAM?

La capacidad determina si tu conjunto de trabajo cabe sin expulsiones. El ancho de banda determina qué tan rápido puedes alimentar cómputo una vez que cabe.
Una evita crash; la otra evita lentitudes.

9) ¿Por qué la misma GPU se comporta distinto en distintos servidores?

La topología PCIe, colocación NUMA, refrigeración, límites de potencia e incluso ajustes de BIOS pueden cambiar el ancho de banda efectivo y la estabilidad. Trata a los servidores como parte del sistema GPU.

10) ¿Debería confiar en memoria unificada/sobredesuscripción para “resolver” límites de VRAM?

Úsala como válvula de seguridad, no como plan. Puede rescatar la corrección, pero el rendimiento puede colapsar cuando empieza la paginación. Si la necesitas rutinariamente, compra más VRAM o rediseña la carga.

Próximos pasos que realmente deberías hacer

Si ejecutas GPUs en producción, trata la VRAM como un subsistema de primera clase: tiene planificación de capacidad, planificación de ancho de banda, monitoreo de salud y modos de fallo.
La evolución de GDDR a HBM no fue una moda tecnológica; fue la industria reaccionando a la misma limitación que estás depurando a las 3 a.m.: movimiento de datos.

1. Establece una línea base para cada clase de nodo: Gen/ancho PCIe, topología, térmicas, límites de potencia y modo ECC.
2. Instrumenta las señales correctas: VRAM usada, reloj de memoria, RX/TX PCIe, errores ECC, razones de throttling y latencia tail.
3. Codifica reglas de cuarentena: tendencias de errores corregibles y eventos Xid deben drenar nodos automáticamente.
4. Haz de la localidad una característica de despliegue: fijación NUMA y colocación de memoria deberían formar parte de la configuración del servicio, no del conocimiento tribal.
5. Elige hardware según cuellos de botella medidos: no compres capacidad para arreglar ancho de banda, y no compres ancho de banda para arreglar un enlace PCIe roto.

La era de “pura locura” de la VRAM no va a ralentizarse. El empaquetado será más extraño, las caches serán más grandes, los enlaces más rápidos y tu carga seguirá encontrando la única parte estrecha del pipeline.
Está bien. Solo no dejes que sea una sorpresa.