Itô Training
ito-training es el skill canónico de ECC para entrenar en cómputo Itô. ECC nunca ejecuta un trainer, scheduler o pipeline de datos propio; nunca reserva, asigna o gasta. Este skill se encadena a una reserva completada de ito-compute.
Límite actual de producción
El entrenamiento gestionado no está disponible hoy. El puente de ECC expone solo login, logout, auth, find, status y evals explícitamente controlados. No tiene un verbo train, y el verbo run del CLI canónico y el backend training-run del escritorio siguen siendo esqueletos. La garantía localmente aplicable es que ECC rechaza train antes de resolver o generar el cliente canónico que porta las credenciales.
Por lo tanto, detente antes de la autenticación o cualquier invocación de comando. Informa de la capacidad faltante y regresa al agente originante. Nunca sustituyas un trainer local, un helper SSH, un workflow de navegador o un endpoint de compra.
Requisito de autorización
Cuando el entrenamiento esté implementado, su primera puerta es una reserva completada verificada por el servidor. La memoria del arnés, una RFQ, un presupuesto, las IPs de los nodos o el acceso SSH no son prueba de autorización. El backend debe devolver elegibilidad de entrenamiento fresca vinculada a la cuenta autenticada, la reserva, la topología de GPU, la región, el tejido y el término. Las reservas caducadas, revocadas, no coincidentes, incompletas o ya liberadas fallan cerradas antes de la confirmación.
Futuro contrato CLI y API
El nombre de comando previsto es train. La entrega futura debe ser equivalente a:
ecc ito train \
--booking <server-verified-booking-id> \
--manifest <absolute-reviewed-json-file> \
--confirmation-ref <opaque-non-authorizing-reference> \
--idempotency-key <stable-retry-key> \
--json
El manifiesto revisado debe identificar el tamaño y revisión del modelo, referencias de datos con proveniencia de descontaminación, objetivo de entrenamiento, receta de post-entrenamiento, límite de presupuesto en USD, política de checkpoint y costo incremental máximo. Ninguna clave API en bruto, clave SSH, contraseña de nodo, token portador o credencial de dataset debe estar en argumentos, manifiestos, logs, resultados MCP o chat.
El cliente debe canonizar la ruta del manifiesto, rechazar enlaces simbólicos, abrir un archivo regular sin seguir enlaces, requerir propiedad apropiada y permisos restrictivos, imponer un tamaño acotado y aplicar hash a los bytes del descriptor abierto. Ese digest debe coincidir exactamente con el digest vinculado a la confirmación antes de cualquier mutación de carga de trabajo. Un intercambio de ruta, discrepancia de digest, archivo sobredimensionado o archivo mutable inseguro falla cerrado.
La API canónica (no ECC) debe poseer la creación de la carga de trabajo y devolver JSON estructurado con ok, live_api_contacted, notice y ya sea data o error. Los datos de entrenamiento deben incluir reserva estable, ejecución, manifiesto e IDs de idempotencia más un enum de estado. Los errores deben incluir un código estable y un mensaje seguro sin secretos.
Puertas de confirmación y ejecución
Antes de la creación de la carga de trabajo, requiére todo lo siguiente:
- Autorización fresca y elegibilidad de entrenamiento del backend canónico.
- Un manifiesto inmutable revisable y un digest determinista.
- Una confirmación separada de un solo uso vinculada a cuenta, acción, manifiesto y costo, con caducidad corta y protección contra repetición. Los argumentos del CLI llevan solo una referencia de confirmación opaca y no autorizante; el servidor resuelve y consume la capacidad portadora fuera de banda.
- Una clave de idempotencia proporcionada por el llamador reservada atómicamente con la ejecución.
- Validación de tejido, capacidad, política de datos, almacenamiento de checkpoint y costo del lado del servidor, incluido el límite de presupuesto del manifiesto.
La autenticación es identidad, no autoridad de carga de trabajo. Un inicio de sesión, clave API, presupuesto o reserva completada nunca sustituye la confirmación de entrenamiento. La inspección y la generación de planes no deben crear una carga de trabajo. Cancelar y limpiar son mutaciones separadas con sus propios límites de confirmación e idempotencia.
Ciclo de vida y recuperación
La superficie de producción está incompleta hasta que el mismo cliente canónico exponga estado, logs, métricas, listado de checkpoint, cancelación y limpieza con ámbito de tenant. Cada operación necesita tiempos de espera de conexión y total acotados, errores conscientes de revocación y salida estructurada. Después de un fallo de transporte ambiguo, consulta el estado por la clave de idempotencia antes de reintentar; nunca crees una segunda ejecución solo porque la primera respuesta se perdió. Una credencial revocada detiene el sondeo y devuelve el control al agente originante sin iniciar sesión automáticamente.
Informa honestamente las puertas de etapa; nunca anules una puerta de evaluación fallida. La limpieza debe ser observable y no debe liberar ni modificar la reserva subyacente a menos que esa acción económica separada haya sido explícitamente autorizada.
Etapas propuestas del backend
Estas etapas describen el futuro backend (Capa 0.3), no código que exista en ECC:
- Preparación de datos — manifiesto, deduplicación, descontaminación contra el conjunto de evaluación; trabajo de decisión de escalera de 150M como verificación económica previa para datos personalizados.
- Paralelismo y precisión — seleccionados según tamaño del modelo, número de nodos, tejido; se rechazan combinaciones derrochadoras.
- Checkpointing y tolerancia a fallos — DCP asíncrono, torchft; detectar < 10 min, reanudar < 15 min. El reinicio por pico de pérdida es una acción propuesta con intervención humana.
- Puertas de currículum y evaluación — pre-entrenamiento por etapas / entrenamiento medio / contexto largo / post-entrenamiento, cada uno con una batería de evaluación fija; una puerta fallida detiene la ejecución.
- Post-entrenamiento — SFT → DPO → RLVR (GRPO con correcciones de estabilidad DAPO), separación trainer/rollout con desactualización acotada.
El backend emite telemetría de escritorio (goodput, tasa de interrupción, ancho de banda de checkpoint) para que el escritorio fije honestamente los bloques de entrenamiento.
Hasta que cada puerta y operación del ciclo de vida anterior exista en el runtime canónico, este skill sigue siendo una verificación de disponibilidad de cierre fallido y una entrega de documentación.