1. Separar el programa, sus parámetros y el seguimiento comercial
El código describe el comportamiento del programa. La configuración precisa la carga: modelo, datos, batch, precisión y destino. Los secretos dan acceso a los recursos necesarios. Mantén estos elementos distintos para cambiar un ensayo sin reescribir el código ni copiar un token en un archivo compartido.
La referencia de pedido de Kernodeck permite recuperar el contexto del alquiler en tu cuenta. El identificador de ensayo distingue las ejecuciones de tu programa durante ese periodo. Asócialos en tus notas si te resulta útil, pero no pidas a tu script que deduzca el estado del cálculo a partir del estado del pago.
Tomemos un proyecto de clasificación de documentos que debe lanzarse varias veces sobre una misma muestra. El contrato del programa describe el archivo de entrada, los parámetros admitidos, la carpeta de salida y la forma de mostrar los errores. La guía sobre los datos precisa la validación del contenido; aquí organizamos la interfaz que conecta estas etapas.
2. Escribir un contrato de entrada explícito y versionado
Documenta los campos obligatorios y los valores aceptados. Evita los valores predeterminados silenciosos para una decisión que cambia el resultado, como el modelo o el dispositivo. Un número de esquema distingue la forma de la configuración de la versión del código; no sustituye a esta última.
En este ejemplo didáctico, el archivo JSON contiene un esquema, una ruta de entrada, un batch y el dispositivo solicitado. Las rutas relativas se leen desde la carpeta de configuración. Esta regla elegida para el ejemplo evita depender del directorio desde el que un colega lanza el comando.
Leer un JSON válido solo comprueba su sintaxis. Tu programa debe verificar después los tipos, los campos y las restricciones del proyecto. En caso de error, debe detenerse antes de cargar un recurso costoso, con un mensaje que nombre el parámetro que hay que corregir.
{
"schema_version": 1,
"input": "../data/pilote.jsonl",
"batch_size": 4,
"device": "cuda"
}3. Preparar un punto de entrada que rechace los errores simples
argparse permite declarar opciones y generar una ayuda para tu comando. El ejemplo siguiente constituye únicamente una precomprobación: lee la configuración, verifica sus campos y detecta una carpeta de salida ya utilizada. No carga ningún modelo ni datos en memoria y no comprueba la disponibilidad de la GPU.
Guarda este código didáctico en prepare_run.py si quieres adaptarlo. Se ofrece sin ejecución verificada. Añade después tus controles de negocio en la aplicación, en lugar de considerar el mensaje final como un resultado de cálculo. El dispositivo cuda sigue siendo una solicitud; PyTorch también usa este nombre con ROCm.
Rechazar un directorio de salida existente es aquí una convención de protección contra la mezcla de ensayos. Un verdadero comando de reanudación debe recibir una opción y controles distintos. No conviertas un lanzamiento nuevo en una reanudación implícita porque haya archivos presentes.
import argparse
import json
from pathlib import Path
parser = argparse.ArgumentParser(description="Validar un lanzamiento del proyecto")
parser.add_argument("--config", type=Path, required=True)
parser.add_argument("--run-dir", type=Path, required=True)
args = parser.parse_args()
try:
config_path = args.config.resolve()
config = json.loads(config_path.read_text(encoding="utf-8"))
except (OSError, UnicodeError, json.JSONDecodeError) as exc:
parser.error(f"Configuración ilegible: {exc}")
expected = {"schema_version", "input", "batch_size", "device"}
if not isinstance(config, dict) or set(config) != expected:
parser.error("Campos esperados: schema_version, input, batch_size, device")
if type(config["schema_version"]) is not int or config["schema_version"] != 1:
parser.error("schema_version debe valer 1")
if type(config["batch_size"]) is not int or config["batch_size"] < 1:
parser.error("batch_size debe ser un entero positivo")
if config["device"] not in ("cpu", "cuda"):
parser.error("device debe valer cpu o cuda")
if not isinstance(config["input"], str) or not config["input"]:
parser.error("input debe ser una ruta no vacía")
input_path = (config_path.parent / config["input"]).resolve()
run_dir = args.run_dir.resolve()
if not input_path.is_file():
parser.error("Falta el archivo de entrada")
if run_dir.exists():
parser.error("Elige una nueva carpeta de salida")
print(json.dumps({
"status": "configuration_validated",
"input": str(input_path),
"run_dir": str(run_dir),
"device_requested": config["device"],
"batch_size": config["batch_size"]
}, ensure_ascii=False))python prepare_run.py --config config/pilote.json --run-dir runs/pilote-0014. Dar una identidad a las ejecuciones y a sus resultados
Asocia cada lanzamiento a un identificador corto, único en tu campaña. Anota la revisión del código, el esquema y los parámetros realmente utilizados, y después la referencia de los datos y del modelo. Conserva estos valores junto con las salidas para que un resultado no dependa de un archivo de configuración modificado más tarde.
Para comparar dos tamaños de batch, crea dos ensayos y dos directorios. Mantén la misma muestra e identifica la diferencia deliberada. Los nombres pilote-001 y pilote-002 no explican por sí solos qué ha cambiado: el manifiesto vincula el nombre a los parámetros.
Reserva un formato de resumen legible por tus herramientas. Puede distinguir elementos recibidos, exitosos, rechazados y pendientes de procesar. Elige una regla de éxito completa y no marques un ensayo como terminado en cuanto se escriba el primer resultado. El código de retorno del programa debe seguir siendo coherente con esa conclusión.
Desplaza la tabla para leer todas las columnas.| Archivo o estado | Rol | Control esperado |
|---|---|---|
| manifest.json | Identidad del código, de los datos y de los parámetros | Valores realmente utilizados, sin secretos. |
| results.jsonl | Una salida por elemento aceptado | Identificadores conocidos y formato conforme. |
| errors.jsonl | Elementos rechazados y motivo útil | Sin desapariciones silenciosas ni contenido sensible innecesario. |
| summary.json | Conclusión del ensayo y contadores | Suma coherente, archivos releídos antes del estado final. |
5. Exponer eventos útiles para tus herramientas
Haz visibles algunas transiciones: configuración aceptada, datos accesibles, modelo cargado, primera salida escrita y fin del procesamiento. Un registro debe permitir responder «¿en qué punto está este lanzamiento?» sin copiar los documentos ni los prompts. Asocia la etapa y el identificador de ensayo al mensaje.
El módulo logging de Python permite organizar los mensajes por nivel y destino. Después elige tu propia convención de eventos y documéntala. Una aplicación que escribe un error y termina con un éxito hace que la automatización sea engañosa; a la inversa, no todas las advertencias significan que el resultado sea inutilizable.
No confundas evento emitido y resultado duradero: un mensaje «copia de seguridad iniciada» no demuestra que un archivo se haya releído. Para una ejecución larga, la guía dedicada explica la relación entre proceso y sesión. Tu interfaz debe sobre todo conservar una conclusión accesible después de que termine la conexión interactiva.
6. Definir el fallo, la reanudación y la verificación final
Clasifica los fallos útiles: configuración inválida, recurso ausente, error de cálculo y resultado no conforme. Da para cada uno una próxima acción. No instales un reintento automático sin decidir qué efectos pueden repetirse: reescribir una salida ya aceptada y retomar un checkpoint requieren reglas diferentes.
Tu procedimiento final explica cómo lanzar, observar, detener, reanudar y exportar. Para un procesamiento de documentos, conserva la lista de identificadores terminados y los que hay que reprocesar. Para un entrenamiento, usa un protocolo que verifique los estados guardados en un proceso nuevo. Una carpeta no vacía no es prueba de una reanudación correcta.
Por último, controla el proyecto desde una nueva invocación, con una configuración conocida y un destino distinto. Verifica los rechazos esperados y después un recorrido completo pequeño. La precomprobación de esta página no cubre accesos concurrentes, exposición pública de un servicio ni permisos de almacenamiento: esos temas requieren su propio diseño.