En GPU dos corridas idénticas no dan los mismos pesos: el orden de reducción de
los kernels varía. Medido en la RTX 2060, dos corridas iguales de 20 pasos
difieren hasta 8,6e-4. Eso hacía imposible comprobar el criterio de aceptación
más importante del entrenamiento — que reanudar reproduzca la corrida — porque
cualquier diferencia se confundía con el ruido de la placa.
Con deterministic activado, la reanudación resulta exacta en los 47 parámetros:
el checkpoint captura todo el estado. Queda como opción del perfil y como una
config propia, en vez de un conjuro de shell que hay que recordar.
La opción rechaza convivir con la compilación, porque el autotune vuelve a
elegir kernels distintos entre corridas y reintroduce justo lo que se quería
eliminar. Está apagada en producción: cuesta rendimiento.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Comprometer uno o dos días de cómputo para descubrir en la hora tres que el
lote no entra en memoria, o que fp16 diverge, es el desperdicio más caro del
proyecto. Esto responde en minutos: construye el modelo y el optimizador como
lo haría el entrenamiento y los ejercita con lotes sintéticos del tamaño
configurado, así que no necesita que el corpus exista.
Mide el pico de VRAM reservada (no la asignada: es la reservada la que hace
fallar la asignación), el rendimiento real convertido a horas de reloj, y la
tasa de pasos que el GradScaler descarta por inf/NaN — la señal directa de que
fp16 está perdiendo actualizaciones.
Aparte: .vscode/ sale del repo (config de IDE por máquina) y smoke-2060 fija
run_name, que sin eso los comandos de logs y de descarga pedían nombres
distintos para la misma corrida.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Un patrón sin "/" inicial en .gitignore matchea cualquier directorio con ese
nombre en cualquier nivel. "data/" y "runs/" estaban excluyendo, además de lo
que se quería:
enlace/data/ los cargadores de datos (ByteStream, ShardStream)
configs/data/ corpus.yaml, smoke.yaml, distill.yaml
configs/runs/ todos los configs ejecutables
Es decir que el repo commiteado no contenía ni la capa de datos ni un solo
config con el que arrancar un entrenamiento. Como scripts/remote.sh sincroniza
por git push/pull, el servidor habría recibido un paquete que falla al
importar, y el síntoma habría aparecido recién allá.
Se anclan las cuatro rutas con "/" inicial y se documenta el porqué en el
propio archivo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
msaldain