Blog · 12

¿Adónde van las GPU-horas? Un simulador de goodputWhere do the GPU-hours go? A goodput simulator

Un entrenamiento de 1.024 GPU simulado con fallos, para ver cuánto valen los checkpoints, los spares y la detección rápida.A 1,024-GPU training job, simulated with failures, to see what checkpoints, spares and fast detection are worth.

Por qué este laboratorio

Se apoya en la gestión de disponibilidad y capacidad y en las revisiones post-incidente. En un entrenamiento grande los fallos son normales; lo que importa es cuánto trabajo útil sobrevive a ellos, y este laboratorio le pone números.

Qué he hecho

  • Un simulador de eventos discretos de un trabajo de 1.024 GPU (128 nodos) con spares, causas de fallo con su propio tiempo de detección y reparaciones.
  • Un analizador que lee un log de eventos JSONL y reparte cada GPU-hora en productivo, checkpoint, trabajo perdido, detección, espera de nodos y reinicio, cargando el coste a cada causa.
  • MTBI y MTBF por nodo, las fórmulas de Young y Daly para el intervalo de checkpoint, un SLO de goodput con presupuesto de error y un informe HTML con gráficos SVG.

Lo que dicen los números

Siete escenarios con 20 semillas cada uno: base 79,6 %, intervalo de Daly 85,1 %, checkpoints asíncronos 91,7 %, sin spares 36,1 %, regresión de firmware 73,5 % y todo combinado 94,0 %. Los supuestos están entre dos referencias públicas: las interrupciones de Llama 3 y el paper de Meta sobre fiabilidad de clústeres.

Cómo se prueba

34 tests unitarios en Python 3.11 a 3.13 y un job de CI que regenera docs/results.md y falla si cambia.

Siguientes pasos

  • Exportar los eventos de tus trabajos en el formato JSONL documentado para ver adónde van tus GPU-horas.
  • Usar las fórmulas de Young y Daly para ajustar el intervalo de checkpoints.
  • Seguir el goodput como un SLO con presupuesto de error.

¿Quieres llevarlo a tu entorno o adaptarlo a tu caso? Escríbeme y lo vemos.

Why this lab

Builds on availability and capacity management and on post-incident reviews. In a large training job failures are normal; what matters is how much useful work survives them, and this lab puts numbers on it.

What I built

  • A discrete-event simulator of a 1,024-GPU job (128 nodes) with spares, failure causes with their own detection time, and repairs.
  • An analyser that reads a JSONL event log and splits every GPU-hour into productive, checkpoint, lost work, detection, waiting for nodes and restart, charging the cost to each cause.
  • MTBI and per-node MTBF, the Young and Daly formulas for checkpoint intervals, a goodput SLO with an error budget and an HTML report with SVG charts.

What the numbers say

Seven scenarios, 20 seeds each: baseline 79.6 %, Daly's interval 85.1 %, asynchronous checkpoints 91.7 %, no spares 36.1 %, a firmware regression 73.5 %, and everything combined 94.0 %. The assumptions sit between two public references, Llama 3's interruption count and Meta's paper on cluster reliability.

How it is tested

34 unit tests on Python 3.11 to 3.13, and a CI job that regenerates docs/results.md and fails if it changes.

Next steps

  • Export your own job events in the documented JSONL format to see where your GPU-hours go.
  • Use the Young and Daly formulas to tune the checkpoint interval.
  • Track goodput as an SLO with an error budget.

Want to bring it to your environment or adapt it to your case? Get in touch and we can look at it together.

Tech Career Lab · newsletter

¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.

Apúntate y llévate las 33 ideasSign up and get the 33 ideas →