Controladores como armas: cómo el software puede “cambiar” tu GPU

diciembre 26, 2025 • febrero 3, 2026 • Lectura: 26 min • Views: 0

¿Te fue útil?

Reinicias una máquina y tu GPU “igual” de pronto va más lenta, más caliente, menos estable o simplemente… diferente.
El silicio no cambió. El controlador sí. Y el controlador es la parte con opiniones: sobre potencia,
relojes, memoria, planificación, manejo de errores, incluso qué funciones existen hoy frente a ayer.

En producción, una actualización del controlador de GPU no es “solo un parche.” Es una reescritura del comportamiento del dispositivo que crees poseer.
Trátalo como un cambio en el contrato de hardware. Porque eso es.

Qué significa que el software “cambie” una GPU

Cuando los ingenieros dicen “el controlador cambió mi GPU,” no quieren decir que reconfiguró transistores.
Quieren decir que el controlador cambió el comportamiento observable de la GPU: el contrato práctico:
qué tan rápido funciona, cómo planifica, cómo usa la memoria, cómo maneja errores y cómo se limita por calor o consumo.

Una GPU moderna es un acuerdo negociado entre hardware, firmware, módulo del kernel, librerías en espacio de usuario y, a veces, un demonio
que mantiene estado entre procesos. Diferentes versiones del controlador pueden:

Cambiar los límites de potencia por defecto y el comportamiento de boost.
Cambiar transiciones de estado P (P-state) (relojes en reposo frente a cálculo).
Cambiar la gestión de memoria y el comportamiento de expulsión (especialmente bajo oversubscription).
Cambiar la equidad en la planificación entre contextos (MPS, MIG, time-slicing).
Activar o desactivar funciones (tamaño de BAR, SR-IOV, resizable BAR, acceso peer-to-peer).
Cambiar la recuperación ante errores: qué se considera una falla recuperable frente a una GPU muerta que requiere reinicio.
Cambiar la selección de kernels en librerías (cuDNN, cuBLAS) y los resultados de autotuning.

Lo que duele es esto: puedes hacer todo “bien” en tu código y aun así ver una variación del 20% porque el controlador cambió un valor por defecto.
La segunda parte que duele: el controlador tiene razones legítimas. Los controladores más nuevos corrigen problemas de corrección, seguridad y condiciones de carrera.
Pero también cambian el comportamiento, y el comportamiento es lo que importa en producción.

Una nota sobre qué incluye “controlador”

La gente dice “controlador” como abreviatura, pero deberías separar mentalmente:

Módulo del kernel (Linux: nvidia.ko y afines): posee el dispositivo, maneja interrupciones, mapeos de memoria, lógica de reinicio.
Librerías en espacio de usuario (runtime de CUDA, ICD de OpenCL, stacks GL/Vulkan): traducen llamadas de API en trabajo para la GPU.
Firmware (en la tarjeta): gestiona tareas del microcontrolador como gestión de potencia y a veces primitivas de planificación.
Stack de gestión (NVML, nvidia-smi, demonio de persistencia): ajusta relojes, límites de potencia, modo de cómputo, particiones MIG.

Cualquiera de estos puede cambiar entre la “versión A” y la “versión B.” A veces actualizas uno y no el otro. Ahí comienza la diversión.

Hechos e historia: cómo llegamos a GPUs moldeadas por controladores

Aquí hay algunos puntos contextuales concretos que explican por qué los controladores hoy tienen tanto apalancamiento. Tenlos en mente; ayudan a diagnosticar la realidad.

Las GPUs tempranas eran de función fija. A finales de los 90 y principios de los 2000, las GPUs ejecutaban principalmente canalizaciones gráficas predefinidas. Los controladores eran importantes, pero “cambiar la GPU” significaba correcciones de errores y ajustes de rendimiento, no nuevos comportamientos de cómputo completos.
La programación de shaders movió la complejidad a los controladores. Una vez que las GPUs se volvieron programables (shaders), los controladores empezaron a hacer compilaciones agresivas y decisiones de planificación. Obtienes rendimiento… y variabilidad.
CUDA (2006) convirtió a las GPUs en dispositivos de cómputo general. Eso aumentó las apuestas: la corrección y la determinismo comenzaron a competir con el máximo rendimiento. La política del controlador se volvió parte del rendimiento de la aplicación.
Los boost clocks convirtieron la frecuencia en una perilla de política de software. El boost dinámico significa que dos tarjetas “idénticas” pueden ejecutar diferentes relojes según la temperatura, potencia y heurísticas del controlador.
ECC en algunas GPUs introdujo una compensación velocidad-vs-seguridad. Habilitar ECC puede reducir la memoria utilizable y, a veces, el rendimiento; los controladores controlan el reporte, el scrubbing y, a veces, los valores por defecto.
MPS y luego MIG cambiaron las semánticas de compartición. Multi-process service y multi-instance GPU son formas de compartir un dispositivo. También son nuevas maneras de tener vecinos ruidosos, thrash de contextos y estadísticas de utilización confusas.
Resizable BAR y mapeos de BAR grandes alteraron caminos de datos CPU↔GPU. Dependiendo de la plataforma y el controlador, la CPU puede mapear más VRAM directamente, cambiando el comportamiento de transferencias y el rendimiento de algunas cargas.
La seguridad se volvió una función del controlador, no solo del SO. Aislamiento, protecciones de memoria y mitigaciones viven en la pila del controlador. Algunas mitigaciones cuestan rendimiento; otras arreglan cosas feas. Elige tu veneno con cuidado y documéntalo.

Controladores como armas: la superficie real de ataque

“Arma” no siempre significa “malware.” En ops, “arma” a menudo significa “una palanca que puede arruinar tu SLO silenciosamente.”
Los controladores son exactamente esa palanca porque se sitúan por debajo de tu aplicación y encima del hardware.

Arma accidental: cambios de política que parecen deriva de hardware

Las actualizaciones de controladores suelen traer nuevos valores por defecto: curvas de boost diferentes, nuevas políticas de ventilador, nuevos asignadores de memoria, nueva planificación.
No lo notas hasta que algo que antes corría en P0 ahora está en P2 bajo la “misma” carga,
o las copias de memoria empeoran porque cambió la ruta IOMMU.

La forma más fácil de perder una semana es asumir que “el hardware es estable.” El hardware es estable. El contrato no lo es.

Arma intencional: empujarte hacia un ecosistema

Los proveedores no son caridad. Los controladores pueden orientarte hacia ciertas cadenas de herramientas y alejarte de otras:
deprecaciones, gating de funciones, versiones “soportadas”, matrices de compatibilidad que te castigan en silencio por actualizar el componente equivocado.

Esto no es automáticamente malvado. Es cómo evolucionan los stacks comerciales. Pero en producción, deberías tratarlo como un gradiente de incentivos.
Decide si seguirás el gradiente o te aislarás con versiones fijadas y despliegues controlados.

Arma por adversarios: cadena de suministro y privilegios

Los controladores de GPU corren con altos privilegios. Tocan espacio kernel, DMA, mapeo de memoria. Si piensas como un atacante,
el controlador es un lugar espectacular para buscar.

Tu respuesta no debe ser pánico. Debe ser: paranoia medida.
Paquetes firmados, repositorios controlados, arranque seguro donde sea posible y un plan de rollback que puedas ejecutar a las 3 a.m.

Cómo los controladores cambian el rendimiento y la fiabilidad

1) Relojes: tu GPU “igual” a una frecuencia diferente

El comportamiento de relojes es política. Los controladores leen temperatura, consumo, tipo de carga y a veces la configuración de “application clocks”.
Si tu nuevo controlador cambió la agresividad del boost o la interpretación del límite de potencia, verás un cambio de rendimiento sin cambiar código.

Observa estas pistas: estado P atascado por encima del reposo, o que nunca alcanza P0 bajo carga; relojes oscilando; límites de potencia alcanzados antes de tiempo.

2) Límites de potencia y objetivos térmicos

El límite de potencia no es solo “cuánto calor generas.” Es con qué frecuencia la GPU puede sostener el boost.
Los centros de datos adoran capear potencia. El entrenamiento ML odia el capeo sorpresa de potencia. Tu controlador puede imponer o interpretar los límites de forma distinta.

3) Gestión de memoria y oversubscription

En el papel, tu GPU tiene X GiB. En la práctica, las asignaciones, la fragmentación y el comportamiento de migración de páginas lo define el controlador.
Unified memory, pinned memory y UVA añaden capas donde “el controlador decide.”

Por eso una actualización del controlador puede convertir una carga de “corre bien” en “OOM aleatorio en el paso 8000.”
Cambió el asignador de memoria. O el umbral de expulsión. O el controlador ahora reserva más memoria para sí mismo.

4) Planificación y concurrencia: MPS, MIG y time-slicing

Si compartes GPUs, confías en el planificador del controlador para ser justo y eficiente.
Ese planificador cambia. A veces mejora. Otras veces cambia la forma de los picos de latencia.

MPS puede mejorar el rendimiento para kernels pequeños. También puede esparcir fallas entre clientes y confundir la atribución.
MIG puede dar un aislamiento fuerte, pero aún puedes tener cuellos de botella en recursos compartidos y sobrecarga a nivel de controlador.

5) Manejo de errores y recuperación: la diferencia entre “advertencia” y “nodo muerto”

El controlador decide qué hacer cuando la GPU se comporta mal: reiniciar el canal, reiniciar el dispositivo o rendirse.
Aquí vive la fiabilidad.

En Linux, verás mensajes NVRM Xid. A veces son benignos y recuperables. Otras veces predicen muerte inminente.
Las versiones del controlador cambian qué significa “recuperable.”

6) Selección de kernels en librerías: “actualización del controlador” que no es solo el controlador

Muchas oscilaciones de rendimiento culpadas al “controlador” son en realidad librerías de espacio de usuario cambiando sus heurísticas:
cuDNN elige algoritmos de convolución distintos; cuBLAS cambia la selección de GEMM; los resultados de autotuning varían con cambios menores.

Si actualizas el controlador y el toolkit CUDA en el mismo sprint, habrás creado una novela de misterio. Sepáralos.

Una cita de fiabilidad para mantenerte honesto

Idea parafraseada de Werner Vogels: Todo falla, todo el tiempo; construye sistemas que lo esperen y se recuperen automáticamente.

Guía rápida de diagnóstico (primero/segundo/tercero)

Cuando una carga GPU se vuelve más lenta o inestable tras un cambio de controlador, no empieces reescribiendo tu modelo o culpando al “PCIe.”
Empieza con un bucle de triaje estricto que aísle dónde cambió el contrato.

Primero: confirma qué cambió realmente

Versión del controlador, versión de CUDA, versión del kernel.
Versión del firmware de la GPU si está disponible.
Límites de potencia, modo de persistencia, modo de cómputo, estado MIG/MPS.
ECC habilitado/deshabilitado.

Segundo: decide si el cuello de botella es relojes, memoria o planificación

Problema de relojes/potencia: estado P que no alcanza los niveles esperados, límites de potencia alcanzados, picos de temperatura, rendimiento que oscila.
Problema de memoria: OOMs, síntomas de fragmentación, picos de paginación/migración, caída súbita en tamaño efectivo de batch.
Problema de planificación: regresiones multi-tenant, utilización extraña, picos de latencia en cola, kernels retrasados por otros contextos.

Tercero: reproduce con una prueba mínima y fija las variables

Ejecuta un microbenchmark estable o un pequeño paso representativo de inferencia/entrenamiento con semillas fijas.
Usa la misma imagen de contenedor y el mismo driver del host entre pruebas (o viceversa—controla un lado).
Recoge: relojes, potencia, temp, utilización, uso de memoria, registros Xid.

Si no puedes reproducirlo en una prueba mínima, probablemente sea un problema de concurrencia o contención, no de “velocidad bruta de la GPU.”

Tareas prácticas: comandos, salidas, decisiones (12+)

Estas son las tareas que realmente ejecuto cuando alguien dice “el controlador cambió nuestras GPUs.”
Cada tarea incluye: comando, qué significa la salida y la decisión que tomas.

Task 1: Identify the driver and GPU inventory

cr0x@server:~$ nvidia-smi
Tue Jan 13 10:22:41 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-SXM4-40GB          On  | 00000000:3B:00.0 Off |                    0 |
|  36%   48C    P0             210W / 400W|  1234MiB / 40960MiB   |     12%      Default |
+-----------------------------------------+----------------------+----------------------+

Significado: Confirma la versión del controlador, compatibilidad CUDA reportada, modo de persistencia, límite de potencia, estado de perf y contadores básicos de salud.

Decisión: Si la versión del controlador difiere de tu línea base, considera todo lo demás sospechoso hasta demostrar estabilidad. Regístralo en las notas del incidente.

Task 2: Confirm kernel module version loaded

cr0x@server:~$ modinfo nvidia | head -n 8
filename:       /lib/modules/6.5.0-28-generic/updates/dkms/nvidia.ko
version:        550.54.14
license:        NVIDIA
description:    NVIDIA kernel module
author:         NVIDIA Corporation
srcversion:     8F6C9C5B6B61A2D4E3B1B19
depends:
retpoline:      Y

Significado: Asegura que el módulo del kernel en ejecución coincide con la versión del paquete que crees haber instalado.

Decisión: Si nvidia-smi y modinfo no coinciden, tienes una actualización parcial o un módulo obsoleto. Arréglalo antes de benchmarkear.

Task 3: See recent driver errors (Xid) and GPU resets

cr0x@server:~$ sudo dmesg -T | egrep -i 'nvrm|xid|gpu has fallen off|reset' | tail -n 20
[Tue Jan 13 10:18:02 2026] NVRM: Xid (PCI:0000:3b:00): 31, pid=24811, name=python, Ch 0000002a
[Tue Jan 13 10:18:02 2026] NVRM: Xid (PCI:0000:3b:00): 31, pid=24811, name=python, MMU Fault: ENGINE GRAPHICS
[Tue Jan 13 10:18:04 2026] nvidia-modeset: WARNING: GPU:0: Corrected error detected

Significado: Los códigos Xid son informes de fallos a nivel de controlador. Fallos MMU pueden indicar kernels erróneos, accesos de memoria malos o regresiones del controlador.

Decisión: Si aparecen Xids tras la actualización y se correlacionan con fallos de trabajos, deja de discutir sobre “rendimiento” y empieza a tratarlo como regresión de fiabilidad. Considera rollback o aislar nodos canarios.

Task 4: Check power limit and whether it was silently changed

cr0x@server:~$ nvidia-smi -q -d POWER | egrep -i 'Power Limit|Default Power Limit|Enforced Power Limit'
    Power Limit                    : 400.00 W
    Default Power Limit            : 400.00 W
    Enforced Power Limit           : 400.00 W

Significado: Muestra la política de potencia actual y por defecto. Un desajuste entre “por defecto” y “impuesto” es una bandera roja.

Decisión: Si el límite impuesto bajó (común en racks compartidos), decide si aumentarlo (si está permitido) o retocar tamaños de batch y expectativas. No hagas benchmarks con límites desconocidos.

Task 5: Observe real-time clocks and throttling reasons

cr0x@server:~$ nvidia-smi dmon -s pucvmt -d 1 -c 5
# gpu   pwr  u  c  v  m  t
# Idx     W  %  MHz  MHz  %  C
    0   212 12  1410 12150  3  49
    0   225 85  1410 12150 61  56
    0   238 92  1410 12150 72  59
    0   399 98  1170 12150 84  66
    0   401 99  1140 12150 86  67

Significado: Puedes ver los relojes caer cuando se alcanza el límite de potencia. La utilización se mantiene alta, los relojes bajan: eso es throttling por potencia.

Decisión: Si los relojes colapsan al límite de potencia, o sube el cap, mejora refrigeración/flujo de aire o acepta menor rendimiento. No culpes al “modelo.”

Task 6: Confirm persistence mode (to avoid cold-start jitter)

cr0x@server:~$ nvidia-smi -q | egrep -i 'Persistence Mode' | head -n 1
    Persistence Mode               : Enabled

Significado: La persistencia deshabilitada puede causar costes repetidos de inicialización y demoras de asentamiento de relojes entre trabajos.

Decisión: En clústeres compartidos con trabajos cortos, activa persistence mode en nodos de cómputo para reducir variabilidad—a menos que tu organización tenga razón para no hacerlo.

Task 7: Check ECC mode and error counts

cr0x@server:~$ nvidia-smi -q -d ECC | egrep -i 'ECC Mode|Volatile|Aggregate'
    ECC Mode
        Current                     : Enabled
        Pending                     : Enabled
    Volatile Uncorrectable ECC Errors : 0
    Aggregate Uncorrectable ECC Errors : 0

Significado: ECC cambia el comportamiento de memoria y puede revelar fallos de hardware. Los errores volátiles son desde el arranque; los agregados persisten.

Decisión: Si los errores uncorrectable agregados aumentan, esto tiende hacia una conversación de RMA de hardware, no de ajuste. Pone en cuarentena el nodo.

Task 8: Verify MIG state and layout (is the GPU actually partitioned?)

cr0x@server:~$ nvidia-smi -L
GPU 0: NVIDIA A100-SXM4-40GB (UUID: GPU-0a1b2c3d-4e5f-6789-abcd-0123456789ef)
  MIG 1g.5gb Device 0: (UUID: MIG-GPU-0a1b2c3d-4e5f-6789-abcd-0123456789ef/1/0)
  MIG 1g.5gb Device 1: (UUID: MIG-GPU-0a1b2c3d-4e5f-6789-abcd-0123456789ef/2/0)

Significado: Si existen dispositivos MIG, tu “GPU 0” no es una GPU completa desde la perspectiva del trabajo.

Decisión: Si el rendimiento regresó tras una actualización y MIG está activo, confirma que tu scheduler asigna el perfil MIG esperado. Muchas “regresiones” son en realidad cortes más pequeños.

Task 9: Validate PCIe link width/speed (classic silent limiter)

cr0x@server:~$ sudo lspci -s 3b: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)

Significado: La GPU está ejecutándose a velocidad/anchura PCIe reducida. Eso puede ocurrir tras cambios de firmware, ajustes BIOS o hardware marginal.

Decisión: Si el enlace está degradado, tu cuello de botella puede ser I/O del host. Arregla la plataforma (volver a asentar, BIOS, riser, ajustes ASPM) antes de culpar al controlador.

Task 10: Check IOMMU status (can affect DMA performance and compatibility)

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.5.0-28-generic root=/dev/nvme0n1p2 ro quiet splash intel_iommu=on iommu=pt

Significado: Muestra si IOMMU está habilitado y si se usa modo passthrough. Algunas configuraciones empeoran si IOMMU está en modo de traducción completa.

Decisión: Si ves ajustes inesperados de IOMMU tras una actualización de kernel/controlador, reevalúa rendimiento DMA y requisitos de aislamiento del dispositivo. No “optimices” esto a ciegas.

Task 11: Confirm container sees the expected CUDA runtime

cr0x@server:~$ docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi
Tue Jan 13 10:25:10 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14              Driver Version: 550.54.14      CUDA Version: 12.4  |
+---------------------------------------------------------------------------------------+

Significado: Confirma que el driver del host se expone dentro del contenedor y que las herramientas del contenedor concuerdan.

Decisión: Si el contenedor no puede ejecutar nvidia-smi o reporta componentes desajustados, arregla la integración del runtime de contenedores (NVIDIA Container Toolkit) antes de perseguir “bugs del modelo.”

Task 12: Detect library-level shifts (cuDNN / cuBLAS) that look like driver regressions

cr0x@server:~$ python -c "import torch; print(torch.__version__); print(torch.version.cuda); print(torch.backends.cudnn.version())"
2.2.1
12.1
8902

Significado: Las versiones CUDA/cuDNN de tu framework importan tanto como el controlador. Una actualización del controlador puede coincidir con un refresh del contenedor.

Decisión: Si las versiones cambiaron, no tienes un A/B limpio. Vuelve a ejecutar pruebas cambiando solo una variable (solo controlador o solo contenedor).

Task 13: Check GPU process list and whether “utilization” is lying to you

cr0x@server:~$ nvidia-smi pmon -c 1
# gpu        pid  type    sm   mem   enc   dec   jpg   ofa   command
# Idx          #   C/G     %     %     %     %     %     %     name
    0      24811     C    92    18     0     0     0     0     python
    0      25102     C     5     2     0     0     0     0     python

Significado: Múltiples procesos de cómputo comparten el dispositivo. Tu “lentitud” puede ser contención, no una regresión del controlador.

Decisión: Si existen procesos inesperados, arregla programación/aislamiento primero. Depurar rendimiento sin control de tenencia es astrología con mejores gráficos.

Task 14: Capture a short performance trace (high-level) for regression proof

cr0x@server:~$ nvidia-smi --query-gpu=timestamp,driver_version,pstate,clocks.sm,clocks.mem,power.draw,temperature.gpu,utilization.gpu,utilization.memory --format=csv -l 1 -c 5
timestamp, driver_version, pstate, clocks.sm [MHz], clocks.mem [MHz], power.draw [W], temperature.gpu, utilization.gpu [%], utilization.memory [%]
2026/01/13 10:26:31, 550.54.14, P0, 1410, 12150, 225.11, 56, 85, 61
2026/01/13 10:26:32, 550.54.14, P0, 1410, 12150, 238.42, 59, 92, 72
2026/01/13 10:26:33, 550.54.14, P0, 1170, 12150, 399.72, 66, 98, 84
2026/01/13 10:26:34, 550.54.14, P0, 1140, 12150, 401.03, 67, 99, 86
2026/01/13 10:26:35, 550.54.14, P0, 1140, 12150, 401.10, 67, 99, 86

Significado: Este es el “recibo” más simple para adjuntar a un incidente: relojes, potencia, temp y utilización en un CSV.

Decisión: Si puedes mostrar que los relojes caen exactamente cuando se alcanza el límite de potencia, dejas de debatir y empiezas a negociar la política de potencia o una remediación térmica.

Chiste corto #1: Una actualización de controlador GPU es como una “solicitud de cambio menor” de finanzas—técnicamente pequeña, emocionalmente devastadora.

Tres micro-historias corporativas desde el campo

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

Una compañía operaba una flota mixta de GPUs para entrenamiento e inferencia. El equipo SRE tenía una regla clara: actualizar controladores mensualmente, parchear kernels trimestralmente.
Asumieron que la frontera de compatibilidad clave era “la versión de CUDA dentro del contenedor.” Si el contenedor corría, estaban satisfechos.

Un mes, una actualización de controlador llegó a la mitad de los nodos de inferencia. En horas, la latencia en cola se volvió extraña: no catastrófica, solo suficiente para fallar un SLO interno.
Los ingenieros vieron la utilización GPU alta. Supusieron que el modelo se había hecho más pesado. No fue así.

El cambio real fue la política de potencia. El nuevo controlador interpretó los controles del límite de potencia de la plataforma de forma distinta. Bajo carga sostenida, las GPUs alcanzaron el tope y bajaron la frecuencia más agresivamente.
Misma utilización, menos ciclos efectivos. El sistema parecía “ocupado” mientras entregaba menos trabajo—colapso de throughput disfrazado de productividad.

La suposición equivocada fue que “las actualizaciones de controladores no cambian el comportamiento de potencia.” Lo hacen. La solución fue aburrida: registrar y hacer cumplir los límites de potencia explícitamente como parte del aprovisionamiento del nodo,
y mantener una traza CSV base (como la anterior) de una ejecución conocida buena. Una vez hecho eso, las “regresiones de rendimiento” se convirtieron en eventos demostrables, no en impresiones subjetivas.

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

Otra organización perseguía el máximo throughput en un clúster multi-tenant de entrenamiento. Habilitaron una función de compartición para mejorar utilización:
más trabajos por GPU, menos huecos inactivos, mejores números en el dashboard.

Funcionó el primer día. Luego llegó la actualización del controlador. De pronto, ejecuciones raras de entrenamiento comenzaron a fallar con errores relacionados con memoria y a veces Xids del controlador.
Los fallos no estaban distribuidos uniformemente: algunos equipos sufrieron, otros no, lo que lo hizo políticamente delicioso y técnicamente horrible.

La optimización tenía un coste oculto: la nueva versión del controlador cambió el comportamiento de gestión de memoria bajo oversubscription y aumentó la sobrecarga del cambio de contexto
para la mezcla específica de kernels que ejecutaban. Más concurrencia significó más presión de fragmentación y más tiempo en rutas del controlador, no en los SMs.

La “solución” no fue abandonar la compartición para siempre. Fue aplicarla con restricciones: exigir margen duro por trabajo en memoria, limitar contextos concurrentes por GPU,
y condicionar la actualización del controlador a pruebas de estrés diseñadas para disparar la ruta de fragmentación. La lección: utilización no es throughput, y throughput no es fiabilidad.

Chiste corto #2: Intentamos “optimizar el compartido de GPU” y accidentalmente inventamos un generador de números aleatorios con ventilador.

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

Una tercera compañía hizo algo poco glamuros: mantuvieron un “nodo dorado” por clase de GPU. Mismo BIOS, mismo kernel, mismo controlador,
mismas imágenes de contenedor. Ejecutaba una suite nocturna: un microbenchmark, un batch representativo de inferencia y un breve bucle de entrenamiento.

Cuando se proponía una actualización de controlador, primero se aplicaba en el nodo dorado y en una pequeña pool canaria. La suite corría automáticamente y comparaba con una línea base fijada.
El equipo no pedía perfección; pedía explicación. Si el rendimiento cambiaba, querían una razón: potencia, relojes, memoria, planificación o cambios en librerías.

Una actualización mostró una pequeña regresión de throughput pero también eliminó una clase de errores Xid que previamente causaban drenados raros de nodos.
El impacto de negocio favoreció la fiabilidad. Porque tenían evidencia, pudieron elegir el tradeoff intencionadamente en lugar de por sorpresa.

La práctica “aburrida” fue fijar versiones, canarios controlados y artefactos de prueba de regresión. No hizo a nadie famoso.
Sí mantuvo al clúster fuera del canal de incidentes.

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

Estos son patrones que veo repetidamente cuando los equipos tratan a los controladores GPU como una dependencia inofensiva.
Usa esto como una tabla de búsqueda de modos de fallo.

1) Síntoma: Utilización GPU alta, throughput menor que la semana pasada

Causa raíz: Cambio en el cap/thermal throttling; los relojes están más bajos mientras la utilización SM permanece alta.

Solución: Mide relojes/potencia con nvidia-smi --query-gpu y dmon. Confirma límite de potencia. Mejora refrigeración o ajusta caps; retunea tamaños de batch si los caps son política.

2) Síntoma: OOM aleatorio después de actualizar el controlador, mismo batch size

Causa raíz: El controlador ahora reserva más VRAM; cambió el comportamiento del asignador; la fragmentación aumentó con concurrencia.

Solución: Reduce pico de VRAM (batch/longitud de secuencia), añade margen, reduce contextos concurrentes y compara líneas base de uso de memoria entre versiones.

3) Síntoma: Trabajos de entrenamiento se cuelgan, el nodo necesita reinicio

Causa raíz: Canal GPU bloqueado; el controlador no puede recuperar; cambió la ruta de reinicio. A menudo correlacionado con Xids.

Solución: Recolecta Xids con dmesg, aisla por versión del controlador, prueba rollback. Considera habilitar un chequeo de salud que drene el nodo ante patrones de Xid antes de que se cuelgue profundamente.

4) Síntoma: Después de la actualización, algunos nodos son lentos, otros bien

Causa raíz: Versiones de controlador mixtas, layouts MIG mixtos o diferencias de plataforma (PCIe degradado, ajustes BIOS).

Solución: Aplica controles de deriva de configuración. Revisa versiones de controlador, estado MIG y estado del enlace PCIe. No compares manzanas con manzanas ligeramente rotas.

5) Síntoma: El contenedor dice versión CUDA X, pero errores de runtime mencionan driver incompatible

Causa raíz: Driver del host demasiado antiguo para las expectativas del runtime del contenedor; o integración del runtime de contenedores rota.

Solución: Alinea el driver del host con la compatibilidad CUDA requerida. Valida con un simple test docker run --gpus all ... nvidia-smi antes de ejecutar cargas reales.

6) Síntoma: Picos de latencia en inferencia multi-tenant tras la actualización

Causa raíz: Cambios en la equidad del planificador; time-slicing más agresivo; diferencias en MPS; aumento de overhead por cambio de contexto.

Solución: Reduce la compartición, usa perfiles MIG para aislamiento fuerte o dedica GPUs para servicios sensibles a latencia. Mide latencia cola bajo carga, no el throughput promedio en aislamiento.

7) Síntoma: Rendimiento de transferencia PCIe cayó

Causa raíz: Anchura/velocidad PCIe degradada; modo IOMMU cambiado; resizable BAR toggled por combinación BIOS/controlador.

Solución: Revisa lspci -vv LnkSta, confirma ajustes BIOS, valida parámetros IOMMU. Si es necesario, vuelve a asentar hardware o cambia risers antes de afinar software.

Listas de verificación / plan paso a paso

Paso a paso: despliegue seguro de controladores GPU en producción

Inventario y clasificación de nodos por modelo GPU, placa base, versión BIOS, versión de kernel y tipo de carga (entrenamiento vs inferencia).
Fija una línea base: registra versión del controlador, límites de potencia, modo ECC, estado MIG/MPS y un pequeño resultado de benchmark con traza de relojes/potencia.
Actualiza solo el controlador primero (no el toolkit CUDA, no los contenedores) en un nodo dorado. Recoge la misma traza.
Ejecuta una suite de estrés que incluya kernels de larga ejecución, presión de memoria y concurrencia si la usas en producción.
Canary en una pequeña pool con cargas representativas. Observa latencia cola y tasas de error, no solo throughput.
Establece políticas explícitas: límites de potencia, persistence mode, modo de cómputo y layout MIG deben configurarse, no asumirse.
Despliega gradualmente con una condición de rollback clara: patrones Xid específicos, umbral de regresión de throughput o incumplimiento de SLO.
Bloquéalo tras el despliegue: asegúrate de que nadie actualice controladores automáticamente en nodos al azar. La deriva es cómo obtienes “solo los martes van lento.”

Lista pre-vuelo para reportes de “la GPU se siente diferente”

¿Tenemos registro de la versión del controlador antes/después?
¿Son comparables relojes/potencia/temperaturas?
¿Cambió el estado MIG/MPS?
¿Cambió el modo ECC?
¿Está degradado el enlace PCIe?
¿Hay Xids en dmesg?
¿Cambió versión CUDA/cuDNN del contenedor al mismo tiempo?
¿Hay multi-tenancy inesperado en la GPU?

Guardarraíles operativos que recomiendo (opinión)

Nunca actualices controlador + toolkit CUDA + framework en una sola ventana de cambio si te importa la causa raíz.
Mantén un nodo dorado por clase de GPU con una suite de regresión automatizada.
Haz los límites de potencia explícitos. Los valores por defecto no son contratos.
Requiere un plan de rollback que incluya rollback de módulo del kernel y automatización de drenado de nodos.
Mide latencia cola para inferencia y estabilidad de pasos/segundo para entrenamiento. Los promedios ocultan cambios de política del controlador.

Preguntas frecuentes

1) ¿Puede un controlador de GPU realmente cambiar el rendimiento sin cambiar mi código?

Sí. Los controladores ajustan relojes, comportamiento de potencia, políticas de planificación, estrategia de asignación de memoria y heurísticas de selección de kernels en librerías.
Tu código puede ser idéntico mientras el contrato efectivo del hardware cambia.

2) Si `nvidia-smi` muestra alta utilización, ¿no demuestra eso que la GPU está completamente usada?

No. La utilización es “tiempo ocupado,” no “trabajo útil realizado.” Puedes estar 99% ocupado a relojes más bajos por cap de potencia y entregar menos throughput.
Siempre mira relojes y potencia junto a la utilización.

3) ¿Cuál es la forma más rápida de probar una regresión de potencia/relojes?

Recoge una traza CSV corta de pstate, relojes SM, consumo de potencia, temperatura y utilización durante la carga.
Si los relojes caen cuando la potencia alcanza el cap, tienes al culpable.

4) ¿Las actualizaciones de controladores son mayormente sobre rendimiento?

No. Muchas tratan corrección, seguridad y estabilidad a través de kernels y plataformas. Los cambios de rendimiento suelen ser efectos secundarios de cambios de política.
En producción, las correcciones de estabilidad pueden valer una pequeña ralentización—si lo eliges conscientemente.

5) ¿MIG es siempre mejor para multi-tenancy?

Es un aislamiento mejor que el time-slicing simple, pero no es magia. Aún puedes tener cuellos de botella en recursos compartidos y overhead del controlador.
MIG es excelente cuando necesitas slices previsibles; puede ser derrochador si tus cargas son bursty y no encajan bien en los perfiles.

6) ¿Por qué algunas actualizaciones de controladores aumentan el uso de memoria?

Los controladores pueden reservar diferentes cantidades de VRAM para bookkeeping interno, tablas de páginas o nuevas funciones.
Además, el comportamiento de librerías y asignadores puede cambiar. Ese “1–2 GiB faltante” suele ser real, no imaginación.

7) ¿Deberíamos fijar controladores para siempre una vez que todo funciona?

No. Fijar para siempre es cómo acumulas riesgo de seguridad y deuda de incompatibilidad futura. Fija deliberadamente, actualiza deliberadamente.
Una cadencia controlada con canarios es mejor que tanto el caos como la estasis.

8) ¿Cuál es la diferencia entre problemas de controlador y problemas de hardware?

Los problemas de hardware suelen mostrarse como tendencias persistentes de errores ECC, fallos reproducibles a través de versiones de controlador o degradaciones físicas del enlace.
Los problemas de controlador se correlacionan estrechamente con cambios de versión y a menudo afectan a muchos nodos de forma similar. Usa logs Xid y contadores ECC para diferenciarlos.

9) ¿Por qué varía el rendimiento entre GPUs “idénticas”?

Variación del silicio, diferencias de refrigeración, entrega de potencia y políticas de boost todo importa. Los controladores amplifican estas diferencias cambiando heurísticas de boost y throttling.
En otras palabras: números de parte idénticos no son comportamiento de ejecución idéntico.

10) ¿Qué debo almacenar en los artefactos de incidente para una regresión de GPU?

Como mínimo: versión del controlador, versión del kernel, modelo GPU, ajustes de límite de potencia, estado MIG/MPS/ECC, una traza corta de nvidia-smi --query-gpu
y extractos relevantes de dmesg con Xids.

Conclusión: qué hacer el próximo lunes

Si ejecutas GPUs en producción, deja de tratar a los controladores como una dependencia de fondo y empieza a tratarlos como firmware con opiniones.
Los controladores no solo “habilitan el dispositivo.” Definen su comportamiento bajo potencia, calor, contención y fallo.

Pasos prácticos siguientes:

Elige un controlador base por clase de GPU y registra explícitamente políticas de potencia/ECC/MIG/MPS.
Construye una pequeña suite de regresión y ejecútala en un nodo dorado y en una pool canaria antes de despliegues.
Cuando veas regresiones, captura primero relojes/potencia/util y logs Xid. Discute después.
Separa las actualizaciones de controlador de las del toolkit CUDA/framework cuando quieras una causa raíz clara.
Mantén los caminos de rollback ensayados, no teóricos.

El hardware envejece. Los controladores evolucionan. Tu trabajo es hacer visibles, testeables y reversibles esos cambios—para que “la GPU cambió” sea un diagnóstico, no una superstición.