Tercer módulo del Curso de GPU para IA. Ya sabes qué GPU necesitas (Módulo 2); ahora toca la parte que nadie cuenta: el hardware no hace nada solo. Entre tu aplicación y el silicio hay una torre de software, y la mayoría de los problemas que vas a tener en este curso — “no detecta la GPU”, “versión incompatible”, “funciona pero va lento” — viven en esa torre.

La tesis del módulo

NVIDIA no domina la IA por su hardware: domina por CUDA. El foso competitivo es el software — quince años de librerías, frameworks y documentación que asumen CUDA. Entender el stack por capas te da el mapa para diagnosticar cualquier problema y para evaluar las alternativas con ojos fríos.

La torre, capa por capa

 tu aplicación (agente, chat, API)
        │
        ▼
 runtime de inferencia (Ollama, llama.cpp, vLLM, PyTorch)
        │
        ▼
 librerías de cómputo (cuBLAS, cuDNN)
        │
        ▼
 CUDA (la plataforma de programación de NVIDIA)
        │
        ▼
 driver de la GPU
        │
        ▼
 GPU (hardware)

De abajo hacia arriba:

Driver: el traductor entre el sistema operativo y la tarjeta. Sin driver actualizado, nada de lo de arriba funciona. Es lo ÚNICO que instalas sí o sí.
CUDA: la plataforma de NVIDIA para programar la GPU como computador genérico (no solo gráficos). Existe desde 2007; toda la IA moderna se construyó encima.
cuBLAS / cuDNN: librerías de NVIDIA con las operaciones matemáticas (multiplicación de matrices, redes neuronales) hiperoptimizadas. Los frameworks las llaman por debajo.
Runtime de inferencia: el programa que carga el modelo y genera tokens. En este curso usarás Ollama y llama.cpp (bloque local) y vLLM (bloque de nube).
Tu aplicación: el agente o la API que conversa con el runtime.

La buena noticia: los runtimes modernos empaquetan casi todo. Ollama trae sus librerías CUDA incluidas — instalas driver + Ollama y listo. La torre completa importa cuando algo falla o cuando usas PyTorch directamente.

La herramienta de diagnóstico: nvidia-smi

En cualquier máquina con GPU NVIDIA, este comando es tu primer reflejo:

nvidia-smi

+-----------------------------------------------------------+
| NVIDIA-SMI 560.xx      Driver Version: 560.xx             |
| CUDA Version: 12.6                                        |
|-----------------------------------------------------------|
| GPU  Name          | Memory-Usage    | GPU-Util           |
|  0   RTX 3060      | 4210MiB / 12288MiB |  87%            |
+-----------------------------------------------------------+

Las tres lecturas que importan:

Driver Version: la versión del driver instalado.
CUDA Version: la versión máxima de CUDA que ese driver soporta — no la que tienes instalada. Confusión clásica.
Memory-Usage: cuánta VRAM está ocupada. Con un modelo cargado, aquí verificas la cuenta del módulo 2 en vivo.

Y desde Python, la comprobación de que PyTorch ve la GPU:

import torch

print(torch.cuda.is_available())        # True si todo el stack está sano
print(torch.cuda.get_device_name(0))    # "NVIDIA GeForce RTX 3060"

Si esto imprime False teniendo GPU, el problema está en la torre: driver viejo, o instalaste la versión de PyTorch para CPU (el error de instalación más común del ecosistema — al instalar PyTorch hay que elegir el build que corresponde a tu versión de CUDA, no el genérico).

Las alternativas: el mapa honesto

Plataforma	De quién	Estado real para IA local
CUDA	NVIDIA	El estándar. Todo funciona aquí primero
Metal / MPS	Apple	Sorprendentemente maduro: Ollama y llama.cpp lo usan nativo en Mac
ROCm	AMD	Funciona en Linux con tarjetas soportadas; en Windows sigue verde
Vulkan	Khronos (abierto)	El plan B universal de llama.cpp: corre en casi cualquier GPU, más lento

La lectura práctica:

Tienes NVIDIA: camino pavimentado, sigue el curso tal cual.
Tienes Mac M-series: camino pavimentado también — Metal es ciudadano de primera en el ecosistema local.
Tienes AMD: posible, con asteriscos. En Linux con ROCm anda bien; en Windows, tu mejor amigo es el backend Vulkan de llama.cpp.
Eliges GPU en la nube: será NVIDIA prácticamente siempre; esta torre es la que verás en los logs.

Versiones: la fuente de todos los llantos

La regla de compatibilidad de la torre, de una vez y para siempre:

El driver debe ser igual o más nuevo que lo que exige tu versión de CUDA; y tu framework debe estar compilado para una CUDA que tu driver soporte. Driver nuevo con CUDA vieja: bien. Driver viejo con CUDA nueva: error.

Por eso el consejo operativo es aburrido pero infalible: mantén el driver al día e instala runtimes que traigan su CUDA empaquetada (Ollama, LM Studio). Pelear versiones a mano es el peaje de usar PyTorch pelado.

Errores comunes

Leer “CUDA Version” en nvidia-smi como “lo que tengo instalado”. Es lo máximo que tu driver soporta. Puedes no tener CUDA instalada y ese campo igual aparece.
Instalar PyTorch con pip install torch a secas esperando GPU. Según la plataforma, eso puede traer el build de CPU. torch.cuda.is_available() es el test de la verdad.
En AMD, asumir que ROCm es “el CUDA de AMD” en cualquier sistema. El soporte serio es en Linux y por lista de tarjetas; verifica la tuya antes de prometerte nada.
Actualizar CUDA toolkit para “arreglar” un problema de driver. Casi siempre la solución es al revés: actualizar el driver.

La frase para llevarse

“El silicio es de quien lo fabrica; el ecosistema es de quien lo programa. NVIDIA vende chips, pero lo que compraste es CUDA.”

Qué viene

Módulo 4, cierre del bloque básico: precisión y cuantización — el truco matemático que mete un modelo de 16 GB en una GPU de 8, qué se pierde a cambio, y cómo leer esos sufijos crípticos (Q4_K_M, Q8_0) que verás en cada modelo descargable.

GPU para IA — Módulo 3: CUDA y el stack de software