ito-training

Itô Training (Entraînement Itô)

ito-training est la compétence ECC canonique pour l'entraînement sur les ressources de calcul Itô. ECC n'exécute jamais son propre moteur d'entraînement, planificateur ou pipeline de données ; il ne réserve, ne réserve ni ne dépense jamais de ressources. Cette compétence s'enchaîne à partir d'une réservation terminée de ito-compute.

Limite actuelle de production

L'entraînement géré n'est pas disponible actuellement. Le pont ECC expose uniquement login, logout, auth, find, status et des evals explicitement verrouillés. Il ne possède pas de verbe train, et la commande run du CLI canonique ainsi que le backend training-run du desk restent des échafaudages. La garantie localement applicable est qu'ECC rejette train avant de résoudre ou de générer le client canonique porteur des identifiants.

Par conséquent, arrêtez-vous avant toute authentification ou invocation de commande. Signalez la capacité manquante et revenez à l'agent d'origine. Ne substituez jamais un entraîneur local, un assistant SSH, un workflow navigateur ou un point de terminaison d'achat.

Droit requis

Lorsque l'entraînement sera implémenté, sa première barrière sera une réservation terminée vérifiée par le serveur. La mémoire du harnais, une demande de devis (RFQ), un devis, les adresses IP des nœuds ou l'accès SSH ne constituent pas une preuve de droit. Le backend doit retourner une éligibilité à l'entraînement fraîche, liée au compte authentifié, à la réservation, à la topologie GPU, à la région, au tissu et à la durée. Les réservations expirées, révoquées, non concordantes, incomplètes ou déjà libérées échouent fermées avant la confirmation.

Futur contrat CLI et API

Le nom de commande prévu est train. Le futur transfert doit être équivalent à :

ecc ito train \
  --booking <id-de-réservation-vérifié-par-serveur> \
  --manifest <chemin-absolu-manifeste-json-validé> \
  --confirmation-ref <référence-opaque-non-autorisante> \
  --idempotency-key <clé-de-répétition-stable> \
  --json

Le manifeste validé doit identifier la taille et la révision du modèle, les références des données avec la provenance de décontamination, la cible d'entraînement, la recette post-entraînement, le plafond budgétaire en USD, la politique de points de contrôle et le coût incrémental maximal. Aucune clé API brute, clé SSH, mot de passe de nœud, jeton porteur ou identifiant de jeu de données ne doit figurer dans les arguments, manifestes, journaux, résultats MCP ou chat.

Le client doit canoniser le chemin du manifeste, rejeter les liens symboliques, ouvrir un fichier régulier sans suivre les liens, exiger une propriété appropriée et des permissions restrictives, imposer une taille limitée, et hacher les octets du descripteur ouvert. Ce condensé doit être exactement égal au condensé lié dans la confirmation avant toute mutation de la charge de travail. Un changement de chemin, une discordance de condensé, un fichier surdimensionné ou un fichier mutable non sécurisé échouent fermés.

L'API canonique – et non ECC – doit posséder la création de la charge de travail et retourner un JSON structuré avec ok, live_api_contacted, notice et soit data soit error. Les données d'entraînement doivent inclure les identifiants stables de réservation, d'exécution, de manifeste et d'idempotence, ainsi qu'une énumération d'état. Les erreurs doivent inclure un code stable et un message sûr, sans secrets.

Barrières de confirmation et d'exécution

Avant la création de la charge de travail, exigez tous les éléments suivants :

1. Un droit frais et une éligibilité à l'entraînement depuis le backend canonique.
2. Un manifeste immuable et révisable ainsi qu'un condensé déterministe.
3. Une confirmation distincte à usage unique, liée au compte, à l'action, au manifeste et au coût, avec une courte durée de validité et une protection contre la relecture. Les arguments CLI ne portent qu'une référence de confirmation opaque et non autorisante ; le serveur résout et consomme la capacité du porteur hors bande.
4. Une clé d'idempotence fournie par l'appelant, réservée de manière atomique avec l'exécution.
5. Une validation côté serveur du tissu, de la capacité, de la politique de données, du stockage des points de contrôle et du coût, y compris le plafond budgétaire du manifeste.

L'authentification est une identité, pas une autorité de charge de travail. Un login, une clé API, un devis ou une réservation terminée ne se substituent jamais à la confirmation d'entraînement. L'inspection et la génération de plan ne doivent pas créer de charge de travail. L'annulation et le nettoyage sont des mutations distinctes avec leurs propres limites de confirmation et d'idempotence.

Cycle de vie et reprise

La surface de production est incomplète tant que le même client canonique n'expose pas le statut, les journaux, les métriques, la liste des points de contrôle, l'annulation et le nettoyage par locataire. Chaque opération nécessite des délais d'attente de connexion et globaux limités, des erreurs tenant compte des révocations et une sortie structurée. En cas d'échec de transport ambigu, interrogez le statut via la clé d'idempotence avant de réessayer ; ne créez jamais une deuxième exécution simplement parce que la première réponse a été perdue. Un identifiant révoqué arrête l'interrogation et rend le contrôle à l'agent d'origine sans lancer automatiquement la connexion.

Signalez honnêtement les barrières d'étape ; ne remplacez jamais une évaluation échouée. Le nettoyage doit être observable et ne doit pas libérer ni modifier la réservation sous-jacente à moins que cette action économique distincte n'ait été explicitement autorisée.

Étapes proposées du backend

Ces étapes décrivent le futur backend (couche 0.3), et non du code qui existe dans ECC :

1. Préparation des données — manifeste, déduplication, décontamination par rapport à la suite d'évaluation ; job de décision à 150M échelons comme pré-vérification économique pour les données personnalisées.
2. Parallélisme et précision — sélectionnés en fonction de la taille du modèle, du nombre de nœuds, du tissu ; les combinaisons inefficaces sont refusées.
3. Points de contrôle et tolérance aux pannes — DCP asynchrone, torchft ; détection < 10 min, reprise < 15 min. Le redémarrage suite à un pic de perte est une action proposée, nécessitant une validation humaine.
4. Barrières de curriculum et d'évaluation — pré-entraînement / entraînement intermédiaire / contexte long / post-entraînement par étapes, chacune avec une batterie d'évaluation fixe ; une barrière échouée arrête l'exécution.
5. Post-entraînement — SFT → DPO → RLVR (GRPO avec correctifs de stabilité DAPO), séparation entraîneur/déploiement avec une obsolescence limitée.

Le backend émet de la télémétrie de desk (bon débit, taux d'interruption, bande passante des points de contrôle) afin que le desk tarifie honnêtement les blocs d'entraînement.

Tant que chaque barrière et opération de cycle de vie ci-dessus n'existe pas dans l'exécution canonique, cette compétence reste une vérification de disponibilité à échec fermé et un transfert de documentation.