ito-training

Itô-Training

ito-training ist der kanonische ECC-Skill für Training auf Itô-Compute. ECC führt niemals einen eigenen Trainer, Scheduler oder eine Datenpipeline aus; es bucht, reserviert oder gibt kein Geld aus. Dieser Skill setzt auf einer abgeschlossenen Buchung von ito-compute auf.

Aktuelle Produktionsgrenze

Verwaltetes Training ist heute nicht verfügbar. Die ECC-Brücke stellt nur login, logout, auth, find, status und explizit eingeschränkte evals bereit. Sie hat kein train-Verb, und der run-Befehl der kanonischen CLI sowie das training-run-Backend der Desk sind noch Gerüste. Lokal durchsetzbar ist die Garantie, dass ECC train ablehnt, bevor der berechtigungsführende kanonische Client aufgelöst oder gestartet wird.

Daher stoppe vor der Authentifizierung oder jedem Befehlsaufruf. Melde die fehlende Fähigkeit und kehre zum ursprünglichen Agenten zurück. Ersetze niemals einen lokalen Trainer, SSH-Helfer, Browser-Workflow oder Kauf-Endpunkt.

Erforderliche Berechtigung

Wenn Training implementiert ist, ist sein erstes Tor eine servergeprüfte abgeschlossene Buchung. Harness-Speicher, eine RFQ, ein Angebot, Knoten-IPs oder SSH-Zugriff sind kein Berechtigungsnachweis. Das Backend muss frische Training-Berechtigung zurückgeben, die an das authentifizierte Konto, die Buchung, die GPU-Topologie, die Region, das Fabric und die Laufzeit gebunden ist. Abgelaufene, widerrufene, nicht übereinstimmende, unvollständige oder bereits freigegebene Buchungen schlagen vor der Bestätigung fehl.

Zukünftiger CLI- und API-Vertrag

Der vorgesehene Befehlsname ist train. Die zukünftige Übergabe muss äquivalent sein zu:

ecc ito train \
  --booking <servergeprüfte-buchungs-id> \
  --manifest <absoluter-geprüfter-json-pfad> \
  --confirmation-ref <undurchsichtiger-nicht-autorisierender-verweis> \
  --idempotency-key <stabiler-wiederholungsschlüssel> \
  --json

Das geprüfte Manifest muss die Modellgröße und -revision, Datenreferenzen mit Dekontaminationsherkunft, das Training-Ziel, das Post-Training-Rezept, das Budget-Obergrenze in USD, die Checkpoint-Richtlinie und die maximalen inkrementellen Kosten identifizieren. Kein roher API-Key, SSH-Key, Knotenpasswort, Bearer-Token oder Datensatz-Zugangsdaten gehören in Argumente, Manifeste, Logs, MCP-Ergebnisse oder Chat.

Der Client muss den Manifest-Pfad kanonisieren, Symlinks ablehnen, eine reguläre Datei ohne Linkverfolgung öffnen, angemessene Eigentümerschaft und restriktive Berechtigungen verlangen, eine begrenzte Größe durchsetzen und Bytes aus dem geöffneten Deskriptor hashen. Dieser Digest muss exakt dem Digest entsprechen, der vor jeder Workload-Änderung in die Bestätigung eingebunden ist. Ein Pfadwechsel, Digest-Fehlanpassung, übermäßig große Datei oder eine veränderbare unsichere Datei schlägt fehl.

Die kanonische API – nicht ECC – muss die Workload-Erstellung übernehmen und strukturiertes JSON mit ok, live_api_contacted, notice und entweder data oder error zurückgeben. Trainingsdaten müssen stabile Buchungs-, Lauf-, Manifest- und Idempotenz-IDs sowie einen Zustands-Enum enthalten. Fehler müssen einen stabilen Code und eine sichere Nachricht ohne Geheimnisse enthalten.

Bestätigungs- und Ausführungstore

Vor der Workload-Erstellung sind alle folgenden Voraussetzungen erforderlich:

1. Frische Berechtigung und Training-Eignung vom kanonischen Backend.
2. Ein überprüfbares unveränderliches Manifest und deterministischer Digest.
3. Eine separate einmalige Bestätigung, gebunden an Konto, Aktion, Manifest und Kosten, mit kurzer Gültigkeitsdauer und Replay-Schutz. CLI-Argumente tragen nur einen undurchsichtigen, nicht autorisierenden Bestätigungsverweis; der Server löst die Berechtigung außerhalb der Band auf und verbraucht sie.
4. Ein vom Aufrufer bereitgestellter Idempotenzschlüssel, der atomar mit dem Lauf reserviert wird.
5. Serverseitige Fabric-, Kapazitäts-, Datenrichtlinien-, Checkpoint-Speicher- und Kostenvalidierung, einschließlich der Budget-Obergrenze des Manifests.

Authentifizierung ist Identität, nicht Workload-Autorität. Ein Login, API-Key, Angebot oder eine abgeschlossene Buchung ersetzt niemals die Trainingsbestätigung. Inspektion und Planerstellung dürfen keinen Workload erzeugen. Abbrechen und Bereinigen sind separate Mutationen mit eigenen abgegrenzten Bestätigungs- und Idempotenzgrenzen.

Lebenszyklus und Wiederherstellung

Die Produktionsoberfläche ist unvollständig, bis derselbe kanonische Client mandantenfähigen Status, Logs, Metriken, Checkpoint-Liste, Abbrechen und Bereinigen bereitstellt. Jeder Vorgang benötigt begrenzte Verbindungs- und Gesamtzeitüberschreitungen, widerrufsbewusste Fehler und strukturierte Ausgabe. Nach einem mehrdeutigen Transportfehler frage den Status über den Idempotenzschlüssel ab, bevor du wiederholst; erstelle niemals einen zweiten Lauf nur, weil die erste Antwort verloren ging. Ein widerrufener Zugang stoppt das Polling und gibt die Kontrolle an den ursprünglichen Agenten zurück, ohne automatisch einen Login zu starten.

Melde Stufentore ehrlich; überschreibe niemals ein fehlgeschlagenes Evaluierungstor. Die Bereinigung muss beobachtbar sein und darf die zugrunde liegende Buchung nicht freigeben oder ändern, es sei denn, diese separate wirtschaftliche Aktion wurde explizit autorisiert.

Vorgeschlagene Backend-Stufen

Diese Stufen beschreiben das zukünftige Backend (Layer 0.3), nicht Code, der in ECC existiert:

1. Datenvorbereitung — Manifest, Deduplizierung, Dekontamination gegen die Evaluierungssuite; 150M-Leiter-Entscheidungsjob als günstige Vorprüfung für benutzerdefinierte Daten.
2. Parallelität und Präzision — ausgewählt aus Modellgröße, Knotenanzahl, Fabric; verschwenderische Kombinationen abgelehnt.
3. Checkpointing und Fehlertoleranz — asynchrones DCP, torchft; Erkennung < 10 Min., Fortsetzung < 15 Min. Loss-Spike-Neustart ist eine vorgeschlagene, vom Menschen kontrollierte Aktion.
4. Curriculum- und Evaluierungstore — gestaffeltes Pretrain / Mid-Train / Long-Context / Post-Training, jede mit einer festen Evaluierungsbatterie; ein fehlgeschlagenes Tor stoppt den Lauf.
5. Post-Training — SFT → DPO → RLVR (GRPO mit DAPO-Stabilitätskorrekturen), Trainer/Rollout-Trennung mit begrenzter Veralterung.

Das Backend sendet Desk-Telemetrie (Goodput, Unterbrechungsrate, Checkpoint-Bandbreite), damit die Desk die Training-Blöcke ehrlich bepreisen kann.

Bis jeder Tor- und Lebenszyklusvorgang oben in der kanonischen Laufzeit existiert, bleibt dieser Skill eine fehlgeschlossene Verfügbarkeitsprüfung und Dokumentationsübergabe.