No perdiste la reunión del presupuesto de GPUs. La física la ganó. Y las cadenas de suministro. Y un ecosistema de software que convirtió los chips de un proveedor en la CPU por defecto del aprendizaje automático moderno.
Si has intentado comprar GPUs recientemente, ya conoces los síntomas: plazos de entrega que parecen una broma, alternativas “equivalentes” que no lo son y un problema de colas que se propaga desde la compra hasta la planificación, la energía y el almacenamiento. No puedes arreglar el mercado. Pero puedes entenderlo lo suficientemente rápido para tomar decisiones sensatas y evitar que la producción se derrita.
La explicación más simple (con la verdad aburrida)
La IA “se comió” el mercado de GPUs porque el aprendizaje profundo es una forma brutalmente eficiente de convertir cómputo en valor de producto, y las GPUs son el hardware más rentable que tenemos para esa conversión a escala. Cuando una única clase de carga de trabajo puede consumir de forma rentable casi cualquier cantidad de cálculo paralelo, no solo aumenta la demanda. Reescribe la definición de “suficiente”.
Hay tres fuerzas en juego, y necesitas las tres para entender por qué el mercado colapsó:
- Forma matemática: Entrenar y servir redes neuronales modernas es, en su mayoría, multiplicaciones de matrices gigantes y operaciones vectoriales: trabajo que las GPUs hacen de forma extraordinaria.
- Ancho de banda de memoria: La IA no es solo cómputo; es mover tensores. La memoria de alto ancho de banda (HBM) y buses anchos en el paquete son la guía de trampa, y las GPUs las tienen.
- Software + efectos de red: CUDA, cuDNN, NCCL y una década de herramientas hicieron que pudieras convertir capex en modelos más rápido en GPUs que en cualquier otro sitio. El mercado siguió el camino de menor fricción.
Una vez que algunos grandes actores demostraron que escalar GPUs escalaba ingresos, todos los demás perseguieron lo mismo. No es hype. Son incentivos.
Una verdad operacional seca: antes comprábamos aceleradores para acelerar programas. Ahora compramos aceleradores para acelerar organizaciones. El clúster de GPUs es una línea de fábrica, y el producto es la velocidad de iteración.
Para qué son realmente buenas las GPUs
Las GPUs no son magia. Son un intercambio muy específico: rendimiento masivo para una clase estrecha de trabajo paralelo, a cambio de tener que lidiar con restricciones (tamaño de memoria, ancho de banda de memoria, interconexión, sobrecarga de lanzamiento de kernels y una pila de software que puede morderte).
Rendimiento: el modelo de “muchos trabajadores pequeños”
Una CPU son pocos trabajadores muy capaces con grandes cajas de herramientas. Una GPU son miles de trabajadores más estrechos con la misma llave, dando vueltas a la misma clase de tornillo. La IA resulta ser “muchos del mismo tornillo”, especialmente durante el entrenamiento: multiplicar matrices, acumular gradientes, repetir.
HBM: la estrella oculta del espectáculo
Si solo miras FLOPS, tomarás malas decisiones. Muchos entrenamientos reales están limitados por la velocidad a la que puedes mover pesos y activaciones por la memoria. Las GPUs emparejan cómputo con un ancho de banda de memoria muy alto—especialmente cuando llevan HBM. Eso no es un detalle de marketing; muchas veces es la diferencia entre una utilización del 30% y del 90%.
Interconexión: escalar es, en su mayoría, redes
Una vez que entrenas en múltiples GPUs, dejas de “hacer matemáticas” y empiezas a “hacer sistemas distribuidos”. Sincronizar gradientes es un problema de all-reduce. La diferencia entre solo PCIe y NVLink/NVSwitch puede ser la diferencia entre escalar y entrar en thrashing.
El remate operativo: comprar más GPUs a veces es la forma más rápida de descubrir que tu topología de red está equivocada.
Por qué las cargas de IA dominan todo lo demás
Históricamente, las GPUs eran una mezcla: videojuegos, visualización, algo de HPC, algunos granjas de renderizado. Ese mercado era grande pero fragmentado. La IA lo convirtió en un comprador único y voraz con necesidades estandarizadas: matemáticas densas, enorme ancho de banda de memoria, interconexión rápida, drivers estables y un modelo de programación predecible.
Entrenamiento es una mercancía a granel, inferencia es un negocio de latencia
La IA tiene dos modos de producción principales:
- Entrenamiento: maximizar el rendimiento y la eficiencia de escalado. Se acepta el procesamiento por lotes. Te importa la utilización y el costo por token/muestra.
- Inferencia: minimizar la latencia y el costo por consulta, sin violar el SLA. Te importan la latencia en la cola, la estrategia de batching y la huella de memoria.
Ambos modos quieren GPUs, pero por razones distintas:
- El entrenamiento quiere densidad de cómputo, ancho de banda de memoria y interconexión.
- La inferencia a menudo quiere capacidad de memoria y rendimiento predecible, porque el modelo tiene que caber y responder rápido.
Por qué las CPUs no compitieron (durante la mayor parte de esto)
Las CPUs mejoraron, las unidades vectoriales avanzaron y hay despliegues serios de inferencia en CPU. Pero para modelos grandes y entrenamiento a gran escala, la economía favorece a las GPUs: el “costo para hacer una unidad de álgebra lineal densa” ha sido mejor en GPUs por mucho tiempo, y las pilas de software lo han hecho aún mejor.
Además: las canalizaciones modernas de IA son ahora un problema de pila. No es “mi código corre en silicio.” Son kernels CUDA, operaciones fusionadas, precisión mixta, bibliotecas de comunicación, compiladores y planificadores en tiempo de ejecución. La plataforma que hace eso menos doloroso gana demanda.
Broma corta #1: Comprar GPUs para IA es como adoptar un husky—no lo “posees”, solo te vuelves responsable de su necesidad diaria de correr.
La economía: un gráfico que puedes mantener en la cabeza
Imagina una simple proporción:
Valor producido por unidad de tiempo ÷ costo por unidad de tiempo.
La IA hizo que esa proporción explotara para las empresas que podían enviar mejor búsqueda, mejores recomendaciones, mejores herramientas de código, mejor targeting de anuncios, mejor soporte al cliente o productos completamente nuevos. Una vez que esa proporción es lo bastante grande, dejas de preguntar “¿Necesitamos GPUs?” y empiezas a preguntar “¿Cuántas podemos conseguir sin colapsar el datacenter?”
La demanda no escala linealmente; la ambición sí
Cuando las GPUs eran para gráficos, podías pronosticar la demanda con las tendencias de consumo. Cuando las GPUs son ventaja competitiva, la demanda se vuelve estratégica. Si la próxima iteración del modelo podría mover tus métricas de producto, asignarás más presupuesto de entrenamiento sin dudar. Tu competidor también. Así es como los mercados se devoran: no por una única innovación, sino por un bucle de retroalimentación.
La oferta es lenta, y el empaquetado es el cuello de botella
Aun si la capacidad de silicio existe, las GPUs de alta gama dependen de empaquetado avanzado, suministro de HBM, sustratos y capacidad de test. Esos no son infinitos, y no puedes “encender” más de la noche a la mañana. Los plazos de entrega son la forma en que el mercado te dice: el mundo físico aún manda.
El impuesto operacional: potencia y refrigeración
Un rack con muchas GPUs es un rack con alta densidad de potencia. Eso significa que tus restricciones cambian de “presupuesto” a “vatios y BTU”. Muchos equipos descubren—tarde—que su contrato de datacenter asumía un mundo donde racks de 10–15 kW eran lo normal. Ahora aparecen racks de 30–60 kW y, de repente, tu despliegue queda bloqueado por trabajo de la instalación, no por la compra de hardware.
La pila de software que consolidó la demanda
La gente subestima cuánto el mercado de GPUs es una historia de software. El hardware importa, pero el tiempo del desarrollador importa más. La plataforma ganadora es la que te da el camino más corto desde “tengo una idea” a “se entrena durante la noche y las métricas mejoraron”.
CUDA es un foso hecho de herramientas y hábitos
El ecosistema CUDA ha tenido años para endurecerse: kernels, bibliotecas, perfiles, depuradores, comunicaciones colectivas (NCCL), primitivas de precisión mixta y soporte del proveedor. La mayoría de frameworks de ML lo asumen. Muchas optimizaciones de vanguardia aterrizan allí primero. Eso crea un gradiente de adopción: la solución más fácil se convierte en la solución por defecto, y la adquisición la sigue.
La precisión mixta convirtió “demasiado grande” en “posible”
Los tensor cores y el entrenamiento en precisión mixta no son solo ajustes de rendimiento. Cambiaron la escala factible de modelos y abarataron el entrenamiento por unidad de progreso. Cuando los trucos numéricos adecuados están disponibles en la pila mainstream, el tamaño del modelo crece. El crecimiento del tamaño del modelo impulsa más demanda de GPUs. La demanda genera más inversión. El bucle se repite.
Entrenamiento distribuido: una elección de biblioteca puede cambiar tu burn rate
Los equipos suelen tratar el escalado multi-GPU como una casilla por marcar. No lo es. Tu elección de data parallelism, tensor parallelism, pipeline parallelism y estrategia de comunicación puede cambiar el costo de entrenamiento por múltiples órdenes de magnitud.
Y si tu all-reduce está peleando con tu topología, ninguna cantidad de “más GPUs” te salvará. Solo pagarás por una decepción más rápida.
Idea parafraseada (atribuida): Werner Vogels ha argumentado que deberías construir sistemas asumiendo que las cosas fallarán, de modo que tu servicio siga funcionando de todas formas.
Dónde están realmente los cuellos de botella (pista: no siempre la GPU)
En producción, la “escasez de GPUs” a veces es solo “subutilización de GPU”. Antes de gastar otro millón, aprende dónde se va tu tiempo. Hay cinco puntos de estrangulamiento comunes:
1) Canal de entrada y almacenamiento
Tu trabajo de entrenamiento no puede entrenar si no puede leer. Cargadores de datos, tormentas de archivos pequeños, sistemas de archivos en red, limitación de object stores y descompresión pueden dejar hambrientas a las GPUs. Un clúster con un 80% de tiempo de GPU inactiva suele ser una historia de almacenamiento y CPU con disfraz de GPU.
2) Preprocesamiento en el lado de la CPU
Tokenización, aumentos, decodificación, ingeniería de características, parseo de JSON—esto puede convertirse en el limitador. Si un hilo de CPU prepara lotes para ocho GPUs, felicitaciones: construiste un costoso calentador de espacio.
3) Capacidad de memoria de GPU y fragmentación
Los OOM no siempre significan “modelo demasiado grande”. A veces son fragmentación del asignador, múltiples procesos en una GPU o cachés descontrolados. A veces es tu tamaño de lote. A veces es una fuga de memoria en una extensión personalizada. Diagnostica, no adivines.
4) Saturación de la interconexión
El entrenamiento multinodo es intensivo en comunicación. Si la red está sobresuscrita o mal configurada, la eficiencia de escalado se viene abajo. Vigila errores NCCL, reintentos, colectivas lentas y tiempos de paso por rank desbalanceados.
5) Limitaciones de potencia y térmicas
Las GPUs están diseñadas para alcanzar límites de potencia y térmicos. Si tu datacenter está caliente, el flujo de aire es incorrecto o los límites de potencia están mal configurados, la GPU reducirá su reloj. No te avisará. Simplemente hará menos trabajo mientras tu job tarda más.
Hechos y contexto histórico que importan
- Las GPUs se volvieron cómputo de propósito general a mediados de los 2000 cuando los desarrolladores empezaron a usar pipelines gráficos para matemáticas no gráficas (la era temprana del GPGPU).
- CUDA se lanzó en 2007, haciendo que programar GPUs fuera mucho menos torpe que los hacks de shaders y dando un objetivo estable para herramientas y bibliotecas.
- AlexNet (2012) se atribuye ampliamente por hacer evidente que el deep learning acelerado por GPU “valía la pena” para visión por computador, porque se entrenaba eficientemente en GPUs.
- HBM llegó a mediados de los 2010 y cambió el perfil de rendimiento de los aceleradores de alta gama al elevar dramáticamente el ancho de banda de memoria.
- Los tensor cores (finales de los 2010) impulsaron las matemáticas de matrices en precisión mixta al mainstream, multiplicando el rendimiento efectivo para cargas de entrenamiento.
- NCCL maduró hasta convertirse en el estándar para colectivas en GPU, lo que hizo que el entrenamiento multi-GPU y multinodo fuera viable para más equipos sin tunear MPI personalizado.
- Los modelos Transformer (desde 2017) desplazaron la IA hacia cargas de trabajo que escalan agresivamente con cómputo y datos, acelerando la demanda de grandes clústeres.
- En 2020–2022, las interrupciones globales de la cadena de suministro más la creciente demanda empeoraron los plazos de entrega, pero la ola de IA no esperó educadamente a las fábricas.
- La densidad de potencia del centro de datos se convirtió en un factor limitante primario a medida que los racks aceleradores pasaron de “alto” a “re-diseño de instalaciones”.
Tres mini-historias corporativas desde las trincheras
Mini-historia #1: El incidente causado por una suposición equivocada
Una empresa SaaS de tamaño medio pasó de un servicio de inferencia con GPU única a un nodo multi-GPU para reducir la latencia en cola. El equipo asumió que “más GPUs” significaba “más margen”, y programó múltiples réplicas de modelo por host. También asumieron que la topología PCIe era efectivamente uniforme.
No lo era. La mitad de las GPUs compartían un switch PCIe con la NIC y, bajo carga, el patrón de tráfico se puso feo. La latencia P99 empezó a derivar hacia arriba y luego a dispararse. El servicio no se cayó; simplemente se volvió poco fiable de una forma que los clientes notaron. El on-call vio que la utilización de GPU parecía “bien”, lo que retrasó el diagnóstico correcto.
Eventualmente alguien corrió una comprobación de topología y se dio cuenta de que las réplicas más ocupadas estaban fijadas a GPUs con la peor ruta host-a-dispositivo y dispositivo-a-red. La solución no fue heroica: establecer afinidad explícita de GPU, mover réplicas con mucho tráfico de red a las GPUs con mejor localidad PCIe y dejar de sobresuscribir la E/S del nodo.
La lección quedó: nunca asumas que el bus es “lo suficientemente rápido”. El bus a menudo es el producto.
Mini-historia #2: La optimización que salió mal
Un grupo de investigación estaba desesperado por mejorar el rendimiento de entrenamiento, así que aumentaron los workers del dataloader, activaron caché agresiva y cambiaron a una ratio de compresión mayor para reducir lecturas de almacenamiento. Los gráficos de GPU se vieron mejor durante una hora. Todos se felicitaron.
Luego el nodo empezó a intercambiar. No poco. Mucho. La caché comprimida se infló en memoria, la page cache peleó con buffers GPU fijados y el kernel empezó a reclamar. La utilización de CPU se fue por las nubes mientras el trabajo útil real caía. El tiempo por paso de entrenamiento se volvió ruidoso y luego empeoró constantemente. Los jobs empezaron a caducar y el scheduler del clúster apiló reintentos encima, haciendo que la situación pareciera “inestabilidad aleatoria”.
La solución fue aburrida: limitar el tamaño de la caché, fijar menos lotes, bajar el número de workers y medir el tiempo de paso de extremo a extremo en lugar de “porcentaje de GPU ocupada”. La tubería optimizada había optimizado la métrica equivocada.
Ese modo de falla es común en sistemas de IA: puedes mejorar mucho una etapa y amplificar el peor comportamiento de la siguiente. Felicidades, encontraste el cuello de botella real al irritarlo.
Mini-historia #3: La práctica aburrida pero correcta que salvó el día
Una fintech ejecutaba inferencia GPU para puntuación de fraude. Nada glamoroso: SLA estricto, tráfico constante y un equipo de seguridad que lee changelogs de drivers como cuentos antes de dormir. Mantenían imagenes doradas por modelo de GPU, fijaban versiones de drivers y validaban combinaciones CUDA/cuDNN en un entorno de staging que coincidía con el hardware de producción.
Un fin de semana, un proveedor emitió una actualización urgente de seguridad que incluía un bump de driver. Un equipo distinto intentó desplegarla ampliamente. El equipo de plataforma de la fintech se resistió, porque tenían una regla: ningún cambio de driver GPU sin un canario que ejecute carga real de inferencia y compruebe tanto la corrección como la distribución de latencias.
El canario falló. No catastróficamente—peor. El nuevo driver introdujo una regresión sutil de rendimiento en su mezcla exacta de kernels. Bajo carga, la latencia P99 se degradó lo suficiente como para violar su SLA. Como tenían histogramas base y tráfico de replay, lo detectaron antes del rollout.
La solución fue aplicar la actualización de seguridad solo en nodos sin GPU de inmediato y luego planear un despliegue controlado en GPUs con mitigación (buffer de capacidad, ajuste de batch) y una versión de driver posterior. La práctica no fue emocionante. Fue la diferencia entre “fin de semana tranquilo” y “revisión de incidente con ejecutivos”.
Guía de diagnóstico rápido
Si un trabajo de entrenamiento es lento o la latencia de inferencia se dispara, no empieces culpando al modelo de GPU. Empieza por probar dónde se pierde el tiempo. Este es el orden que ahorra horas.
Primero: ¿están las GPUs realmente ocupadas?
- Comprueba utilización y consumo de potencia.
- Comprueba si el job está limitado por cómputo o por memoria.
- Comprueba si estás en throttling (potencia/térmico).
Segundo: ¿está la canalización de datos alimentando la bestia?
- Mide el throughput de lectura y las IOPS desde la ruta del dataset.
- Comprueba saturación de CPU (especialmente un núcleo caliente).
- Busca tormentas de archivos pequeños, sobrecarga de descompresión y jitter de almacenamiento en red.
Tercero: ¿funciona el escalado multi-GPU o estás pagando por sincronización?
- Comprueba la topología de interconexión y el ancho/velocidad de enlaces.
- Vigila errores NCCL, reintentos o colectivas lentas.
- Compara tiempo por paso por rank; el desbalance suele apuntar a problemas de fibra o stragglers.
Cuarto: ¿te está mintiendo el scheduler?
- Confirma asignación de GPU, ajustes MIG y límites cgroup.
- Verifica que no haya “vecinos invisibles” en la misma GPU o NIC.
- Comprueba la localidad NUMA si el preprocesamiento en CPU importa.
Broma corta #2: La GPU nunca está “inactiva”; solo está esperando a que el resto de tu arquitectura alcance su ritmo.
Tareas prácticas: comandos, salidas, decisiones
Estas son las comprobaciones que realmente ejecuto (o pido que ejecuten) cuando el rendimiento, la capacidad o la estabilidad están en juego. Cada una incluye el comando, qué te dice una salida típica y cuál es la decisión siguiente.
Task 1: Confirmar que las GPUs son visibles y el driver está sano
cr0x@server:~$ nvidia-smi
Tue Jan 13 12:10:11 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14 Driver Version: 550.54.14 CUDA Version: 12.4 |
|-----------------------------------------+----------------------+----------------------|
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 NVIDIA A100-SXM4-80GB On | 00000000:41:00.0 Off | 0 |
| 34% 56C P0 265W / 400W| 61234MiB / 81920MiB | 92% Default |
+-----------------------------------------+----------------------+----------------------+
Qué significa: Versiones de driver/CUDA, modelo de GPU, uso de memoria, utilización y consumo de potencia. Si GPU-Util es baja pero la memoria es alta, puede que estés limitado por entrada o por sincronización.
Decisión: Si las GPUs no aparecen o muestran errores, para y arregla drivers/firmware/integración del runtime de contenedores antes de tunear cualquier otra cosa.
Task 2: Detectar throttling térmico o de potencia
cr0x@server:~$ nvidia-smi -q -d PERFORMANCE,POWER,TEMPERATURE | sed -n '1,120p'
Performance State : P0
Clocks Throttle Reasons
Idle : Not Active
Applications Clocks Setting : Not Active
SW Power Cap : Not Active
HW Slowdown : Active
HW Thermal Slowdown : Active
Power Readings
Power Draw : 395.12 W
Power Limit : 400.00 W
Temperature
GPU Current Temp : 86 C
Qué significa: “HW Thermal Slowdown: Active” te dice que la GPU está reduciendo reloj. Eso es pérdida real de rendimiento.
Decisión: Arregla flujo de aire, curvas de ventilador, temperatura de entrada o densidad de rack antes de comprar más GPUs. El throttling es pagar por hardware que no puedes usar.
Task 3: Validar conectividad NVLink (cuando aplique)
cr0x@server:~$ nvidia-smi nvlink -s
GPU 0: NVLink Status
Link 0: 25 GB/s
Link 1: 25 GB/s
GPU 1: NVLink Status
Link 0: 25 GB/s
Link 1: 25 GB/s
Qué significa: Los enlaces NVLink están activos e informan el ancho de banda esperado.
Decisión: Si los enlaces están caídos, no asumas escalado multi-GPU; investiga asiento de hardware, firmware o soporte de la plataforma.
Task 4: Comprobar ancho y velocidad de enlace PCIe
cr0x@server:~$ sudo lspci -s 41:00.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s (ok), Width x16 (ok)
Qué significa: Si ves x8 en lugar de x16, o GT/s más bajos, estás dejando ancho de banda sobre la mesa.
Decisión: Corrige ajustes BIOS, problemas con riser/cable o la colocación en slots. La sub-negociación PCIe es un asesino silencioso de rendimiento.
Task 5: Inspeccionar localidad NUMA GPU-a-CPU
cr0x@server:~$ nvidia-smi topo -m
GPU0 GPU1 CPU Affinity NUMA Affinity
GPU0 X NV2 0-31 0
GPU1 NV2 X 0-31 0
Qué significa: Afinidad de CPU y mapeo del nodo NUMA. Si el preprocesamiento es pesado, una colocación NUMA incorrecta aumenta latencia y reduce throughput.
Decisión: Fija hilos de CPU y dataloaders al nodo NUMA local a las GPU(s) que alimentan.
Task 6: Buscar presión por fragmentación de memoria GPU
cr0x@server:~$ nvidia-smi --query-compute-apps=pid,process_name,used_gpu_memory --format=csv
pid, process_name, used_gpu_memory [MiB]
23144, python, 61234 MiB
Qué significa: Confirma qué proceso consume memoria. Múltiples procesos pueden fragmentar la memoria y causar OOMs impredecibles.
Decisión: Si múltiples PIDs comparten una GPU inesperadamente, arregla el scheduling/aislamiento (configuración del plugin de dispositivo de Kubernetes, Slurm GRES o placement de systemd).
Task 7: Comprobar saturación de CPU y tiempo robado (VMs o vecinos ruidosos)
cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0 (server) 01/13/2026 _x86_64_ (64 CPU)
12:11:02 PM CPU %usr %nice %sys %iowait %irq %soft %steal %idle
12:11:03 PM all 780.0 0.0 90.0 15.0 0.0 5.0 0.0 10.0
12:11:03 PM 7 99.0 0.0 1.0 0.0 0.0 0.0 0.0 0.0
Qué significa: Un núcleo al 99% puede convertirse en cuello de botella (tokenización, descompresión). Alto %steal sugiere contención por virtualización.
Decisión: Paraleliza el preprocesamiento, incrementa cuidadosamente los workers o descarga preprocesamiento. Si %steal es alto, cambia a hosts dedicados.
Task 8: Verificar throughput de lectura de almacenamiento (ejemplo NVMe local)
cr0x@server:~$ sudo fio --name=readtest --filename=/mnt/datasets/.fio_test --rw=read --bs=1M --ioengine=libaio --direct=1 --numjobs=1 --iodepth=32 --size=4G --runtime=30 --time_based
read: IOPS=2850, BW=2850MiB/s (2988MB/s)(83.5GiB/30001msec)
Qué significa: Si entrenas desde NVMe local y solo obtienes unos pocos cientos de MiB/s, algo anda mal (opciones de montaje, salud del dispositivo, sistema de archivos).
Decisión: Si el ancho de banda está por debajo de lo que tu pipeline necesita, arregla el almacenamiento o cachea datasets localmente antes de tunear kernels GPU.
Task 9: Comprobar throughput de red hacia una fuente de datos (sanity básica)
cr0x@server:~$ iperf3 -c datahost -P 4 -t 10
[SUM] 0.00-10.00 sec 37.5 GBytes 32.2 Gbits/sec sender
[SUM] 0.00-10.00 sec 37.4 GBytes 32.1 Gbits/sec receiver
Qué significa: Confirma el throughput alcanzable. Si esperas 100 Gbit/sec y ves 20–30, estás limitado por la configuración de NIC, switch o host.
Decisión: Arregla MTU, bonding, configuración de puerto de switch o ruta. El entrenamiento distribuido no perdona enlaces débiles.
Task 10: Detectar iowait como el silencioso hambriento de GPU
cr0x@server:~$ iostat -xz 1 3
avg-cpu: %user %nice %system %iowait %steal %idle
18.40 0.00 6.10 32.50 0.00 42.90
Device r/s rkB/s await %util
nvme0n1 220.0 2800000.0 14.2 96.0
Qué significa: Alto %iowait y utilización del dispositivo cercana al 100% indican saturación de almacenamiento. El tiempo de GPU inactivo a menudo se correlaciona.
Decisión: Añade almacenamiento más rápido, particiona datasets, aumenta paralelismo de lectura cuidadosamente o pre-carga datos en discos locales.
Task 11: Comprobar asignación de GPU en Kubernetes (si ejecutas K8s)
cr0x@server:~$ kubectl describe pod infer-6c9c8d7f6f-kp2xw | sed -n '1,160p'
Limits:
nvidia.com/gpu: 1
Requests:
nvidia.com/gpu: 1
Node-Selectors: gpu=true
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 2m default-scheduler Successfully assigned prod/infer-... to gpu-node-12
Qué significa: Confirma que el pod solicitó y obtuvo una GPU, y dónde cayó.
Decisión: Si los pods caen en tipos de nodos equivocados o compiten por GPUs, arregla etiquetas de nodo, taints/tolerations y la configuración del device plugin.
Task 12: Buscar resets de GPU o errores Xid en logs
cr0x@server:~$ sudo journalctl -k -S -2h | egrep -i 'NVRM|Xid|pcie|nvlink' | tail -n 20
Jan 13 10:44:02 server kernel: NVRM: Xid (PCI:0000:41:00): 79, GPU has fallen off the bus.
Jan 13 10:44:05 server kernel: pcieport 0000:00:03.1: AER: Corrected error received: id=00e1
Qué significa: “fallen off the bus” suele apuntar a problemas de señal PCIe, firmware, eventos de potencia o fallos severos de driver.
Decisión: Deja de tratarlo como bug de aplicación. Involucra hardware/proveedor, revisa BIOS/firmware, vuelve a insertar tarjetas, valida la entrega de potencia y ejecuta pruebas de burn-in.
Task 13: Validar persistence mode y relojes de aplicación (cuando corresponde)
cr0x@server:~$ sudo nvidia-smi -pm 1
Enabled persistence mode for GPU 00000000:41:00.0.
Qué significa: El modo persistente reduce la sobrecarga de inicialización y puede estabilizar la latencia para ciertos servicios de inferencia.
Decisión: Habilita para servicios de larga duración; para cajas interactivas compartidas, evalúa impacto y política.
Task 14: Verificar hugepages / presión de memoria que puede afectar RDMA y rendimiento
cr0x@server:~$ grep -E 'HugePages|MemAvailable' /proc/meminfo
MemAvailable: 18234564 kB
HugePages_Total: 0
HugePages_Free: 0
Qué significa: MemAvailable baja significa que el SO está bajo presión; hugepages pueden ser requeridas para algunos setups RDMA/NIC o para tuning de rendimiento.
Decisión: Si la presión de memoria es alta, reduce cachés, arregla límites de contenedores o aumenta RAM. Si RDMA requiere hugepages, configúralas explícitamente.
Task 15: Confirmar que el runtime de contenedores ve la GPU
cr0x@server:~$ docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi
+-----------------------------------------------------------------------------+
| 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 |
| 0 NVIDIA A100 On | 00000000:41:00.0 Off | 0 |
+-----------------------------------------------------------------------------+
Qué significa: Si esto falla, los fallos de tu app pueden ser de fontanería, no de ML.
Decisión: Arregla NVIDIA Container Toolkit, compatibilidad driver/runtime y permisos cgroup/dispositivo antes de culpar al framework.
Errores comunes: síntoma → causa raíz → solución
1) “La utilización de GPU es baja, pero el job es lento”
Síntoma: GPU-Util 10–40%, tiempo por paso alto, CPU parece ocupada o iowait elevado.
Causa raíz: Cuello de botella en el pipeline de entrada: throughput de almacenamiento, descompresión, tokenización o contención del dataloader.
Solución: Perfila el tiempo del dataloader; pre-carga datasets en NVMe local; aumenta paralelismo de preprocesamiento; cambia a formatos shard/packed; reduce lecturas de archivos pequeños.
2) “El escalado multi-GPU empeora después de añadir nodos”
Síntoma: 2 GPUs más rápido que 8 GPUs; añadir nodos aumenta el tiempo por época.
Causa raíz: La interconexión o la overhead de colectivas domina: NCCL all-reduce saturando la red, switches sobresuscritos, desconocimiento de la topología.
Solución: Valida ancho de banda de la red; asegura configuración correcta de NCCL para tu topología; evita sobresuscripción; considera acumulación de gradientes o cambiar la estrategia de paralelismo.
3) “OOM ocurre aleatoriamente aunque el batch size es estable”
Síntoma: Misma configuración a veces cabe, a veces OOM después de horas.
Causa raíz: Fragmentación de memoria, tensores filtrados, múltiples procesos por GPU o crecimiento de caché.
Solución: Asegura un proceso por GPU salvo que particiones intencionalmente; monitoriza memoria por proceso; reinicia workers con fugas; usa ajustes del asignador y checkpointing.
4) “La latencia de inferencia se dispara cada pocos minutos”
Síntoma: P50 estable, P99 picos periódicos.
Causa raíz: Jobs en segundo plano causando contención PCIe/NVMe, pausas del GC de CPU, reclaim de páginas del kernel o cambios de reloj de GPU.
Solución: Aísla hosts de inferencia; fija CPUs; controla el batcher; habilita persistence mode; elimina cron jobs ruidosos; ajusta límites de memoria.
5) “El nodo GPU se cae o reinicia bajo carga”
Síntoma: Errores Xid, GPU cae del bus, nodo reinicia, job de entrenamiento muere.
Causa raíz: Problemas de suministro de potencia, riser/cable defectuoso, runaway térmico, firmware inestable o hardware marginal.
Solución: Revisa logs para Xid; valida estabilidad del enlace PCIe; prueba burn-in; actualiza BIOS/firmware; involucra al proveedor; reduce temporalmente el power cap para confirmar sospecha.
6) “Compramos GPUs pero no podemos desplegarlas”
Síntoma: El hardware llega; el despliegue queda bloqueado por instalaciones o diseño de rack.
Causa raíz: Suposiciones de densidad de potencia basadas en racks de era CPU.
Solución: Planifica presupuestos de potencia a nivel de rack temprano; verifica PDUs, capacidad de refrigeración, contención y límites de breakers; modela casos de fallo (un CRAC caído).
7) “Las GPUs alternativas son ‘equivalentes’ pero el rendimiento es peor”
Síntoma: Mismo código de modelo, entrenamiento/inferencia más lento en proveedor no por defecto.
Causa raíz: Diferencias en madurez de kernels/bibliotecas, falta de ops fusionadas, stack de comunicación menos optimizado o menor ancho de banda efectivo de memoria para tu carga.
Solución: Benchmarca tu carga exacta, no FLOPS sintéticos. Presupuesta tiempo de ingeniería para portar y tunear, o no finjas que es plug-and-play.
Listas de verificación / plan paso a paso
Checklist A: Antes de comprar más GPUs
- Mide el duty cycle de GPU: si la utilización es baja, resuelve alimentación/E/S antes de escalar la oferta.
- Cuantifica el desglose del tiempo por paso: dataloader vs forward/backward vs all-reduce.
- Valida la interconexión: ancho/velocidad PCIe; estado NVLink; ancho de banda de la red para multinodo.
- Comprueba margen térmico: asegúrate de que no haya throttling a temperaturas ambiente esperadas.
- Revisa provisión de potencia: presupuesto de rack, capacidad PDU, alimentaciones redundantes y power caps.
- Confirma pinning de la pila de software: versiones driver/CUDA/framework que puedas reproducir.
Checklist B: Primera semana de un nuevo clúster GPU (haz esto incluso si es “temporal”)
- Instala una imagen dorada por modelo de GPU; mantén builds inmutables.
- Ejecuta burn-in y monitoriza errores Xid y advertencias PCIe AER.
- Registra rendimiento base: tiempo por paso, tokens/seg, latencia P99, consumo de potencia y térmicas.
- Valida la topología: mapeo NUMA, colocación de GPUs, localidad de NIC y enlaces NVLink.
- Configura observabilidad: node exporter + DCGM metrics + tiempos de paso a nivel de job.
- Escribe un runbook: qué hacer cuando la GPU cae del bus, tormentas OOM o NCCL cuelga.
Checklist C: Endurecimiento del servicio de inferencia (mantén el SLA)
- Define el SLO usando P99 y tasa de errores, no promedios.
- Implementa load shedding y backpressure; evita colas infinitas.
- Usa batching explícito con límites; mide impacto en latencia de cola.
- Aísla vecinos ruidosos: nodos dedicados o cgroups/cuotas estrictas.
- Canary de actualizaciones de driver/runtime con tráfico de replay y comprobaciones de corrección.
- Mantén un buffer de capacidad para despliegues y para la realidad de “una GPU murió”.
Checklist D: Plan de almacenamiento para entrenamiento (porque las GPUs odian esperar)
- Prefiere datasets sharded para reducir overhead de metadata y lecturas de archivos pequeños.
- Pre-carga en NVMe local para épocas repetidas cuando sea posible.
- Mide IOPS y throughput bajo concurrencia; benchmarks de cliente único mienten.
- Monitorea comportamiento de caché; establece límites explícitos para evitar caos de page-reclaim.
- Alinea el formato con el patrón de acceso: lecturas secuenciales ganan; lecturas aleatorias pierden.
Preguntas frecuentes
1) ¿Por qué no podemos usar CPUs para todo?
Puedes para cierta inferencia y modelos pequeños. Pero para entrenamiento a gran escala y inferencia de alto throughput, las GPUs ofrecen mejor rendimiento por vatio y por dólar para álgebra lineal densa, además de kernels y bibliotecas maduras.
2) ¿La escasez de GPUs es solo por el hype de la IA?
No. El hype puede inflar planes, pero el impulsor subyacente es que las cargas de IA convierten cómputo en valor de negocio medible. Cuando eso ocurre, la demanda se vuelve estratégica y persistente.
3) ¿Cuál es la razón técnica más grande por la que las GPUs ganan para IA?
Ancho de banda de memoria emparejado con cómputo masivamente paralelo. Muchos kernels de IA son sensibles al ancho de banda; HBM y caminos internos anchos mantienen alimentadas las unidades matemáticas.
4) ¿Por qué importa tanto NVLink/NVSwitch?
Porque el entrenamiento distribuido pasa mucho tiempo sincronizando parámetros y gradientes. Enlaces GPU-a-GPU más rápidos reducen overhead de comunicación y mejoran la eficiencia de escalado.
5) ¿Por qué los aceleradores “equivalentes” suelen rendir peor?
Madurez del software. La fusión de kernels, bibliotecas, compiladores y stacks de comunicación tardan años en madurar. Si el camino rápido de tu framework asume un ecosistema, las alternativas pueden ejecutar el camino lento.
6) ¿Qué debo monitorizar en nodos GPU en producción?
Como mínimo: utilización GPU, uso de memoria, consumo de potencia, temperatura, razones de throttling, errores ECC/Xid, estado del enlace PCIe y métricas de tiempo por paso o histogramas de latencia a nivel de job.
7) ¿Cómo sé si estoy limitado por cómputo o por entrada?
Si la utilización de GPU y el consumo de potencia son bajos mientras CPU/iowait es alto, probablemente estés limitado por entrada. Si las GPUs están al máximo y el tiempo por paso es estable, estás más limitado por cómputo. Confirma con tiempos del pipeline dentro del job.
8) ¿Por qué ocurren picos de latencia en inferencia aunque la utilización media de GPU sea baja?
La latencia de cola es sensible al encolamiento, comportamiento del batcher, pausas de CPU, reclaim de páginas y contención en PCIe/NVMe. Una GPU mayormente inactiva no garantiza tiempos de respuesta consistentes.
9) ¿Cuál es la forma más segura de desplegar actualizaciones de driver GPU?
Canary en hardware idéntico con tráfico de replay. Valida corrección y distribución de latencias. Luego despliega gradualmente con buffer de capacidad. Trata los drivers como actualizaciones de kernel: potentes, riesgosas y no para un viernes por la tarde.
10) ¿Cuál es la forma más rápida de malgastar dinero en GPUs?
Comprarlas antes de validar potencia, refrigeración, throughput de almacenamiento, tejido de red y tu capacidad para mantener estable la pila de software. El hardware llegará a tiempo; tu preparación no.
Próximos pasos que puedes tomar esta semana
Si eres responsable de mantener sistemas respaldados por GPU fiables—o de hacer un plan de compra que no implosione—haz estas cosas a continuación. Son prácticas y mueven la aguja.
- Establece una línea base con una carga real en tu hardware actual: tiempo por paso, tokens/seg, latencias P95/P99, consumo y térmicas.
- Ejecuta la guía de diagnóstico rápido en un job lento y uno “saludable”. Anota las diferencias.
- Prueba que tu ruta de datos pueda alimentar las GPUs: throughput de almacenamiento y capacidad de preprocesamiento CPU bajo concurrencia.
- Mapea la topología (PCIe, NUMA, NVLink) y documenta. Luego fija cargas intencionalmente.
- Implementa un runbook mínimo para GPU: qué hacer ante errores Xid, tormentas OOM, cuelgues NCCL y throttling térmico.
- Deja de comprar por FLOPS. Compra por throughput end-to-end para tu carga exacta, más el costo operacional de mantenerla estable.
El mercado de GPUs no se rompió porque todos de repente se volvieron irracionales. Se rompió porque las cargas de IA son racionalmente hambrientas y el camino más rápido para entregarlas ha sido con forma de GPU durante años. Trata las GPUs como una dependencia de producción, no como un lujo. Construye los sistemas aburridos a su alrededor: potencia, refrigeración, almacenamiento, scheduling y control de cambios. Así conviertes la escasez en salida predecible.