Skip to content

English · Español

04 — Plantilla de post-mortem de spike de pérdida (ejemplo continuo: tutor de gramática §A13)

Una spike de loss no es un misterio — es una historia con sujeto, verbo y predicado. Esta plantilla separa síntomas (lo que viste) de hipótesis (lo que crees) de remedio (lo que cambias). La aplicamos al entrenamiento del tutor de gramática para que la próxima vez que veas una sierra en el dashboard, escribas el post-mortem en 20 minutos, no en 2 horas.

Una plantilla reutilizable para documentar y recuperarse de la inestabilidad de entrenamiento. El formato es opinionado — cada sección debe rellenarse. Las secciones vacías son en sí mismas diagnósticas.

Recorremos la plantilla con una spike real (diseñada) del tutor de gramática §A13 abajo.

La plantilla

# Loss spike post-mortem — <date> — <run-id>

## 1. Symptoms (what you observed; numbers only, no theories)

- step where spike began: <int>
- pre-spike loss (50-step EMA): <float>
- peak loss: <float>
- recovery loss (50 steps after peak), or "did not recover": <float or "NaN">
- grad-norm pre-clip at spike: <float>
- LR at spike: <float>
- dtype regime: fp32 / fp16 / bf16
- batch index in the spike step (if logged): <int>
- corpus token(s) in that batch that look unusual: <list or "none flagged">

## 2. Hypotheses (rank by likelihood; cite the dashboard panel that supports each)

1. <hypothesis>: supported by <panel/observation>
2. <hypothesis>: supported by <panel/observation>
3. <hypothesis>: supported by <panel/observation>

## 3. Discriminating evidence (which panels rule each hypothesis in or out)

- Panel <n>: <observation> → favors H<k>, rules out H<j>
- Panel <n>: <observation> → ...

## 4. Root cause (a single sentence; if you can't write one, you don't know yet)

<one sentence>

## 5. Remediation (the smallest change that fixes the root cause)

- <change>

## 6. Verification (the test that confirms the fix)

- Re-run with seed <s>, expect loss curve within <ε> of baseline through step <T>.

## 7. Lesson (one line, added to learners/<name>/phase-NN/notes/lessons.md)

<one line>

Ejemplo trabajado — tutor de gramática §A13, ejecución 19-spike-001

Montaje: entrenamiento del mini-GPT de la Fase 17 sobre el corpus §A13. AdamW, \(\eta_\text{max} = 3 \times 10^{-4}\), warmup 100, cosenoidal hasta 2000 pasos, batch size 8, fp32. En el paso 312 la pérdida salta de 2.31 a 5.84, luego se asienta en 3.40 hacia el paso 360.

1. Síntomas

  • paso donde comenzó la spike: 312
  • pérdida pre-spike (EMA de 50 pasos): 2.31
  • pérdida pico (paso 313): 5.84
  • pérdida de recuperación (paso 360): 3.40
  • norma de gradiente pre-clip en la spike: 47.2 (baseline rolling: 0.6)
  • LR en la spike: \(2.94 \times 10^{-4}\) (cosenoidal, cerca del pico)
  • dtype: fp32
  • batch index 312: contenía 3 frases con el verbo write en forma de pasado participio (written), y el tokenizador BPE partió written como wri + tten.
  • inusual: sí, tten es un token BPE de baja frecuencia (aparece solo en conjugaciones de write y formas tipo bitten, ~5 ocurrencias en el train set entero de 240 frases).

2. Hipótesis (ordenadas)

  1. Outlier de token de cola larga. Un token raro (tten) apareció en 3 frases de un único batch (concentración probabilística). Su embedding no se ha actualizado suficientes veces para estar bien calibrado; la cross-entropy en este token es enorme, produciendo un gradiente gigante en su fila de embedding. Apoyado por: spike en el panel de norma de gradiente + log de composición del batch.
  2. Numérico (redondeo fp32). Improbable en fp32 — el redondeo se acumula a lo largo de muchos pasos, no en un único paso. Sería más plausible en fp16.
  3. Bug del schedule del LR. Posible pero improbable; el panel del LR muestra una cosenoidal suave, sin salto. Se autodescarta.
  4. Bug del data-loader (mismo batch repetido). Comprobación: hash del batch 312 ≠ hash del batch 311 ≠ 313. Se autodescarta.

3. Evidencia discriminadora

  • Panel 3 (norma de gradiente pre-clip): 47.2 en el paso 312, baseline 0.6. Decisivo para H1 (cola larga).
  • Panel 4 (activaciones): la activación del embedding de la capa 0 en el paso 312 es ~3.2× el baseline (porque la fila de embedding del raro token tten está siendo ponderada en tres secuencias del batch). Confirma H1.
  • Panel 7 (histograma de pérdida por token): el histograma de pérdida en el paso 312 tiene una cola derecha pesada con moda en ~12.0 (log-prob negativa de tten dado el contexto). La masa en esta moda está concentrada en 3 frases. Confirma H1.
  • Panel 2 (LR): cosenoidal suave, sin salto. Descarta H3.

4. Causa raíz

Un único batch contenía un token BPE raro sobrerrepresentado (tten) cuyo gradiente de embedding dominó la norma global del gradiente, superó el umbral de clip por 47×, y empujó las estimaciones de momentos del optimizador a una región de la que tardó ~50 pasos en recuperarse.

5. Remediación

Dos cambios complementarios:

  1. Reducir el umbral grad-clip de 1.0 a 0.5. Esto limita el daño por paso de cualquier batch futuro de cola larga. La norma rolling pre-clip es 0.6, así que 0.5 enganchará el clipping en el suelo de ruido del 10% inferior — coste aceptable.
  2. Batching estratificado — scripts/build_loader.py debe asegurar que ningún batch contenga más de 1 ocurrencia de cualquier token BPE raro (set: tokens con \(<10\) ocurrencias en train). Esto es barato: O(N log N) para ordenar y rebalancear.

Una tercera opción, no tomada: re-tokenizar para que written se convierta en un único token. Esto escondería el problema de cola larga, no lo resolvería — la Fase 27 lo revisitará a escala.

6. Verificación

Re-ejecutar con seed 42, esperar curva de pérdida dentro de \(\pm 0.05\) del baseline pre-spike hasta el paso 500. Específicamente:

  • pérdida en el paso 312: \(< 2.5\) (bajada desde 5.84 en la ejecución rota)
  • norma máxima de gradiente en la ventana [300, 400]: \(< 3.0\)
  • norma máxima de gradiente clipeada: \(\leq 0.5\) (el nuevo umbral)

7. Lección

Un único token raro sobrerrepresentado en un batch puede dominar la norma global del gradiente y desestabilizar el optimizador durante 50+ pasos; el batching estratificado + un umbral de clip más bajo previene la recurrencia.

Por qué importa el formato de la plantilla

La disciplina de escribir los síntomas como solo números antes de listar hipótesis evita que "creo que el LR está demasiado alto" contamine el diagnóstico antes incluso de leer los datos. La disciplina de ordenar las hipótesis (no solo listarlas) te obliga a comprometerte con una causa más probable antes de testar. La disciplina de causa raíz en una sola frase te obliga a saber qué arreglaste.

La mayoría de las spikes de pérdida siguen uno de cuatro patrones:

  1. Spike de token de cola larga (este ejemplo): un token BPE raro concentrado en un batch.
  2. Overflow fp16: bf16/fp16 sin loss scaling, una magnitud de activación supera 65504. Ver stability-check.md §3.
  3. Discontinuidad en el schedule del LR: el warmup acaba de repente, o un restart está mal alineado.
  4. Reset del optimizador: se recargó un checkpoint a mitad de ejecución sin restaurar el estado m, v, así que los primeros ~10 pasos tras el reload tienen momentos sin calibrar.

El patrón 1 es el más-probable en §A13. El patrón 2 solo aparece en el laboratorio de precisión mixta de la Fase 19. Los patrones 3 y 4 son fáciles de detectar una vez sabes mirar al LR y a los paneles de estado de momentos, respectivamente.

Cuándo la plantilla es más difícil de rellenar

Spikes que no se recuperan (loss → NaN, se queda en NaN). Para estas:

  • La sección de síntomas (§1) termina con "did not recover" y la pérdida de recuperación es "NaN".
  • La sección de hipótesis debe incluir "un update destructivo escribió un NaN en un parámetro que se propaga para siempre". Comprueba hasheando el estado de parámetros en cada paso e identificando el primer paso donde el hash cambia "violentamente".
  • La remediación debe incluir revertir al checkpoint sin NaN más reciente, lo cual asume que estabas checkpointing cada \(K\) pasos. Si no, reinicia desde cero con un LR menor.

Este es el modo de fallo que aborda stability-check.md §4.

Cita

Chowdhery, A. et al. (2022). PaLM: Scaling Language Modeling with Pathways. La sección 5.1 ("Training instability") documenta el patrón de spike de cola larga a escala PaLM y las mitigaciones que usó el equipo de Google: misma forma, números mucho mayores. Leer la sección 5.1 después de esta plantilla da la visión entre escalas.

Resumen en un párrafo

Un post-mortem de spike de pérdida es un documento estructurado: síntomas numéricos, hipótesis ordenadas, evidencia discriminadora por panel, causa raíz en una frase, remediación con cambio mínimo, test verificable, lección en una línea. Recorrer la plantilla fuerza el diagnóstico desde la observación hasta la acción sin saltarse el paso de "qué evidencia descarta qué alternativa", que la mayoría de la depuración ad-hoc se salta. Para el tutor de gramática §A13, la causa más común es un token BPE raro sobrerrepresentado en un batch; la remediación es batching estratificado + umbral de clip más ajustado; la lección va al cuaderno del aprendiz para la próxima vez.

Referencias cruzadas: theory/03-three-failure-modes.md (los tres breaks diseñados de los que vienen las firmas del dashboard), stability-check.md (el árbol de decisión ejecutable al que alimenta esta plantilla), Fase 18 theory/02-optimizer-and-schedule.md (el estado del optimizador en el que viven los momentos).