D1 Stabilität über heterogene Rechenleistung hinweg
Hardwareausfälle, Netzwerk-Jitter und Teilausfälle werden abgefangen, ohne von vorn zu beginnen.
Resilientes Training über verteilte Cluster
Techniken zur Stabilisierung von Frontier-Training, wenn Rechenleistung, Daten und Teams auf mehrere Kontinente verteilt sind.
Stabilität, Reproduzierbarkeit und Wiederherstellung sind Eigenschaften des Trainingslaufs. Wir konstruieren für sie, nicht um sie herum.
Ausfälle abfangen deterministische Daten reproduzierbare Wiederherstellung
Warum auch Training Forschung ist
Frontier-Training ist ein Systemproblem mit einem Forschungsbudget
Stabilität, Reproduzierbarkeit und Wiederherstellung sind Eigenschaften eines Trainingslaufs. Sie als Systemprobleme statt als technische Pflichtaufgaben zu behandeln, macht den Unterschied zwischen einem fertigen Modell und einem halbfertigen aus. Unsere Arbeit am verteilten Training wird dort veröffentlicht, wo sie nicht differenzierend ist, damit kleinere Labore auf demselben Fundament aufbauen können.
Drei Eigenschaften, für die wir konstruieren
Was „resilient“ in der Praxis bedeutet
D2 Deterministische Daten
Versionierte Datensätze, deterministisches Laden und Checkpoints, die sowohl die Gewichte als auch den Trainingskontext erfassen, der sie hervorgebracht hat.
D3 Reproduzierbare Wiederherstellung
Die Wiederherstellung aus einem Checkpoint reproduziert unter denselben Bedingungen dieselbe Trajektorie.
Multiregionaler Cluster
Rechenleistung, Daten und Teams erstrecken sich über Kontinente.
Ein laufender Trainingslauf hält über vier Regionen und ~46 Knoten hinweg. Die Laufzeitumgebung behandelt Teilausfälle als ein Problem der Neuplanung, nicht als ein Neustart-Ereignis.
46 Knoten insgesamt
4 Regionen
1 Live-Ausfall abgefangen
0 Neustarts
Was die Laufzeitumgebung abfängt
Vier Klassen von Ausfällen, von denen keine den Trainingslauf neu startet.
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 eines Checkpoints
Gewichte allein genügen nicht.
Ein Checkpoint erfasst die Gewichte und den Kontext, der sie hervorgebracht hat. Ohne diesen Kontext ist ein Neustart bloß eine Vermutung.
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
alle sieben Felder gemeinsam geschrieben · gemeinsam geladen
Offene Infrastruktur
Wo die Arbeit nicht differenzierend ist, tragen wir sie zu Upstream-Projekten bei.
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
Arbeit an offener Infrastruktur
Die nicht differenzierenden Teile dieses Stacks tragen wir zu Upstream-Open-Source-Projekten bei. Die differenzierenden Teile bleiben im Haus.