La era de la minería: cómo las criptomonedas rompieron los precios de las GPU (una y otra vez)

Qué cambió realmente: del hardware para jugadores a la infraestructura como commodity

Las GPU solían comportarse como “periféricos premium”. Se veía un pico de lanzamiento, una caída lenta y la ocasional escasez cuando salía un juego nuevo.
La minería lo volteó. Introdujo un comprador industrial que trata las GPU como activos que generan ingresos con un periodo de recuperación, no como una compra de hobby.

Ese cambio importa porque modifica el techo del precio. Cuando un minero puede calcular un retorno, pagará más que cualquier jugador y, a menudo, más que un comprador empresarial cauteloso.
La GPU deja de valer “lo que cuesta fabricar más margen”. Pasa a valer “lo que genera”.

Aquí viene la parte fea: ese descubrimiento de precio ocurre más rápido de lo que la fabricación puede responder. Las fundiciones no son un puesto de comida que puedas acercar a la demanda.
Cuando la rentabilidad se dispara, los mineros compran todo el inventario del canal en días. Cuando la rentabilidad colapsa, deshacen inventario en semanas.
El resultado es un ciclo repetido de auge y caída que golpea a todo el mundo.

También es por esto que tu equipo de compras sufre latigazos. Están entrenados para curvas de depreciación previsibles.
Las GPU en la era de la minería se comportan más como combustible o capacidad de transporte: volátiles, estacionales y sujetas a incentivos extraños.

Hechos y contexto que explican los ciclos

• Bitcoin dejó de usar GPU para minería temprano. La minería SHA-256 de Bitcoin pasó de CPU a GPU a FPGA/ASIC en pocos años, empujando a los mineros con GPU hacia altcoins.
• La era Scrypt de Litecoin fue una gran ola de presión temprana sobre las GPU. Antes de que los ASICs Scrypt fueran comunes, las GPU eran la herramienta para minar Scrypt y causaron escasez minorista.
• Ethash de Ethereum mantuvo relevantes a las GPU por más tiempo. La “dificultad de memoria” de Ethash hizo que las GPU fueran económicamente viables durante años, manteniendo la demanda pegajosa y global.
• La demanda minera está sincronizada globalmente. Los cambios de rentabilidad se propagan al instante—mismos paneles, mismos pools, mismas calculadoras—así que los picos de demanda no se localizan.
• Proof-of-Stake cambió el perfil de demanda. La transición de Ethereum a Proof-of-Stake redujo una de las mayores fuentes de demanda continua por GPU, pero el mercado conserva los reflejos.
• La logística en la era COVID magnificó las oscilaciones de precio. Retrasos en envíos y componentes restringidos (no solo GPU) convirtieron las escaseces normales en apagones prolongados para la infraestructura física.
• El precio de la electricidad y la regulación importan. La rentabilidad minera está fuertemente ligada al coste eléctrico; cambios de política o tarifas pueden reubicar demanda entre países, afectando la oferta regional.
• Los socios de placa (AIBs) introdujeron silenciosamente “ediciones de minería”. Aparecieron tarjetas sin ventilador frontal y SKUs especializados durante los picos—a menudo con garantías y características de reventa diferentes.

Esto no es trivia. Te dicen por qué el mercado repite el mismo patrón: un algoritmo rentable más coordinación global sin fricción más fabricación lenta equivale a escasez.
Luego la rentabilidad cae y el mundo se inunda de hardware usado de calidad desconocida.

Cómo la minería rompe los precios de las GPU, mecánicamente

1) Convierte el inventario minorista en una delgada capa sobre un mercado mayorista

En tiempos normales, las GPU de consumo tienen una cadena de distribución relativamente amplia: fabricante → socio de placa → distribuidor → minorista → usuario final.
Cuando la minería es rentable, los mineros actúan como compradores empresariales sin paciencia empresarial. Llaman a distribuidores. Compran pallets. Usan bots. Pagan “prioridad”.
El minorista se convierte en las sobras, y el “MSRP” pasa a ser una etiqueta de museo.

2) Crea una puja que ignora tu caso de uso

Un renderizador se preocupa por VRAM, estabilidad de drivers y errores de memoria. Un jugador se preocupa por el pacing de frames. Un minero se preocupa por la eficiencia por vatio y la estabilidad durante meses.
Cuando los mineros dominan la demanda, el precio flota hacia la función de valor de la minería—no hacia la tuya.

3) Arrastra toda la pila al radio de explosión: PSUs, risers, placas base, ventiladores

Los auges mineros no solo consumen GPU. Consumen el hardware de soporte que permite muchas GPU en un mismo lugar.
Eso significa que tu plan de “añadir dos nodos GPU este trimestre” se atasca en algo tonto como cables de distribución de energía.

4) Distorsiona el mercado de usados y convierte la “reacondicionación” en un arte escénico

Cuando un minero vende una tarjeta, puede tener:
historial de undervolting (bien), historial de overvolting (malo), temperaturas altas constantes (malo), temperatura de estado estable constante (mejor que ciclos térmicos),
reemplazos de ventilador (desconocido), modificaciones de BIOS (arriesgado) y una capa de polvo que califica como aislante.

El mercado secundario no es inherentemente maligno. Solo es ruidoso. Tu trabajo es reducir ese ruido con pruebas que expongan los modos de fallo que crea la minería.

5) Castiga la compra “justo a tiempo”

Si compras GPU solo cuando “las necesitas”, tu presupuesto queda ligado a la rentabilidad cripto y a la logística global.
Eso no es agilidad. Es apostar con un PowerPoint.

Una idea parafraseada a menudo atribuida a Werner Vogels (CTO de Amazon): Todo falla, todo el tiempo; diseña como si el fallo fuera normal. (idea parafraseada)
Trata la disponibilidad y la fiabilidad de las GPU de la misma manera.

OEMs, AIBs, distribuidores: los amplificadores silenciosos

El precio de las GPU no lo fija un solo actor. Es un ecosistema, y la minería introduce incentivos que hacen que cada capa se comporte diferente.
Si operas sistemas de producción, no puedes fingir que esto es “solo el mercado”. El mercado ahora es una dependencia.

Comportamiento de los AIB: binning, refrigeración y realidad de la garantía

Los socios de placa envían múltiples variantes de “la misma GPU” diferenciadas por la calidad del cooler, robustez del VRM, curvas de ventilador y overclocks de fábrica.
La demanda minera tiende a consumirlo todo, pero especialmente adora las tarjetas con buena eficiencia y memoria estable.
Esas son también las tarjetas que quieres para nodos de inferencia de ML que deben funcionar fríos y silenciosos.

Los términos de garantía pueden ser una trampa. Algunas SKUs tienen cobertura de garantía reducida cuando se venden por ciertos canales o regiones.
Si compras por el mercado gris para vencer la escasez, puedes ganar la compra y perder la RMA.
La factura no es el activo. La garantía es parte del activo.

Comportamiento de los distribuidores: asignación y empaquetado

Durante los picos, la asignación se convierte en el verdadero producto. Los distribuidores priorizan cuentas que compran de forma consistente, compran con alto margen o aceptan paquetes.
Empaquetar significa que “se te permite” comprar GPU si también aceptas placas base, PSUs u otro inventario de baja rotación.
Esto no es personal. Es gestión de riesgo de inventario.

Comportamiento en la nube: la capacidad se vuelve un servicio premium

La disponibilidad de GPU en la nube es función de la compra del proveedor más su priorización interna.
Cuando la demanda se dispara, las instancias GPU en la nube desaparecen o quedan limitadas por cuotas.
En ese entorno, tu plan de infra necesita alternativas: GPUs más pequeñas, rutas de fallback por CPU o estrategias de capacidad preemptible.

Broma #1: Las GPU durante un auge minero son como ingenieros on-call—de pronto todos descubren que “realmente te necesitan”, y nunca es durante horas laborales.

El mercado secundario de GPU minadas: qué falla, qué mienten, qué sobrevive

Las GPU usadas después de un colapso minero pueden ser una ganga o una trampa. Ambos resultados se merecen.
La clave es entender el perfil de estrés que crea la minería y luego probar para detectarlo.

Los verdaderos modos de fallo

• Desgaste de ventiladores y cojinetes. Los rigs de minería hacen girar los ventiladores constantemente. Incluso si el silicio de la GPU está bien, los ventiladores pueden estar cerca del fin de su vida útil.
• Degradación de pads térmicos. Chips de memoria y VRMs calientes dependen de pads que se comprimen, se resecan y pierden eficacia.
• Errores de memoria bajo carga sostenida. La minería es intensiva en memoria; una VRAM marginal puede pasar pruebas ligeras y fallar tras horas de presión.
• Estrés y oxidación del conector PCIe. Inserciones repetidas, risers y entornos polvorientos pueden degradar la integridad de la señal.
• Modificaciones de BIOS. Algunos mineros flashean BIOS para cambiar comportamiento de potencia o temporizaciones de memoria. Eso puede crear inestabilidad en tu carga de trabajo.
• Fatiga en la entrega de energía. Los VRMs que funcionan calientes durante períodos largos pueden derivar, especialmente en diseños de placa más baratos.

Qué suele sobrevivir mejor de lo que piensas

Las cargas de trabajo en estado estable no son automáticamente peores que el gaming. Un minero que hizo undervolt y mantuvo temperaturas bajas puede haber tratado mejor la tarjeta que
un jugador que la sometió a ciclos térmicos diarios y la corrió caliente en una caja polvorienta.

El problema es que no puedes auditar su comportamiento desde el anuncio. Así que debes tratar las tarjetas usadas como discos usados: cualificarlas, hacerles burn-in y rastrearlas.
Si no estás dispuesto a hacer eso, no estás comprando GPU baratas—estás comprando cortes sorpresivos de servicio.

Tres micro-historias corporativas desde el frente

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

Una empresa mediana desplegó un servicio de inferencia con GPU para moderación de imágenes. La carga de trabajo era estable, el código estaba bien y el plan de despliegue parecía sensato.
Compraron un lote de GPU “idénticas” de dos proveedores porque el primer proveedor no pudo satisfacer toda la orden.

La suposición fue simple: mismo número de modelo de GPU significa mismo comportamiento. En la práctica, la mitad de la flota tenía variantes de placa y diseños de VRM diferentes.
Bajo carga sostenida, una variante funcionaba ~10–15°C más caliente en la temperatura de unión de memoria.
No se colapsó de inmediato. Degradó el rendimiento con throttling térmico y errores CUDA ocasionales que parecían fallos de software.

Los SREs pasaron días persiguiendo latencias de cola “aleatorias” e fallos intermitentes de jobs. Intentaron actualizar drivers, cambiar contenedores y reinicios en rolling.
Nada de eso arregló la física subyacente.

La solución fue terriblemente básica: tratar las GPU como SKUs de hardware, no como nombres de marketing.
Etiquetaron nodos por ID exacto de placa y solución de refrigeración, impusieron límites de potencia por nodo y establecieron una puerta de burn-in antes de entrar en producción.
El incidente dejó de ser misterioso y el equipo de compras aprendió a pedir socio de placa y revisión, no solo “modelo de GPU”.

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

Otra organización—esta con un equipo de plataforma serio—quiso exprimir más rendimiento de un clúster de entrenamiento GPU.
Ajustaron límites de potencia al alza, relajaron curvas de ventilador para reducir ruido y desgaste, y subieron offsets de reloj para mantener alta la utilización.
Los dashboards se vieron bien durante dos semanas.

Luego empezaron a subir las tasas de error. No fallos duros—fallos suaves. Eventos ECC ocasionales en algunas tarjetas, timeouts NCCL esporádicos, jobs de entrenamiento que “se colgaban”.
El equipo culpó a la red. Luego al backend de almacenamiento. Luego al scheduler. Clásico scapegoating en sistemas distribuidos.

El culpable fue el comportamiento térmico en VRAM y componentes VRM. La “optimización” eliminó margen.
Bajo ciertas condiciones ambientales, un subconjunto de nodos derivó a un régimen donde las GPU no se colapsaban; se comportaban mal.
El scheduler amplificó el problema colocando repetidamente jobs grandes en los mismos nodos “rápidos”.

Revirtieron los ajustes, estandarizaron un tope de potencia conservador e introdujeron control de admisión por nodo: si las temperaturas o los errores corregidos superaban umbrales,
el nodo se drenaba. El rendimiento cayó ligeramente, pero la tasa de éxito de jobs y la predictibilidad del clúster mejoraron drásticamente.
A nadie le hace falta ese extra del 6% a cambio de páginas a las 3am.

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

Una empresa de servicios financieros tenía un parque GPU pequeño pero importante para análisis de riesgo y algo de ML interno.
Nunca intentaron sincronizar con el mercado. En su lugar, ejecutaron un programa de reemplazo rodante, mantuvieron un pequeño inventario de reserva e insistieron en pruebas de burn-in
antes de que cualquier GPU llegara a producción.

Durante una escasez provocada por minería, sus competidores estaban pidiendo cuota y pagando precios de especuladores.
Este equipo siguió entregando porque ya tenían repuestos y contratos que garantizaban asignación parcial.
La compra no fue emocionante, pero fue continua.

El héroe silencioso fue su seguimiento de activos. Cada GPU tenía un serial registrado, revisión de placa, versión de firmware/BIOS, benchmarks base y versión de driver conocida-buena.
Cuando apareció una inestabilidad, pudieron correlacionarla con un lote y aislarla rápido en lugar de adivinar.

El resultado no fue “cero problemas”. Fue contención rápida. En sistemas de producción, eso es lo que compras con corrección aburrida: un radio de explosión más pequeño.

Guion de diagnóstico rápido: qué comprobar primero/segundo/tercero para encontrar el cuello de botella rápidamente

Primero: ¿es realmente la GPU el cuello de botella?

• Comprueba utilización GPU, relojes y consumo de potencia durante la carga.
• Comprueba saturación de CPU, cola de ejecución y presión de IRQ (especialmente con redes de alta tasa).
• Comprueba rendimiento de disco/red si estás alimentando modelos o conjuntos de datos.

Segundo: ¿estás sufriendo throttling (potencia, térmico o driver)?

• Busca razones de throttling “Pwr” o “Thrm”.
• Confirma el modo persistente, application clocks y límites de potencia.
• Confirma temperaturas: núcleo GPU, unión de memoria (si está disponible) y hotspot.

Tercero: ¿te está mintiendo la plataforma (PCIe, firmware, risers, errores)?

• Comprueba velocidad/anchura del enlace PCIe. Una GPU atascada en x4 Gen3 puede parecer “CUDA lento”.
• Revisa logs del kernel en busca de errores AER/PCIe corregidos y errores Xid.
• Valida que las versiones de driver/librerías coincidan con tu stack CUDA y tu runtime de contenedores.

Cuarto: ¿está bien formada la carga de trabajo?

• Tamaños de batch y settings del data loader pueden bloquear CPU o almacenamiento, no la GPU.
• Configuraciones de precisión mixta pueden moverte de bound por cómputo a bound por memoria (o viceversa).
• La colocación NUMA puede cortar silenciosamente el rendimiento.

Tareas prácticas con comandos: verificar, diagnosticar, decidir

Estas no son “trucos aleatorios de Linux”. Son las tareas que ejecutas cuando el precio de las GPU es volátil, el hardware es heterogéneo
y necesitas decidir si comprar, desplegar, drenar, RMA o retirar.
Cada tarea incluye: el comando, qué significa su salida y la decisión que impulsa.

Task 1: Identify exact GPUs and board variants

cr0x@server:~$ nvidia-smi -L
GPU 0: NVIDIA GeForce RTX 3090 (UUID: GPU-2a1b...)
GPU 1: NVIDIA GeForce RTX 3090 (UUID: GPU-9c7d...)

Significado: Tienes nombres de modelo, pero no socio de placa/revisión.

Decisión: Si estás depurando GPUs “idénticas” que se comportan diferente, necesitas IDs PCI más profundos y versiones de VBIOS (siguiente tarea).

Task 2: Capture VBIOS version and board ID

cr0x@server:~$ nvidia-smi -q | egrep -i "Product Name|VBIOS Version|Board Part Number" -n
12:    Product Name                    : NVIDIA GeForce RTX 3090
48:    VBIOS Version                   : 94.02.42.40.3A
52:    Board Part Number               : 900-1G136-2540-000

Significado: VBIOS y número de parte de placa te dicen si estás mezclando variantes.

Decisión: Si existen variantes, etiqueta nodos en consecuencia y evita mezclarlos en pools sensibles a latencia sin ajustes/límites de potencia.

Task 3: Confirm PCIe link width and speed (silent performance killer)

cr0x@server:~$ nvidia-smi -q | egrep -i "PCIe Generation|Link Width" -n
140:    PCIe Generation
141:        Current                     : 3
142:        Max                         : 4
146:    Link Width
147:        Current                     : x8
148:        Max                         : x16

Significado: La GPU funciona en Gen3 x8 aunque puede hacerlo en Gen4 x16.

Decisión: Revisa la configuración BIOS, cableado del slot, risers o compartición de lanes. Para entrenamiento con mucho tráfico host-device, esto puede ser un cuello de botella real.

Task 4: Spot throttling reasons (power/thermal)

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | egrep -i "Clocks Throttle Reasons|Thermal|Power" -n
25:    Clocks Throttle Reasons
26:        Idle                         : Not Active
27:        Applications Clocks Setting   : Not Active
28:        SW Power Cap                  : Active
29:        HW Slowdown                   : Not Active
30:        HW Thermal Slowdown           : Not Active

Significado: Estás limitado por potencia (software).

Decisión: Si el rendimiento es bajo y SW Power Cap está activo, o bien sube el límite de potencia (si los térmicos lo permiten) o acepta el límite como política de estabilidad.

Task 5: Watch real-time utilization, power, and temps during workload

cr0x@server:~$ nvidia-smi dmon -s pucvmt
# gpu   pwr gtemp mtemp sm   mem   enc   dec   mclk  pclk
# Idx     W     C     C   %     %     %     %   MHz   MHz
  0     345    78    96  92    84     0     0  9751  1725

Significado: Alta temperatura de memoria (mtemp) cerca del límite; cargas sostenidas pueden activar throttling de VRAM o errores.

Decisión: Mejora el flujo de aire, reemplaza pads térmicos, reduce el límite de potencia o mueve este nodo fuera del “pasillo caliente” antes de que empiece a fallar jobs.

Task 6: Check kernel logs for NVIDIA Xid errors (hardware/driver instability)

cr0x@server:~$ sudo journalctl -k -b | egrep -i "NVRM: Xid|pcie|AER" | tail -n 8
Jan 13 09:14:21 server kernel: NVRM: Xid (PCI:0000:65:00): 79, GPU has fallen off the bus.
Jan 13 09:14:22 server kernel: pcieport 0000:40:01.0: AER: Corrected error received: id=00e0

Significado: “Fallen off the bus” sugiere problemas PCIe/firmware/potencia, a veces una tarjeta que está muriendo.

Decisión: Drena el nodo. Reasienta la GPU, revisa rieles de PSU, deshabilita risers, actualiza BIOS y vuelve a probar. Si se repite, trátalo como RMA/retirar.

Task 7: Confirm driver version matches your CUDA userspace expectations

cr0x@server:~$ nvidia-smi | head -n 5
Tue Jan 13 09:16:01 2026
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14    Driver Version: 550.54.14    CUDA Version: 12.4     |
+-----------------------------------------------------------------------------+

Significado: El driver es 550.x, anuncia compatibilidad con CUDA 12.4.

Decisión: Si tu contenedor usa un runtime CUDA más antiguo, aún puede funcionar, pero las incompatibilidades aparecen como errores raros en tiempo de ejecución. Bloquea y estandariza.

Task 8: Validate CUDA device visibility inside a container

cr0x@server:~$ docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi -L
GPU 0: NVIDIA GeForce RTX 3090 (UUID: GPU-2a1b...)
GPU 1: NVIDIA GeForce RTX 3090 (UUID: GPU-9c7d...)

Significado: El runtime del contenedor ve las GPUs correctamente.

Decisión: Si las GPUs no aparecen aquí, tu problema es de runtime/config (nvidia-container-toolkit, permisos), no de “rendimiento GPU”.

Task 9: Check persistence mode (prevents cold-start weirdness)

cr0x@server:~$ nvidia-smi -q | egrep -i "Persistence Mode" -n | head
78:    Persistence Mode                : Disabled

Significado: La GPU puede entrar en estados de bajo consumo entre jobs, aumentando latencia del primer job y a veces exponiendo bugs del driver.

Decisión: En servidores compartidos, habilita persistence mode para estabilizar los inicios de jobs (siguiente tarea).

Task 10: Enable persistence mode (operational stability)

cr0x@server:~$ sudo nvidia-smi -pm 1
Enabled persistence mode for GPU 00000000:65:00.0.
Enabled persistence mode for GPU 00000000:66:00.0.

Significado: El driver mantiene los dispositivos inicializados.

Decisión: Haz esto en nodos de flota salvo que tengas una política de ahorro de energía que lo prohíba explícitamente.

Task 11: Set a conservative power limit (stability over bragging rights)

cr0x@server:~$ sudo nvidia-smi -pl 300
Power limit for GPU 00000000:65:00.0 was set to 300.00 W from 350.00 W.
Power limit for GPU 00000000:66:00.0 was set to 300.00 W from 350.00 W.

Significado: Has limitado la potencia; las temperaturas y el estrés del VRM suelen mejorar con una ligera pérdida de rendimiento.

Decisión: Si tus cargas toleran latencia, acepta el tope. A menudo reduce más fallos de los que reduce rendimiento.

Task 12: Verify ECC error counters (on ECC-capable GPUs)

cr0x@server:~$ nvidia-smi -q -d ECC | egrep -i "Single Bit|Double Bit" -n | head -n 20
110:    Single Bit ECC Errors
111:        Volatile
112:            Device Memory            : 0
120:    Double Bit ECC Errors
121:        Volatile
122:            Device Memory            : 0

Significado: No se reportan eventos ECC (bien). Si ves errores corregidos en aumento, la tarjeta puede estar degradándose o sobrecalentándose.

Decisión: Cualquier no cero en errores no corregibles (double-bit) es un evento de drenar y reemplazar en producción.

Task 13: Stress test GPU compute and memory (basic burn-in)

cr0x@server:~$ sudo apt-get update >/dev/null && sudo apt-get install -y stress-ng >/dev/null
cr0x@server:~$ stress-ng --gpu 1 --gpu-ops 200000 --timeout 10m --metrics-brief
stress-ng: info:  [21434] dispatching hogs: 1 gpu
stress-ng: metrc: [21434] gpu              200000 ops in 600.02s, 333.32 ops/s

Significado: Un simple stress GPU corrió durante 10 minutos. Esto no es una cualificación completa, pero detecta inestabilidades inmediatas.

Decisión: Si falla o los logs del nodo muestran mensajes Xid, no inscribas la GPU en producción. Investiga refrigeración/potencia/driver.

Task 14: Measure whether you’re I/O bound feeding the GPU

cr0x@server:~$ iostat -xz 1 5
Linux 6.5.0 (server) 	01/13/2026 	_x86_64_	(64 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.20    0.00    4.10    9.80    0.00   67.90

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s w_await wareq-sz  aqu-sz  %util
nvme0n1         920.0  148000.0     2.0   0.2    6.80   160.9     55.0   12000.0   4.20   218.2    6.45   92.0

Significado: Alto %util y iowait sugieren que el almacenamiento puede ser cuello de botella para la carga de datos, dejando las GPUs mal alimentadas.

Decisión: Cachea conjuntos de datos localmente, aumenta workers de prefetch, mueve a NVMe más rápido o paraleliza lecturas. No compres más GPUs para arreglar discos lentos.

Task 15: Check NUMA and CPU affinity (avoid cross-socket penalties)

cr0x@server:~$ lscpu | egrep -i "NUMA node|Socket"
Socket(s):             2
NUMA node(s):          2
NUMA node0 CPU(s):     0-31
NUMA node1 CPU(s):     32-63

Significado: NUMA de doble socket. Si tu GPU está conectada a un socket, programar trabajo en el otro socket puede perjudicar el rendimiento.

Decisión: Fija loaders y procesos GPU al nodo NUMA más cercano cuando persigues rendimiento o jitter.

Task 16: Check network saturation (training and distributed workloads)

cr0x@server:~$ ip -s link show dev eno1 | sed -n '1,8p'
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    9876543210  8765432      0      12       0       0
    TX:  bytes packets errors dropped carrier collsns
    12345678901 7654321      0       0       0       0

Significado: Paquetes RX descartados pueden traducirse en stalls/timeouts en entrenamiento distribuido o pulls remotos de datasets.

Decisión: Investiga buffers de anillo NIC, consistencia MTU, congestión de switch o mueve el dataset local. No culpes a “CUDA” por pérdidas de paquetes.

Broma #2: Una GPU usada de minería es como un coche de alquiler usado—técnicamente está bien, emocionalmente complicado, y deberías asumir que ha visto cosas.

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

1) Síntoma: “La utilización de GPU es baja, pero la CPU parece bien”

Causa raíz: Almacenamiento o red no pueden alimentar la canalización de datos (iowait, alto %util disco, lecturas remotas lentas).

Solución: Mide con iostat, cachea datasets en NVMe local, aumenta prefetching, usa formatos secuenciales o pre-particiona datos.

2) Síntoma: “Nodos idénticos tienen distinto rendimiento”

Causa raíz: Mezcla de variantes de placa GPU, VBIOS distinto, límites de potencia diferentes o anchura PCIe distinta.

Solución: Inventario con nvidia-smi -q, normaliza topes de potencia, verifica Gen/anchura PCIe y etiqueta nodos en pools separados.

3) Síntoma: “Errores CUDA aleatorios después de horas, no inmediatamente”

Causa raíz: Deriva térmica en memoria/VRMs, VRAM marginal o desgaste de ventilador/pads térmicos común en hardware ex-minero.

Solución: Registra temperaturas a lo largo del tiempo, limita potencia, mejora flujo de aire, reemplaza ventiladores/pads, haz burn-in más largo, drena repetidores.

4) Síntoma: “La GPU se cae del bus”

Causa raíz: Problemas de integridad de señal PCIe (cables riser, slots), inestabilidad de PSU o GPU fallando.

Solución: Quita risers, reasienta tarjetas, revisa actualizaciones BIOS/firmware, valida margen de PSU y retira/RMA si es repetible.

5) Síntoma: “El rendimiento empeoró tras actualizar el driver”

Causa raíz: Cambios en el driver afectan comportamiento, gestión de potencia o rompen expectativas de CUDA/userspace.

Solución: Bloquea versiones de driver por clúster, prueba en nodos canario, mantén paquetes de rollback listos, estandariza imágenes de contenedor base.

6) Síntoma: “Compramos GPUs usadas baratas y ahora la fiabilidad es pésima”

Causa raíz: No hubo puerta de cualificación; trataste hardware como software (envía ahora, arregla después).

Solución: Implementa burn-in, umbrales de error/temperatura para admisión, rastrea seriales e historial y presupuest a la atrición.

7) Síntoma: “No podemos comprar GPUs, proyecto bloqueado”

Causa raíz: Compras justo a tiempo en un mercado volátil de commodities.

Solución: Mantén stock de reserva, firma contratos por asignación, acepta planificación multi-SKU y diseña un fallback por CPU para rutas críticas.

Listas de verificación / plan paso a paso

Lista de compras (cómo comprar GPUs sin que te jueguen)

1. Define tu función de valor. Para inferencia, el tamaño de memoria y la eficiencia energética pueden importar más que los FLOPs pico. Para entrenamiento, interconexión y ancho de banda de VRAM pueden dominar.
2. Rechaza la dependencia de un solo SKU. Planifica al menos dos opciones aceptables de GPU y múltiples variantes de placa.
3. Pide socio de placa + revisión + términos de garantía. “Mismo modelo” no es una especificación.
4. Insiste en lenguaje de asignación en contratos. No solo “mejor esfuerzo.” Quieres ventanas de entrega y reglas de sustitución.
5. Presupuesta repuestos. Un pequeño buffer vence compras de emergencia a precios pico.
6. Establece una política de precio máximo. Si debes sobrepagar, hazlo deliberadamente con aprobación ejecutiva, no por compras de pánico.

Lista de recepción de GPUs usadas (trátalas como discos)

1. Registra identidad. Número de serie, UUID, número de parte de placa, versión VBIOS y condición física.
2. Limpia e inspecciona. Polvo, corrosión, juego del ventilador, conectores dañados. Si detectas olor a PCB quemado, para y pon en cuarentena.
3. Prueba base. Verifica anchura/velocidad PCIe y realiza un stress test mientras registras temperaturas y errores.
4. Remediación térmica. Reemplaza ventiladores/pads cuando las temperaturas sean altas o inestables; no “esperes” a que la refrigeración funcione en el rack.
5. Admisión con umbrales. Cualquier Xid recurrente, tormenta AER o fuga térmica significa rechazar/retirar.

Lista de operaciones en producción (mantén los nodos GPU aburridos)

1. Estandariza drivers y contenedores. Bloquea versiones, canarios para cambios, automatiza rollback.
2. Habilita persistence mode. Reduce rarezas por arranques en frío y estabiliza tiempos de lanzamiento de jobs.
3. Limita potencia y monitoriza throttling. Prefiere rendimiento estable a benchmarks picosos.
4. Monitorea temperaturas y errores como señales SLO de primera clase. La salud GPU no es un problema “del equipo de hardware” cuando rompe tu servicio.
5. Drena automáticamente ante señales malas. Si suben errores o PCIe se vuelve inestable, retira el nodo del pool antes de que sea un incidente multi-equipo.
6. Rastrea historial por tarjeta. El seguimiento por serial supera adivinar qué “GPU0” está poseída esta semana.

Lista de planificación de capacidad (sobrevive al próximo auge)

1. Cuantifica GPU-horas, no cuenta de GPUs. Tu demanda depende de la carga; mídela en rendimiento de jobs y latencia.
2. Modela la volatilidad de precios. Trata el coste de GPU como variable, no como constante.
3. Diseña caminos de degradación. Tamaños de batch más pequeños, inferencia por CPU para peticiones de baja prioridad o reducción de complejidad de modelos durante la escasez.
4. Mantén una pista de compra. Si el tiempo de entrega son meses, tu horizonte de planificación debe ser mayor que un sprint.

Preguntas frecuentes

Q1: ¿La minería cripto “causó” todos los picos de precio de GPU?

No. Es un amplificador importante. Las restricciones de oferta, lanzamientos, shocks logísticos y la demanda general por cómputo también importan.
La minería es especialmente buena en convertir la rentabilidad en demanda inmediata y global.

Q2: ¿Por qué los mineros pujan más alto que todos?

Porque valoran las GPU como activos que generan ingresos con matemática de payback. Si una tarjeta gana más por día que su coste de capital, se compra—rápido.
Esa puja no se preocupa por tu ciclo presupuestario trimestral.

Q3: ¿Las GPU ex-mineras son siempre malas?

No. Algunas están bien, especialmente si se hicieron undervolt y se mantuvieron frías. Pero la varianza es alta.
Si no puedes hacer burn-in y rastrear salud, no las compres para producción.

Q4: ¿Cuál es la métrica más útil para vigilar en producción?

Razones de throttling más la tendencia de temperatura. La utilización sola puede mentir; una GPU con throttling puede estar “ocupada” mientras entrega menos trabajo.
Observa potencia, relojes y si alcanzas límites térmicos o de potencia.

Q5: ¿Debemos subir los límites de potencia para obtener más rendimiento?

Solo después de probar que no estás limitado térmicamente y que la tasa de errores se mantiene estable en carreras largas.
En producción, la estabilidad es una característica. La afinación de límites de potencia debe ir detrás de un canario y un plan de rollback.

Q6: ¿Cómo evitamos la próxima escasez?

No puedes evitarla; puedes evitar sorprenderte por ella. Mantén stock de reserva, contrata asignación, acepta estrategias multi-SKU
y construye caminos de degradación para las cargas.

Q7: ¿Es la nube una salida segura cuando faltan GPUs?

A veces. La capacidad en la nube también se tensa durante los picos, y las cuotas pueden convertirse en la nueva escasez.
La nube es una opción útil si ya tienes cuota, imágenes y controles de coste listos.

Q8: ¿Cuál es el mayor riesgo operativo con flotas GPU mixtas?

La no determinismo. Diferente refrigeración, VBIOS y comportamiento de potencia producen distinto rendimiento y características de fallo.
Sin etiquetado y conciencia del scheduling, acabarás depurando problemas “de software” que en realidad son heterogeneidad de hardware.

Q9: ¿Deberíamos estandarizar en GPUs “data center” para evitar esto?

Ayuda con la soportabilidad y a menudo con la disponibilidad, pero no es inmunidad. Las piezas para centro de datos también pueden estar restringidas.
La verdadera ganancia es termales previsibles, firmware validado y caminos de garantía/RMA que se ajusten a tus necesidades operativas.

Conclusión: siguientes pasos para mantenerte fuera del radio de explosión

La cripto no solo “hizo las GPU caras”. Enseñó al mundo a tratar las GPU como un recurso comercializable.
Esa mentalidad no desaparece cuando baja la rentabilidad; perdura en prácticas de compras, en mercados secundarios y en la forma en que los vendedores gestionan la asignación.

La respuesta práctica no es quejarse del MSRP. Es operar como si las GPU fueran infraestructura de producción con riesgo de suministro y modos de fallo:
cualifica el hardware, estandariza el software, instrumenta la flota y planifica capacidad con volatilidad en mente.

• Hoy: Haz inventario de tu flota GPU por número de parte de placa y VBIOS, y comienza a etiquetar nodos en consecuencia.
• Esta semana: Añade razones de throttling, temperaturas y contadores Xid/AER a tu monitorización, con automatización de drenaje.
• Este trimestre: Reescribe las compras para incluir asignación, reglas de sustitución y stock de reserva. Luego hazlas cumplir.
• Antes del próximo auge: Construye un camino de degradación de carga para que la escasez sea “más lenta” en lugar de “caída”.

Los precios de las GPU volverán a romperse. Tu trabajo es asegurarte de que tus sistemas no se rompan con ellos.