Glosario de GPU e IA local

Los términos que aparecen una y otra vez en el Curso de GPU para IA y en cualquier conversación sobre correr modelos en tu propia máquina. Como todo glosario de la academia, crece con cada bloque nuevo del curso.

Hardware

GPU (Graphics Processing Unit) — procesador con miles de núcleos simples diseñado para hacer la misma operación sobre muchos datos a la vez. Nació para gráficos; hoy es el motor de la IA porque los modelos son, en el fondo, multiplicaciones de matrices gigantes.

CPU (Central Processing Unit) — el procesador principal del computador: pocos núcleos muy sofisticados, optimizados para terminar rápido tareas secuenciales. Puede correr modelos cuantizados, decenas de veces más lento que una GPU.

VRAM — la memoria propia de la GPU. Define qué modelos puedes cargar: si el modelo (más su contexto) no cabe en la VRAM, no corre. El número más importante al elegir una GPU para IA.

Ancho de banda de memoria — la velocidad a la que la GPU lee su propia VRAM, en GB/s. En inferencia define los tokens por segundo, porque generar cada token exige leer todos los pesos del modelo.

GDDR — el tipo de memoria de las GPUs consumer (GDDR6, GDDR7). Rápida y económica.

HBM (High Bandwidth Memory) — la memoria de las GPUs de datacenter (A100, H100): apilada junto al chip, con un ancho de banda varias veces mayor que GDDR. Gran parte del precio de esas tarjetas.

Memoria unificada — la arquitectura de Apple Silicon: CPU y GPU comparten el mismo pozo de memoria. Permite cargar modelos enormes en un Mac, a cambio de menos ancho de banda que una GPU dedicada grande.

Núcleo CUDA — la unidad de cómputo genérica de una GPU NVIDIA. Se cuentan por miles; son los “ayudantes” del paralelismo.

Tensor Core — núcleo especializado de NVIDIA que hace multiplicación de matrices en bloque. La razón de que las GPUs modernas sean desproporcionadamente buenas para IA comparadas con su generación anterior.

GPU integrada (iGPU) — la que viene dentro de la CPU y comparte la RAM del sistema. Para IA seria, no alcanza.

GPU de datacenter — tarjetas sin salida de video, puro cómputo, pensadas para servidores: T4, L4, A100, H100, H200, B200. Se arriendan por hora en la nube.

Software

Driver — el software que comunica el sistema operativo con la GPU. Lo único que siempre debes instalar y mantener al día; la mayoría de los “no detecta la GPU” se arreglan aquí.

CUDA — la plataforma de NVIDIA para programar la GPU como computador de propósito general. Existe desde 2007 y toda la IA moderna se construyó encima: es el verdadero foso competitivo de NVIDIA.

cuBLAS / cuDNN — librerías de NVIDIA con las operaciones matemáticas hiperoptimizadas (álgebra lineal, redes neuronales). Los frameworks las usan por debajo; tú rara vez las tocas directo.

ROCm — la respuesta de AMD a CUDA. Funciona en Linux con tarjetas soportadas; en Windows sigue inmaduro.

Metal / MPS — la plataforma de GPU de Apple y su backend para frameworks de IA. Sorprendentemente maduro: Ollama y llama.cpp corren nativos en Mac gracias a esto.

Vulkan — API gráfica abierta que llama.cpp usa como backend universal: corre en casi cualquier GPU (incluidas AMD en Windows), a cambio de menos velocidad que CUDA o Metal.

nvidia-smi — el comando de diagnóstico de NVIDIA: muestra driver, VRAM ocupada y utilización. El primer reflejo ante cualquier problema. Ojo: su campo “CUDA Version” es lo máximo que el driver soporta, no lo que tienes instalado.

Modelos y memoria

Parámetro — cada uno de los números ajustables que componen un modelo; un “7B” tiene 7 mil millones (billions). El tamaño en memoria es parámetros × bytes por parámetro.

Precisión — cuántos bits se usan para guardar cada parámetro: FP32 (32 bits), FP16/BF16 (16), INT8 (8), ~4 bits. Menos bits = menos memoria y más velocidad, con algo de pérdida de calidad.

Cuantización — reducir la precisión de los pesos de un modelo ya entrenado para que ocupe menos memoria. De FP16 a 4 bits el modelo se achica a un tercio con pérdida casi imperceptible. La tecnología que hace posible la IA local.

GGUF — el formato de archivo del ecosistema llama.cpp/Ollama: el modelo completo, ya cuantizado, en un solo archivo portable.

K-quants — la familia moderna de cuantizaciones GGUF (la K en Q4_K_M): reparte más bits a las capas más sensibles en vez de cuantizar parejo. Al mismo tamaño, mejor calidad que la vieja escuela (Q4_0).

Q4_K_M — el nivel de cuantización consenso para uso local: ~4.5 bits por peso, un tercio del tamaño de FP16, calidad casi intacta. El default razonable para empezar.

AWQ / GPTQ — familias de cuantización del ecosistema vLLM/Hugging Face (el mundo fuera de GGUF). Mismos principios que los K-quants, otros formatos: un modelo AWQ no es un archivo GGUF ni viceversa.

Perplexity — métrica de qué tan “sorprendido” queda un modelo ante texto real; menor es mejor. Se usa para medir cuánta calidad pierde una cuantización.

KV cache — la memoria donde el modelo guarda lo ya procesado de la conversación para no recalcularlo con cada token. Crece con el largo del contexto y vive en la VRAM junto a los pesos; por defecto no viene cuantizado.

OOM (out of memory) — el error de quedarse sin VRAM. Su forma más traicionera: el modelo carga bien y revienta a mitad de conversación, cuando el KV cache creció. Se previene dejando 15–20% de margen.

Offloading — repartir un modelo que no cabe: unas capas en la GPU, el resto en la RAM procesado por la CPU. Funciona, pero cada capa fuera de la GPU cuesta velocidad.

Rendimiento

Inferencia — usar un modelo ya entrenado para generar respuestas (a diferencia de entrenarlo). Todo este curso es sobre inferencia.

Tokens por segundo (tokens/s) — la métrica de velocidad de generación. Techo teórico ≈ ancho de banda ÷ tamaño del modelo en memoria.

Latencia — cuánto tarda en llegar la primera respuesta (o el primer token). Lo que el usuario percibe como “rapidez”.

Throughput — cuántas peticiones (o tokens) totales procesa el sistema por segundo. Lo que define cuántos usuarios aguantas.

Memory-bound — cuando el límite de velocidad es la lectura de memoria, no el cálculo: los núcleos esperan datos. La inferencia de LLMs es memory-bound — por eso el ancho de banda importa más que los núcleos.

Batch — procesar varias peticiones juntas para aprovechar mejor la GPU. Mejora el throughput a cambio de algo de latencia; la base del serving eficiente.

Batching continuo — la evolución del batch para texto generativo: las peticiones entran y salen del lote en cada token, en vez de esperar a que termine la más larga. La idea central de vLLM.

PagedAttention — técnica de vLLM que guarda el KV cache en páginas chicas (como la memoria virtual de un sistema operativo) en vez de bloques contiguos: sin fragmentación, caben muchas más conversaciones en la misma VRAM.

Prompt processing vs generación (pp / tg) — las dos fases de la inferencia: leer tu prompt (paralelizable, miles de tokens/s) y escribir la respuesta (memory-bound, decenas de tokens/s). Por eso el modelo “piensa” rápido y escribe lento; llama-bench las mide por separado.

Utilización — el porcentaje del tiempo que la GPU está realmente trabajando. La variable que decide el costo real: una GPU arrendada al 10% de uso multiplica por 10 tu costo por token.

Local y nube

Ollama — el runtime más simple para correr LLMs locales: instala, descarga modelos con un comando y expone una API compatible con OpenAI. La herramienta del bloque intermedio del curso.

llama.cpp — el motor de inferencia de código abierto detrás de gran parte del ecosistema local (Ollama incluido). Control fino: offloading por capas, backends para CUDA/Metal/Vulkan.

vLLM — runtime de inferencia orientado a producción: batching continuo y uso eficiente de memoria para servir muchos usuarios a la vez. La herramienta del bloque de nube.

Serverless GPU — modalidad de nube donde pagas solo los segundos en que tu código usa la GPU, sin servidor permanente. Ideal para cargas intermitentes; su precio es el cold start.

Cold start — el tiempo de arranque de un servicio serverless que estaba apagado: levantar el contenedor y cargar el modelo a la VRAM puede tomar de segundos a minutos. El trade-off central del serverless con GPU.

Pod GPU — máquina con GPU arrendada por hora en un proveedor de nube (RunPod, Lambda y similares). Es tuya mientras pagues: sin cold start, con costo aunque nadie la use.

Escala a cero — la capacidad del serverless de apagar todo cuando no hay tráfico y cobrar cero. Su contracara es el cold start del próximo usuario.

Keep-warm — mantener un contenedor serverless tibio (cargado en VRAM) tras la última petición para evitar cold starts. Se paga: keep-warm permanente ya no es escala a cero.

Instancia spot — capacidad sobrante del proveedor con gran descuento, que puede quitarte con poco aviso. Ideal para lotes tolerantes a fallas; mala idea para servir usuarios.

sentence-transformers — la librería Python estándar para generar embeddings localmente (modelos como multilingual-e5 para español).

faster-whisper — implementación optimizada de Whisper (el modelo abierto de transcripción) para correr voz-a-texto local con poca VRAM.

Costo por millón de tokens — la métrica que permite comparar tu GPU contra una API comercial: precio por hora de la GPU dividido por los tokens útiles que genera en esa hora. Depende brutalmente de la utilización.