Itô Inference
ito-inference ist der alleinige kanonische ECC-Skill für Inference Serving auf Itô
Compute. Anfragen mit dem Namen ito-serve werden hierher geleitet; erstellen oder installieren Sie keinen zweitens ito-serve-Skill. ECC führt niemals SSH zu Knoten aus, lädt keine Gewichte herunter, startet keine Engine oder gibt keinen Endpunkt frei; es bucht, reserviert oder gibt niemals Geld aus.
Aktuelle Produktionsgrenze
Verwaltetes Serving ist derzeit nicht verfügbar. Die ECC-Brücke stellt nur login,
auth, find, status und explizit eingeschränkte evals bereit. Sie hat kein serve-Verb.
Die kanonische Runtime dokumentiert inference nur als nicht unterstützten Kompatibilitäts-
Test; ECC ruft es nicht auf und ist nicht davon abhängig. Die MCP-Oberfläche stellt nur auth, find
und status bereit. Die lokal durchsetzbare Garantie ist, dass ECC serve ablehnt,
bevor der berechtigungsführende kanonische Client aufgelöst oder gestartet wird.
Stoppen Sie daher vor der Authentifizierung oder einem Befehlsaufruf. Melden Sie die
fehlende Fähigkeit und kehren Sie zum ursprünglichen Agenten zurück. Ersetzen Sie niemals
lokale Runner, SSH-Helfer, Browser-Workflows, Kaufendpunkte oder einen nicht verfolgten
lokalen ito-serve-Entwurf.
Erforderliche Berechtigung
Wenn Serving implementiert ist, ist sein erstes Tor eine serververifizierte abgeschlossene Buchung. Harness-Speicher, eine RFQ, ein Angebot, Knoten-IPs oder SSH-Zugriff sind kein Nachweis der Berechtigung. Das Backend muss frische Serving-Berechtigung zurückgeben, die an das authentifizierte Konto, die Buchung, die GPU-Topologie, die Region, das Fabric, die Laufzeit und die Modell- richtlinie gebunden ist. Abgelaufene, widerrufene, nicht übereinstimmende, unvollständige oder bereits freigegebene Buchungen schlagen vor der Bestätigung geschlossen fehl.
Zukünftiger CLI- und API-Vertrag
Der beabsichtigte Befehlsname ist serve; inference kann nach der Einführung des Produktionsvertrags
nur noch als explizit veralteter Kompatibilitätsalias bestehen bleiben.
Die zukünftige Übergabe muss äquivalent sein zu:
ecc ito serve \
--booking <server-verifizierte-buchungs-id> \
--manifest <absoluter-geprüfter-json-pfad> \
--confirmation-ref <undurchsichtiger-nicht-autorisierender-referenz> \
--idempotency-key <stabiler-wiederholungs-schlüssel> \
--json
Das geprüfte Manifest muss die Modellrevision, Engine und Version, Quantisierung, Tensor/Pipeline-Topologie, Endpunkt-Exposition-Richtlinie, Artefakt- Prüfsummen, Speichergrenze, Laufzeitbeschränkungen, optionale TTFT/TPOT-Ziele und die maximalen inkrementellen Kosten identifizieren. Kein roher API-Key, SSH-Key, Knoten-Passwort oder Bearer- Token gehört in Argumente, Manifeste, Logs, MCP-Ergebnisse oder Chat.
Der Client muss den Manifest-Pfad kanonisch machen, Symlinks ablehnen, eine reguläre Datei ohne Linkfolge öffnen, entsprechende 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 Arbeitslastmutation in die Bestätigung eingebunden ist. Ein Pfad-Tausch, Digest-Ungleichheit, zu große Datei oder mutierbare unsichere Datei schlägt geschlossen fehl.
Die kanonische API – nicht ECC – muss die Arbeitslast-Erstellung besitzen und strukturiertes JSON
mit ok, live_api_contacted, notice und entweder data oder error zurückgeben.
Serving-Daten müssen stabile Buchungs-, Arbeitslast-, Manifest- und Idempotenz-IDs plus einen
Zustands-Enum enthalten; sie dürfen nicht behaupten, dass ein Endpunkt live ist, bis Gesundheits- und Modellprüfungen
bestanden sind. Fehler müssen einen stabilen Code und eine sichere Nachricht ohne Geheimnisse enthalten.
Bestätigungs- und Ausführungstore
Vor der Arbeitslast-Erstellung müssen alle folgenden Punkte erfüllt sein:
- Frische Berechtigung und Serving-Eignung vom kanonischen Backend.
- Ein überprüfbares, unveränderliches Manifest und deterministischer Digest.
- Eine separate, einmalige Bestätigung, gebunden an Konto, Aktion, Manifest und Kosten, mit kurzer Ablaufzeit und Wiederholungsschutz. CLI-Argumente enthalten nur eine undurchsichtige, nicht autorisierende Bestätigungsreferenz; der Server löst auf und verbraucht die Berechtigung out of band.
- Ein vom Aufrufer bereitgestellter Idempotenz-Schlüssel, der atomar mit der Arbeitslast reserviert wird.
- Serverseitige Fabric-, Kapazitäts-, Modellrichtlinien-, Speicher- und Kostenvalidierung.
Authentifizierung ist Identität, nicht Arbeitslast-Autorität. Ein Login, API-Key, Angebot oder abgeschlossene Buchung ersetzt niemals die Serving-Bestätigung. Inspektion und Planerstellung dürfen keine Arbeitslast erzeugen. Abbrechen und Bereinigen sind separate Mutationen mit eigenen abgegrenzten Bestätigungs- und Idempotenz-Grenzen.
Lebenszyklus und Wiederherstellung
Die Produktionsoberfläche ist unvollständig, bis derselbe kanonische Client mandantenfähige Status-, Log-, Metrik-, Abbrechen- und Bereinigungsoperationen bereitstellt. Jede Operation benötigt begrenzte Verbindungs- und Gesamtzeitüberschreitungen, widerrufssensitive Fehler und strukturierte Ausgabe. Nach einem mehrdeutigen Transportfehler fragen Sie den Status anhand des Idempotenz-Schlüssels ab, bevor Sie es erneut versuchen; erstellen Sie niemals eine zweite Arbeitslast nur, weil die erste Antwort verloren ging. Ein widerrufenes Zugangsdaten stoppt das Abfragen und übergibt die Kontrolle an den ursprünglichen Agenten, ohne automatisch den Login zu starten.
Melden Sie ready erst, nachdem Endpunkt-Gesundheit, Modellidentität und Canary-Inferenz
bestanden sind. Melden Sie Zwischen- und Endfehlerzustände ehrlich. 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-Phasen
Diese Phasen beschreiben das zukünftige Backend, nicht Code, der in ECC existiert:
- Berechtigungs-, Topologie-, Fabric- und Kostengates überprüfen.
- Prüfsummenfixierte Gewichte in backendverwalteten Speicher abrufen.
- Einen überprüfbaren Topologie-/Engine-Plan ausgeben und validieren.
- Über die Steuerungsebene des Anbieters starten, niemals direktes Root-SSH von ECC.
- Aufwärmen, Gesundheits- und Modellidentität testen, einen SLO-Canary ausführen, dann den Endpunkt und die geschwärzte Konfiguration registrieren.
Bis jedes oben genannte Gate und jede Lebenszyklus-Operation in der kanonischen Runtime existiert, bleibt dieser Skill eine geschlossen fehlschlagende Verfügbarkeitsprüfung und Dokumentationsübergabe.