English · Español

00 — Por qué una fase de hardware antes que cualquier IA¶

La intuición central: el cuello de botella en IA (AI) no son las multiplicaciones, es mover los datos. Si no entiendes la jerarquía de memoria, todo lo demás (matmul lento, training I/O-bound, KV cache caro) parece magia.

La mentira que cuentan los libros de texto¶

Un libro de álgebra lineal dice que matmul es O(N³). Eso es cierto como recuento de multiplicaciones. Es falso como predictor del tiempo de pared en hardware real. Pruébalo: escribe un matmul fp32 ingenuo en Python con tres bucles anidados, ejecútalo sobre una entrada de 1024×1024, y luego ejecuta np.matmul sobre la misma entrada.

La versión ingenua es al menos 50× más lenta que NumPy. Ambas hacen el mismo número de multiplicaciones. La diferencia es por completo el coste de mover datos a través de la jerarquía de memoria.

El modelo de los libros de texto trata el acceso a memoria como gratuito. El hardware real no. Hasta que lo hayas medido tú mismo, cada fase posterior tiene una fuga — explicarás el entrenamiento como "el optimizador encuentra un mínimo" sin preguntarte nunca por qué una pasada forward tarda 50 ms en vez de 50 µs.

La tesis de la Fase 1¶

La Fase 1 entrena un hábito:

Siempre que veas un kernel más lento de lo esperado, tu primera pregunta es "¿está limitado por ancho de banda o por cómputo?", no "¿es correcto el algoritmo?".

La optimización algorítmica es rara. La optimización de memoria es constante. Al final de la Fase 1, deberías ser capaz de leer un kernel y predecir en qué lado del roofline vive — antes de ejecutarlo.

Qué significa "bandwidth-bound", en concreto¶

Una CPU moderna puede hacer aproximadamente 100 GFLOPS de aritmética fp32. Leyendo datos de la RAM principal, la misma CPU sostiene aproximadamente 20 GB/s. fp32 son 4 bytes. Así que en el tiempo que se tarda en cargar un valor fp32 desde la memoria principal, la CPU podría haber hecho 20 operaciones en coma flotante.

Si tu kernel hace menos de ~20 FLOPs por byte cargado, está memory-bound — las FPUs están ociosas, esperando datos. El matmul ingenuo hace exactamente 2 FLOPs por fp32 cargado (una multiplicación, una acumulación). Está limitado por ancho de banda por un factor de diez antes incluso de empezar a optimizar.

El número que captura esto es la intensidad aritmética I = FLOPs / bytes_movidos, y la gráfica que lo visualiza es el roofline. Ambos se introducen en theory/03-roofline-model.md.

Por qué esto importa específicamente para la IA¶

Cinco afirmaciones que deberían tener sentido después de la Fase 1, pero que probablemente ahora parezcan jerga:

GEMM (matmul) es el cuello de botella del entrenamiento y de la inferencia. La razón por la que "velocidad de matmul" es la métrica de rendimiento estrella para cualquier acelerador de IA es que todo lo demás — softmax, layer norm, residual add — está tan limitado por memoria que la eficiencia de GEMM domina el runtime total.
El transformer está memory-bound durante la inferencia, compute-bound durante el entrenamiento. Durante el entrenamiento, los batch sizes son grandes, por lo que cada carga de pesos se amortiza sobre muchas activaciones — alta intensidad aritmética. Durante la inferencia con batch size 1 (chat), cada peso se carga para un token — baja intensidad. Este cambio es la razón completa de la existencia del KV cache (Fase 22).
El marketing del A100/H100 va sobre todo de ancho de banda de memoria, no de FLOPS. El H100 tiene ~2× el ancho de banda de memoria del A100, lo cual importa más que el aumento de FLOPS para la mayoría de las cargas. Los fabricantes citan FLOPS porque es un número mayor.
La cuantización (Fase 26) acelera la inferencia principalmente reduciendo bytes movidos, no multiplicaciones. Las multiplicaciones INT8 no son 4× más rápidas que las FP32 en la mayoría del hardware. Pero los pesos INT8 son 4× más pequeños, y los estás cargando desde memoria.
Flash Attention (Fase 27) no es un algoritmo más inteligente; es el mismo algoritmo reorganizado para encajar en SRAM en vez de en HBM. Eso es una optimización de jerarquía de memoria, no una optimización matemática.

Cada una de esas afirmaciones es un argumento de roofline. No serás capaz de evaluar ninguna arquitectura ni acelerador hasta que puedas hacer estos argumentos tú mismo, a partir de mediciones.

El camino a través de la Fase 1¶

Theory 01 hace zoom: ¿qué es una CPU, mecánicamente? Desde transistores hasta un motor de ejecución segmentado y fuera de orden. La idea no es recrear un curso de lógica digital sino poner palabras a las abstracciones que asumen las siguientes páginas de teoría.
Theory 02 hace zoom out: caches, DRAM, NUMA, PCIe, disco. Cada nivel tiene una latencia en nanosegundos y un ancho de banda en GB/s. Las proporciones entre ellos son el sustrato de cada argumento de rendimiento en el currículo.
Theory 03 unifica los dos con el modelo roofline.
Labs 00–03 te obligan a hacer las mediciones en tu propio ordenador. Cada gráfica es tuya, no una captura de un libro de texto. El roofline que comprometes al final es el roofline de este portátil, lo que hace concretas las comparaciones de GPU posteriores del currículo (Fase 23+) en vez de abstractas.

Para aquí si¶

Te tienta saltar la Fase 1 porque "ya sé lo que son las caches". No lo hagas. La prueba no es "¿puedes decir la palabra L1?". La prueba es: ¿puedes predecir en qué lado del roofline vive tu código, antes de ejecutarlo? Si todavía no puedes, la Fase 1 es para ti.

Siguiente: theory/01-from-transistor-to-cpu.md.