Zum Hauptinhalt springen
Führen Sie Inferenz mit Fastino-Modellen über einen von zwei API-Verträgen aus. Jeder Vertrag hat eine eigene Anfrage- und Antwortform; die Felder sind nicht austauschbar.

Eine Entscheidung mit GLiDE treffen

Rufen Sie POST /v1/systemone mit state und typisierten questions auf. Sie erhalten Noul-, Choice- oder Score-Antworten mit Wahrscheinlichkeiten und Konfidenz.

GLiNER ausführen

Rufen Sie POST /v1/chat/completions mit messages auf. Fügen Sie ein schema für GLiNER-Extraktion, Klassifikation, Strukturen oder Relationen hinzu.
Für GLiDE-Konzepte und die Auswahl der Primitive beginnen Sie mit Entscheidungsmodelle. Der GLiDE-Inferenzleitfaden behandelt die HTTP-Integration.

​
API-Verträge

GLiDE / System One

Vollständiges Anfrage- und Antwortschema für Entscheidungsmodell-Inferenz.

GLiNER / Chat Completions

Vollständiger OpenAI-kompatibler GLiNER-Vertrag.

Natives GLiNER

Verträge für synchrone, asynchrone und Jobstatus-Aufrufe.

Responses

OpenAI-Responses-kompatibler Inferenzvertrag.

Messages

Anthropic-Messages-kompatibler Inferenzvertrag.

Modelle

Kompatible Modell-IDs auflisten.

​
Routing und Aufbewahrung bestätigen

Erfolgreiche Aufrufe von POST /v1/systemone, /v1/chat/completions, /v1/responses, /v1/messages und /v1/gliner-2 geben zwei Diagnose-Header zurück:
  • X-Fastino-Data-Retention ist zero bei Zero Data Retention für das Team, not-stored, wenn die Anfrage den Inferenzverlauf abgelehnt hat, und andernfalls stored.
  • X-Fastino-Served-Model ist das kanonische Modell, das den Aufruf verarbeitet hat. Es ist die ID des feinabgestimmten Modells, wenn ein Fine-Tune die Anfrage bedient hat, und andernfalls die ID des Basismodells.
Prüfen Sie sie, wenn Sie eine Integration verifizieren:
Bei Fehlerantworten und bei Streams, die vor der Weiterleitung an den Provider fehlschlagen, fehlen die Header. Ein Stream, der nach der Weiterleitung fehlschlägt, behält sie und meldet seinen Fehler im Stream.

​
Kaltstarts und Wiederholungsversuche

Ein inaktives oder neu bereitgestelltes Modell kann einen Kaltstart durchführen. Verwenden Sie ein Lese-Timeout von mindestens 300 Sekunden und begrenztes Backoff für Antworten mit 425, 429 und 503. Beachten Sie Retry-After, sofern vorhanden. Eine Anfrage, die in einen Timeout gelaufen ist, kann die Bereitstellung dennoch aufwärmen, sodass die nächste Anfrage erfolgreich sein kann. Wiederholen Sie Fehler bei Authentifizierung, Abrechnung, Validierung oder unbekanntem Modell nicht, ohne das zugrunde liegende Problem zu beheben.