Escasez de GPUs: cómo los jugadores se convirtieron en daño colateral

Qué pasó realmente: una escasez es una cola

Llamarlo una “escasez de GPUs” hace que parezca que un villano único robó todas las tarjetas gráficas. La realidad es más sosa y brutal: construimos una cola global y luego fingimos que no era una cola.

Cuando la demanda se dispara y la oferta no puede escalar rápidamente, no obtienes “no hay GPUs.” Obtienes asignación. Alguien es atendido primero: proveedores en la nube con contratos a largo plazo, compradores empresariales con compromisos de volumen, OEMs con órdenes de compra predecibles y—sí—personas que ejecutan bots que se comportan como traders de alta frecuencia pero para RGB.

Los jugadores fueron empujados al final porque el gaming es el segmento menos vinculado contractualmente. También es el más fragmentado. Millones de compradores individuales son fáciles de ignorar comparados con un puñado de clientes que firman contratos plurianuales y pueden mover mercados con una sola reserva de capacidad.

Dos números que silenciosamente deciden tu destino

• Tiempo para escalar: construir nueva capacidad de semiconductores se mide en años, no en trimestres.
• Valor marginal por hora-GPU: si un centro de datos puede facturar una GPU a tarifas empresariales 24/7, una venta única al consumidor es menos atractiva—especialmente cuando la oferta es limitada.

Como SRE, reconozco este patrón al instante: cuando un servicio está sobrecargado, no falla “de forma justa.” Falla hacia quien tenga reintentos, prioridad y persistencia. El inventario minorista de GPUs se comportó como una API sobrecargada sin limitación de tasa. Y los bots fueron los únicos clientes que sabían hablar ese idioma.

Datos rápidos y contexto histórico (la lista de “ah, por eso”)

Aquí hay puntos concretos que hacen que los últimos años de caos con GPUs sean menos misteriosos—y más previsibles.

1. Las GPUs modernas dependen de empaquetado avanzado (como enfoques estilo CoWoS para cómputo de alto nivel), y la capacidad de empaquetado puede convertirse en cuello de botella incluso cuando existe capacidad de oblea.
2. La oferta de memoria GDDR importa: una tarjeta gráfica no es “una GPU más un ventilador.” Si las asignaciones de VRAM son ajustadas, las placas no se envían.
3. Los plazos de entrega son largos por diseño: la producción de semiconductores se programa con mucha antelación; “haz más ahora” no es una opción de última hora.
4. Las consolas compiten por cadenas de suministro similares: cuando nuevas generaciones de consolas se introducen, consumen sustrato, memoria y capacidad logística que también necesitan las GPUs de consumo.
5. La demanda de cripto minado se disparó en ciclos y es singularmente elástica: los mineros compran hasta que la rentabilidad colapsa y luego vuelcan tarjetas usadas al mercado.
6. Los centros de datos normalizaron la aceleración por GPU: las GPUs se convirtieron en la opción por defecto para entrenamiento de ML y cada vez más para inferencia, desplazando el “mejor silicio” hacia lo empresarial.
7. Los saltos de generación PCIe no fueron el cuello de botella, pero aumentaron la rotación de plataformas y actualizaciones de placas base—amplificando el gasto total por ensamblado.
8. La logística de la era COVID no solo ralentizó envíos; distorsionó pronósticos. Cuando todos hacen pedidos por pánico, la previsión se vuelve astrología con hojas de cálculo.
9. La calidad del mercado de segunda mano se degradó tras períodos de minería intensa: más tarjetas con ventiladores degradados, termales de VRAM y fallos intermitentes.

El desplazamiento de la demanda: jugadores vs. tres industrias con más recursos

La demanda del gaming no desapareció. Fue superada y priorizada por industrias que tratan las GPUs como equipo de capital. Si estabas acostumbrado a las GPUs como “algo que se compra”, este es el giro mental: para muchos compradores, las GPUs ahora son “algo por lo que alquilas tiempo”, y el mercado de alquiler empuja la asignación de hardware hacia arriba.

1) Nube y empresas: la GPU como motor de ingresos

Los proveedores en la nube no compran GPUs porque amen el trazado de rayos. Las compran porque las GPUs convierten electricidad en facturas. El hardware está en un rack, amortizado durante años, utilizado casi 24/7 y facturado por hora. Esa tasa de utilización lo cambia todo.

Las GPUs de consumo a menudo están inactivas. Incluso los jugadores dedicados duermen, trabajan o fingen tocar césped. Una GPU de centro de datos no duerme; solo cambia de inquilinos.

Cuando la oferta es limitada, los vendedores asignan a la demanda predecible y basada en contratos. En la práctica, eso significa que los hyperscalers y grandes empresas obtienen prioridad en SKUs deseables o bins de silicio. El retail recibe lo que queda, cuando queda.

2) IA: una curva de demanda que no respeta tu fin de semana

Las cargas de trabajo de IA son una tormenta perfecta para la demanda de GPUs: paralelizables, hambrientas de rendimiento y cada vez más obligatorias para productos competitivos. Empresas que antes gestionaban flotas de CPU empezaron a reservar clústeres de GPU. Luego se dieron cuenta de que la inferencia también quiere GPUs. Luego se dieron cuenta de que la inferencia los quiere todo el tiempo.

Y como la IA ahora es una prioridad a nivel de dirección en muchas empresas, el presupuesto de GPU sale de “inversión estratégica”, no del “centro de costos de TI”. Eso significa menos restricciones de compra y más disposición a firmar compromisos largos.

3) Cripto y especulación: demanda que llega como un DDoS

Los picos de minería se comportaron como un ataque DDoS al inventario minorista. Fueron insensibles al precio hasta que la rentabilidad cambió. El resultado no fue solo “más compradores”, sino una clase de compradores optimizada para adquirir inventario a escala, a menudo con automatización y dispuesta a pagar por encima del MSRP.

Luego llega la fase de quiebre y el mercado de segunda mano se satura. Eso ayuda a la disponibilidad, pero crea una lotería de fiabilidad para los jugadores—porque las tarjetas tuvieron otro trabajo antes de que las adoptes.

Broma corta #1: Comprar una GPU en plena escasez se sentía como comprar entradas reventa, excepto que el concierto era que tu propio ordenador arrancara correctamente.

El lado de la oferta: fábricas, empaquetado, memoria y restricciones aburridas

La gente ama una narrativa sencilla: “simplemente fabriquen más GPUs.” Si alguna vez intentaste escalar un sistema de producción, sabes que escalar nunca es “solo añadir servidores.” Con chips, los “servidores” son las fábricas, y las fábricas son absurdamente caras, lentas de construir y están limitadas por equipos especializados y materiales.

Capacidad de oblea y nodos de proceso

Las GPUs avanzadas a menudo usan nodos de vanguardia donde la capacidad es finita y compartida con SoCs de smartphones, CPUs de servidores y otro silicio de alto margen. Cuando varias industrias quieren el mismo nodo, alguien queda racionado. Adivina quién no tiene un contrato take-or-pay plurianual.

Incluso si un vendedor quiere más obleas, la foundry necesita tener capacidad. Y si no la tiene, no puedes “pedir más fuerte.” Puedes rediseñar a otro nodo—lento, arriesgado y no siempre rentable—o puedes aceptar la asignación.

Rendimiento (yield): la parte que nadie quiere explicar en la caja

El rendimiento es el porcentaje de dados en una oblea que son funcionales en un nivel de calidad dado. Las GPUs de alto nivel son dies grandes, lo que dificulta el rendimiento. Al principio del ciclo de producto, los rendimientos pueden ser más bajos, lo que significa menos chips de primera por oblea. Los vendedores pueden rescatar dados imperfectos en SKUs inferiores, pero eso no lo soluciona totalmente si la demanda se concentra en la gama alta.

Empaquetado y sustratos: el cuello de botella silencioso

Aun con buen inicio de obleas, necesitas empaquetar los chips. La capacidad de empaquetado avanzado no es infinita, y los sustratos pueden estar limitados. Esto es el equivalente en la cadena de suministro a tener servidores de aplicación perfectamente sanos pero no suficientes balanceadores de carga. Es embarazoso, pero sucede.

Memoria y componentes de placa

La VRAM es una cadena de suministro por derecho propio. La producción de GDDR compite con otros mercados de memoria, y los socios de placas dependen de un flujo constante de componentes VRM, condensadores y conectores. La escasez de un componente pequeño puede detener un producto terminado, porque no puedes enviar “una GPU casi completa”.

Logística y distribución minorista

Finalmente, el envío y el retail importan. Cuando el inventario es escaso, las decisiones de distribución amplifican la percepción: si una región recibe un envío pequeño, se agota al instante y parece que “no hay stock en ninguna parte”. En realidad, hay stock, solo que no donde tú estás, no cuando miras y no en la forma que te gusta (hola, paquetes obligados).

Dinámica minorista: bots, paquetes y por qué “MSRP” se volvió arte performativo

El retail es donde la escasez se volvió personal. No porque la cadena de suministro quisiera tu configuración, sino porque el retail está optimizado para el rendimiento, no para la equidad. Bajo demanda extrema, el camino más fácil para “vender inventario rápido” se vuelve “venderlo al que pueda hacer clic más rápido.” Esos son los bots.

Bots y la tormenta de reintentos

Piensa en un sitio minorista como una API. Bajo carga, los usuarios normales se comportan con educación: recargan ocasionalmente, hacen clic una vez, esperan. Los bots no. Atacan endpoints, rotan identidades y explotan cualquier ventaja de latencia. Si el sitio carece de encolamiento robusto, limitación de tasa y anti-automatización, el resultado es determinista: los bots ganan.

Paquetes y saturación de canales

Los paquetes son una respuesta racional a un mercado roto. Los minoristas usaron paquetes para aumentar margen, mover inventario muerto y reducir la arbitraje de revendedores. Los jugadores lo experimentaron como un impuesto: compra una GPU más una fuente de alimentación que no necesitabas, o no compres GPU.

Revendedores: síntoma, no causa raíz

Los revendedores no crearon la escasez; la explotaron. En términos SRE, no son el incidente. Son el vecino ruidoso que te muestra que tu sistema no tiene cuotas.

Si quieres reducir la reventa, no moralices. Diseña para clientes adversariales: colas obligatorias, identidades verificadas, límites de compra que realmente funcionen y estrategias de liberación de inventario que no permitan que los milisegundos decidan ganadores.

La visión SRE: las GPUs son un recurso compartido, y los recursos compartidos se abusan

En sistemas de producción, la escasez se convierte en política. La escasez de GPUs se convirtió en economía. Misma mecánica.

Dentro de las empresas, la asignación de GPUs se volvió un generador interno de incidentes. Equipos lucharon por acceso. Compras aprendió nuevo vocabulario (plazo, asignación, capacidad reservada). Los ingenieros aprendieron que “simplemente lanzar una instancia más grande” deja de funcionar cuando la instancia más grande está agotada.

Cita de confiabilidad (parafraseada)

Werner Vogels (CTO de AWS) tiene un conocido mantra de operaciones—parafraseando: «Todo falla, todo el tiempo.» En el mundo GPU, “todo” incluye cadenas de suministro y órdenes de compra.

La escasez de GPU cambia los modos de fallo

• El riesgo de capacidad se desplaza hacia la izquierda: descubres la escasez cuando planificas, no cuando despliegas—si eres disciplinado. Si no lo eres, la descubres durante una interrupción y finges que fue imprevisible.
• El rendimiento se vuelve presupuesto: dejas de preguntar “¿es rápido?” y comienzas a preguntar “¿es rápido por vatio, por dólar, por unidad de disponibilidad?”
• La multi-tenencia se vuelve más desagradable: compartir GPUs (MIG, vGPU, contenedores) se vuelve común y los efectos de vecino ruidoso se multiplican.

Para los jugadores, la lección operativa es simple: no compites con otros jugadores. Compites con la utilización. Una GPU que renderiza tu juego 2–4 horas al día es menos “valiosa” para el mercado que una GPU alquilada 24/7 para entrenar modelos, ejecutar inferencia o procesar simulaciones.

Tres mini-historias corporativas desde las trincheras

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

Una empresa SaaS de tamaño mediano decidió añadir procesamiento de video acelerado por GPU a su producto. El equipo hizo lo correcto sobre el papel: construyeron un prototipo, lo sometieron a pruebas de carga y confirmaron que una sola instancia GPU podía manejar el rendimiento esperado. Todos se sintieron bien. Fecha de lanzamiento fijada.

La suposición errónea fue silenciosa: asumieron que las GPUs eran “como CPUs” en términos de compras. Esperaban escalar lanzando nuevas instancias el día que las necesitaran. Su código de infra lo soportaba. Su arquitectura lo soportaba. Sus runbooks lo soportaban. Su proveedor no.

Llegó la semana de lanzamiento y la demanda superó las previsiones. El autoscaling intentó añadir nodos GPU. La cuenta en la nube tenía una cuota. La solicitud de aumento de cuota entró en una cola. Mientras tanto, las subidas de clientes se acumularon, la latencia se disparó y los reintentos amplificaron la acumulación. El servicio no falló rápido; se degradó lentamente, que es el tipo de fallo más caro porque sigues sirviendo malas experiencias en lugar de rechazar carga.

La revisión del incidente fue incómoda porque nadie “rompió” nada. El sistema se comportó exactamente como fue diseñado. El diseño simplemente ignoró que la capacidad de GPU no es infinita ni instantáneamente aprovisionable. Mitigaron añadiendo una canalización de reserva en CPU (peor calidad, más lenta), implementando control de admisión en las subidas y reservando GPU con antelación—aunque eso dañó el presupuesto.

La solución real no fue técnica. Fue planificación: trata las GPUs como un recurso limitado con plazos, como la compra de hardware. La capacidad se convirtió en un riesgo de producto, no en un detalle de infraestructura.

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

Un equipo de analítica empresarial ejecutaba un clúster GPU para entrenamiento de modelos. Notaron que las GPUs estaban a menudo infrautilizadas—cargas espigadas, huecos inactivos y mucho tiempo desperdiciado en carga de datos. Alguien propuso una optimización: empaquetar más trabajos por GPU aumentando la concurrencia y dejar que el scheduler “lo resolviera”.

El primer día, los gráficos de utilización se veían fantásticos. Las GPUs rondaban 90–95%. El equipo celebró. A la semana, los tiempos de entrenamiento empeoraron. No ligeramente peor—salvajemente impredecible. Algunos trabajos terminaban rápido; otros avanzaban a paso de tortuga y caducaban. Los ingenieros culparon a la red, luego al almacenamiento, luego al código del modelo.

El problema real fue la contención de memoria y la sobrecarga por cambio de contexto. Al forzar demasiada concurrencia, provocaron frecuentes evicciones de VRAM, lanzamientos extra de kernels y más transferencias por PCIe. Su “alta utilización” era en parte sobrecarga. El clúster estaba ocupado, no productivo. En términos SRE: optimizaste una métrica, no la experiencia del usuario.

Revirtieron a un objetivo de concurrencia menor, implementaron límites de memoria por trabajo y añadieron una regla en el scheduler: si la huella de VRAM de un trabajo excede un umbral, obtiene acceso exclusivo a la GPU. La utilización cayó a un número menos impresionante—y el rendimiento mejoró. Eso es madurez operativa: dejas de perseguir gráficos bonitos.

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

Un estudio de juegos (ni enorme, ni diminuto) necesitaba GPUs para validación de builds y pruebas automatizadas—chequeos de render, compilación de shaders, instantáneas de rendimiento. Su responsable de compras insistió en algo dolorosamente poco sexy: un pronóstico de hardware rodante actualizado mensualmente, con relaciones con proveedores y un pequeño inventario de reserva.

Los ingenieros refunfuñaron porque el inventario de reserva parecía “hardware sin usar.” Finanzas refunfuñó porque los pedidos prepago y los largos plazos son molestos. Luego el mercado se tensó. Repentinamente, todos estaban “sorprendidos” por las escaseces—a excepción de este estudio, que ya tenía órdenes de compra colocadas meses antes y un pool de tarjetas de última generación guardadas para emergencias.

Cuando una canalización crítica de builds empezó a fallar por un lote de GPUs defectuosas (ventiladores muriendo pronto bajo carga continua), el estudio cambió inmediatamente unidades del buffer, aisló el lote malo y entregó a tiempo. Sin heroísmos. Sin sala de guerra nocturna. Solo un plan aburrido ejecutado como si importara.

Esta es la lección que a la gente no le gusta: la fiabilidad a menudo parece “capacidad desperdiciada” hasta el día en que no lo es. Entonces parece competencia.

Guía de diagnóstico rápido: qué comprobar primero, segundo, tercero

Cuando alguien dice “la GPU está lenta” o “necesitamos más GPUs”, no des por sentado nada. Las GPUs fallan de maneras que parecen problemas de GPU pero en realidad son CPU, almacenamiento, red, térmicas, controladores o política del scheduler.

Primero: confirma que la GPU existe, está sana y realmente se usa

• ¿Está la GPU esperada presente, con el controlador esperado?
• ¿La utilización es alta cuando debería serlo, o la GPU está inactiva mientras el trabajo espera otra cosa?
• ¿La tarjeta está limitada por potencia o reduciendo frecuencia por temperatura?

Segundo: identifica la categoría dominante del cuello de botella

• Limitado por cómputo: alta utilización GPU, relojes estables, VRAM cerca de lo esperado, baja espera de CPU anfitrión.
• Limitado por memoria: VRAM al límite, alta utilización del controlador de memoria, asignaciones frecuentes, fallos de página/terminaciones por OOM.
• Limitado por la canalización de datos: la utilización de GPU hace dientes de sierra; alta iowait de CPU; lecturas de almacenamiento lentas; red saturada.
• Limitado por el scheduler: el tiempo en cola domina; las GPUs están inactivas porque los trabajos no aterrizan por política, fragmentación o falta de VRAM adecuada.

Tercero: decide si escalar verticalmente, horizontalmente o arreglar la canalización

• Escalar verticalmente si estás limitado por cómputo y no puedes paralelizar eficientemente.
• Escalar horizontalmente si la carga se fragmenta bien y la red/almacenamiento pueden mantenerse al día.
• Arreglar si la utilización es baja por inanición de entrada, batching pobre, transferencias excesivas o controladores mal configurados.

Broma corta #2: Si tu GPU está al 2% de utilización, felicitaciones—has construido un calentador extremadamente caro mediante PCIe.

Tareas prácticas (con comandos): verificar, diagnosticar y decidir

Querías algo accionable. Aquí hay tareas que realmente ejecutaría en una caja Linux en producción o en una estación de trabajo seria. Cada una incluye lo que significa su salida y qué decisión tomar a continuación.

Tarea 1: Confirma que el kernel ve la GPU

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|nvidia|amd'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)

Qué significa: El dispositivo PCIe está presente e identificado. Si no aparece nada, puede haber un problema de montaje/energía/BIOS.

Decisión: Si está ausente, para. Revisa conectores de alimentación físicos, ajustes del BIOS (Above 4G decoding) y configuración de la ranura de la placa base antes de culpar a los controladores.

Tarea 2: Comprueba presencia del controlador NVIDIA y telemetría básica

cr0x@server:~$ nvidia-smi
Wed Jan 22 11:02:13 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 RTX A5000               Off | 00000000:01:00.0 Off |                  N/A |
| 30%   49C    P2              112W / 230W |   8120MiB / 24576MiB |     76%      Default |
+-----------------------------------------+----------------------+----------------------+

Qué significa: El controlador carga, la GPU está activa y la utilización y uso de memoria son visibles. P2 indica un estado de rendimiento; no siempre son relojes máximos.

Decisión: Si nvidia-smi falla, arregla los controladores antes de afinar cargas de trabajo. Si la utilización es baja mientras los trabajos se ejecutan, probablemente estás limitado por entrada o mal configurado.

Tarea 3: Observa la utilización a lo largo del tiempo para ver patrones de inanición

cr0x@server:~$ nvidia-smi dmon -s pucm
# gpu   pwr  u  c  m
# Idx     W  %  %  %
    0   115 78 68 33
    0   112 12 10 31
    0   118 81 70 35

Qué significa: El efecto sierra (78% luego 12% luego 81%) a menudo apunta a paradas por carga de datos o puntos de sincronización.

Decisión: Si la utilización oscila, inspecciona CPU, disco y red antes de pedir más GPUs.

Tarea 4: Comprueba relojes de GPU y razones de estrangulamiento

cr0x@server:~$ nvidia-smi -q -d CLOCK,POWER,THERMAL | sed -n '1,120p'
==============NVSMI LOG==============
Clocks
    Graphics                    : 1815 MHz
    SM                          : 1815 MHz
    Memory                      : 7001 MHz
Power Readings
    Power Draw                  : 118.34 W
    Power Limit                 : 230.00 W
Temperature
    GPU Current Temp            : 50 C
    GPU Shutdown Temp           : 95 C
    GPU Slowdown Temp           : 83 C

Qué significa: Temperaturas sanas, lejos del estrangulamiento. Si las temperaturas están cerca del umbral de reducción, los relojes bajarán y el rendimiento colapsará.

Decisión: Si hay limitación térmica, limpia el polvo, mejora el flujo de aire, re-aplica pasta térmica si es necesario, o reduce el límite de potencia intencionalmente para estabilizar.

Tarea 5: Verifica el ancho de enlace y la velocidad PCIe (limitador oculto común)

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s, Width x8

Qué significa: La ranura soporta x16, pero estás funcionando a x8—a veces está bien, a veces es un verdadero cuello de botella dependiendo de las transferencias.

Decisión: Si es inesperado (debería ser x16), revisa compartición de líneas en la placa base, ajustes BIOS, risers y elección de ranura. Arregla antes de comprar hardware.

Tarea 6: Comprueba carga del sistema y cuellos de botella de CPU (GPU inactiva porque la CPU no la alimenta)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0 (server) 	01/22/2026 	_x86_64_	(32 CPU)

11:03:01 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
11:03:02 AM  CPU   all  72.10  0.00  8.20    9.80 0.00  0.60   0.00  9.30
11:03:03 AM  CPU   all  70.85  0.00  7.95   10.10 0.00  0.55   0.00 10.55

Qué significa: Alta iowait (~10%) sugiere paradas en almacenamiento. La CPU también está ocupada. La GPU puede estar esperando datos.

Decisión: Si la iowait es alta, salta a métricas de disco y comportamiento de dataset/cache. No toques ajustes de GPU aún.

Tarea 7: Identifica latencia de almacenamiento que causa paradas en la canalización

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          68.50    0.00    8.00   10.20    0.00   13.30

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
nvme0n1         220.0  35200.0     0.0   0.00    1.20   160.0    40.0   9600.0    2.10   0.55  35.0
sda             180.0   7200.0     2.0   1.10   22.50    40.0    30.0   2400.0   18.90   6.10  98.0

Qué significa: sda está al ~98% de utilización con esperas ~20ms. Eso es clásico “GPU hambrienta por disco lento.”

Decisión: Mueve datasets a NVMe, añade caché o prefetch/buffer en RAM. Más GPUs no ayudarán si sda es el cuello de botella.

Tarea 8: Comprueba presión de memoria e intercambio (asesino silencioso de rendimiento)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           125Gi        98Gi       3.2Gi       2.1Gi        24Gi        18Gi
Swap:           16Gi       6.8Gi       9.2Gi

Qué significa: El uso de swap es no trivial. Si tu cargador de datos intercambia, tu GPU se quedará inactiva mientras el SO hace thrashing.

Decisión: Reduce el tamaño de lote, corrige fugas de memoria, aumenta RAM o reconfigura cachés. Intercambiar en una canalización GPU es una interrupción autoinfligida.

Tarea 9: Observa memoria y utilización por proceso

cr0x@server:~$ nvidia-smi pmon -c 1
# gpu        pid  type    sm   mem   enc   dec   jpg   ofa   command
    0      24711     C     72    31     0     0     0     0   python
    0      25102     C      4     2     0     0     0     0   python

Qué significa: Un trabajo usa la GPU; otro apenas hace nada pero aún reserva recursos.

Decisión: Finaliza o reprograma procesos de bajo valor. Aplica políticas de scheduling para que trabajos “pequeños” no ocupen VRAM.

Tarea 10: Verifica compatibilidad del toolkit CUDA (incompatibilidad controlador/toolkit)

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: Confirma la versión del toolkit instalada. Una desalineación entre runtime y controlador puede causar fallos o caminos lentos.

Decisión: Si las apps requieren una versión específica de CUDA, alinea imágenes base de contenedor/toolkit y el controlador. Fija versiones; no improvises.

Tarea 11: Revisa errores GPU en logs del kernel

cr0x@server:~$ sudo dmesg -T | egrep -i 'nvrm|xid|amdgpu|gpu fault' | tail -n 20
[Wed Jan 22 10:41:10 2026] NVRM: Xid (PCI:0000:01:00): 31, pid=24711, name=python, Ch 0000002b, intr 00000000

Qué significa: Los errores Xid pueden indicar bugs de controlador, relojes inestables, sobrecalentamiento o hardware fallando.

Decisión: Si los Xid se repiten, reduce overclocks, actualiza el controlador, prueba con una carga conocida buena y prepárate para RMA si persiste.

Tarea 12: Valida la entrega de energía (subtensión = reinicios raros)

cr0x@server:~$ sudo sensors | egrep -i 'in12|in5|in3|vcore|temp' | head
Vcore:        +1.08 V
in12:        +11.76 V
in5:          +5.04 V
temp1:        +42.0°C

Qué significa: Los rieles están dentro de tolerancia. Un hundimiento del riel de 12V bajo carga GPU puede causar reinicios “aleatorios”.

Decisión: Si los rieles están fuera de especificación bajo carga, reemplaza la PSU o redistribuye cables de potencia (cables PCIe separados, no en cadena).

Tarea 13: Comprueba restricciones de cgroup/contenedor (GPU presente, trabajo aún lento)

cr0x@server:~$ cat /sys/fs/cgroup/cpu.max
200000 100000

Qué significa: La CPU está limitada (equivalente a 2 cores). Tu trabajo GPU puede estar hambriento por límites de CPU para preprocesamiento.

Decisión: Aumenta límites de CPU para pods/contenedores GPU, o externaliza el preprocesamiento. La aceleración GPU no excusa starvar al host.

Tarea 14: Mide el rendimiento de red para datasets remotos

cr0x@server:~$ ip -s link show dev eth0 | sed -n '1,20p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes  packets  errors  dropped  overrun  mcast
    9876543210  8765432  0       12       0       0
    TX:  bytes  packets  errors  dropped  carrier  collsns
    1234567890  2345678  0       3        0        0

Qué significa: Hay drops. Si los drops RX suben durante entrenamiento/streaming, podrías perder rendimiento y detener la entrada.

Decisión: Investiga buffers de anillo de NIC, congestión en switches, desajustes MTU o mueve datos localmente. Las canalizaciones GPU odian la jitter.

Tarea 15: Identifica “tiempo en cola” vs “tiempo de ejecución” en un scheduler (ejemplo Slurm)

cr0x@server:~$ squeue -u $USER -o "%.18i %.9P %.8j %.8T %.10M %.10l %.6D %R"
12345678 gpu        trainA   RUNNING   00:21:10  02:00:00      1 node17
12345679 gpu        trainB   PENDING   00:00:00  02:00:00      1 (Resources)

Qué significa: Pendiente debido a recursos, no porque el trabajo esté roto. El cuello de botella es la asignación, no el código.

Decisión: Si el tiempo en cola domina, considera pedir GPUs más pequeñas, políticas de empaquetado, MIG/vGPU o programación fuera de pico.

Tarea 16: Revisa una GPU usada por abuso previo (chequeo básico de ventilador y térmicas)

cr0x@server:~$ nvidia-smi --query-gpu=fan.speed,temperature.gpu,power.draw,power.limit --format=csv
fan.speed, temperature.gpu, power.draw, power.limit
30 %, 51, 119.02 W, 230.00 W

Qué significa: El ventilador responde, las temperaturas se ven normales bajo carga. Las tarjetas usadas para minería suelen mostrar un comportamiento de refrigeración degradado.

Decisión: Si las temperaturas suben rápido o los ventiladores son erráticos, planifica mantenimiento (reemplazo de ventiladores, reaplicación de pasta) o evita la tarjeta por completo.

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

1) “La utilización de GPU es baja, así que necesitamos más GPUs”

Síntomas: 5–20% de utilización GPU, tiempo de ejecución alto, nvidia-smi dmon con picos.

Causa raíz: inanición de entrada: disco lento, red lenta, cuello de botella de preprocesamiento en CPU, tamaños de lote pequeños.

Solución: Mueve datasets a NVMe/SSD local, aumenta workers del dataloader, fija memoria, hace batching más agresivo, perfila tiempo CPU vs GPU.

2) “El rendimiento bajó tras una actualización de controladores”

Síntomas: Mismo código, menor rendimiento; errores Xid ocasionales; inestabilidad rara.

Causa raíz: incompatibilidad controlador/toolkit, regresiones, diferente gestión de energía por defecto.

Solución: Fija versiones de controladores. Valida actualizaciones en nodos canario. Alinea contenedores con el runtime CUDA soportado por el controlador.

3) “Nos quedamos sin VRAM, así que compra una GPU más grande”

Síntomas: errores OOM, paginación, grandes paradas, caídas en picos de uso.

Causa raíz: fragmentación de VRAM, fugas de memoria, cachés sin límites, batch demasiado grande, precisión ineficiente.

Solución: Usa mixed precision, gradient checkpointing (ML), reduce batch, reutiliza buffers, limita cachés, reinicia procesos de larga duración.

4) “La GPU está instalada pero la app corre en CPU”

Síntomas: CPU al máximo; GPU inactiva; logs de la app muestran backend CPU.

Causa raíz: faltan librerías runtime, contenedor no configurado con acceso GPU, flags de compilación incorrectos.

Solución: Valida con nvidia-smi dentro del contenedor, asegura NVIDIA Container Toolkit, revisa LD_LIBRARY_PATH y selección de dispositivo en frameworks.

5) “La GPU usada fue una gran oferta, luego empezó a fallar”

Síntomas: Fallos bajo carga, ruido en ventiladores, altas temperaturas, artefactos intermitentes.

Causa raíz: desgaste por minería: ventiladores degradados, pasta térmica seca, termales de VRAM, estabilidad de potencia marginal.

Solución: Prueba de estrés antes de confiar en ella; reemplaza ventiladores/pasta/almohadillas térmicas; subvoltea o limita potencia; si hay dudas, no la pongas en un sistema crítico.

6) “Nuestro clúster GPU está ‘ocupado’ pero la finalización de trabajos es más lenta”

Síntomas: Alta utilización, alta cola, peor rendimiento.

Causa raíz: oversubscription, sobrecarga por cambio de contexto, contención de memoria, vecinos ruidosos.

Solución: Aplica cuotas de VRAM por trabajo, ajusta concurrencia, usa MIG/vGPU apropiadamente, mide la tasa de finalización de trabajos, no la utilización.

7) “Compramos GPUs, pero no las podemos montar lo suficientemente rápido”

Síntomas: Hardware en cajas, no desplegado; proyectos demorados.

Causa raíz: restricciones de potencia/enfriamiento, espacio en rack, PDUs, cableado, procesos de firmware, preparación de imagen de drivers.

Solución: Planifica potencia y enfriamiento temprano; estandariza imágenes; preaplica firmware; ten una pipeline de burn-in; trata el despliegue como un servicio de producción.

Listas de verificación / plan paso a paso

Para jugadores: compra con inteligencia, no con ira

1. Decide tu verdadero cuello de botella: ¿estás limitado por GPU, CPU, VRAM o por resolución/refresh del monitor? No actualices a ciegas.
2. Apunta a VRAM de forma realista: los juegos modernos y los paquetes de texturas castigan la baja VRAM más que los núcleos ligeramente más débiles.
3. Prefiere canales reputables: evita vendedores del mercado gris a menos que disfrutes contabilidad forense y disputas de devoluciones.
4. Haz pruebas de estrés inmediatamente: ejecuta una carga real, revisa temperaturas, relojes y estabilidad mientras las devoluciones son sencillas.
5. Presupuesta para todo el sistema: la calidad de la PSU, el flujo de aire y las limitaciones de la caja pueden convertir una GPU premium en una máquina que reduce frecuencia.
6. Sé flexible con la generación: una generación anterior a buen precio puede superar a la actual a precio ridículo, especialmente si estás limitado por CPU de todos modos.

Para equipos: trata la capacidad GPU como capacidad de producción

1. Pronostica la demanda mensualmente: mide horas-GPU necesarias, no solo “número de GPUs”.
2. Separa interactivo de batch: no permitas que trabajos ad-hoc canibalicen trabajo programado.
3. Reserva capacidad base: comprométete con un mínimo que sepas que usarás; explota en picos estratégicamente.
4. Mide el rendimiento de extremo a extremo: rendimiento de la canalización, no solo utilización GPU.
5. Construye una ruta de respaldo: calidad inferior o ruta más lenta en CPU es mejor que una caída total cuando las GPUs no están disponibles.
6. Estandariza imágenes y controladores: fijar versiones reduce fallos de “funciona en el nodo A”.
7. Planifica potencia y enfriamiento: las GPUs convierten vatios en calor con entusiasmo. La infraestructura debe seguir el ritmo.
8. Mantén un pequeño buffer: unas pocas tarjetas/nodos de repuesto pueden convertir un retraso de suministro en un no-evento.

Chequeo de realidad para compras (la parte que los ingenieros evitan)

1. Conoce tus plazos de entrega y ordena antes de que “necesites” el hardware.
2. Verifica asignaciones por escrito: “esperamos enviar” no es un plan.
3. Califica alternativas: múltiples SKUs, múltiples vendedores, múltiples socios de placa.
4. Presupuesta repuestos y fallos: DOA sucede. Fallos tempranos pasan. No lo conviertas en crisis.

Preguntas frecuentes

1) ¿Por qué los fabricantes de GPUs no aumentaron simplemente la producción?

Porque la producción está limitada por la capacidad de foundries, rendimientos, empaquetado, suministro de VRAM y horizontes largos de programación. No puedes “autoscalar” fábricas.

2) ¿Son los revendedores la razón principal de la falta de GPUs?

No. Los revendedores amplificaron la escasez y capturaron margen, pero el problema subyacente fue la demanda superando la oferta. Arregla el diseño de la cola y reduces el impacto de la reventa.

3) ¿Realmente importó tanto la minería de cripto?

En periodos de auge, sí—la demanda minera se comportó como un aumento súbito insensible al precio que apuntó a canales minoristas. Cuando la rentabilidad colapsó, el mercado usado se inundó, a menudo con hardware desgastado.

4) ¿Es la demanda de IA el nuevo impulsor “permanente” de la escasez?

La demanda de IA es más estructuralmente persistente que la minería porque está ligada a hojas de ruta de productos y cargas de inferencia continuas. También concentra el poder de compra en menos compradores más grandes.

5) ¿Deberían los jugadores comprar GPUs usadas durante o después de las escaseces?

A veces. Pero trátalo como comprar un coche usado que pudo haber sido un rental: prueba de estrés inmediatamente, observa termales, verifica transferibilidad de garantía y planifica mantenimiento.

6) ¿Por qué veo GPUs “en stock” solo en paquetes?

Los paquetes aumentan el margen del minorista y reducen el arbitraje. También ayudan a mover inventario menos popular. Es una respuesta del mercado a demanda extrema y oferta limitada.

7) ¿Cómo puede un sistema tener alta utilización GPU pero aún así ser lento?

Porque la utilización puede ser sobrecarga: cambios de contexto, thrash de memoria, kernels ineficientes o esperas por sincronización. Mide rendimiento y latencia de trabajos, no solo utilización.

8) ¿Cuál es la forma más rápida de decir si estoy limitado por GPU o por datos?

Observa la utilización de GPU a lo largo del tiempo (nvidia-smi dmon) y correlaciónala con iowait de CPU (mpstat) y latencia de disco (iostat). Uso de GPU con picos y alta iowait suele significar que estás limitado por datos.

9) ¿Las tarjetas con más VRAM son siempre mejores para gaming?

No siempre, pero la falta de VRAM crea stutter y aparición tardía de texturas que ninguna cantidad de velocidad de núcleo arregla. Si juegas a altas resoluciones con títulos modernos, la VRAM suele ser el limitador más doloroso.

10) ¿Qué debe hacer una organización si las cuotas de GPU en la nube bloquean la escalada?

Negocia cuotas y capacidad reservada con antelación, mantiene modos de reserva, y diseña schedulers para degradar elegantemente. La cuota es una dependencia de capacidad; trátala como tal.

Conclusión: próximos pasos realistas

Las escaseces de GPUs no fueron una inconveniencia minorista temporal. Fueron la forma en que el mercado admitió que las GPUs ahora son infraestructura estratégica. Los jugadores no hicieron nada mal; simplemente llegaron a una pelea con un carrito de compras.

Haz esto a continuación:

1. Diagnostica antes de gastar: confirma si estás limitado por GPU, VRAM, CPU o por la canalización. Los comandos arriba te llevarán rápido allí.
2. Planifica para las restricciones: si eres un equipo, trata la capacidad GPU como capacidad de producción—pronostica, reserva y mantén un buffer.
3. Compra pensando en estabilidad: evita PSUs marginales, flujo de aire pobre y tarjetas usadas dudosas si te importa la disponibilidad (y te importa, aunque lo llames “consistencia de frames”).
4. Deja de adorar la utilización: ya sea que juegues o administres un clúster, optimiza la experiencia—frames fluidos o finalización predecible de trabajos—no una métrica bonita aislada.

La era de la escasez enseñó una verdad útil, aunque molesta: los mercados de hardware se comportan como sistemas distribuidos bajo carga. Si quieres equidad y fiabilidad, diseñas para condiciones adversariales. Si no, el cliente más despiadado gana—y rara vez es quien sostiene un control.