Gráficas MCM: qué puede fallar y cómo los proveedores lo parchean

Qué es diferente en las gráficas MCM (y por qué a operaciones le importa)

Las gráficas MCM son la idea de que una “GPU” ya no es una única pieza monolítica de silicio. Es un paquete con múltiples dies activos—tiles de cómputo, dies de E/S, pilas de memoria, dies de caché—unidos mediante interconexiones de alta velocidad y empaquetado avanzado (interposadores 2.5D, puentes de silicio, sustratos orgánicos, diversas variantes de micro-bumps).

Desde la perspectiva de operaciones en producción, el perfil de riesgo cambia en tres formas:

1. Más enlaces que pueden fallar. Cada salto adicional die-a-die es un punto donde la integridad de señal, el clocking, el entrenamiento o el ruido de alimentación pueden torcerse.
2. Más arbitraje por firmware. Un die monolítico puede ocultar complejidad interna tras un “simplemente funciona”. MCM necesita más entrenamiento en el arranque, gestión de enlaces, manejo de errores y a veces reconfiguración en tiempo de ejecución.
3. Más formas de estar “casi funcionando”. La degradación parcial se vuelve común: un tile se estrangula, una pila de memoria genera correcciones ECC, un enlace se reentrena bajo carga. Tus paneles muestran “GPU activa”, mientras que tus SLOs dicen lo contrario.

Aquí está la trampa operativa: los ingenieros tratan las GPUs MCM como versiones grandes de las piezas del año pasado. Mismo playbook de controladores, mismas suposiciones térmicas, misma mentalidad de “si pasa el burn-in está bien”. Esa suposición no envejece bien.

Una cita que sigue siendo dolorosamente relevante en este ámbito es una idea parafraseada a menudo atribuida a John Ousterhout: La complejidad es incremental; se acumula hasta que el sistema se vuelve difícil de entender e poco fiable. MCM no crea complejidad de la nada—la reubica en empaquetado, firmware y telemetría, donde quizá tengas menos intuición.

Hechos y contexto interesantes (la versión corta y útil)

• Los chiplets no son nuevos. Los paquetes multi-die han existido durante décadas; lo que cambió es la densidad de ancho de banda y el empaquetado que los hace comportarse como un único dispositivo a velocidades de GPU.
• HBM convirtió lo “a nivel de paquete” en lo nuevo a nivel placa base. Cuando las pilas de memoria están junto al cómputo en un interposador, muchos patrones de fallo de la era DIMM desaparecen—y llegan otros nuevos (gradientes térmicos locales de la pila, margen PHY, comportamiento ECC por pila).
• El multi-GPU temprano (SLI/CrossFire) es el modelo mental equivocado. Aquello era “múltiples dispositivos sobre PCIe”. MCM es “un dispositivo con telas internas”, lo que cambia la contención de errores y las semánticas de reinicio.
• La economía del rendimiento por yield es un motor importante. Los dies más pequeños tienen mejor rendimiento de fabricación; los proveedores pueden clasificar tiles, quemar unidades débiles y construir gamas de producto sin apostar por un único retículo gigante.
• El empaquetado avanzado es su propio dominio de confiabilidad. Micro-bumps, underfill y deformación del sustrato pueden crear fallos dependientes del tiempo que parecen “bloqueos aleatorios del controlador”.
• El entrenamiento del interconectado ahora es una fase crítica de arranque. Fallos en el entrenamiento de enlaces pueden aparecer como problemas de enumeración intermitente o caídas de rendimiento que solo ocurren después de un arranque en frío.
• La telemetría mejoró, pero la interpretación se complicó. Obtienes contadores por enlace, ECC por pila, estrangulamiento por tile… y una avalancha de falsos positivos si tus umbrales son ingenuos.
• Las características RAS definen cada vez más el producto. Los errores corregibles y el comportamiento de aislamiento son ahora parte de la promesa de producto, no solo un extra para HPC.

Modos de fallo: qué se rompe en el mundo real

1) Inestabilidad en la interconexión die-a-die: “no está caída, solo va lento… a veces”

Las GPUs MCM viven o mueren por sus telas internas: enlaces die-a-die, interconexiones coherentes de caché, conexiones PHY de memoria y, a veces, telas externas como enlaces clase NVLink entre paquetes. Estos enlaces tienen procesos de entrenamiento, ecualización y comportamientos de corrección de errores que pueden variar con la temperatura, el voltaje o el envejecimiento.

Cómo se presenta:

• Jitter de rendimiento: la latencia p95 se duplica sin cambios obvios de utilización.
• Bloqueos intermitentes bajo carga máxima, a menudo durante all-reduce o tráfico intenso peer-to-peer.
• Los contadores de errores corregibles suben de forma sostenida; errores no corregibles provocan reinicio de la GPU o terminación de trabajos.

Qué está pasando en realidad: margen de enlace marginal, reentrenamiento periódico o sobrecarga creciente de la corrección de errores. La GPU “funciona”, pero tu ancho de banda efectivo se colapsa.

2) Entrega de potencia y respuesta transitoria: tu PSU es inocente, tus rieles no

MCM tiende a aumentar las transientes de corriente locales: múltiples tiles conmutando al unísono, ráfagas HBM, picos de actividad en la tela. Las VRM de placa y los reguladores en paquete deben mantenerse al ritmo. Si no lo hacen, obtienes comportamientos tipo browout que parecen bugs de software.

Cómo se presenta:

• Reinicios de GPU ante rampas de carga súbitas (inicio de trabajo, ráfaga de lanzamientos de kernels, transiciones de fases en precisión mixta).
• Registros de kernel muestran “GPU has fallen off the bus” o reinicios del enlace PCIe.
• Más errores a límites de potencia altos o relojes de boost agresivos.

3) Gradientes térmicos dentro del paquete: la temperatura media miente

Con múltiples dies y pilas HBM, el punto más caliente puede no coincidir con donde apunta tu métrica de “temperatura de GPU” de una sola línea. Puedes tener una temperatura reportada “bien” y aun así tener un tile o una pila de memoria estrangulada.

Cómo se presenta:

• Los relojes se reducen de forma impredecible; el rendimiento parece congestión pero no lo es.
• Los errores ECC de HBM correlacionan con ambientes más cálidos o curvas de ventiladores.
• Los problemas solo aparecen en ciertas elevaciones del rack o flujos de aire.

Broma #1: El estrangulamiento térmico es la forma en que la GPU dice “no estoy enfadada, solo estoy decepcionada”, mientras reduce tu rendimiento a la mitad en silencio.

4) Las semánticas de reinicio se vuelven más extrañas: reinicios parciales, contextos atascados y “GPUs fantasma”

En GPUs monolíticas, un reinicio a menudo significa “reiniciar todo el dispositivo”. En MCM, los proveedores pueden intentar recuperaciones más finas: reiniciar un tile, reentrenar un enlace, aislar una pila de memoria, reiniciar un microcontrolador. Esto es bueno—hasta que tu controlador, kernel o pila de aplicaciones asume que “reinicio es reinicio”.

Cómo se presenta:

• GPU visible para el SO, pero la creación de contextos en CUDA/ROCm/OpenCL falla.
• Nodos de dispositivo existen; las herramientas indican “OK”; los trabajos fallan inmediatamente.
• Sólo un reinicio completo del host restaura el comportamiento normal.

5) ECC y telemetría RAS: las correcciones son una advertencia, no un trofeo

Las correcciones ECC de HBM a menudo se tratan como “está bien”. En producción, una tasa creciente de correctables es una advertencia temprana de problemas térmicos, margen de integridad de señal marginal o errores no corregibles inminentes. MCM añade más superficies para esto: múltiples pilas, más PHYs, más controladores.

Cómo se presenta:

• Ascenso lento en errores correctables, seguido de terminaciones abruptas de trabajos.
• Errores “illegal memory access” inexplicables que correlacionan con eventos ECC.
• Tasas de error más altas en GPUs específicas o posiciones dentro del chasis.

6) Comportamiento PCIe y BAR: el enlace del host sigue importando

Aunque la GPU interna sea basada en chiplets, el host ve un dispositivo PCIe. Las GPUs MCM pueden aumentar la presión MMIO, la sensibilidad al tamaño de BAR y la complejidad de reinicio. Resizable BAR y ajustes de IOMMU pueden ayudar o perjudicar dependiendo de la calidad del firmware.

Cómo se presenta:

• El dispositivo se enumera, pero el controlador no inicializa tras actualizaciones de firmware.
• Los registros PCIe Advanced Error Reporting (AER) muestran ráfagas corregibles durante la carga.
• Las transferencias peer-to-peer son más lentas de lo esperado, o a veces se agotan por tiempo.

7) Planificación del controlador y “suposiciones implícitas” sobre simetría

Algunos diseños MCM tempranos exponen asimetrías: die de E/S frente a dies de cómputo, cachés compartidas o diferentes dominios de afinidad de memoria. Si el controlador asume latencia uniforme, puede ubicar trabajo subóptimamente. Si tu aplicación asume uniformidad, puede amplificar el problema.

Cómo se presenta: caídas de rendimiento que aparecen solo para ciertos tamaños de batch, formas de tensores o patrones de acceso a memoria. El benchmark A dice “genial”, la carga de producción dice “¿por qué pagamos esto?”.

8) Microcontroladores de firmware: el sistema operativo oculto dentro de tu GPU

Las GPUs modernas se envían con múltiples controladores embebidos que manejan potencia, seguridad, planificación y RAS. MCM incrementa las necesidades de coordinación: más endpoints, más estados, más secuencias de entrenamiento. Los bugs de firmware se convierten en “inestabilidad de hardware” en tu canal de incidentes.

Cómo se presenta:

• Problemas que desaparecen tras una actualización de firmware (o que aparecen después de una).
• Problemas que se reproducen solo después de un reinicio en caliente, no en frío.
• “Atascada en modo de baja potencia” o “no sube de frecuencia” sin causa térmica.

9) Envejecimiento a nivel de empaquetado: cuando “funciona en QA” no significa “funciona en el mes 14”

El ciclo térmico, la vibración y la electromigración a largo plazo pueden degradar las conexiones de bumps y el margen de interconexión. Estas fallas a menudo empiezan como errores correctables y reentrenamientos de enlace intermitentes. Más tarde se convierten en “reinicios aleatorios”.

Cómo se presenta: “Cambiamos software, kernel, controlador, versión de modelo, y el problema persiste en la misma GPU física.” Aquí es cuando dejas de debatir y empiezas a aislar hardware.

Cómo parchean los proveedores las gráficas MCM en la práctica

Cuando una GPU MCM tiene un problema en campo, los proveedores lo parchean a través de capas. Los cambios de hardware llegan después. La producción tiene que sobrevivir el entretiempo.

Parche capa 1: Actualizaciones de firmware (VBIOS, firmware del dispositivo, imágenes de microcontrolador)

Los parches de firmware típicamente se enfocan en:

• Entrenamiento y ecualización de enlaces: mejores presets, ventanas de entrenamiento más largas, lógica de reintentos afinada para canales marginales.
• Gestión de potencia: transiciones de boost menos agresivas, diferentes mitigaciones de caída de voltaje, secuencias revisadas de power gating.
• Política RAS: cuándo reiniciar, cuándo aislar, cuándo funcionar en modo degradado; umbrales para escalar errores corregibles.
• Manejo de reinicios: mejorar la recuperabilidad sin reboot del host.

Realidad operativa: las actualizaciones de firmware no son “agradables”. Son eventos de cambio con riesgo de rollback, dependencia en versiones de controladores y a veces interacciones con el BIOS de la placa base.

Parche capa 2: Cambios en el controlador del kernel

Los controladores parchean alrededor del comportamiento del hardware. Patrones comunes:

• Afinación del manejo de timeouts: evitar detección falsa de cuelgues en kernels largos o telas más pesadas.
• Mejor decodificación de errores: mapear códigos crípticos a categorías accionables; exponer contadores por enlace.
• Workarounds: deshabilitar un camino de optimización que dispara un bug de hardware (sí, ocurre).
• Mejoras en reinicios: intentar un reinicio de tile antes de un reinicio completo del dispositivo; mejor limpieza de contextos.

Parche capa 3: Bibliotecas y runtimes en espacio de usuario

Staks como CUDA/ROCm/OpenCL, bibliotecas de colectivas y frameworks ML a veces lanzan mitigaciones:

• Diferentes elecciones de algoritmo por defecto para all-reduce cuando P2P es inestable.
• Comportamiento más conservador en pools de memoria para reducir el estrés por fragmentación.
• Chequear salud que detectan estados de “dispositivo zombi” y fallan rápido.

Parche capa 4: BIOS de plataforma y peculiaridades PCIe

Las actualizaciones del BIOS/UEFI de la placa base pueden ajustar ASPM de PCIe, comportamiento de entrenamiento de enlaces, manejo de BAR y valores por defecto de IOMMU. En algunas plataformas, esto marca la diferencia entre “correctables raros” y “reinicios diarios del bus”.

Cómo deciden los proveedores qué parchear primero

Los proveedores persiguen la reproducibilidad. Si pueden reproducir un cuelgue con un patrón de carga específico, parchearán el controlador. Si es específico de plataforma, publicarán guías de BIOS. Si claramente es integridad de señal marginal, afinarán el entrenamiento o bajarán relojes por defecto. Si es un erratum de silicio verdadero, emitirán workarounds ahora y lo corregirán en una nueva revisión (stepping) más adelante.

Qué deberías hacer: trata firmware/controlador GPU como una unidad acoplada. No “solo actualices el controlador” en aislamiento y luego te sorprendas cuando un desajuste con el firmware del dispositivo cause nuevos modos de fallo.

Broma #2: Las notas de la versión del proveedor son como pronósticos meteorológicos: útiles, ocasionalmente incorrectas, y aun así no debes ignorar las advertencias de tormenta.

Guía de diagnóstico rápido

Cuando un clúster de GPUs MCM empieza a comportarse mal, no estás resolviendo un problema filosófico. Estás localizando un cuello de botella y decidiendo si remediar, aislar o revertir.

Primero: decide si es enlace host, salud del dispositivo o carga de trabajo

1. Saneamiento del enlace host: PCIe AER, cambios de velocidad/anchura del enlace, “fallen off the bus”, fallos de IOMMU.
2. Salud del dispositivo: contadores ECC, razones de estrangulamiento, registros Xid/reinicios del controlador, errores de tela.
3. Correlación con la carga: ¿ocurre solo con ciertos kernels, tamaños de batch o patrones de comunicación?

Segundo: clasifica la falla como “degradación” vs “fallo duro”

• Degradación: rendimiento a la baja, latencia al alza, correctables aumentando, relojes inestables. Acción: drenar + investigar, posiblemente ajuste de firmware/controlador, revisión de flujo de aire.
• Fallo duro: ECC no corregible, bucles de reinicio de GPU, dispositivo desaparece. Acción: aislar GPU/nodo inmediatamente, preservar registros, no girar en falso.

Tercero: determina alcance y radio de blast

• Solo una GPU: sospecha marginalidad de hardware o problema local de slot/PSU/flujo de aire.
• Nodo completo: sospecha BIOS de plataforma, kernel, fuente de alimentación, backplane o actualización de controlador.
• Rack/fila: sospecha refrigeración, distribución de potencia, despliegue de firmware o lote defectuoso de nodos.
• Clúster entero tras un cambio: sospecha desajuste de software/firmware o comportamiento del planificador.

Cuarto: elige la mitigación menos riesgosa que compre tiempo

• Reducir el tope de potencia / deshabilitar boost temporalmente.
• Ajustar la curva de ventiladores o el contención de flujo de aire; verificar temperaturas de entrada.
• Deshabilitar la ruta P2P problemática / cambiar algoritmo de colectivas.
• Fijar a combinación estable de controlador+firmware; revertir si la regresión es obvia.
• Aislar GPUs específicas con ECC en ascenso o reinicios recurrentes.

Tareas prácticas: comandos, salidas y decisiones

Estos son los chequeos básicos que ejecuto cuando las GPUs MCM huelen a problema. Cada tarea incluye un comando, qué significa la salida y qué decisión tomar. Los comandos asumen Linux con herramientas comunes; ajusta a tu entorno.

Task 1: Check basic GPU visibility and persistence state

cr0x@server:~$ nvidia-smi -L
GPU 0: NVIDIA A100-SXM4-80GB (UUID: GPU-2d3f...)
GPU 1: NVIDIA A100-SXM4-80GB (UUID: GPU-9a11...)

Qué significa: Las GPUs se enumeran y el controlador puede comunicarse con ellas. GPUs ausentes sugieren problemas de PCIe/enlace/plataforma, no un “kernel lento”.

Decisión: Si una GPU falta o aparece de forma intermitente, revisa inmediatamente PCIe AER y dmesg; no pierdas tiempo en logs del framework ML.

Task 2: Read driver/kernel error logs for resets and bus events

cr0x@server:~$ sudo dmesg -T | egrep -i "nvrm|xid|pcie|aer|amdgpu|iommu" | tail -n 20
[Mon Jan 21 08:12:44 2026] NVRM: Xid (PCI:0000:41:00): 79, pid=22341, GPU has fallen off the bus.
[Mon Jan 21 08:12:44 2026] pcieport 0000:40:01.0: AER: Corrected error received: 0000:40:01.0
[Mon Jan 21 08:12:44 2026] pcieport 0000:40:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)

Qué significa: “Fallen off the bus” es un evento de la clase enlace host/potencia/reinicio. Los AER de capa física corregidos sugieren integridad de señal o inestabilidad del enlace.

Decisión: Si ves ráfagas repetidas de AER alrededor de las fallas, trátalo primero como un problema de hardware/plataforma: slot, riser, cable (si lo hay), ajustes de BIOS de PCIe, transientes de potencia.

Task 3: Verify PCIe link width/speed didn’t downshift

cr0x@server:~$ sudo lspci -s 41:00.0 -vv | egrep -i "LnkCap:|LnkSta:"
LnkCap: Port #0, Speed 16GT/s, Width x16, ASPM L0s L1, Exit Latency L0s<1us, L1<8us
LnkSta: Speed 8GT/s (downgraded), Width x8 (downgraded)

Qué significa: El dispositivo puede operar en Gen4 x16 pero está funcionando en Gen3 x8. Eso es un cliff de rendimiento y a menudo síntoma de integridad de señal marginal o peculiaridades del BIOS.

Decisión: Si está degradado, resitúa/revisa risers, actualiza BIOS de la plataforma, considera forzar la generación PCIe en BIOS por estabilidad y compara con nodos conocidos buenos.

Task 4: Check Resizable BAR status (common source of “works but weird”)

cr0x@server:~$ sudo lspci -s 41:00.0 -vv | egrep -i "Resizable BAR|BAR 1|Region 0" -n
55: Region 0: Memory at 3a000000000 (64-bit, prefetchable) [size=16M]
61: Resizable BAR: Current Size: 256MB, Supported: 256MB 512MB 1GB 2GB 4GB

Qué significa: El tamaño de BAR afecta la eficiencia con que la CPU mapea aperturas de memoria de la GPU. Algunas combinaciones firmware/controlador regresan con ciertos tamaños.

Decisión: Si ves fallos de inicialización tras actualizaciones, intenta alternar Resizable BAR en el BIOS de forma consistente en toda la flota en lugar de permitir variación nodo a nodo.

Task 5: Check GPU clocks, power, and throttling reasons

cr0x@server:~$ nvidia-smi -q -d CLOCK,POWER,TEMPERATURE | egrep -i "GPU Current Temp|Power Draw|Power Limit|Clocks|Throttle" -n | head -n 60
118: GPU Current Temp            : 78 C
141: Power Draw                  : 345.22 W
142: Power Limit                 : 400.00 W
210: Clocks
214:     Graphics                : 990 MHz
230:     Memory                  : 1215 MHz
310: Clocks Throttle Reasons
314:     SW Power Cap            : Active
318:     HW Thermal Slowdown     : Not Active

Qué significa: Estás limitado por potencia en software aunque los térmicos no estén estrangulando. Eso puede ser intencional (política de centro de datos) o una mala configuración.

Decisión: Si el rendimiento es bajo y el tope de potencia SW está activo, valida tu política de límite de potencia; considera elevar el tope o suavizar picos de carga.

Task 6: Inspect ECC error counters (correctables matter)

cr0x@server:~$ nvidia-smi -q -d ECC | egrep -i "Volatile|Aggregate|Correctable|Uncorrectable" -n | head -n 80
60: Volatile ECC Errors
62:     Single Bit
64:         Device Memory        : 120
70:     Double Bit
72:         Device Memory        : 0
90: Aggregate ECC Errors
92:     Single Bit
94:         Device Memory        : 8421

Qué significa: Los errores ECC corregibles se están acumulando. Los contadores volátiles se reinician en reboot; los agregados persisten entre reboots (depende de la implementación).

Decisión: Si los correctables aumentan rápido o correlacionan con periodos calientes, drena esa GPU de cargas sensibles a latencia e investiga refrigeración y actualizaciones de firmware. Si aparecen double-bit (no corregibles), aísla inmediatamente.

Task 7: Pull fabric / NVLink-class link status (where supported)

cr0x@server:~$ nvidia-smi nvlink --status
GPU 0: Link 0: Up
GPU 0: Link 1: Up
GPU 1: Link 0: Up
GPU 1: Link 1: Down

Qué significa: Un enlace está caído; el sistema puede recurrir a rutas más lentas, cambiando el rendimiento y a veces la estabilidad según la topología.

Decisión: Si un enlace cae inesperadamente, programa mantenimiento. No “resubas los trabajos”—las colectivas pueden comportarse distinto y ocultar el problema hasta el tráfico pico.

Task 8: Check PCIe AER counters live (if exposed) via journal

cr0x@server:~$ sudo journalctl -k --since "10 min ago" | egrep -i "AER:|PCIe Bus Error" | tail -n 20
Jan 21 08:11:05 server kernel: pcieport 0000:40:01.0: AER: Corrected error received: 0000:40:01.0
Jan 21 08:11:05 server kernel: pcieport 0000:40:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer

Qué significa: Los errores corregidos en la capa física indican a menudo enlaces marginales. Uno o dos pueden ser ruido; ráfagas bajo carga son un patrón.

Decisión: Si el conteo sube con la actividad GPU, prioriza arreglos de plataforma: resituar, ajustes de BIOS, cambiar riser o mover la GPU a otro slot para confirmar.

Task 9: Confirm IOMMU state (can interact with resets and peer-to-peer)

cr0x@server:~$ dmesg -T | egrep -i "iommu|dmar" | head -n 20
[Mon Jan 21 07:58:01 2026] DMAR: IOMMU enabled
[Mon Jan 21 07:58:01 2026] DMAR: Intel(R) Virtualization Technology for Directed I/O

Qué significa: IOMMU está habilitado. Eso suele ser correcto en entornos compartidos, pero puede exponer bugs de dispositivo/controlador o regresiones de rendimiento según la configuración.

Decisión: Si ves fallos de mapeo DMA o comportamiento extraño peer-to-peer, prueba con configuraciones IOMMU conocidas buenas (incluido passthrough) en un canario antes de cambiar a toda la flota.

Task 10: Measure GPU utilization vs memory utilization to spot “fabric waits”

cr0x@server:~$ nvidia-smi dmon -s pucm -d 1 -c 5
# gpu   pwr gtemp mtemp    sm   mem   enc   dec
# Idx     W     C     C     %     %     %     %
    0   210    74     -     12     85     0     0
    1   205    73     -     15     88     0     0

Qué significa: La utilización SM es baja mientras la memoria está alta: la carga es bound a memoria, está bloqueada o esperando transferencias. En MCM, problemas de tela interna pueden hacerse pasar por “bound a memoria”.

Decisión: Si este patrón aparece de repente tras un cambio o solo en ciertas GPUs, sospecha estrangulamiento, degradaciones de enlace o problema de tela/enlace en lugar de “el modelo empeoró”.

Task 11: Check for GPU resets and persistence events via vendor tools (NVIDIA example)

cr0x@server:~$ nvidia-smi -q | egrep -i "Reset Status|Pending|Retired Pages" -n | head -n 80
420: Reset Status
424:     Reset Required          : No
610: Retired Pages
614:     Single Bit ECC          : 2
618:     Double Bit ECC          : 0

Qué significa: El retiro de páginas indica que el controlador/firmware está excluyendo ubicaciones de memoria malas. Eso es una señal de confiabilidad, no una trivialidad.

Decisión: Si las páginas retiradas aumentan, planifica reemplazo. Si se estabilizan en un número bajo y no ocurren otros errores, puedes mantenerla en una pool de menor prioridad, pero vigílala de cerca.

Task 12: Stress-test the interconnect path you actually use (not a toy benchmark)

cr0x@server:~$ python3 -c "import torch; import time; x=torch.randn(8192,8192,device='cuda'); torch.cuda.synchronize(); t=time.time(); y=x@x; torch.cuda.synchronize(); print('matmul_s', time.time()-t)"
matmul_s 0.7421183586120605

Qué significa: Una comprobación de tiempo de kernel simple. No validará toda tu pila, pero ayuda a distinguir “GPU fundamentalmente lenta/rota” de “la red del clúster está en llamas”.

Decisión: Si el cómputo single-GPU es estable pero los trabajos multi-GPU fallan, céntrate en P2P/NVLink/PCIe y en las bibliotecas de colectivas. Si single-GPU es inestable, enfócate en térmicos/potencia/controlador/firmware por nodo.

Task 13: Validate topology and peer-to-peer capability (NVIDIA example)

cr0x@server:~$ nvidia-smi topo -m
        GPU0    GPU1    CPU Affinity
GPU0     X      NV1     0-31
GPU1    NV1      X      0-31

Qué significa: Las GPUs tienen un enlace rápido (NV1). Si esperabas NVLink y ves “PHB” o “SYS”, tu tráfico va por PCIe/CPU y tu modelo de rendimiento está equivocado.

Decisión: Si la topología no es la diseñada, no optimices software infinitamente. Arregla la colocación, cableado, BIOS o la construcción física.

Task 14: Confirm versions (driver, firmware) and stop running mystery combos

cr0x@server:~$ nvidia-smi
Wed Jan 21 08:14:02 2026
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14    Driver Version: 550.54.14    CUDA Version: 12.4     |
+-----------------------------------------------------------------------------+

Qué significa: Tienes una versión concreta del controlador. Vincúlala a tu inventario de versiones de firmware; “último” no es una estrategia de inventario.

Decisión: Si las fallas se correlacionan con un despliegue reciente de controladores, congela y revierte en un subconjunto. Si se correlacionan con firmware, coordina una actualización/reversión combinada.

Task 15: Check CPU frequency scaling and IRQ storms (because GPUs don’t live alone)

cr0x@server:~$ sudo turbostat --Summary --quiet --show Avg_MHz,Busy%,Bzy_MHz -i 2 -n 3
Avg_MHz  Busy%  Bzy_MHz
  1020   12.34    8270
   980   10.90    8205
  1005   11.80    8250

Qué significa: Si la CPU está atascada a baja frecuencia por política de potencia o límites térmicos, puede convertirse en cuello de botella para alimentar datos, sobrecarga de lanzamiento y manejo de I/O—especialmente para kernels pequeños o tráfico de control intenso.

Decisión: Si la utilización GPU es baja y la CPU parece constreñida, arregla la política de potencia de la CPU, refrigeración o distribución de IRQs antes de culpar a la GPU.

Task 16: Quick NIC and RDMA sanity (multi-GPU jobs fail here a lot)

cr0x@server:~$ ip -s link show dev eth0 | head -n 12
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  missed   mcast
    9876543210  1234567  0       0        0        12
    TX:  bytes  packets  errors  dropped  carrier collsns
    8765432109  2345678  0       0        0       0

Qué significa: Sin errores/caídas. Si ves errores, tu “cuelgue de GPU” puede ser un trabajo esperando colectivas de red.

Decisión: Si los errores de red se alinean con los stalls, triagea la tela de red primero. Si la red está limpia y solo ciertos pares de GPU fallan, vuelve a centrarte en enlaces P2P y topología GPU.

Tres mini-historias corporativas (anonimizadas, plausibles y dolorosamente reales)

Mini-historia 1: El incidente causado por una suposición equivocada

La empresa tenía una nueva flota basada en GPUs MCM y un brillante documento interno que decía “los correctables ECC son esperados; ignóralos salvo que haya no corregibles”. Alguien escribió ese doc basándose en una generación anterior donde los correctables eran raros y mayormente inofensivos.

Seis meses después, los trabajos de entrenamiento empezaron a fallar en clusters—siempre durante la misma fase de ejecución del modelo. Los ingenieros culparon a una actualización reciente del framework. La revirtieron. Las fallas continuaron. Luego culparon a la biblioteca de colectivas. La ajustaron. Las fallas continuaron. Mientras tanto, el dashboard de correctables ECC estaba en verde porque el umbral de alerta se había fijado “irracionalmente alto, para evitar ruido”.

Finalmente, un SRE comparó un “nodo bueno” y un “nodo malo” lado a lado. El nodo malo mostraba una subida constante en errores HBM correctables correlacionada con temperaturas de entrada más altas en la parte superior del rack. Nada dramático. Solo una pendiente.

La solución no fue glamorosa: ajustaron el control térmico, refinaron curvas de ventiladores y cambiaron la automatización para aislar GPUs cuando los correctables subían más rápido que una línea base. Tras eso, los no corregibles desaparecieron en su mayoría. La suposición equivocada fue tratar correctables como algo descartable en lugar de predictivo.

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

Un equipo de rendimiento quiso exprimir más throughput. Incrementaron límites de potencia de GPU y activaron el comportamiento de boost más agresivo permitido por el proveedor. Los benchmarks mejoraron bien. El despliegue fue amplio, porque las pruebas canarias fueron cortas y las gráficas se veían bien.

Dos semanas después, empezaron a aparecer reinicios intermitentes de GPU, siempre bajo cargas muy bursty. Los registros parecían “flaky del controlador” clásico. Los ingenieros persiguieron fantasmas de software: runtimes de contenedores, versiones de kernel, incluso un agente de monitorización sospechoso. Los reinicios seguían ocurriendo, mayormente en nodos con PSU algo más antiguas y aire ambiente algo más cálido.

Lo que realmente pasó fue física aburrida: la nueva política de potencia aumentó los escalones transitorios de carga, y un subconjunto de placas/plataformas tenía menos margen. Las telas internas y los enlaces PCIe eran más sensibles a esas caídas que las GPUs monolíticas anteriores. Las fallas eran lo bastante raras para escapar pruebas cortas, pero lo bastante comunes como para destruir los SLOs en producción.

La reversión a límites de potencia conservadores detuvo los reinicios. Luego reintrodujeron ajustes despacio, con pruebas de soak más largas y monitorización explícita de ráfagas AER de PCIe y cambios en razones de estrangulamiento. La lección: en terreno MCM, “más potencia” no es un control de rendimiento gratuito; también es una palanca de confiabilidad.

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

Un equipo distinto mantenía una matriz estricta de hardware+firmware. Cada nodo reportaba versión de controlador, VBIOS/firmware, BIOS de plataforma y un pequeño set de contadores RAS en un sistema tipo CMDB. Era aburrido. Los ingenieros se quejaban de que retardaba los despliegues.

Entonces un proveedor liberó una actualización de controlador que mejoraba rendimiento en papel pero introdujo un bug raro de reinicio en un stepping de firmware específico. Solo un subconjunto de nodos tenía ese stepping—por una compra de mitad de año. Las flotas mixtas pasan; fingir que no sucede no ayuda.

Cuando empezaron las fallas, no necesitaron una semana de arqueología. Consultaron: “muestra nodos con controlador X y firmware Y y AER de PCIe en ascenso”. La intersección fue pequeña y clara. Fijaron esos nodos al controlador antiguo, mantuvieron al resto en la versión nueva y siguieron adelante.

No fueron heroísmos. Fue disciplina de inventario y despliegues graduales. La mejor respuesta a incidentes es no tener que adivinar.

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

1) Síntoma: caída súbita de throughput en un subconjunto de nodos

Causa raíz: degradación del enlace PCIe (Gen4→Gen3, x16→x8) tras reentrenamiento por integridad de señal marginal o problemas de riser.

Solución: Revisa el estado del enlace con lspci -vv; resitúa GPU/riser, actualiza BIOS de plataforma, considera forzar la generación PCIe; reemplaza risers sospechosos.

2) Síntoma: “GPU fallen off the bus” intermitente bajo carga

Causa raíz: problema de transiente de potencia/margen VRM, a veces exacerbado por límites de potencia/boost agresivos o falta de capacidad PSU.

Solución: reduce temporalmente el tope de potencia; verifica PSU y cableado; actualiza firmware de GPU; realiza pruebas de soak más largas antes de volver a habilitar ajustes agresivos.

3) Síntoma: los trabajos fallan solo en multi-GPU, las pruebas single-GPU pasan

Causa raíz: problemas de tela/P2P/enlace NVLink, desajuste de topología o sensibilidad del algoritmo de colectivas a errores de enlace.

Solución: verifica nvidia-smi topo -m y el estado de enlaces; cambia el algoritmo de colectivas o deshabilita la ruta P2P como mitigación; programa inspección de hardware si un enlace está caído.

4) Síntoma: aumento de errores ECC correctables pero “todavía sin fallos”

Causa raíz: gradiente térmico, PHY HBM marginal, envejecimiento del empaquetado. A menudo es predictivo.

Solución: correlaciona la tasa ECC con temperatura de entrada y velocidad de ventilador; mejora la refrigeración; actualiza firmware/controlador; aísla si la tasa excede la línea base o aumentan las páginas retiradas.

5) Síntoma: GPU visible para el SO pero el runtime falla al crear contextos

Causa raíz: reinicio parcial dejó el dispositivo en estado inconsistente; desajuste controlador/firmware; estado de demonio de persistencia obsoleto.

Solución: intenta un reinicio de GPU soportado por el proveedor; si no es fiable, reinicia el nodo; aplica combos coincidentes de controlador+firmware y ajustes de persistencia coherentes.

6) Síntoma: jitter de rendimiento con utilización estable

Causa raíz: reentrenamiento interno de enlaces, razones de estrangulamiento ocultas o oscilación en la gestión de potencia.

Solución: inspecciona razones de estrangulamiento; busca ráfagas AER; estabiliza la política de potencia; actualiza firmware que mejore el entrenamiento de enlaces.

7) Síntoma: tras una actualización, algunos nodos no inicializan el controlador GPU

Causa raíz: interacción entre BIOS de plataforma + Resizable BAR + controlador, o dependencia de firmware no satisfecha.

Solución: estandariza configuraciones BIOS; valida el estado de Resizable BAR; revierte el controlador en hardware afectado; evita configuraciones mixtas en la flota.

8) Síntoma: fallas “aleatorias” que siguen a la misma GPU física entre hosts

Causa raíz: marginalidad de hardware o envejecimiento a nivel de empaquetado; los contadores de errores cuentan la historia.

Solución: intercambia la GPU a un host conocido bueno para confirmar; si el problema sigue a la GPU, aíslala y RMA; deja de culpar a los kernels.

Listas de verificación / plan paso a paso

Cuando compras o adoptas GPUs MCM

1. Exige una matriz de soporte controlador+firmware y trátala como contrato, no sugerencia.
2. Planea la ingestión de telemetría: ECC (por pila si está disponible), contadores de enlace, razones de estrangulamiento, conteos de reinicio.
3. Estandariza ajustes BIOS de plataforma: política de generación PCIe, Resizable BAR, modo IOMMU.
4. Diseña para margen térmico: objetivos de temperatura de entrada, políticas de ventiladores y validación de flujo de aire a nivel de rack.
5. Ejecuta pruebas de soak que imiten producción (la duración importa; la burstiness importa).

Cuando despliegas nuevo firmware/controlador

1. Canary en steppings de hardware representativos y ubicaciones de rack (zonas calientes/frías).
2. Monitorea: ráfagas AER PCIe, ancho/velocidad de enlace, tasas correctables ECC, páginas retiradas, eventos de reinicio.
3. Mantén listos artefactos de rollback (paquetes de controlador, imágenes de firmware, perfil BIOS conocido bueno).
4. Despliega gradualmente; detén al primer signo de una nueva firma de error.
5. Nunca cambies firmware, controlador y BIOS al mismo tiempo salvo que disfrutes de la ambigüedad.

Cuando estás en un incidente

1. Clasifica: degradación vs fallo duro.
2. Preserva evidencia: dmesg/journal, logs del proveedor, contadores ECC antes del reboot si es posible.
3. Revisa estado de enlace PCIe y AER primero; es rápido y con frecuencia decisivo.
4. Mitiga con el menor radio de blast: drena/aisla una GPU o nodo; reduce el tope de potencia.
5. Solo entonces profundiza en síntomas a nivel de framework.

Cuando construyes confiabilidad a largo plazo

1. Alerta por tasas, no solo umbrales absolutos (correctables ECC por hora vence a “ECC > 10,000”).
2. Mantén un nodo “conocido bueno” para comparaciones.
3. Automatiza la cuarentena para firmas recurrentes de reinicio y tasas de error en ascenso.
4. Mantén inventario de: firmware/VBIOS de GPU, controlador, kernel, BIOS de plataforma y mapeo slot/riser.
5. Ejecuta comprobaciones periódicas de enlace y rendimiento para detectar degradaciones silenciosas.

Preguntas frecuentes

1) ¿Las GPUs MCM son inherentemente menos confiables que las monolíticas?

No inherentemente. Tienen más superficies de fallo (enlaces, entrenamiento, empaquetado), pero también mejores opciones RAS y mejor cribado por yield. La confiabilidad depende mucho de la madurez del firmware, la calidad de la plataforma y tu disciplina operativa.

2) ¿Cuál es el indicador más común de “es hardware”?

Eventos repetidos de PCIe AER bajo carga, degradaciones de enlace y mensajes “fallen off the bus”. Esos no son tus scripts Python fallando.

3) ¿Debo ignorar los errores ECC corregibles?

No. Trátalos como un detector de humo. Una corrección ocasional puede ser aceptable; una tasa en ascenso es predictiva y merece investigación o cuarentena.

4) ¿Por qué los problemas aparecen solo después de un reinicio en caliente?

Porque el entrenamiento de enlaces y las secuencias de inicialización de firmware pueden diferir entre arranque en frío y reinicio en caliente. Algunos canales marginales pasan por una ruta y fallan por otra.

5) ¿Las actualizaciones de firmware suelen mejorar la estabilidad?

A menudo sí—especialmente en la vida temprana de un producto. Pero también pueden introducir regresiones. Maneja firmware como manejas kernels: por etapas, medido y reversible.

6) ¿Qué métricas debo alertar para GPUs MCM?

Tasa correctable ECC, eventos no corregibles, páginas retiradas, conteos de reinicio, razones de estrangulamiento (potencia/térmico), ancho/velocidad de enlace PCIe y ráfagas AER de PCIe. Añade estado de enlaces de tela donde esté disponible.

7) ¿“GPU con baja utilización y memoria alta” siempre es un problema del modelo?

No. Puede indicar comportamiento bound a memoria, pero en sistemas MCM también puede indicar problemas de tela interna, reentrenamiento de enlaces, estrangulamiento o cuellos de botella del host alimentando la GPU.

8) ¿Cómo decido entre aislar una GPU o reemplazar todo el nodo?

Si el problema sigue a la GPU al moverla a un host conocido bueno, aísla/RMA la GPU. Si múltiples GPUs fallan en el mismo host/slot/rack, sospecha plataforma: potencia, térmicos, BIOS, risers o backplane.

9) ¿Resizable BAR puede causar problemas reales en producción?

Sí—principalmente por interacciones firmware/controlador. Estandariza la configuración y valida con tu combo exacto controlador+firmware; no permitas variación en la flota.

10) ¿Cuál es la mejor “primera prueba” cuando el rendimiento parece incorrecto?

Revisa el estado de enlace PCIe (lspci -vv), luego razones de estrangulamiento y potencia/térmicos, y después ECC y registros de reinicio. Rápido, objetivo y con frecuencia decisivo.

Conclusión: próximos pasos prácticos

Las gráficas MCM no son magia frágil. Son simplemente una GPU más distribuida: más enlaces, más controladores, más estados. Cuando fallan, a menudo lo hacen como “realidad degradada” en lugar de una caída limpia, lo cual es peor para los SLOs y más duro para las personas.

Qué hacer a continuación, en orden:

1. Estandariza e inventaría tu matriz controlador+firmware+BIOS. Las combinaciones misteriosas mixtas son cómo obtienes clusters embrujados.
2. Alerta sobre tendencias: tasa correctable ECC, ráfagas AER, degradaciones de enlace, firmas de reinicio.
3. Operativiza la cuarentena para repetidores. No dejes que una GPU marginal envenene una cola de trabajos.
4. Despliega por etapas con pruebas de soak que reflejen producción, incluyendo fases bursty y colectivas multi-GPU.
5. Mantén un bucle de diagnóstico rápido que empiece por PCIe/enlace/térmicos antes de ahondar en logs de framework.

Si haces esas cosas, las GPUs MCM dejan de ser misteriosas. Se convierten en lo que deberían ser: calentadores caros que también hacen matemáticas útiles.