Was macht Itô-Training?
ito-training ist das kanonische ECC-Skill für Training auf Itô-Compute. ECC führt niemals einen Trainer, Scheduler oder eine Datenpipeline selbst aus; ECC bucht, reserviert oder gibt kein Geld aus. Dieses Skill kettet an eine abgeschlossene Buchung von ito-compute an.
Aktuelle Produktionsgrenze
Managed Training ist heute nicht verfügbar. Die ECC-Bridge stellt nur login, logout, auth, find, status und explizit abgeschirmte evals bereit. Es gibt kein train-Verb, und der run-Befehl des kanonischen CLI sowie das Desk-Backend training-run sind lediglich Gerüste. Die lokal durchsetzbare Garantie ist, dass ECC train ablehnt, bevor der berechtigte kanonische Client aufgelöst oder gestartet wird.
Daher vor der Authentifizierung oder einem Befehlsaufruf anhalten. Die fehlende Fähigkeit melden und zum ursprünglichen Agenten zurückkehren. Niemals einen lokalen Trainer, SSH-Helfer, Browser-Workflow oder Kauf-Endpunkt einsetzen.
Erforderliche Berechtigung
Wenn Training implementiert ist, ist das erste Tor eine serververifizierte abgeschlossene Buchung. Harness-Speicher, eine RFQ, ein Angebot, Knoten-IPs oder SSH-Zugang sind kein Berechtigungsnachweis. Das Backend muss frische Trainingsberechtigung 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 fehl, bevor eine Bestätigung erfolgt.
Zukünftiger CLI- und API-Vertrag
Der vorgesehene Befehlsname ist train. Die zukünftige Übergabe muss äquivalent zu folgendem sein:
ecc ito train \
--booking <server-verifizierte-buchungs-id> \
--manifest <absoluter-geprüfter-json-pfad> \
--confirmation-ref <opaquer-nicht-autorisierender-verweis> \
--idempotency-key <stabiler-wiederholungsschlüssel> \
--json
Das geprüfte Manifest muss die Modellgröße und -revision, Datenreferenzen mit Dekontaminationsprovenienz, das Trainingsziel, das Post-Training-Rezept, die Budgetobergrenze in USD, die Checkpoint-Policy und die maximalen inkrementellen Kosten identifizieren. Kein roher API-Key, SSH-Key, Knoten-Passwort, Bearer-Token oder Datensatz-Zugangsdaten darf in Argumenten, Manifesten, Logs, MCP-Ergebnissen oder Chat erscheinen.
Der Client muss den Manifest-Pfad kanonisieren, Symlinks ablehnen, eine reguläre Datei ohne Verfolgung von Links öffnen, angemessenen Besitz und restriktive Berechtigungen verlangen, eine begrenzte Größe durchsetzen und die Bytes aus dem geöffneten Deskriptor hashen. Dieser Digest muss exakt dem in der Bestätigung gebundenen Digest entsprechen, bevor eine Workload-Mutation erfolgt. Ein Pfadaustausch, Digest-Fehler, eine zu große Datei oder eine mutierbare 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-, Ausführungs-, Manifest- und Idempotenz-IDs sowie einen Status-Enum enthalten. Fehler müssen einen stabilen Code und eine sichere Nachricht ohne Geheimnisse enthalten.
Bestätigungs- und Ausführungsgates
Vor der Workload-Erstellung sind alle folgenden Punkte erforderlich:
- Frische Berechtigung und Trainingsberechtigung vom kanonischen Backend.
- Ein überprüfbares unveränderliches Manifest mit deterministischem Digest.
- Eine separate, einmalige Bestätigung, gebunden an Konto, Aktion, Manifest und Kosten, mit kurzer Ablaufzeit und Wiederholungsschutz. CLI-Argumente tragen nur einen opaquen, nicht autorisierenden Bestätigungsverweis; der Server löst die Berechtigung out-of-band auf und verbraucht sie.
- Ein vom Aufrufer bereitgestellter Idempotenzschlüssel, der atomar mit dem Run reserviert wird.
- Server-seitige Validierung von Fabric, Kapazität, Daten-Policy, Checkpoint-Speicher und Kosten, einschließlich der Budgetobergrenze 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 Planerzeugung dürfen keinen Workload erstellen. 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-Listen, Abbrechen und Bereinigen bereitstellt. Jede Operation benötigt begrenzte Verbindungs- und Gesamt-Timeout, widerrufsbewusste Fehler und strukturierte Ausgabe. Nach einem mehrdeutigen Transportfehler den Status über den Idempotenzschlüssel abfragen, bevor ein erneuter Versuch unternommen wird; niemals einen zweiten Run erstellen, nur weil die erste Antwort verloren ging. Ein widerrufenes Zugangsmedium stoppt das Polling und gibt die Kontrolle an den ursprünglichen Agenten zurück, ohne automatisch einen Login zu starten.
Stufengates ehrlich melden; niemals ein fehlgeschlagenes Evaluierungs-Gate überschreiben. Die Bereinigung muss beobachtbar sein und darf die zugrunde liegende Buchung nicht freigeben oder ändern, es sei denn, diese separate wirtschaftliche Aktion wurde ausdrücklich autorisiert.
Vorgeschlagene Backend-Stufen
Diese Stufen beschreiben das zukünftige Backend (Layer 0.3), nicht den in ECC existierenden Code:
- Datenvorbereitung – Manifest, Deduplizierung, Dekontamination gegen die Evaluierungs-Suite; 150M-Leiter-Entscheidungsjob als kostengünstige Vorprüfung für benutzerdefinierte Daten.
- Parallelität und Präzision – ausgewählt aus Modellgröße, Knotenanzahl, Fabric; verschwenderische Kombinationen werden abgelehnt.
- Checkpointing und Fehlertoleranz – asynchrones DCP, torchft; Erkennung < 10 min, Fortsetzung < 15 min. Loss-Spike-Neustart ist eine vorgeschlagene, menschlich abgesicherte Aktion.
- Curriculum- und Evaluierungs-Gates – gestaffeltes Pretrain / Mid-Train / Long-Context / Post-Training, jeweils mit fester Evaluierungs-Batterie; ein fehlgeschlagenes Gate stoppt den Run.
- Post-Training – SFT → DPO → RLVR (GRPO mit DAPO-Stabilitätsfixes), Trainer/Rollout-Trennung mit begrenzter Veraltung.
Das Backend erzeugt Desk-Telemetrie (Goodput, Unterbrechungsrate, Checkpoint-Bandbreite), damit das Desk Trainingsblöcke ehrlich bepreisen kann.
Bis jede dieser Gates- und Lebenszyklusoperationen in der kanonischen Laufzeit existiert, bleibt dieses Skill eine Fail-Closed-Verfügbarkeitsprüfung und Dokumentationsübergabe.