English · Español
00 — Motivación: por qué distribuir¶
🇪🇸 Hay exactamente dos razones para distribuir: (1) el modelo no cabe en una GPU (presión de memoria), (2) el cómputo tarda demasiado (presión de tiempo). Cada estrategia (DDP / ZeRO / FSDP / TP / PP) ataca una de las dos. Confundir las razones es la causa #1 de elegir mal la paralelización.
Puedes correr la mayoría de este currículo en una sola CPU. Entrenaste Mini-GPT ahí. ¿Por qué se molesta el campo en clusters multi-GPU?
Dos razones. Exactamente dos. Confúndelas y elegirás la estrategia de paralelización equivocada cada vez.
Razón 1: el modelo no cabe¶
Un modelo tiene parámetros \(\theta\) (los pesos) y activaciones (tensores intermedios durante forward y backward). Ambos consumen memoria de GPU.
Para entrenamiento, la huella de memoria es aproximadamente:
Para un modelo de 7B parámetros en fp32 (sí, eso es derrochador — sígueme la corriente), sin considerar activaciones:
Una A100 tiene 40 u 80 GB de HBM. No puedes entrenar un modelo 7B en una sola A100 en fp32, punto. Incluso con precisión mixta (~la mitad del número), las activaciones te empujan por encima del límite.
Para inferencia, gradientes y estado del optimizador desaparecen:
Pesos 7B fp16 = 14 GB. Cabe en una GPU de consumo de 24 GB con margen para la KV cache. Inferir 7B es terreno de una GPU; entrenar no.
Cuando el modelo en sí no cabe en una GPU, las únicas opciones son:
- Reducir la huella del modelo por GPU. Estrategias de sharding: ZeRO-1 (shardea el estado del optimizador), ZeRO-2 (+ gradientes), ZeRO-3 / FSDP (+ parámetros). Cada GPU sigue haciendo el trabajo de un batch pero retiene 1/N del "estado" del modelo.
- Partir el modelo entre GPUs. Tensor parallel (TP) parte dentro de cada capa; pipeline parallel (PP) pone capas distintas en GPUs distintas.
Elige una (o combina — paralelismo 3D). La elección depende de en qué eje el modelo es "demasiado grande": demasiados parámetros (TP / ZeRO-3 / FSDP), demasiadas capas (PP) o simplemente demasiado estado del optimizador para una GPU (ZeRO-½).
Razón 2: el cómputo tarda demasiado¶
Distinto de "no cabe": el modelo cabe pero entrenar una época lleva un mes y tienes 3 días.
La solución es paralelismo de datos (data parallel, DDP): cada GPU tiene una copia completa del modelo, cada una recibe un shard distinto del batch, los gradientes se hacen all-reduce entre las GPUs al final de cada step. Cada GPU hace menos trabajo por step (batch por GPU más pequeño); el cómputo total es más rápido.
DDP escala bien hasta cierto punto, luego la comunicación empieza a dominar (más sobre esto en theory/03-collectives-and-cost.md). Para clusters muy grandes, DDP se combina con ZeRO-N para compartir la presión de memoria de mantener el modelo.
Cuando las dos razones chocan¶
Un equipo tiene un modelo de 70B parámetros. No cabe (Razón 1) y quieren entrenarlo rápido (Razón 2). ¿Y ahora qué?
Este es el problema del paralelismo 3D. La respuesta de manual:
- Usa TP dentro de un nodo (el ancho de banda intra-nodo es alto — NVLink a 600 GB/s).
- Usa PP entre nodos (el ancho de banda inter-nodo es menor — InfiniBand a 200 Gb/s ≈ 25 GB/s).
- Usa DDP en el nivel más externo (shardea los datos entre los grupos "TP × PP").
Eso te da configuraciones del tipo "DP=N, TP=8, PP=4". La matemática se vuelve espinosa. La Fase 35 cubre las piezas; la combinación es solo conceptual.
Lo que NO pertenece a esta fase¶
Un modo de fallo al enseñar entrenamiento distribuido es empezar por el cluster. No lo hagas. Empieza por por qué una sola GPU no es suficiente para tu carga concreta, y deja que eso guíe la estrategia.
Para el currículo de Borja:
- MiniGPT (≤500k params, fp32) cabe en una calculadora. Nunca necesita distribución por razones de memoria.
- Entrenarlo distribuido es solo un ejercicio docente — cómo es el protocolo de cable, cuánto cuesta un all-reduce.
- Inferencia de MiniGPT bajo TP también es pedagógica — cómo es el patrón de comunicación.
Borja no entrenará un modelo frontera en este currículo. El sentido de la Fase 35 es vocabulario y modelos mentales para que, cuando lea un log real de entrenamiento distribuido dentro de seis meses, los nombres mapeen a mecanismos.
La dimensión coste¶
La Fase 35 es la única fase que gasta dinero real en la nube del currículo (Fase 23 y Fase 24 podrían — depende del setup de Borja — pero la Fase 35 gastará).
Cada experimento cloud en esta fase empieza con una frase como:
"Esto levanta 2× RTX 4090 spot en RunPod a ~$0.35/hr cada una = $0.70/hr total, corre ~3 horas incluyendo setup tax = $2.10. Presupuesto: $3.00. Confirmado aceptable, $0.90 de buffer."
Si Borja no puede escribir esa frase sobre un lab, no corre el lab. La Fase 35 introduce src/distributed/budget_guard.py precisamente para imponerlo — un wrapper que se niega a lanzar cualquier trabajo cuyo coste estimado superaría el techo configurado.
El techo total de la factura cloud de la Fase 35 es $5. Es un presupuesto de aprendiz, no un presupuesto real de cluster; el objetivo es educación, no benchmarks.
Cómo conecta esto con el currículo más amplio¶
- Fase 33 construyó serving en nodo único. La Fase 35 introduce el concepto de serving multi-nodo (TP para inferencia), implementación diferida.
- El stack de observabilidad de la Fase 34 se extiende aquí: cada worker emite sus propias métricas; el dashboard agrega. Las métricas GPU USE de DCGM entran ahora.
- Fase 36 cubre MoE; expert parallelism se monta de manera natural sobre el vocabulario de paralelización de esta fase.
- Fase 37 eleva la superficie de amenaza — los pesos del modelo cruzan fronteras de red; datos derivados de KB tocan múltiples workers; la historia de integridad de safetensors escala.
- Fase 38 hace dimensionamiento de cluster óptimo en coste; construido sobre la matemática de coste de la Fase 35.
Así que aunque la Fase 35 es una fase "pesada en concepto, ligera en implementación", lo que aterriza aquí fluye a la segunda mitad del currículo.
Resumen en un párrafo¶
Distribuye porque (1) el modelo no cabe en una GPU o (2) el cómputo tarda demasiado. La elección de estrategia se sigue de cuál: TP/PP/ZeRO-3/FSDP para presión de memoria, DDP para presión de tiempo, combinaciones 3D para ambas. MiniGPT cabe en una calculadora, así que la Fase 35 es pedagógica — vocabulario, lectura de fuentes, un mínimo contacto cloud. La disciplina de coste es obligatoria: cada experimento cloud estima el gasto por adelantado, el techo total de la Fase 35 es $5, budget_guard.py lo impone.
Siguiente: theory/01-data-parallel-and-zero.md.