D1 Estabilidad en cómputo heterogéneo
Los fallos de hardware, la fluctuación de red y los fallos parciales se absorben sin reiniciar desde cero.
Entrenamiento resiliente en clústeres distribuidos
Técnicas para mantener el entrenamiento de frontera estable cuando el cómputo, los datos y los equipos abarcan varios continentes.
La estabilidad, la reproducibilidad y la recuperación son propiedades de la ejecución. Diseñamos para ellas, no a su alrededor.
absorber fallos datos deterministas recuperación reproducible
Por qué el entrenamiento también es investigación
El entrenamiento de frontera es un problema de sistemas con un presupuesto de investigación
La estabilidad, la reproducibilidad y la recuperación son propiedades de una ejecución de entrenamiento. Tratarlas como problemas de sistemas en lugar de tareas rutinarias de ingeniería marca la diferencia entre un modelo terminado y uno a medio terminar. Nuestro trabajo de entrenamiento distribuido se publica donde no es diferenciador, para que los laboratorios más pequeños puedan construir sobre la misma base.
Tres propiedades para las que diseñamos
Qué significa «resiliente» en la práctica
D2 Datos deterministas
Conjuntos de datos versionados, carga determinista y checkpoints que capturan tanto los pesos como el contexto de entrenamiento que los produjo.
D3 Recuperación reproducible
Restaurar desde un checkpoint reproduce la misma trayectoria bajo las mismas condiciones.
Clúster multirregión
El cómputo, los datos y los equipos abarcan continentes.
Una ejecución en vivo se mantiene a través de cuatro regiones y ~46 nodos. El runtime trata el fallo parcial como un problema de reprogramación, no como un evento de reinicio.
46 nodos totales
4 regiones
1 fallo en vivo absorbido
0 reinicios
Lo que el runtime absorbe
Cuatro clases de fallo, ninguna de las cuales reinicia la ejecución.
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 Anatomía del checkpoint
Los pesos no bastan.
Un checkpoint captura los pesos y el contexto que los produjo. Sin ese contexto, un reinicio es una conjetura.
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
los siete campos escritos juntos · cargados juntos
Infraestructura abierta
Donde el trabajo no es diferenciador, lo aportamos upstream.
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
Trabajo de infraestructura abierta
Aportamos las partes de este stack que no son diferenciadoras a proyectos de código abierto upstream. Las partes diferenciadoras se quedan en casa.