ito-training

Itô Training

ito-training es el skill canónico de ECC para entrenamiento sobre cómputo Itô. ECC nunca ejecuta un entrenador, programador o pipeline de datos propio; nunca reserva, adquiere o gasta. Este skill se encadena a una reserva completada de ito-compute.

Límite de producción actual

El entrenamiento gestionado no está disponible hoy. La puerta de enlace ECC solo expone login, logout, auth, find, status y evaluaciones explícitamente controladas. No tiene un verbo train, y el verbo run de la CLI canónica y el backend de escritorio training-run siguen siendo esqueletos. La garantía localmente exigible es que ECC rechaza train antes de resolver o generar el cliente canónico que porta las credenciales.

Por lo tanto, deténgase antes de la autenticación o cualquier invocación de comando. Reporte la capacidad faltante y retorne al agente originante. Nunca sustituya un entrenador local, un helper SSH, un flujo de trabajo de navegador o un endpoint de compra.

Requisito de habilitación

Cuando el entrenamiento esté implementado, su primera puerta de seguridad es una reserva completada verificada por el servidor. La memoria del arnés, una solicitud de cotización, un presupuesto, las IPs de los nodos o el acceso SSH no son prueba de habilitación. El backend debe devolver elegibilidad de entrenamiento fresca vinculada a la cuenta autenticada, la reserva, la topología de GPU, la región, la estructura y el plazo. Las reservas expiradas, revocadas, no coincidentes, incompletas o ya liberadas fallan de forma segura antes de la confirmación.

Futuro contrato CLI y API

El nombre de comando previsto es train. La futura transferencia debe ser equivalente a:

ecc ito train \
  --booking <id-de-reserva-verificado-por-servidor> \
  --manifest <archivo-json-absoluto-revisado> \
  --confirmation-ref <referencia-opaca-no-autorizante> \
  --idempotency-key <clave-estable-para-reintento> \
  --json

El manifiesto revisado debe identificar el tamaño del modelo y la revisión, las referencias de datos con procedencia de descontaminación, el objetivo de entrenamiento, la receta posterior al entrenamiento, el límite de presupuesto en USD, la política de puntos de control y el costo incremental máximo. Ninguna clave API en bruto, clave SSH, contraseña de nodo, token de portador o credencial de dataset debe estar presente en argumentos, manifiestos, registros, resultados de MCP o chat.

El cliente debe canonizar la ruta del manifiesto, rechazar enlaces simbólicos, abrir un archivo regular sin seguir enlaces, exigir propiedad adecuada y permisos restrictivos, imponer un tamaño acotado y generar un hash de los bytes del descriptor abierto. Este resumen debe coincidir exactamente con el resumen vinculado en la confirmación antes de cualquier mutación de carga de trabajo. Un intercambio de ruta, una discrepancia de resumen, un archivo sobredimensionado o un archivo mutable inseguro falla de forma segura.

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 data o error. Los datos de entrenamiento deben incluir identificadores estables de reserva, ejecución, manifiesto e idempotencia, más un enumerado 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, se requieren todos los siguientes:

1. Habilitación y elegibilidad de entrenamiento frescas desde el backend canónico.
2. Un manifiesto inmutable revisable y un resumen determinista.
3. Una confirmación separada de un solo uso vinculada a cuenta, acción, manifiesto y costo, con una caducidad corta y protección contra repetición. Los argumentos de la CLI llevan solo una referencia de confirmación opaca y no autorizante; el servidor resuelve y consume la capacidad de portador fuera de banda.
4. Una clave de idempotencia proporcionada por el llamante, reservada atómicamente con la ejecución.
5. Validación del lado del servidor de la estructura, capacidad, política de datos, almacenamiento de puntos de control y costo, 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 a la confirmación de entrenamiento. La inspección y la generación de planes no deben crear una carga de trabajo. La cancelación y limpieza 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, registros, métricas, listado de puntos de control, cancelación y limpieza con ámbito de inquilino. Cada operación necesita tiempos de espera de conexión y globales acotados, errores conscientes de revocación y salida estructurada. Después de un fallo de transporte ambiguo, consulte el estado mediante la clave de idempotencia antes de reintentar; nunca cree una segunda ejecución solo porque la primera respuesta se perdió. Una credencial revocada detiene la encuesta y devuelve el control al agente originante sin iniciar sesión automáticamente.

Reporte las puertas de etapa honestamente; nunca anule 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 del backend propuestas

Estas etapas describen el backend futuro (Capa 0.3), no código que exista en ECC:

1. 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 previa económica para datos personalizados.
2. Paralelismo y precisión — seleccionados del tamaño del modelo, recuento de nodos, estructura; combinaciones derrochadoras rechazadas.
3. Puntos de control 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 y controlada por humanos.
4. Puertas de currículo y evaluación — preentrenamiento por etapas / entrenamiento intermedio / contexto largo / post-entrenamiento, cada uno con una batería de evaluación fija; una puerta fallida detiene la ejecución.
5. Post-entrenamiento — SFT → DPO → RLVR (GRPO con correcciones de estabilidad DAPO), separación de entrenador/despliegue con desfase acotado.

El backend emite telemetría de escritorio (rendimiento bueno, tasa de interrupción, ancho de banda de puntos de control) para que el escritorio precio los bloques de entrenamiento honestamente.

Hasta que cada puerta y operación de ciclo de vida anterior exista en el tiempo de ejecución canónico, este skill sigue siendo una verificación de disponibilidad con fallo seguro y una transferencia de documentación.