ito-training

Itô Training

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

Limite de production actuelle

L'entraînement géré est indisponible aujourd'hui. Le pont ECC n'expose que login, logout, auth, find, status et des evals explicitement limités. Il n'a pas de verbe train, et le verbe run du CLI canonique ainsi que le backend training-run du desk restent des échafaudages. La garantie localement applicable est que ECC rejette train avant de résoudre ou de générer le client canonique porteur d'identifiants.

Par conséquent, arrêtez-vous avant toute authentification ou appel de commande. Signalez la capacité manquante et revenez à l'agent d'origine. Ne remplacez jamais par 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 porte sera une réservation complétée vérifiée par le serveur. La mémoire du harnais, un RFQ, un devis, les 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 réseau et à la durée. Les réservations expirées, révoquées, non concordantes, incomplètes ou déjà libérées échouent en échec fermé avant 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 <fichier-json-absolu-examiné> \
  --confirmation-ref <référence-opaque-non-autorisante> \
  --idempotency-key <clé-de-réessai-stable> \
  --json

Le manifeste examiné doit identifier la taille et la révision du modèle, les références de données avec provenance de décontamination, la cible d'entraînement, le recette post-entraînement, le plafond budgétaire en USD, la politique de checkpoint 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, les manifestes, les logs, les résultats MCP ou le chat.

Le client doit canonicaliser 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 bornée, et hacher les octets à partir du descripteur ouvert. Ce condensé doit exactement correspondre au condensé lié dans la confirmation avant toute mutation de charge de travail. Un échange de chemin, une discordance de condensé, un fichier trop volumineux ou un fichier non sécurisé mutable échoue en échec fermé.

L'API canonique — pas ECC — doit posséder la création de charge de travail et retourner du 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.

Portes 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 vérifiable, et 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 expiration et une protection contre la relecture. Les arguments CLI ne portent qu'une référence opaque et non autorisante à la confirmation ; le serveur résout et consomme la capacité porteuse hors bande.
4. Une clé d'idempotence fournie par l'appelant, réservée atomiquement avec l'exécution.
5. Une validation côté serveur du réseau, de la capacité, de la politique de données, du stockage de checkpoints et du coût, y compris le plafond budgétaire du manifeste.

L'authentification est une identité, pas une autorité de charge de travail. Une connexion, une clé API, un devis ou une réservation complétée ne remplace 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 séparées avec leurs propres limites de confirmation et d'idempotence.

Cycle de vie et récupération

La surface de production est incomplète tant que le même client canonique n'expose pas l'état, les logs, les métriques, la liste des checkpoints, l'annulation et le nettoyage par locataire. Chaque opération nécessite des délais d'attente de connexion et généraux bornés, des erreurs conscientes de la révocation et une sortie structurée. Après un échec de transport ambigu, interrogez l'état par 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 démarrer automatiquement la connexion.

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

Étapes proposées pour le backend

Ces étapes décrivent le futur backend (Couche 0.3), pas 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 d'échelons comme vérification économique préalable 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 réseau ; les combinaisons gaspillantes sont refusées.
3. Checkpointing 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, avec validation humaine.
4. Portes de curriculum et d'évaluation — pré-entraînement par étapes / entraînement intermédiaire / contexte long / post-entraînement, chacune avec une batterie d'évaluation fixe ; une porte échouée arrête l'exécution.
5. Post-entraînement — SFT → DPO → RLVR (GRPO avec corrections de stabilité DAPO), séparation entraîneur/génération avec vétusté bornée.

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

Jusqu'à ce que chaque porte et opération de cycle de vie ci-dessus existe dans l'exécution canonique, cette compétence reste une vérification de disponibilité avec échec fermé et une remise de documentation.