Skip to content

English · Español

Extensión X1 — Pretraining a Escala

Requiere: 35 — Entrenamiento e inferencia distribuidos Enseña: scaling-laws · chinchilla · mfu · pretraining · cluster-economics Salta a cualquier capítulo desde el índice de referencia de fases.

Mapa del capítulo

Extension track. Autorizada por §A15 (addendum de extensión, paralela). Este módulo se sitúa fuera del currículo principal de 40 fases y cierra el hueco de "no hay pretraining real a escala" señalado en HIRING_PATH.md §"Honest gaps" (línea 262). No es una expansión de alcance del universo microscópico de §A13: el tutor de gramática verbal sigue siendo el capstone del currículo. X1 es el módulo post-currículo donde Borja ejecuta una corrida real de pretraining sobre una GPU real en la nube para que las palabras "loss spike", "Chinchilla-óptimo" y "MFU 0.45" se asocien a números vividos, no a entradas de blog.

🇪🇸 X1 cierra el hueco de pretraining real señalado en HIRING_PATH.md. Una sola corrida de 24 h en la nube, 50M parámetros, ~5B tokens, presupuesto duro de $50 — suficiente para sentir las dinámicas (curva de loss, spikes, MFU, coste por token) sin entrar en el presupuesto de un laboratorio frontera.

Estado

  • Tipo: extensión post-currículo (no es una fase).
  • Prerrequisitos: Fase 18 (training loop), Fase 26 (cuantización, para el epílogo de coste de inferencia), Fase 35 (vocabulario de paralelismo distribuido). El lab asume que ya has entregado un pipeline funcional de mlflow + safetensors + manifest desde la Fase 18.
  • Hardware: 1× GPU en la nube (objetivo A100 80GB). Sin multi-nodo. Multi-GPU se describe solo en teoría — las corridas son single-GPU.
  • Tope de gasto: $50 (tope duro, aplicado por budget_guard.py reutilizado de la Fase 35).
  • Duración: ~3 días de esfuerzo de reloj de pared a lo largo de ~2 semanas (lectura de teoría + una corrida en nube de ~24 h + un triple de scaling laws).

Lo que enseña esta extensión

Al final de X1 puedes:

  1. Enunciar y aplicar la regla compute-óptima de Chinchilla (\(N_\text{opt} \approx 20 \cdot D\), donde \(N\) es número de parámetros y \(D\) son tokens de entrenamiento) y explicar cuándo subestima y cuándo sobreestima.
  2. Estimar el coste en dólares de entrenar un modelo arbitrario de \(N\) parámetros hasta \(D\) tokens sobre un cluster (cluster) específico, incluyendo MFU, $/GPU-hora spot/on-demand, y energía.
  3. Ejecutar una corrida de pretraining (pretraining) de 24 horas en una sola GPU sobre lambda.ai o runpod.io, entrenar un transformer decoder-only de ~50M parámetros sobre ~5B tokens de Pile-CC / FineWeb-Edu, y producir una curva de loss reproducible.
  4. Ajustar una scaling law (scaling laws) a partir de un barrido de 3 puntos (5M / 25M / 100M parámetros, presupuesto de tokens fijo) y predecir el conteo de tokens compute-óptimo para un modelo hipotético de 1B parámetros.
  5. Diagnosticar un loss spike post-hoc desde una corrida de mlflow: identificar el rango de batch ofensor, clasificar el modo de fallo (gradiente de token raro, explosión de Adam β₂, learning rate demasiado alto, corrupción del dataset), y proponer la recuperación apropiada (skip-batch, restart-from-prior-ckpt, clip más estricto, re-escalado μP).
  6. Leer un log real de pretraining frontera (OLMo, Pythia, Falcon, Llama) y nombrar las decisiones arquitectónicas y de datos que motivaron cada línea.

Orden de lectura

Teoría (leer primero, en orden)

  1. theory/00-motivation.md — por qué una corrida en la nube; el hueco que cierra; qué puedes y qué no puedes aprender con $50 de pretraining.
  2. theory/01-scaling-laws.md — Kaplan 2020, Hoffmann (Chinchilla) 2022; la regla de 20 tokens/parámetro; Pareto datos vs parámetros; regímenes de sobre-entrenamiento y sub-entrenamiento.
  3. theory/02-cluster-economics.md — especificaciones de H100 / A100 / H200; \(/GPU-hora spot vs on-demand; coste de ancho de banda; energía; el cálculo de 7B-por-\)1M desarrollado.
  4. theory/03-data-pipelines-at-scale.md — CommonCrawl → filtro de calidad → dedup → tokenización → shards; FineWeb-Edu; aritmética de throughput; sharding para streaming.
  5. theory/04-training-stability-at-scale.md — loss spikes, μP, weight decay; procedimientos de recuperación; intervenciones mid-training (resets de LR, currículo, intercambios de datos).

Lab (hacer después de la teoría)

  1. lab/00-one-day-cloud-pretraining.md — la corrida real. ~24 h en 1× A100 80GB. Tope duro $50.
  2. lab/01-scaling-laws-experiment.md — tres corridas más pequeñas (5M / 25M / 100M parámetros) sobre un presupuesto de cómputo fijo. Ajustar curva Chinchilla. Predecir el óptimo para 1B parámetros.

Enlaces cruzados

  • Fase 18 — Training loop. El optimizador, el scheduler, el checkpoint y el cableado de mlflow que entregas en la Fase 18 es el sustrato sobre el que se ejecuta X1. El lab de X1 añade un dataloader streaming y un runner por presupuesto de tokens — todo lo demás se reutiliza. (docs/phase-18-training-loop/)
  • Fase 26 — Cuantización. Tras el pretraining, cuantizas el checkpoint de 50M a int8 / int4 y mides $/token de inferencia. El artefacto capstone de X1 es un número de coste por token para el modelo que tú entrenaste versus las baselines de pesos abiertos. (docs/phase-26-quantization/)
  • Fase 35 — Distribuido. X1 es single-GPU. El contenido "qué cambia a >10B parámetros" de theory/02 y theory/04 se apoya en el vocabulario TP/PP/ZeRO-3 de la Fase 35. Si esas palabras todavía no se asocian a un mecanismo, termina primero la Fase 35. (docs/phase-35-distributed/)
  • Fase 36 — Arquitecturas frontera. La elección de forma del modelo para el lab (profundidad, ancho, número de cabezas, GQA encendido/apagado) cita el espacio de diseño de la Fase 36. El lab de X1 usa una forma por defecto de mediados de 2024 (32 capas × 768 ancho × 12 cabezas × GQA-4); la Fase 36 es donde justificarías desviarte. (docs/phase-36-frontier-architectures/)

Definition of Done (DoD del extension track)

Los extension tracks no tienen un PHASE_NN_REPORT.md (están fuera del ritual de 40 fases). X1 entrega estos cuatro checks binarios:

  1. Una corrida en la nube reproducible. experiments/X1-pretraining/run-cloud/ contiene: manifest.json (seed, versiones, config, cluster, $-gastados), URI de mlflow, loss-curve.png, y checkpoint en safetensors. La corrida llegó al reloj de pared de 24 horas y se mantuvo por debajo de $50.
  2. Triple de scaling law hecho. experiments/X1-pretraining/scaling-law/ tiene tres corridas (5M, 25M, 100M parámetros), un CSV de (parámetros, tokens, val-loss), un plot de la curva ajustada y una predicción escrita para el conteo de tokens compute-óptimo de 1B parámetros con un intervalo de confianza.
  3. Post-mortem de loss spike. experiments/X1-pretraining/spike-postmortem.md existe con: timestamp del spike detectado (sintético si no ocurrió ninguno real — inyéctalo), clasificación, evidencia (log de norma del gradiente, histograma de batch-tokens), acción de recuperación tomada y resultado.
  4. Quiz /quiz X1 ≥ 80%.

Un reflections.md breve en learners/borja/extension-X1/ cubre: qué me sorprendió sobre el MFU a esta escala; cómo el óptimo de Chinchilla difirió de mi intuición previa a la corrida; qué línea de coste dominó (cómputo / ancho de banda / almacenamiento / horas humanas).

Estimación de coste (concreta)

Concepto Detalle $
Lab 00 (pretraining de un día) 1× A100 80GB spot @ ~$1.10/h × 24 h $26
Lab 00 egress de almacenamiento 200 GB de datos tokenizados, en caliente durante 24 h $3
Lab 01 triple de scaling law 3× corridas de ~4 h sobre el mismo nodo = 12 h × $1.10/h $13
Buffer para reinicios / debug ~10% de margen $5
Tope total aplicado por budget_guard.py $50

Si el precio spot real es más alto (A100 80GB ha visto $1.79/h on-demand en Lambda, $0.79/h en el cuartil más bajo de RunPod community spot), budget_guard.py rechaza el lanzamiento y re-planificas. No excedas en silencio.

Lo que esta extensión intencionadamente NO cubre

  • Entrenamiento multi-nodo. Solo single-GPU. Las topologías InfiniBand / NVLink entre nodos se cubren en theory/02-cluster-economics.md para vocabulario, no para corrida.
  • Un modelo a escala frontera. 50M parámetros es el tamaño de la corrida. Extrapolamos a 1B / 7B / 70B en teoría; no los entrenamos.
  • Kernels CUDA personalizados. La Fase 24 cubre Triton. X1 usa torch.compile estándar y FlashAttention-2 desde pip.
  • Modelos MoE / dispersos. Territorio de la Fase 36. X1 se queda en denso.
  • RLHF / SFT sobre el modelo pre-entrenado. Territorio de la Fase 31 / hipotético X3. X1 se detiene en el modelo base.
  • Entrenamiento de tokenizador. Usamos un tokenizer (tokenizer) pre-entrenado (BPE de GPT-2 o tokenizer de Llama-3). El entrenamiento de tokenizer a escala es territorio de la Fase 11; la escala de datos de ese paso es minúscula comparada con la del paso de entrenamiento del modelo en el que nos centramos aquí.
  • Búsqueda de hiperparámetros. Una sola configuración, derivada de la teoría. Si diverge, hacemos post-mortem y re-lanzamos una vez; no barremos.

Política build-before-abstract para X1

La regla del currículo principal (CLAUDE.md §0.4): nada de PyTorch antes de la Fase 25, nada de transformers antes de la Fase 24. Cuando llegas a X1, ambas puertas están abiertas. X1 usa:

  • PyTorch 2.4+ con torch.compile para el training loop.
  • transformers.GPT2Tokenizer (o el tokenizer de Llama-3) — no re-entrenamos un tokenizer.
  • datasets para streaming de Pile-CC / FineWeb-Edu.
  • flash-attn para el kernel de atención (attention) (solo CUDA; protegido tras un runtime check).
  • NADA de accelerate, NADA de deepspeed, NADA de lightning. Single-GPU es single-process; no necesitamos un framework para lanzar un script de Python.

El script de entrenamiento en sí mismo es un único fichero de ~400 líneas con forma de nanoGPT en src/x1_pretrain/train.py. El objetivo es mantener toda variable visible — cuando el loss spikee a la hora 14, puedes leer el bucle de arriba abajo sin salir del fichero.

Siguiente: theory/00-motivation.md.

Lecturas recomendadas

Opcional — enriquece pero no es necesario para aprobar la fase.