itô-inference

Was macht itô-inference?

ito-inference ist der einzige kanonische ECC-Skill für das Inferenz-Serving auf Itô-Compute. Anfragen mit dem Namen ito-serve werden hierher weitergeleitet; erstelle oder installiere keinen zweiten ito-serve-Skill. ECC führt niemals SSH auf Knoten aus, lädt keine Gewichte herunter, startet keine Engine oder legt einen Endpunkt offen; es bucht, reserviert oder verbraucht keine Ressourcen.

Aktuelle Produktionsgrenze

Managed Serving ist derzeit nicht verfügbar. Die ECC-Bridge legt nur login, auth, find, status und explizit beschränkte evals offen. Es gibt kein serve-Verb. Die kanonische Runtime dokumentiert inference nur als nicht unterstützten Kompatibilitätsprobe; ECC ruft sie nicht auf und ist nicht von ihr abhängig. Die MCP-Oberfläche legt nur auth, find und status offen. Die lokal durchsetzbare Garantie ist, dass ECC serve ablehnt, bevor der berechtigungstragende kanonische Client aufgelöst oder gestartet wird.

Halte daher vor der Authentifizierung oder einem Befehlsaufruf an. Melde die fehlende Fähigkeit und kehre zum auslösenden Agenten zurück. Ersetze niemals durch einen lokalen Runner, SSH-Helfer, Browser-Workflow, Kauf-Endpunkt oder einen unverfolgten lokalen ito-serve-Entwurf.

Erforderliche Berechtigung

Wenn Serving implementiert ist, ist die erste Hürde eine serververifizierte, abgeschlossene Buchung. Harness-Speicher, ein RFQ, ein Angebot, Knoten-IPs oder SSH-Zugriff sind kein Berechtigungsnachweis. Das Backend muss eine frische Serving-Berechtigung zurückgeben, die an das authentifizierte Konto, die Buchung, die GPU-Topologie, die Region, das Fabric, die Laufzeit und die Modellrichtlinie 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 beabsichtigte Befehlsname ist serve; inference kann nach dem Produktionsstart nur noch als explizit veralteter Kompatibilitätsalias bestehen bleiben. Die zukünftige Übergabe muss äquivalent zu folgendem sein:

ecc ito serve \
  --booking <server-verified-booking-id> \
  --manifest <absolute-reviewed-json-file> \
  --confirmation-ref <opaque-non-authorizing-reference> \
  --idempotency-key <stable-retry-key> \
  --json

Das überprüfte Manifest muss die Modellrevision, die Engine und Version, die Quantisierung, die Tensor-/Pipeline-Topologie, die Endpunkt-Exposition-Richtlinie, die Artefakt-Checksummen, das Speicherlimit, die Laufzeitbeschränkungen, optionale TTFT/TPOT-Ziele und die maximalen inkrementellen Kosten identifizieren. Kein roher API-Schlüssel, SSH-Schlüssel, Knotenpasswort oder Bearer-Token darf in Argumenten, Manifesten, Logs, MCP-Ergebnissen oder im Chat auftauchen.

Der Client muss den Manifest-Pfad kanonisieren, Symlinks ablehnen, eine reguläre Datei ohne Verfolgung von Links öffnen, angemessene Eigentümerschaft und restriktive Berechtigungen erfordern, eine begrenzte Größe durchsetzen und Bytes aus dem geöffneten Deskriptor hashen. Dieser Digest muss exakt mit dem in der Bestätigung gebundenen Digest übereinstimmen, bevor eine Workload-Änderung erfolgt. Ein Pfadwechsel, Digest-Fehler, zu große Datei oder eine ä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. Serving-Daten müssen stabile Buchungs-, Workload-, Manifest- und Idempotenz-IDs sowie einen Status-Enum enthalten; sie darf erst dann behaupten, dass ein Endpunkt live ist, wenn Health- und Modellprüfungen bestanden sind. 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:

1. Frische Berechtigung und Serving-Fähigkeit 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ültigkeit und Wiederholungsschutz. CLI-Argumente enthalten 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 der Workload reserviert wird.
5. Serverseitige Validierung von Fabric, Kapazität, Modellrichtlinie, Speicher und Kosten.

Authentifizierung ist Identität, nicht Workload-Autorität. Ein Login, API-Schlüssel, Angebot oder eine abgeschlossene Buchung ersetzt niemals die Serving-Bestätigung. Inspektion und Planerstellung dürfen keine 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ähige Status-, Log-, Metrik-, Abbrechen- und Bereinigungsoperationen bereitstellt. Jede Operation benötigt begrenzte Verbindungs- und Gesamt-Timeouts, widerrufsbewusste Fehler und strukturierte Ausgaben. Nach einem mehrdeutigen Transportfehler sollte der Status anhand des Idempotenzschlüssels abgefragt werden, bevor ein erneuter Versuch unternommen wird; erstelle niemals eine zweite Workload nur, weil die erste Antwort verloren ging. Ein widerrufenes Zugangsdokument stoppt die Abfrage und gibt die Kontrolle an den auslösenden Agenten zurück, ohne automatisch einen Login zu starten.

Melde ready erst, nachdem Endpunkt-Health, Modellidentität und Canary-Inferenz bestanden sind. Melde 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 ausdrücklich autorisiert.

Vorgeschlagene Backend-Stufen

Diese Stufen beschreiben das zukünftige Backend, keinen in ECC vorhandenen Code:

1. Berechtigung, Topologie, Fabric und Kostengates überprüfen.
2. Checksummen-gesicherte Gewichte in Backend-verwalteten Speicher abrufen.
3. Einen überprüfbaren Topologie-/Engine-Plan ausgeben und validieren.
4. Über die Provider-Steuerungsebene starten, niemals direktes Root-SSH von ECC.
5. Aufwärmen, Health und Modellidentität testen, einen SLO-Canary durchführen, dann den Endpunkt und die redigierte Konfiguration registrieren.

Bis jedes Gate und jede Lebenszyklusoperation oben in der kanonischen Runtime existiert, bleibt dieser Skill eine Fail-Close-Verfügbarkeitsprüfung und Dokumentationsübergabe.