Lo que vas a ejecutar
El mini-proyecto de Kernodeck contiene un pequeño conjunto de datos sintéticos, una red con dropout, un bucle de entrenamiento y un verificador. El protocolo fuerza la CPU para aislar la lógica de guardado y reanudación. No constituye una cualificación CUDA, ROCm, multitarjeta ni una medición de rendimiento de una GPU alquilada.
El verificador abre procesos nuevos para el recorrido continuo, la interrupción, la reanudación completa y un caso negativo que no restaura los generadores aleatorios. El interés de este último es verificar que el control sabe detectar una reanudación incompleta, aunque los pesos y el número de paso parezcan correctos.
Desplaza la tabla para leer todas las columnas.| Recorrido | Ejecución | Pregunta verificada |
|---|---|---|
| Continuo | 10 actualizaciones desde el estado inicial. | ¿Qué estado se alcanza sin interrupción? |
| Interrupción | 5 actualizaciones, luego copia de seguridad y parada. | ¿El punto intermedio contiene los estados esperados? |
| Reanudación completa | Proceso nuevo, carga del punto 5 y luego 5 actualizaciones. | ¿Se obtiene la misma secuencia de entradas, tasas y parámetros dentro de la tolerancia elegida? |
| Reanudación sin RNG | Proceso nuevo, mismo punto de reanudación pero sin restaurar la aleatoriedad. | ¿Detecta la prueba una deriva que una simple carga de los pesos dejaría pasar? |
Requisitos y lanzamiento del protocolo
Descarga el archivo, extráelo en una carpeta de trabajo y colócate en la carpeta que contiene train.py y verify_resume.py. Usa un entorno Python que disponga de PyTorch y NumPy. El archivo contiene el código y los datos sintéticos; no descarga ningún modelo y no exige una cuenta de Kernodeck para ejecutar el ejercicio.
La prueba proporcionada se ejecutó con Python 3.14.6, PyTorch 2.11.0+cu128 y NumPy 2.4.4. El programa fuerza la CPU, la precisión float64 y un hilo de PyTorch. El sufijo del paquete no significa, por tanto, que la reanudación haya usado CUDA. En otro entorno, ejecuta tu propia verificación.
Elige un directorio de salida que aún no exista. Cada recorrido produce checkpoint.pt, su huella checkpoint.pt.sha256 y summary.json. El verificador reúne la comparación en verification.json. La opción --steps cuenta pasos adicionales: tras la interrupción en 5, el comando de reanudación ejecuta 5 para llegar a 10. La opción de Python -B evita las cachés de bytecode en la carpeta del ejercicio.
python -B verify_resume.py --output runs/preuve-cpupython -B train.py --steps 10 --output runs/continu
python -B train.py --steps 5 --output runs/coupure
python -B train.py --steps 5 --resume runs/coupure/checkpoint.pt --output runs/repriseLa exportación de pesos y el checkpoint de reanudación no tienen el mismo papel
Empieza por elegir qué quieres recuperar. Una exportación para la inferencia sirve para producir predicciones con un modelo entrenado. Una reanudación de entrenamiento debe recuperar también el estado que determina las próximas actualizaciones. Un procesamiento de inferencia por archivos exige, por su parte, una lista fiable de los elementos ya terminados. Estas tres necesidades producen copias de seguridad diferentes.
No confundas esta copia de seguridad persistente con el activation checkpointing. Esta técnica reduce ciertas activaciones guardadas en memoria recalculándolas durante la retropropagación; por sí sola, no crea un archivo que permita reanudar tras una parada. Por lo tanto, precisa en tu proyecto si la palabra checkpoint designa una optimización de memoria o un punto de reanudación.
Los estados que deben mantenerse juntos
El state_dict del modelo contiene los parámetros y los buffers registrados; el optimizador tiene su propio estado. Aquí, Adam, StepLR, el dropout y tres generadores aleatorios influyen en las próximas actualizaciones. El checkpoint debe representar el mismo instante para todos estos elementos.
Documenta también la versión del código, los parámetros del experimento y la identidad de los datos. En mitad de una época, conocer solo su número no es suficiente: hay que poder recuperar el orden de los ejemplos y el próximo grupo por consumir. Un error en este punto puede saltarse entradas o procesarlas dos veces.
El conjunto de 24 filas describe una relación sintética entre dos variables y un objetivo. La red cuenta con 33 parámetros, con una capa de ocho neuronas y un dropout de 0,25. El batch contiene cuatro filas. Tras cinco actualizaciones, el cursor vale 20 sobre 24: el corte se sitúa en mitad de una época. Las diez actualizaciones consumen 40 observaciones, lo que obliga al control a atravesar una nueva permutación de los datos.
Desplaza la tabla para leer todas las columnas.| Estado | Rol | Comprobación a realizar |
|---|---|---|
| Modelo | Conservar pesos y buffers. | Comparar los parámetros finales y una salida de evaluación. |
| Optimizador | Conservar los estados utilizados por la próxima actualización. | Verificar su recarga, no solo sus hiperparámetros. |
| Scheduler | Continuar la secuencia de tasas de aprendizaje. | Comparar la próxima tasa aplicada y luego las tasas siguientes. |
| RNG de Python, NumPy y PyTorch | Continuar los sorteos efectivamente utilizados. | Verificar que el ejercicio negativo sin restauración diverge. |
| Datos | Reanudar la permutación y el cursor. | Comparar los identificadores de entradas tras el corte. |
| Progreso | Interpretar los pasos y las épocas. | Llegar a 10 actualizaciones en total, sin rehacer ninguna ni omitir ninguna. |
| Configuración | Reconstruir el mismo experimento. | Conservar dimensiones, precisión, ajustes y versiones. |
Restaurar en el orden correcto
Reconstruye el modelo, el optimizador y el scheduler antes de cargar sus estados. El scheduler debe crearse antes de optimizer.load_state_dict(): de lo contrario, su construcción puede sobrescribir las tasas de aprendizaje restauradas. Recarga también su propio estado y, después, verifica la tasa realmente utilizada en el paso siguiente.
Restaura los generadores aleatorios después de construir los objetos que consumen sorteos, justo antes de continuar el trabajo. Volver a poner simplemente la semilla inicial haría que la secuencia empezara de nuevo; eso no es recuperar el estado alcanzado tras la quinta actualización. En tu proyecto, localiza todos los generadores utilizados, incluidos los de las transformaciones y de la carga de datos.
En este ejercicio, Python ajusta una ligera ganancia sobre las entradas, un generador NumPy PCG64 produce ruido y las permutaciones, y PyTorch produce el dropout. El checkpoint conserva sus estados alcanzados en el corte. El verificador observa también sus próximos sorteos, restaurando inmediatamente el estado para no perturbar el resto del cálculo.
optimizer = torch.optim.Adam(model.parameters(), lr=0.03)
scheduler = torch.optim.lr_scheduler.StepLR(optimizer, step_size=3, gamma=0.5)
# En el recorrido de reanudación, tras la construcción de los objetos:
state = load_checkpoint(resume)
model.load_state_dict(state["model"])
scheduler.load_state_dict(state["scheduler"])
optimizer.load_state_dict(state["optimizer"])
progress = state["progress"]
history = state["history"]
restore_rng(state["rng"], generator)
model.train()Elegir una frontera de guardado coherente
Fija una frontera explícita, por ejemplo tras una actualización completa del optimizador. Si acumulas varios microbatchs antes de esa actualización, guardar en mitad obliga a gestionar también el estado intermedio. Una primera implementación es más fácil de verificar cuando guarda en una frontera donde los gradientes acumulados ya se han consumido.
Conserva varias generaciones de copia de seguridad. Escribe el nuevo archivo con un nombre distinto, espera a que termine la escritura, verifica que sea legible y luego márcalo como utilizable. No reemplaces tu único checkpoint válido antes de esta comprobación. La frecuencia depende del trabajo que aceptes rehacer y del tiempo de escritura observado; no se deduce solo de la duración del alquiler.
El miniproyecto guarda tras finalizar una iteración, luego exporta el archivo y su huella. Usa una carpeta nueva para cada recorrido y no reemplaza una prueba anterior. Si tu entrenamiento emplea precisión mixta con un GradScaler, su estado también forma parte de la reanudación. Esta variante no está cubierta por el ejercicio de CPU.
Leer la comparación y su tolerancia
El protocolo compara la continuación después del punto 5: datos consumidos, tasa de aprendizaje, pérdidas y parámetros alcanzados. Que coincida solo el número de paso no es suficiente. Un optimizador reinicializado puede continuar el bucle mientras produce actualizaciones diferentes.
La tolerancia elegida para este ejercicio es absoluta: 1e-12, con una tolerancia relativa de 0. Este umbral forma parte del protocolo de CPU proporcionado; no constituye una regla universal para tus modelos. La comparación debe señalar valores no finitos y las diferencias de estructura, en lugar de aceptar silenciosamente una salida inutilizable.
PyTorch no garantiza una identidad de los resultados entre versiones, plataformas, CPU y GPU. Si portas el ejercicio, vuelve a hacer la prueba en el destino y explica la tolerancia adoptada. No amplíes el umbral solo para hacer desaparecer un fallo cuya causa no has entendido.
En la prueba proporcionada, todas las diferencias del recorrido completo valen cero: parámetros, estado del optimizador, pérdidas, tasas y MSE. El orden de las líneas, la progresión, el estado del scheduler y los siguientes sorteos también coinciden. La siguiente tasa de aprendizaje tras el paso 10 vale 0,00375 en ambos recorridos. El resultado no depende, por tanto, solo de una métrica final que podría ocultar diferencias intermedias.
Desplaza la tabla para leer todas las columnas.| Comparación | Reanudación completa | Reanudación sin restauración de RNG |
|---|---|---|
| Diferencia máxima de los pesos | 0 | 0,011669328447718508 |
| MSE final | 0,09538858591775097 | 0,0936034144665111 |
| Diferencia de MSE respecto al recorrido continuo | 0 | 0,001785171451239867 |
| Veredicto del subtest de concordancia | Concordante dentro de la tolerancia de 1e-12 | Divergencia detectada |
Por qué conservar el caso negativo sin aleatoriedad restaurada
Un control es más útil cuando sabes qué error detecta. La variante negativa recarga los mismos pesos, estados de optimizador, scheduler y progresión, pero omite voluntariamente la restauración de RNG. El proceso puede terminar sin excepción de Python mientras sigue otra trayectoria.
En la prueba proporcionada, esta omisión produce una diferencia máxima de los pesos superior a 0,011 y una diferencia de MSE superior a 0,0017. La MSE negativa es aquí más baja que la del recorrido continuo: eso no hace que la reanudación sea correcta. El objetivo es recuperar la misma experiencia, no clasificar dos modelos por su error final.
El verificador tiene éxito solo cuando el recorrido completo concuerda y el caso negativo diverge. Entonces muestra all_checks_passed: true, positive: true y negative_divergence_detected: true. Su código de salida vale 0 si el protocolo tiene éxito, 1 si la comparación falla y 2 si la verificación no se pudo completar.
python -B train.py --steps 5 --resume runs/coupure/checkpoint.pt --omit-rng-restore --output runs/reprise-incompleteCargar el archivo del ejercicio sin relajar las protecciones
El proyecto carga únicamente el checkpoint que has creado con este ejercicio y conservado bajo tu control. Usa explícitamente torch.load(..., map_location="cpu", weights_only=True). El estado de Python contiene primitivas, el del generador NumPy PCG64 enteros y cadenas, y el de PyTorch CPU un tensor de bytes. No se coloca ningún array NumPy arbitrario en el estado RNG guardado.
El cargador verifica la huella asociada, el tamaño, el esquema, la progresión, las versiones y la identidad del código y de los datos. Rechaza un estado incoherente en lugar de restablecer silenciosamente un elemento faltante. La huella detecta una modificación; no autentica al remitente de un archivo.
No añadas weights_only=False simplemente para silenciar un error de carga. El formato guardado y su reconstrucción deben ser coherentes. La carga restringida reduce las posibilidades de deserialización, pero no hace que un archivo desconocido sea digno de confianza.
Lo que cambia para un entrenamiento distribuido
Con varios procesos o estados repartidos entre GPU, verifica quién escribe qué. Un archivo producido por un solo proceso no es necesariamente una copia de seguridad completa del trabajo distribuido. Usa el procedimiento de guardado previsto por tu estrategia y espera a que finalice en los participantes correspondientes. Identifica claramente los fragmentos que pertenecen al mismo punto de reanudación.
Un cambio en el número de GPU puede requerir una redistribución de los estados y modificar el reparto de los datos. Los mecanismos de checkpoint distribuido pueden gestionar algunos cambios, pero esa posibilidad debe verificarse para tu formato y tu configuración. Haz una prueba de carga en el destino previsto. Añadir lotes al pedido no convierte automáticamente una copia de seguridad de una sola tarjeta en un programa distribuido.
Terminar con una exportación realmente recuperable
Antes del vencimiento, exporta los checkpoints útiles con su configuración, las métricas, las instrucciones de carga y los identificadores de los datos. Verifica el tamaño y una huella de los archivos copiados, y luego carga al menos una copia de seguridad desde su destino. Una huella idéntica controla la copia; la recarga verifica que el contenido realmente basta para reconstruir el trabajo.
Carga únicamente archivos cuya procedencia conozcas y elige un formato y opciones de deserialización adecuados. Conserva el último punto de reanudación validado hasta que el nuevo haya pasado tus controles. El resultado esperado es una carpeta recuperable y una breve prueba de reanudación: comando ejecutado, paso recuperado, control superado y resultado exportado. Prevé este tiempo en tus 3, 7 o 30 días.
Alcance de la prueba y elección del alquiler
La prueba del 24 de septiembre de 2026 compara cuatro procesos nuevos en CPU, con una tolerancia absoluta de 1e-12 y ninguna tolerancia relativa. No cubre CUDA, ROCm, AMP, entrenamiento distribuido ni workers de carga de datos. Valida la lógica de reanudación de la versión proporcionada, en el entorno descrito, y no mide las capacidades de una GPU alquilada.
Tras este pequeño ejercicio, traslada el mismo protocolo a tu modelo, tus datos y tu backend. Una tarjeta de 80 GB o una tarjeta de 192 GB no corrige un checkpoint incompleto: elige primero la cadena compatible y luego dimensiona la memoria de un paso real. Las ofertas enlazadas a continuación no se presentan como hardware probado para esta prueba.
Prevé en tu periodo de 3, 7 o 30 días un primer ciclo de guardado–detención–reanudación y el tiempo de exportación final. El resultado útil es una carpeta de la que puedas explicar las versiones, el punto de reanudación, el control comparativo y los límites; la sola existencia de un archivo .pt no da esa garantía.