D1 Stabilité sur du calcul hétérogène
Les pannes matérielles, la gigue réseau et les défaillances partielles sont absorbées sans repartir de zéro.
Entraînement résilient sur des clusters distribués
Techniques pour maintenir la stabilité de l'entraînement frontier lorsque le calcul, les données et les équipes sont répartis sur plusieurs continents.
La stabilité, la reproductibilité et la reprise sont des propriétés de l’exécution. Nous les concevons de front, et non en les contournant.
absorber les pannes données déterministes reprise reproductible
Pourquoi l’entraînement est aussi de la recherche
L’entraînement frontier est un problème de systèmes, doté d’un budget de recherche
La stabilité, la reproductibilité et la reprise sont des propriétés d’une exécution d’entraînement. Les traiter comme des problèmes de systèmes plutôt que comme des corvées d’ingénierie fait toute la différence entre un modèle abouti et un modèle laissé à moitié. Nos travaux sur l’entraînement distribué sont publiés là où ils ne sont pas différenciants, afin que des laboratoires plus modestes puissent bâtir sur la même fondation.
Trois propriétés que nous concevons de front
Ce que « résilient » signifie en pratique
D2 Données déterministes
Des jeux de données versionnés, un chargement déterministe et des points de contrôle qui capturent à la fois les poids et le contexte d’entraînement qui les a produits.
D3 Reprise reproductible
Restaurer depuis un point de contrôle reproduit la même trajectoire dans les mêmes conditions.
Cluster multi-région
Le calcul, les données et les équipes s’étendent sur plusieurs continents.
Une exécution en cours tient sur quatre régions et ~46 nœuds. Le runtime traite la défaillance partielle comme un problème de re-planification, et non comme un événement de redémarrage.
46 nœuds au total
4 régions
1 panne absorbée en direct
0 redémarrages
Ce que le runtime absorbe
Quatre classes de défaillance, dont aucune ne redémarre l’exécution.
01
hardware fault
GPU SXM link drop
replicate · resume · continue
no restart 02
network jitter
cross-region latency spike
gradient backpressure · scheduler reslot
no restart 03
partial cluster loss
EU-west rack power event
shard reweight · 2 region failover
no restart 04
data shard skew
one shard yields NaN
shard quarantine · resample
no restart Anatomie d’un point de contrôle
Les poids ne suffisent pas.
Un point de contrôle capture les poids et le contexte qui les a produits. Sans ce contexte, un redémarrage relève de la conjecture.
weights tensor 1.2 TB
optimizer state tensor 480 GB
rng seeds context 48 KB
data offset context 8 KB
config hash context 64 B
cluster topology context 12 KB
commit sha provenance 40 B
les sept champs écrits ensemble · chargés ensemble
Infrastructure ouverte
Là où le travail n’est pas différenciant, nous le contribuons en amont.
01 fault-tolerant scheduler upstream contributed to ray + nccl ecosystems
02 deterministic data loader upstream sharded streaming · pinned offsets
03 checkpoint format + context upstream spec + reference reader
04 gradient-aware re-slotting internal differentiating · in-house
05 cross-region training runbook internal differentiating · in-house
Travaux d’infrastructure ouverte
Nous contribuons les parties de cette stack qui ne sont pas différenciantes à des projets open-source en amont. Les parties différenciantes restent en interne.