CapordiaDelimitar lo que migra y lo que debe esperar
Esta guía se dirige a la persona que coordina el cálculo, los datos y la explotación. Aquí, un lote designa un paquete de trabajo identificado, distinto de un lote de tarjetas GPU del catálogo. El método conviene en primer lugar a las salidas que pueden controlarse antes de su aceptación. Para un servicio que recibe solicitudes sin interrupción, prevé dónde esperarán las nuevas entradas, cuánto tiempo es aceptable esa espera y cómo se incorporarán al objetivo. Un dossier copiado no define por sí solo esa política de admisión.
El ejercicio propuesto trabaja sobre un conjunto cerrado de ocho lotes sintéticos. No envía ninguna solicitud de red ni utiliza GPU ni cuentas de Capordia. Enseña una lógica de reanudación en un solo equipo y un solo proceso de trabajo. No valida una cola distribuida, la continuidad de un servicio expuesto ni el traslado en caliente de un cálculo. Antes de una migración real, tu equipo debe cualificar estos elementos con la aplicación y el hardware elegidos.
Constituir un inventario que permita reconstruir
Reúne el código y su versión, las dependencias, los parámetros, los modelos, las entradas, las tareas programadas y los destinos de salida. Para cada uno, indica el propietario, el método de reconstrucción y el control esperado en el objetivo. Anota el nombre de los secretos y su modo de suministro, sin colocar su valor en el registro compartido. Una instalación manual o una tarea activada al arrancar puede faltar en una simple copia del directorio del proyecto.
Separa los archivos de entrada, los resultados aceptados y el estado necesario para el reinicio. En un entrenamiento, este estado puede superar los pesos del modelo: el tutorial de PyTorch sobre cómo guardar un checkpoint de forma general incluye, en particular, el estado del optimizador y el avance. El contenido requerido depende de tu código. Restáuralo en un proceso nuevo y compara después las salidas según una tolerancia decidida antes de la prueba; no deduzcas una identidad numérica universal de un único reinicio correcto.
Asignar la decisión, la transferencia y la aceptación
Designa los roles antes de fijar la ventana. Una misma persona puede desempeñar varios en un equipo pequeño, pero las decisiones siguen siendo distintas. El responsable de conmutación confirma la parada del productor antiguo y autoriza el arranque del destino. El responsable de datos controla el inventario, las huellas y las salidas. El propietario del proceso juzga la calidad funcional. La explotación conserva el registro de cambios y prepara el traspaso.
La ficha de conmutación debe responder a cuatro preguntas concretas: quién puede detener las entradas, quién constata que el proceso antiguo ya no publica, quién acepta los primeros resultados y quién decide la vuelta atrás. Anota también una hora límite de decisión y los medios para contactar con esas personas. «Volver si es necesario» no basta cuando el destino ya ha producido resultados que el registro antiguo no conoce.
Llevar un registro que distinga iniciado y aceptado
Asigna un identificador estable a cada lote y relaciónalo con una versión precisa de los datos. Conserva su estado, el número de intentos, la ubicación del resultado y el control que autoriza su aceptación. Un lote en curso no está terminado porque exista un archivo de salida: ese archivo puede ser parcial o proceder de un intento anterior. El procedimiento debe explicitar qué se conservará, qué se recalculará y qué quedará en cuarentena para su examen.
En el ejercicio, un registro SQLite local mantiene juntos el estado y la aceptación del resultado en una transacción. Sus estados son termine, en_cours y a_reprendre; este último cubre también un lote que aún no ha empezado. El destino retoma los lotes no validados en lugar de relanzar indistintamente las ocho entradas. Las exportaciones JSON y CSV hacen legible el seguimiento. El CSV en blanco acompaña tu preparación y tu revisión humana; no sustituye al mecanismo de coordinación de una aplicación real.
| Lotes | Estado en la frontera | Decisión antes de la reanudación |
|---|---|---|
| LOT-001 a LOT-003 | termine | Conservar los resultados y verificar su integridad |
| LOT-004 | en_cours, resultado no aceptado | Preparar explícitamente un nuevo intento |
| LOT-005 a LOT-008 | a_reprendre, ningún intento | Lanzar en el destino tras la autorización |
Descargar y ejecutar el ejercicio de corte y reanudación
Prevé Python 3.10 o posterior con el módulo sqlite3, y un directorio local accesible en escritura. Descarga el archivo completo y extráelo conservando juntos el script, la carpeta de datos y el manifiesto. El archivo README detalla los comandos disponibles. No hay que instalar ningún controlador, paquete de cálculo ni modelo. Lee el script antes de ejecutarlo y usa luego una carpeta de salida nueva para que las pruebas de varios intentos no se mezclen.
Desde el directorio que contiene exercice.py, el comando de abajo produce una referencia continua, un proceso interrumpido, una copia de conmutación y una reanudación comparada con la referencia. Los ocho archivos CSV contienen 48 mediciones dimensionales ficticias de cupones, expresadas en micrómetros enteros y creadas para este expediente. No se representa ningún control industrial real. El cálculo en CPU sirve para examinar la gestión de los lotes, no para estimar un rendimiento de GPU o una duración de migración de tus datos.
python exercice.py demonstration --dossier essai-capordiaLeer las pruebas de la reanudación, lote por lote
Ejemplo Capordia: un equipo prepara ocho paquetes de archivos para procesar. La referencia los procesa sin interrupción. En el otro recorrido, la parada deja tres lotes terminados, LOT-004 en curso y cuatro lotes por retomar sin intento. El responsable de conmutación no pide «retomar hacia la mitad»: designa LOT-004. La preparación de reanudación lo devuelve al estado a_reprendre: tres lotes quedan entonces terminados y cinco por ejecutar. Los lotes ya aceptados no deben recalcularse.
Consulta etat.json para los identificadores, estados y reintentos, registre-lots.csv para la revisión, resultats.json para las salidas y, por último, rapport-verification.json para los controles. En la ejecución local del 24 de septiembre de 2026 bajo Windows AMD64, Python 3.14.6 y SQLite 3.50.4, los 16 controles derivados de 37 lanzamientos del script pasaron: los ocho resultados reanudados coinciden con la referencia, los lotes terminados no se recalculan y se rechaza una nueva aceptación del mismo lote. También se detectan las entradas alteradas, los identificadores duplicados y las salidas corruptas.
Copiar un estado coherente y luego controlar su integridad
En una conmutación real, detén la admisión o coloca las nuevas entradas en una cola prevista explícitamente. Espera a que termine el trabajo en curso o registra los lotes interrumpidos según tu regla de reanudación. Confirma después que la instancia antigua ya no puede publicar. El sellado de la fuente en este ejercicio impide que el script la reutilice como productor. Sigue siendo una protección local del escenario, no una exclusión mutua entre varias máquinas que poseyeran cada una una copia del estado.
Para copiar una base SQLite utilizada por una aplicación, su documentación propone una API de respaldo que produce una instantánea coherente. Por tanto, una copia ordinaria de un archivo de base en curso de escritura no es un procedimiento que se deba improvisar. Verifica también el manifiesto de los archivos transferidos. Las huellas SHA-256, disponibles en hashlib, ayudan aquí a detectar una diferencia de contenido; no indican si el resultado es correcto para tu negocio, ni si el manifiesto de referencia es digno de confianza.
Decidir cuándo reanudar y cuándo volver
Autoriza el destino solo cuando las entradas, el registro y los resultados conservados concuerden, el productor anterior esté detenido y se cumplan los requisitos de software. Lanza primero un ámbito cuyas salidas puedan revisarse. El propietario del procesamiento acepta la calidad; el responsable de los datos verifica los identificadores, los faltantes y los duplicados. Un arranque sin errores no basta si el resultado útil está incompleto.
Si el defecto aparece antes de cualquier nueva publicación, mantén el destino detenido y vuelve a partir del estado de origen controlado según el procedimiento previsto. Tras una publicación, preserva primero los resultados y el registro del destino. Concilia los lotes que este haya completado con los del origen y, después, elige una sola reanudación autorizada. Reactivar ambos lados para ganar tiempo puede crear precisamente los duplicados que la migración debía evitar.
| Observación | Decisión inmediata | Condición para continuar |
|---|---|---|
| Entrada ausente o huella distinta | Suspender la transferencia y aislar la copia | Recuperar una entrada conforme al manifiesto de referencia |
| Identificador duplicado o salida inesperada | No publicar el lote afectado | Entender el conflicto y retener una sola versión aceptada |
| Estado de reanudación inutilizable | Detener el destino y conservar las pruebas | Restaurar un estado conocido o aplicar el retorno preparado |
| Resultado fuera del criterio de negocio | Detener la ampliación de la recuperación | Corregir y volver a hacer la validación funcional |
| Hora límite de decisión alcanzada | Activar la decisión de retorno o de aplazamiento | Acuerdo explícito del responsable y capacidad de terminar la exportación |
Medir toda la ventana y preparar el traspaso
Repite la instalación, la copia, la verificación, la recuperación y la exportación en su orden real. Anota el tiempo de cada fase y las intervenciones humanas, con una muestra cuyo traslado esté autorizado. Para estimar tu ventana, ten en cuenta las nuevas entradas que esperarán y la capacidad de absorber ese retraso. El mejor tiempo observado en una carpeta pequeña no es un compromiso para un volumen mayor.
El periodo elegido debe cubrir preparación, ensayo, conmutación, observación y recuperación de los resultados. Los planes de Capordia de 3, 7 o 30 días siguen siendo periodos que hay que organizar; esta guía no deduce de ellos ningún tiempo de cálculo. Antes del cierre, una segunda persona debe localizar el registro, abrir las salidas desde su destino y saber relanzar el procesamiento. Archiva la decisión de fin del repliegue, las desviaciones aceptadas y las acciones pendientes antes de retirar los accesos que ya no sean necesarios.
Qué comprueba el ejercicio y qué queda por calificar
La aportación de este expediente es un procedimiento legible y una experiencia reproducible de reanudación sobre archivos sintéticos. El mismo lote debe ser identificable antes de la parada, durante la conmutación y después de la reanudación. El registro, la comparación con una referencia y los rechazos provocados hacen observable esta regla. La interrupción se activa mediante una excepción controlada en el script: no se ha realizado ningún ensayo de fallo eléctrico. La documentación técnica citada explica los mecanismos empleados; no certifica tu futuro entorno de producción.
En el escenario trabaja un solo proceso a la vez. El sellado local no es un bloqueo distribuido; una huella no es una prueba de calidad; un resultado de CPU no es una validación de CUDA, ROCm o multi-GPU. Una aplicación que también escribe en una base de datos externa, un almacenamiento compartido o una cola necesita una regla coherente en todos esos destinos. Haz que validen esta regla y tu plan de retorno antes de migrar el procesamiento real.
Para preparar lo que viene
Una copia de seguridad debe permitir retomar el trabajo.
Restaurar en un destino aislado y verificar que la copia permite realmente reanudar.
Pasar el relevo con un estado, una acción y un responsable.
Transmitir las acciones, los límites y las responsabilidades a otra persona.