ATI vs NVIDIA: por qué esta rivalidad nunca termina

Por qué esta rivalidad nunca termina (no es personal, es operativo)

Las decisiones de compra de GPU parecen debates de producto hasta que las operas. Entonces parecen riesgo de cadena de suministro,
matrices de compatibilidad kernel/controlador, rarezas de firmware y “por qué el contenedor dejó de ver el dispositivo de repente”.
ATI/AMD vs NVIDIA persiste porque cada lado optimiza una definición distinta de “funciona”.

NVIDIA históricamente trata el controlador y el stack de cómputo como un producto fuertemente controlado. Obtienes una historia coherente:
CUDA, cuDNN, NCCL, TensorRT y un modelo de controlador que se mantiene consistente entre distribuciones—al precio de ser un invitado en
el mundo del kernel Linux, no un ciudadano. Es efectivo, es rápido y a veces se siente como ejecutar un controlador RAID propietario:
sorprendente hasta que necesitas que el interior coopere con tu kernel específico, compositor o postura de seguridad.

La historia moderna de AMD está más orientada hacia upstream: AMDGPU en el kernel, Mesa en userland, comportamiento más “nativo” de Linux.
Eso tiende a ser agradable operacionalmente—menos pegamento raro, menos blobs binarios, mejor alineación con cómo las distros esperan
que funcione el gráfico. Pero el cómputo es donde la gravedad muerde: la base instalada de CUDA es un foso, y ROCm aún tiene aristas
en soporte de hardware, empaquetado y la larga cola de bibliotecas.

Si esperas un ganador universal, estás comprando una religión. Mejor: elige los modos de fallo con los que puedes vivir.
Si ejecutas ML, tus valores por defecto están moldeados por CUDA hasta que se demuestre lo contrario. Si gestionas escritorios Linux a escala,
el upstreaming y la integración predecible con el kernel suelen importar más que ganar benchmarks.

Hechos históricos que todavía influyen en las decisiones de hoy

El pasado no es trivia aquí. Es por qué ciertas APIs se convirtieron en valores por defecto, por qué las pilas de controladores lucen como lucen y por qué tu
representante de ventas usa la palabra “hoja de ruta” como un hechizo.

8 puntos de contexto (concretos, no de museo)

1. ATI fue adquirida por AMD en 2006. Eso cambió incentivos: las GPU pasaron a ser parte de una jugada CPU+GPU,
   influyendo en gráficos integrados, APUs y más tarde en la postura de “controladores abiertos”.
2. NVIDIA introdujo CUDA en 2006. No fue la primera en “cómputo GPU”, pero se convirtió en el valor por defecto porque
   era usable, estable y fue evangelizada sin descanso en la academia y la industria.
3. OpenCL nunca destronó a CUDA. Existe, funciona, es relativamente portable y a menudo es una cadena de herramientas
   de “denominador común más bajo” en la que los proveedores no invirtieron por igual.
4. La trayectoria de controladores de código abierto de AMD fue un giro de años. El cambio desde pilas propietarias antiguas hacia
   AMDGPU/Mesa no fue solo ideología; fue una maniobra de supervivencia para la compatibilidad con Linux y la confianza de desarrolladores.
5. El mundo GPGPU normalizó la “aceleración específica del proveedor”. CUDA es el ejemplo obvio, pero muchas bibliotecas de ML y
   HPC incorporan supuestos sobre kernels, comportamiento de memoria y herramientas de perfilado atadas a un proveedor.
6. Los juegos impulsaron una churn agresiva de características. Cambios en modelos de sombreado, async compute, trazado de rayos y funciones de frame-gen hacen tentador el “último controlador”—y peligroso operativamente.
7. Las pilas de display cambiaron bajo los pies de todos. La adopción de Wayland y compositores modernos expuso diferentes puntos de fricción entre modelos propietarios y upstream, especialmente para multi-monitor y refrescos variables.
8. Las líneas de producto de GPU para centros de datos divergen del comportamiento de consumo. ECC VRAM, telemetría, gestión de potencia y funciones de virtualización hicieron que “es básicamente el mismo silicio” sea una suposición arriesgada.

Dos filosofías: cerrado y pulido vs abierto e integrado

Esta rivalidad sobrevive porque los proveedores optimizan distintos vértices del mismo triángulo: rendimiento, portabilidad y operabilidad.
Rara vez obtienes los tres.

Fortaleza de NVIDIA: gravedad del ecosistema y “un punto de fallo claro”

El mayor activo de NVIDIA no son los TFLOPS crudos. Es la expectativa de que CUDA esté disponible, que las herramientas sean maduras y que
la próxima librería que instales con pip tenga rueda CUDA antes que cualquier otra cosa. El perfilado es coherente. El soporte del proveedor
está estructurado. En producción, eso importa: puedes estandarizar imágenes, AMIs base y aprovisionamiento de nodos alrededor de un stack
que se comporta de forma similar entre generaciones de hardware.

El coste es el vendor lock-in y un modelo de controlador que puede sentirse como si estuviera ignorando cortésmente las reglas de tu distro.
Las actualizaciones de kernel se convierten en gestión del cambio. Secure Boot se vuelve una discusión, no una casilla. Y cuando los servidores
de display evolucionan, esperas compatibilidad.

Fortaleza de AMD/ATI: alineación upstream y comportamiento “nativo Linux”

AMDGPU en el kernel y Mesa como stack 3D mainstream significan menos sorpresas exóticas. Te beneficias de la misma ingeniería de lanzamientos que mantiene
funcional al resto de Linux. La depuración puede ser más transparente. Y para muchas cargas gráficas—especialmente en distros modernas—AMD puede ser la
elección de “simplemente funciona” de una manera que antes era impensable.

El coste aparece en cómputo y en la larga cola: restricciones de soporte hardware en ROCm, dolor por fijar versiones y el hecho de que muchos proyectos upstream
aún tratan a NVIDIA como “el objetivo” y al resto como “mejor esfuerzo”.

Opinión: si tu negocio depende de un framework ML específico hoy, asume NVIDIA a menos que tengas una vía ROCm probada. Si tu negocio depende de escritorios
Linux que deben seguir funcionando tras actualizaciones del kernel, trata a AMD como el valor por defecto y haz que NVIDIA se gane la excepción.

Controladores, kernels y el fino arte de no inutilizar tu escritorio

Las GPU son dos cosas a la vez: un dispositivo de cómputo y un dispositivo de pantalla. Esos roles chocan en la arquitectura del controlador. La ruta de display
se preocupa por compositores, modesetting, suspend/resume y rarezas multi-monitor. La ruta de cómputo se preocupa por bibliotecas user-space estables, descubrimiento
de dispositivos consistente y comportamiento de memoria predecible.

Integración con el kernel: upstream vs fuera del árbol

El controlador principal de AMD forma parte del ecosistema del kernel. Eso no garantiza perfección, pero sí significa que las regresiones son visibles y corregibles
en el mismo flujo de trabajo que el resto del SO. El módulo kernel propietario de NVIDIA históricamente vivió fuera del árbol, con una cadencia y restricciones diferentes.
Eso está mejorando con enfoques más nuevos, pero operativamente aún debes planear el acoplamiento kernel-controlador como un riesgo de primera clase.

Pilas de display: Xorg es indulgente, Wayland es honesto

Xorg permite a los proveedores cubrir pecados. Wayland hace más explícita la canalización, y eso expone desajustes: sincronización explícita, gestión de buffers,
enrutamiento multi-GPU y comportamiento VRR. Si despliegas estaciones de trabajo para desarrolladores o VDI, tu “elección de proveedor GPU” suele ser
“qué conjunto de bugs de display queremos asumir”.

Cita sobre fiabilidad (idea parafraseada)

La esperanza no es una estrategia. — idea parafraseada ampliamente atribuida en círculos de ops/fiabilidad

Trata las decisiones sobre proveedor GPU como decisiones sobre controladores de almacenamiento: sí, haces benchmarks. Pero también pruebas actualizaciones,
recuperación de fallos y observabilidad. Ahí es donde la rivalidad se vuelve real.

Stacks de cómputo: CUDA, ROCm, OpenCL y la gravedad de los valores por defecto

La razón práctica por la que la rivalidad no termina: CUDA se convirtió en la suposición por defecto para “cómputo GPU”. Una vez que mil
scripts internos, notebooks, contenedores y herramientas de terceros asumen CUDA, cambiar de proveedor se convierte en un proyecto de migración, no en una orden de compra.

CUDA: el camino bien iluminado

CUDA no es solo una API; es todo un ecosistema de depuradores, perfiles, bibliotecas matemáticas, comunicación colectiva y convenciones de empaquetado.
Ese ecosistema reduce la varianza. La varianza es lo que causa incidentes a las 3 a. m.

Cuando NVIDIA rompe algo, tienden a arreglarlo rápido porque afecta a muchos clientes que pagan. Eso no significa que estés a salvo.
Significa que el radio de explosión es lo bastante grande como para motivar parches rápidos.

ROCm: real, en mejora, aún condicional

ROCm puede ser excelente cuando estás en hardware y versiones soportadas. El rendimiento puede ser competitivo y la historia de herramientas relativamente abiertas es atractiva.
Pero la trampa operacional es el “casi soportado”. Una GPU puede ejecutar gráficos bien y aun así ser un dolor en cómputo. O un desajuste menor de controlador puede convertirse en
dispositivos faltantes dentro de contenedores.

OpenCL y APIs “portables”

OpenCL es la respuesta clásica contra el lock-in, pero muchos equipos solo lo tocan indirectamente. Algunas aplicaciones lo usan para kernels específicos o aceleración heredada.
En 2026, la portabilidad suele alcanzarse via frameworks de más alto nivel que eligen backends. Eso es progreso, pero también deuda de abstracción: cuando el rendimiento es malo,
terminas depurando el backend que esperabas evitar.

Opinión: si quieres portabilidad, diseña para ella desde el principio. No compres NVIDIA, escribas CUDA en todas partes y luego “planees” migrar a AMD más tarde.
Eso no es un plan; es un cuento para dormir.

Realidades del centro de datos: ECC, límites de potencia, térmicas y modos de fallo

En centros de datos, las GPU fallan como cualquier otro componente: térmicas, alimentación, firmware y fatiga del silicio. La diferencia es que las fallas de GPU
a menudo parecen bugs de aplicación. Tu trabajo de entrenamiento “divergió”. Tu render tiene artefactos. Tus transcodificaciones presentan corrupción sutil.
Tu escritorio se cuelga pero el nodo sigue respondiendo a pings. Felicidades: ahora tienes un problema de detección.

ECC VRAM y corrupción silenciosa de datos

ECC en VRAM es aburrido. Lo aburrido es bueno. Si haces entrenamiento ML, cómputo científico, finanzas o cualquier cosa en la que la corrección importe,
trata ECC como un requisito. Si tu línea de GPU no lo soporta, compensa con comprobaciones de validación y redundancia, y acepta el riesgo explícitamente.

Gestión de potencia como palanca de producción

Las GPU de centro de datos pueden limitarse en potencia para ajustarse a sobres térmicos. No se trata solo de facturas de electricidad; es no disparar interruptores,
no sobrecalentar chasis y no provocar cascadas de throttling. Las herramientas del proveedor difieren, pero el principio es el mismo: conoce tus límites de potencia,
mide razones de throttling y establece límites deliberadamente.

Virtualización y particionado de dispositivos

NVIDIA tiene historias maduras alrededor de vGPU en muchos entornos. AMD ha avanzado, pero la disponibilidad operacional depende mucho del hipervisor, el kernel y el SKU exacto.
Si haces VDI o scheduling multi-tenant de GPU, no asumas “es una GPU, se virtualizará”. Prueba toda la pila: licencias, controladores host, controladores guest y monitorización.

Broma #1: Una GPU sin telemetría es como un arreglo de almacenamiento sin SMART—puedes seguir usándolo, pero aprenderás humildad rápido.

Tres micro-historias del mundo corporativo (incluye dolor)

Micro-historia 1: El incidente causado por una suposición incorrecta

Una empresa mediana de analítica desplegó nuevos nodos GPU para una canalización de visión por computador. La decisión de compra fue
“tarjetas AMD modernas, buen precio/rendimiento, amigables con Linux”. El clúster era Kubernetes-based, y el modelo mental del equipo era simple: “Si el nodo ve la GPU, los pods verán la GPU”.

La suposición incorrecta: el descubrimiento de dispositivos y la integración del runtime de contenedores se comportan igual entre proveedores. En la práctica,
su plugin de dispositivo existente e imágenes base estaban moldeadas por CUDA. Los pods comenzaron a fallar con “no GPU devices found”, pero
solo en los nuevos nodos. Los schedulers reintentaban. La cola creció. Los SLA se resintieron.

La primera respuesta fue el clásico desperdicio de tiempo: cambiar tarjetas y reimaging de nodos. Nada cambió. Las GPUs estaban bien.
Los módulos del kernel estaban cargados. Pero las bibliotecas user-space dentro de los contenedores no tenían las piezas runtime correctas,
y el plugin de GPU del clúster no sabía cómo anunciar correctamente esos dispositivos.

Lo solucionaron tratando la pila GPU como parte del grafo de dependencias de la aplicación. Los nuevos pools de nodos tuvieron etiquetas explícitas,
imágenes separadas y un job de validación que corría al arranque para confirmar la visibilidad del dispositivo y un test trivial de kernel. La lección
fue incómoda pero valiosa: la paridad de hardware es irrelevante si las suposiciones de runtime son específicas del proveedor.

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

Una compañía de medios ejecutaba transcodificaciones de vídeo aceleradas por GPU en una flota de máquinas mixtas. Un ingeniero bienintencionado notó
que las GPU estaban “poco utilizadas” y propuso una ganancia rápida: empaquetar más jobs concurrentes por GPU y subir clocks para estabilizar el throughput.

Durante dos semanas, los dashboards se veían bien. El throughput subió. Luego empezaron los incidentes: cuadros corrompidos ocasionales, crashes raros de encoder
y máquinas que se congelaban bajo carga pico. El equipo culpó al códec, luego al runtime de contenedores, luego al kernel.

El problema real fue el comportamiento térmico y de potencia bajo carga sostenida. La “optimización” eliminó margen y empujó las tarjetas hacia throttling frecuente
y errores transitorios. Algunas cargas no fallan ruidosamente; degradan la calidad o caen de forma no determinista. El empaquetamiento agresivo también amplificó
la fragmentación de VRAM y la presión de memoria.

El rollback fue aburrido: limitar jobs concurrentes, imponer límites de potencia y programar con control de admisión sensible a la temperatura. La conclusión del postmortem:
la GPU no estaba infrautilizada; estaba reservando margen de estabilidad. Puedes gastar ese margen, pero espera pagar intereses.

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

Un laboratorio de investigación ejecutaba jobs de entrenamiento nocturnos en un pequeño clúster. No eran sofisticados, pero eran disciplinados: versiones de controladores fijadas,
versiones de kernel fijadas y una ventana de mantenimiento mensual donde actualizaban primero un nodo canario.

Un mes, una actualización rutinaria del SO introdujo una regresión en el controlador GPU que solo aparecía bajo un patrón específico de comunicación colectiva. El nodo canario lo detectó
en pocas horas. Los logs de job eran raros pero consistentes: timeouts intermitentes de NCCL bajo carga.

Como el equipo tenía un plan de rollback escrito, revirtieron el canario a la combinación anterior de driver/kernel y mantuvieron el resto de la flota intacta. Registraron
el problema con el proveedor y esperaron un controlador parcheado.

Sin heroísmos. Sin incidentes globales. Sin “perdimos tres días de entrenamiento”. La práctica aburrida—canarying de actualizaciones de la pila GPU—fue toda la diferencia
entre un martes tranquilo y una semana de caos.

Tareas prácticas: comandos, salidas y qué decidir a continuación

Si operas GPUs, necesitas memoria muscular de verificaciones que te digan: “¿La GPU es visible? ¿Está sana? ¿Se está throttling? ¿La pila de controladores es coherente?
¿El cuello de botella es cómputo, memoria, CPU, I/O o red?”

Abajo hay tareas pragmáticas que puedes ejecutar en Linux. Están escritas para la realidad productiva: incluyen qué significa la salida y qué decisión tomar después.

Tarea 1: Identificar la GPU y el driver del kernel en uso

cr0x@server:~$ lspci -nnk | grep -A3 -E "VGA|3D|Display"
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA102 [GeForce RTX 3090] [10de:2204] (rev a1)
        Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:3895]
        Kernel driver in use: nvidia
        Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Qué significa: El kernel está usando nvidia, pero nouveau también está presente como opción de módulo.

Decisión: Si ves módulos en conflicto (p. ej., nouveau cargado), ponlo en blacklist y reconstruye initramfs; de lo contrario corres riesgo de modesetting inestable o problemas de cómputo sin cabeza.

Tarea 2: Confirmar la salud del driver NVIDIA y telemetría básica

cr0x@server:~$ nvidia-smi
Tue Jan 13 11:20:10 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 A10                    Off  | 00000000:01:00.0  Off  |                  0   |
|  35%   58C    P2              118W / 150W|   6120MiB / 24564MiB   |     72%      Default |
+-----------------------------------------+------------------------+----------------------+

Qué significa: El driver se carga, la GPU está utilizada, la potencia está por debajo del cap y ECC muestra 0 errores no corregidos.

Decisión: Si nvidia-smi cuelga o arroja errores, para y arregla problemas de driver/módulo antes de depurar aplicaciones. Si los errores ECC suben, planea un RMA o aísla la tarjeta.

Tarea 3: Comprobar presencia de GPU AMD y estado del driver

cr0x@server:~$ sudo lshw -c display -short
H/W path           Device     Class          Description
========================================================
/0/100/1.0         card0      display        Advanced Micro Devices, Inc. [AMD/ATI] Navi 31 [Radeon RX 7900 XTX]
/0/100/1.0/0       /dev/fb0   display        AMDGPU framebuffer

Qué significa: El sistema ve una GPU AMD/ATI y está usando el framebuffer AMDGPU.

Decisión: Si muestra vesa o no hay framebuffer, probablemente tienes un problema de driver/initramfs o un desajuste de firmware.

Tarea 4: Revisar logs del kernel por resets, colgados o errores de firmware

cr0x@server:~$ sudo journalctl -k -b | egrep -i "amdgpu|nvidia|gpu|xid|ring|timeout" | tail -n 20
Jan 13 11:02:41 server kernel: NVRM: Xid (PCI:0000:01:00): 79, pid=24118, GPU has fallen off the bus.
Jan 13 11:02:41 server kernel: pcieport 0000:00:01.0: AER: Corrected error received: 0000:00:01.0
Jan 13 11:02:42 server kernel: nvidia 0000:01:00.0: AER: can't recover (no error_detected callback)

Qué significa: “Fallen off the bus” más AER de PCIe sugiere inestabilidad a nivel hardware (potencia, PCIe, riser, sobrecalentamiento) más que un bug de aplicación.

Decisión: Mueve la tarjeta de ranura, revisa cables de alimentación, reduce la velocidad PCIe en BIOS e inspecciona térmicas antes de reescribir código.

Tarea 5: Verificar que existan los nodos de dispositivo (punto común de fallo en contenedores)

cr0x@server:~$ ls -l /dev/nvidia* 2>/dev/null || echo "no nvidia device nodes"
crw-rw-rw- 1 root root 195,   0 Jan 13 11:19 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 Jan 13 11:19 /dev/nvidiactl
crw-rw-rw- 1 root root 195, 254 Jan 13 11:19 /dev/nvidia-modeset

Qué significa: Los nodos de dispositivo existen; el user space puede hablar con el driver.

Decisión: Si faltan, tu driver no está cargado o las reglas udev no se ejecutaron. Arregla la creación de nodos antes de tocar plugins de Kubernetes.

Tarea 6: Comprobar nodos de dispositivo AMD y configuración DRM

cr0x@server:~$ ls -l /dev/dri
total 0
drwxr-xr-x 2 root root        100 Jan 13 10:58 by-path
crw-rw---- 1 root video  226,   0 Jan 13 10:58 card0
crw-rw---- 1 root render 226, 128 Jan 13 10:58 renderD128

Qué significa: Existen nodos DRM. Los frameworks de cómputo a menudo necesitan acceso a renderD128.

Decisión: En contenedores, asegúrate de que el usuario del proceso esté en el grupo correcto o pases el dispositivo; de lo contrario verás “permission denied” que se disfraza de “no GPU”.

Tarea 7: Confirmar qué driver OpenGL/Vulkan estás usando (Mesa vs propietario)

cr0x@server:~$ glxinfo -B | egrep "OpenGL vendor|OpenGL renderer|OpenGL version"
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 17.0.6, DRM 3.54, 6.6.12)
OpenGL version string: 4.6 (Core Profile) Mesa 24.0.3

Qué significa: Estás en Mesa/radeonsi, no en algún renderer por fallback.

Decisión: Si el renderer muestra “llvmpipe”, estás en renderizado por software. Deja de benchmarkear juegos y arregla tu pila de display.

Tarea 8: Revisar temperatura de GPU y pistas de throttling (sensors genérico)

cr0x@server:~$ sensors | egrep -i "edge|junction|gpu|amdgpu" | head
amdgpu-pci-0100
edge:         +62.0°C
junction:     +88.0°C

Qué significa: La temperatura en junction es alta; carga sostenida puede provocar throttling o errores con flujo de aire pobre.

Decisión: Si junction está cerca de los límites del proveedor bajo carga normal, arregla el flujo de aire del chasis o reduce el cap de potencia antes de perseguir “crashes aleatorios”.

Tarea 9: Revisar utilización de GPU y uso por proceso (NVIDIA)

cr0x@server:~$ nvidia-smi pmon -c 1
# gpu        pid  type    sm   mem   enc   dec   command
    0      24118     C    72    41     0     0   python
    0      10211     G     3     1     0     0   Xorg

Qué significa: Un proceso de cómputo domina; Xorg es mínimo.

Decisión: Si ves muchos procesos pequeños usando poca SM pero mucha memoria, puedes estar bound por overhead; consolida batches o aumenta trabajo por lanzamiento.

Tarea 10: Confirmar visibilidad del toolkit CUDA en tu runtime

cr0x@server:~$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2025 NVIDIA Corporation
Cuda compilation tools, release 12.4, V12.4.131

Qué significa: El compilador CUDA está instalado en este entorno.

Decisión: Si las apps fallan con “CUDA not found” pero nvidia-smi funciona, tu contenedor o venv carece de libs user-space; arregla la construcción de la imagen, no el driver host.

Tarea 11: Comprobar visibilidad ROCm (cómputo AMD)

cr0x@server:~$ /opt/rocm/bin/rocminfo | head -n 12
ROCk module is loaded
=====================
HSA Agents
==========
*******
Agent 1
  Name:                    gfx1100
  Uuid:                    GPU-XX
  Marketing Name:          AMD Radeon RX 7900 XTX

Qué significa: La pila ROCm puede ver la GPU como un agente HSA.

Decisión: Si ROCm no ve la GPU pero los gráficos funcionan, probablemente estés en un combo hardware/driver no soportado por ROCm. Detente y alinea versiones o hardware.

Tarea 12: Detectar cuellos de botella CPU que se hacen pasar por “GPU lenta”

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.6.12 (server)  01/13/2026  _x86_64_  (64 CPU)

11:21:01 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
11:21:02 AM  all   92.10 0.00 3.22   0.04 0.00 0.30  0.00  4.34
11:21:02 AM    7   99.70 0.00 0.30   0.00 0.00 0.00  0.00  0.00

Qué significa: CPUs están saturadas; un core está al máximo. La GPU podría estar esperando preparación de input, descompresión, overhead de Python o hilos de dataloader.

Decisión: Aumenta paralelismo, pinnea hilos, mueve preprocesado a la GPU o reescribe el loop caliente. No compres una GPU nueva para resolver un cuello de botella de un solo core.

Tarea 13: Revisar ancho/velocidad PCIe (limitador oculto clásico)

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

Qué significa: La tarjeta negoció velocidad y ancho más bajos de lo capaz. Eso puede limitar cargas de trabajo con mucho tráfico de datos.

Decisión: Resitúa la GPU, revisa ajustes BIOS, verifica riser/cable y confirma el cableado de la ranura. Si es intencional (lances compartidos), planea en consecuencia.

Tarea 14: Verificar que I/O no esté privando a la GPU (común en training)

cr0x@server:~$ iostat -xz 1 3
Device            r/s     w/s   rkB/s   wkB/s  await  %util
nvme0n1         220.0    15.0  54000.0  8000.0  18.5  92.0

Qué significa: NVMe está al 92% de utilización con await alto; tu dataloader puede estar I/O bound, alimentando la GPU tarde.

Decisión: Cachea datasets localmente, aumenta read-ahead, usa almacenamiento más rápido o pre-shardea/comprime diferente. Tu problema de “utilización GPU” puede ser de disco.

Tarea 15: Revisar cuellos de botella de red para entrenamiento multinodo

cr0x@server:~$ sar -n DEV 1 3 | egrep "IFACE|eno1"
11:22:11 AM IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
11:22:12 AM eno1    8200.00   9100.00  980000.00 1040000.00   0.00      0.00     0.00

Qué significa: Estás cerca de la tasa de línea (números de ~10GbE en KB/s). All-reduce puede saturar esto y bloquear GPUs.

Decisión: Mejora la red, habilita RDMA donde aplique o ajusta tamaños de batch/acumulación de gradiente para reducir frecuencia de sincronización.

Tarea 16: Confirmar que el runtime de contenedores puede ver la GPU (ejemplo NVIDIA)

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

Qué significa: La integración entre el driver host y el runtime de contenedores está funcionando.

Decisión: Si esto falla, arregla nvidia-container-toolkit y la configuración del runtime antes de culpar a tu framework ML.

Broma #2: Elegir entre AMD y NVIDIA es como elegir entre dos bases de datos—alguien estará equivocado, y podrías ser tú.

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

Cuando el rendimiento cae o los jobs fallan, no tienes tiempo para filosofía. Necesitas un orden de triage repetible que corte el ruido.
Aquí está el orden que suele funcionar en flotas reales.

Primero: “¿La GPU está siquiera sana y visible?”

• Visibilidad hardware: lspci -nnk muestra el dispositivo y el driver del kernel previsto.
• Telemetría: nvidia-smi funciona (NVIDIA) o rocminfo funciona (ROCm) y no da errores.
• Logs del kernel: escanea journalctl -k -b por resets, Xid, ring timeouts, fallos de carga de firmware.

Condición de parada: Si ves ruido de PCIe/AER, “fallen off the bus”, ring timeouts o spam de firmware—trátalo primero como un problema de plataforma.

Segundo: “¿La GPU está throttling o desabastecida?”

• Térmicas: sensors o telemetría del proveedor. Observa temperaturas junction bajo carga sostenida.
• Caps de potencia: compara uso/cap (NVIDIA: nvidia-smi). Busca P-states persistentemente bajos.
• Alimentación de la pipeline: revisa CPU (mpstat), disco (iostat) y red (sar -n DEV).

Condición de parada: Si la CPU está al máximo o el disco al 90% util, arregla eso. Las GPUs no funcionan con deseo.

Tercero: “¿La pila de software está desalineada?”

• Alineamiento de versiones: versión de driver vs versión de toolkit (CUDA/ROCm) y expectativas del framework.
• Contenedores: valida con un contenedor mínimo conocido bueno (p. ej., nvidia/cuda).
• Permisos: nodos de dispositivo y pertenencia a grupos (/dev/nvidia*, /dev/dri/renderD*).

Condición de parada: Si el contenedor mínimo falla, depurar la aplicación es prematuro.

Cuarto: “¿Es un desajuste de workload?”

• Kernels limitados por memoria vs kernels limitados por cómputo: si el ancho de banda VRAM es el limitante, más SMs no ayudarán.
• Tamaños de batch pequeños: la GPU pasa tiempo lanzando kernels, no ejecutando trabajo.
• Overhead de sincronización: escalado multi-GPU limitado por interconexión o red.

Decisión: Optimiza la forma del workload (batching, pipeline de datos, precisión, operaciones fusionadas) antes de cambiar de proveedor por frustración.

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

1) “La GPU está instalada, pero mi contenedor dice que no hay dispositivos GPU”

Síntomas: Logs de la app muestran “CUDA device not found” o el conteo de dispositivos ROCm es 0 dentro de contenedores.

Causa raíz: Falta integración del runtime de contenedores (NVIDIA toolkit), plugin de dispositivo equivocado o nodos de dispositivo no montados/permissionados.

Solución: Valida con un contenedor mínimo (docker run --gpus all ... nvidia-smi), luego alinea la configuración del runtime y del plugin de dispositivos al proveedor.

2) “El rendimiento empeoró tras actualizar el kernel”

Síntomas: Mismo workload, menor utilización GPU, nuevos stutters/freezes, glitches ocasionales del compositor.

Causa raíz: Mismatch kernel/driver, regresión en la pila DRM o problemas de build del módulo propietario después de la actualización.

Solución: Fija kernel+driver como unidad, actualizaciones canario y mantén una ruta de rollback. Para escritorios, valida Wayland/Xorg explícitamente.

3) “El entrenamiento está más lento pero la GPU muestra 30% de utilización”

Síntomas: Baja utilización GPU, CPU alta, disco ocupado o red saturada.

Causa raíz: Cuello de botella en la pipeline de datos: decodificación, aumento, filesystem o lecturas de dataset shardeado.

Solución: Perfilado de CPU e I/O; cachea datasets en NVMe local rápido; aumenta workers del loader; preprocesa offline; considera decode acelerado por GPU.

4) “Congelamientos aleatorios bajo carga”

Síntomas: El nodo deja de responder, la GPU desaparece, los logs del kernel muestran Xid o ring timeouts, a veces eventos AER.

Causa raíz: Problemas de entrega de potencia, runaway térmico, risers marginales, negociación PCIe inestable o bugs de firmware expuestos por carga sostenida.

Solución: Reduce cap de potencia, mejora flujo de aire, resitúa tarjetas, reemplaza risers, actualiza BIOS/firmware, prueba a menor gen PCIe y aísla GPUs sospechosas.

5) “Optimizamos concurrencia y ahora la calidad de salida es inconsistente”

Síntomas: Artefactos de vídeo, crashes raros del encoder, fallos no deterministas, NaNs ocasionales.

Causa raíz: Throttling térmico o presión de memoria que amplifica bugs en casos límite; fragmentación de VRAM; demasiados contextos.

Solución: Reduce concurrencia, impón límites de potencia/térmicos, adopta control de admisión y valida corrección con comprobaciones muestreadas.

6) “Wayland multi-monitor está embrujado”

Síntomas: Parpadeos, comportamiento VRR raro, apps se traban en un monitor, pantallas negras aleatorias al reanudar.

Causa raíz: Interacciones de sincronización explícita driver/compositor, tasas de refresco mixtas o problemas de enrutamiento multi-GPU.

Solución: Prueba con un par driver/compositor conocido estable; considera Xorg para escritorios críticos; estandariza configuraciones de monitores; evita mezclar paneles VRR y no-VRR en despliegues de flota.

Listas de verificación / plan paso a paso

Checklist A: Elegir AMD vs NVIDIA para un despliegue nuevo

1. Define el “ecosistema por defecto” de la carga de trabajo. Si es ML con frameworks mainstream y tooling de terceros, asume CUDA-first a menos que se demuestre lo contrario.
2. Decide tu postura de actualización. Si debes seguir kernels recientes (escritorios de desarrollador), la alineación upstream es una ventaja seria.
3. Enumera los no negociables: ¿ECC? ¿virtualización? ¿SR-IOV/vGPU? ¿codecs específicos? ¿requisitos de pila de display?
4. Elige una matriz soportada, no un producto. Escoge (GPU SKU, versión de driver, versión de kernel, versión de distro, imagen base de contenedor) como una unidad probada.
5. Ejecuta un burn-in test. 24–72 horas de carga sostenida más ciclos de suspend/resume (si es escritorio), más tests multi-GPU (si es clúster).
6. Planifica observabilidad. Necesitas telemetría por nodo y alertas para temps, errores ECC, throttling y resets de dispositivo.

Checklist B: Actualizaciones seguras de la pila GPU (drivers/toolkits)

1. Inventaria versiones actuales y fíjalas (driver, toolkit, kernel, firmware).
2. Actualiza primero un nodo canario. Ejecuta cargas representativas, no benchmarks sintéticos.
3. Revisa logs del kernel por nuevas advertencias tras el burn-in.
4. Valida acceso GPU en contenedores con una imagen mínima conocida buena.
5. Solo entonces despliega a un pequeño porcentaje y luego al resto de la flota.
6. Mantén artefactos de rollback listos: paquetes anteriores, entrada de kernel y tags de contenedor.

Checklist C: Cuando sospechas que la GPU está “lenta”

1. Confirma velocidad/ancho del enlace (negociación PCIe).
2. Confirma cap de potencia y comportamiento de P-state.
3. Confirma térmicas y señales de throttling.
4. Mide saturación CPU y hotspots por core.
5. Mide saturación de disco y red.
6. Sólo entonces perfila kernels GPU y comportamiento de memoria.

Preguntas frecuentes

1) ¿Sigue siendo real “ATI vs NVIDIA” si ATI pasó a ser AMD?

Sí, porque el nombre de marca cambió pero la tensión central no: la línea de GPU de AMD frente a NVIDIA. La gente aún dice “ATI” de la misma
forma que en ops se dice “ethernet” cuando se refieren a “la red”. Es impreciso, pero la rivalidad es real.

2) Para escritorios Linux, ¿cuál es menos doloroso?

Si quieres menos sorpresas ante cambios de kernel y compositor, el modelo de controlador upstream de AMD suele ser más suave.
NVIDIA puede funcionar perfectamente, pero debes tratar las actualizaciones de driver como eventos de cambio, no como ruido de fondo.

3) Para machine learning hoy, ¿puede AMD reemplazar a NVIDIA?

A veces, sí—especialmente con ROCm en hardware soportado y frameworks bien probados. Pero CUDA sigue siendo la suposición por defecto en muchas herramientas
y binarios preconstruidos. Si necesitas máxima compatibilidad con mínimo trabajo de integración, NVIDIA sigue siendo la elección pragmática.

4) ¿Por qué “gana” CUDA incluso cuando el hardware competidor es fuerte?

Porque los valores por defecto se componen. Cuantas más librerías publiquen ruedas CUDA primero, más equipos se estandarizan en CUDA, más herramientas y conocimiento del proveedor existen
y más se convierte en la opción segura para plazos de entrega.

5) ¿Los controladores propietarios significan automáticamente “inestabilidad”?

No. Las pilas propietarias pueden ser extremadamente estables—a veces más estables que componentes de código abierto que evolucionan rápido.
El riesgo operacional es el acoplamiento: cuando tu kernel, compositor, política de Secure Boot y cadencia de releases divergen, haces más trabajo de integración por tu cuenta.

6) ¿Vale la pena pagar por ECC VRAM?

Si la corrección importa, sí. La corrupción silenciosa es el tipo de fallo que pasa por los dashboards y aparece como “el modelo se volvió raro” o “el render tiene artefactos”.
ECC no lo soluciona todo, pero reduce fuertemente el riesgo.

7) ¿Cuál es la razón más común por la que las GPUs rinden menos en producción?

Hambruna: preprocessing en CPU, almacenamiento lento o sincronización de red. La GPU se convierte en el componente visible, así que la culpan.
Mide toda la pipeline antes de cambiar de hardware.

8) ¿Deberíamos estandarizar en un solo proveedor en toda la empresa?

Estandariza por plataforma cuando sea posible. Un solo proveedor para clústeres ML puede reducir la varianza de tooling. Otro proveedor para escritorios Linux puede reducir
dolores en la pila de display. La meta es menos matrices, no pureza ideológica.

9) ¿Cuándo deberíamos elegir intencionalmente la opción “no por defecto”?

Cuando puedas probarlo en tu carga exacta y estés dispuesto a asumir la integración. Si tu equipo tiene experiencia en ROCm y tus modelos funcionan bien allí,
AMD puede ser una victoria estratégica en costo/rendimiento. Si necesitas máxima compatibilidad de terceros, elige NVIDIA y dedica tiempo a la observabilidad en lugar de portar.

Próximos pasos que puedes hacer esta semana

La rivalidad ATI/AMD vs NVIDIA no terminará porque está alimentada por trade-offs reales: integración upstream versus lock-in de ecosistema,
apertura versus pulido y compatibilidad versus control. No lo resuelves con una gráfica de benchmarks. Lo resuelves con intención operativa.

1. Escribe tu matriz soportada (GPU SKUs, drivers, kernel, distro, imágenes de contenedor). Si no está escrito, no está soportado.
2. Construye un proceso canario para actualizaciones de la pila GPU. Un nodo primero. Siempre.
3. Añade telemetría y alertas para temps, throttling, resets y errores ECC. Si no lo puedes ver, no lo puedes gestionar.
4. Ejecuta las tareas prácticas anteriores en un nodo sano y en uno “problemático” y diff los outputs. La mayoría de los misterios son diferencias.
5. Elige tu proveedor según tus restricciones: gravedad CUDA para ML, alineación upstream para flotas Linux y características hardware (ECC/virtualización) para centros de datos.

Si no te llevas nada más: deja de tratar a las GPUs como aceleradores intercambiables. Trátalas como una plataforma. Tu yo del futuro—el que sostiene el pager—te agradecerá con molestia.