Zum Hauptinhalt springen
start_within ist bei jeder FlexInference-Anfrage erforderlich. Es legt fest, wie lange der Router auf den Start der Anfrage warten darf. Verwenden Sie default, priority oder auto, wenn Sie direkt eine Provider-Stufe wünschen. Verwenden Sie eine Dauer, wenn FlexInference zuerst Flex bei einem Flex-fähigen Modell versuchen soll und dann auf Standard eskaliert, wenn Flex nicht rechtzeitig starten kann. Das Feld hat vier Formen.

​
Die vier Formen

Leitet zur Standard-Echtzeitstufe des Providers zum Standardpreis weiter: default von OpenAI, standard von Gemini oder standard_only von Anthropic. Funktioniert mit jedem Modell.
default, priority und auto leiten jedes Modell an seinen Provider (OpenAI, Gemini oder Anthropic) weiter. Nur eine Dauer fordert den Flex-Wettlauf an. Wenn das Modell Flex nicht verwenden kann, gibt eine Dauer 400 (flex_unsupported_for_anthropic oder flex_model_not_capable) zurück; verwenden Sie stattdessen einen Stufenwert.
Der Flex-Wettlauf ist nicht auf Claude verfügbar, da Anthropic keine Flex-Stufe hat. Eine Dauer start_within bei einem claude-*-Modell gibt 400 flex_unsupported_for_anthropic zurück. Anthropic funktioniert weiterhin mit default, priority und auto Stufen-Proxy-Anfragen.
Eine Dauer start_within kann nicht mit nativen Chat Completions-Parametern wie logprobs oder seed kombiniert werden. Entfernen Sie diese Parameter oder verwenden Sie stattdessen default, priority oder auto.

​
Der Flex-Wettlauf

Mit einer Dauer versucht FlexInference zuerst die Flex-Stufe des Providers (OpenAI oder Gemini). Flex wird zum halben Standardtarif abgerechnet, aber die Kapazität ist Best-Effort. Der Router wartet, bis die Upstream-Anfrage innerhalb Ihres Fensters startet:
1

Flex starten

FlexInference sendet Ihre Anfrage an die Flex-Stufe und wartet, bis der Provider bestätigt, dass sie ausgeführt wird, alles innerhalb der von Ihnen festgelegten Zeit.
2

Flex festlegen

Wenn der Provider die Anfrage rechtzeitig startet, legt FlexInference sie fest. Ihre Antwort wird normal gestreamt und zu Flex-Tarifen abgerechnet. Die Antwort zeigt "service_tier": "flex".
3

Auf Standard eskalieren

Wenn Flex nicht rechtzeitig starten kann, bricht FlexInference ab und sendet die Anfrage an Standard. Dies ist eine Eskalation von der günstigeren Flex- zur Standard-Stufe, keine Herabstufung. Die Antwort zeigt "service_tier": "default" (OpenAI) oder "standard" (Gemini).
Die Eskalation auf Standard erfolgt nur, bevor Flex startet, wenn Flex einen 429 (keine Kapazität), einen beliebigen 5xx, einen Vor-Start-Fehler oder keinen Start vor der Frist zurückgibt. Der Wechsel von Flex zu Standard ist die einzige Stufenänderung, die FlexInference vornimmt. Ein Provider-Fallback, bei dem Sie ein optionales provider-Array festlegen und FlexInference die nächste Route versucht, nachdem eine Route vorübergehend fehlschlägt, ändert die Route, niemals die Stufe oder das Modell. Ein fehlender Schlüssel für eine von Ihnen benannte Route ist ein Konfigurationsfehler und keine vorübergehende Störung, daher wird ein 400 zurückgegeben, anstatt durchzufallen. Siehe Provider-Routing.
Wählen Sie die längste Dauer, die Ihre UX tolerieren kann. Längere Fenster geben Flex mehr Zeit zum Gewinnen, was den Anteil der Anfragen erhöht, die zum günstigeren Tarif bedient werden.

​
Das Ergebnis lesen

Erfolgreiche 200-Antworten enthalten Flex-Ergebnis-Header an jedem Endpunkt, sowohl für Streaming- als auch für Nicht-Streaming-Aufrufe. Fehlerantworten verwenden stattdessen den Fehlerkörper. Die Live-Werte von x-flexinference-flex-reason sind:
Eine Dauer, die keinen Flex-Wettlauf ausführen kann, gibt 400 zurück (flex_unsupported_for_anthropic bei einem claude-*-Modell, flex_model_not_capable bei einem nicht Flex-fähigen OpenAI/Gemini-Modell); die Header-Gründe beschreiben nur Anfragen, die Flex ausgeführt haben oder es nicht angefordert haben.

​
Wenn der Flex-Pool nicht verfügbar ist

Die Flex-Stufe verwendet eine gemeinsam genutzte, Best-Effort-Kapazität. Bevor eine Anfrage startet, kann Flex einen 429 zurückgeben, wenn keine Kapazität vorhanden ist, einen beliebigen 5xx zurückgeben, vor dem Start fehlschlagen oder die Frist verpassen. FlexInference sendet die Anfrage dann an Standard. In seltenen Fällen schlägt Flex nachdem die Anfrage akzeptiert und mit dem Streaming begonnen hat, fehl. FlexInference legt diesen Fehler offen. Bei einer Streaming-Anfrage erhalten Sie ein terminales response.failed-Ereignis. Bei einer Nicht-Streaming-Anfrage erhalten Sie einen 502. Es wird nach der Festlegung kein erneuter Versuch unternommen, da dies eine unvollständige Anfrage maskieren könnte. Wenn dies auftritt, versuchen Sie es erneut, oder verwenden Sie default, priority oder auto, um Flex zu überspringen.

​
Transport-Wiederholung

Der Flex-Wettlauf entscheidet, welche Stufe Ihre Anfrage bedient. Die Transport-Wiederholung entscheidet, was passiert, wenn diese Stufe nicht startet. Fügen Sie ein optionales retry-Objekt hinzu, und FlexInference wartet und versucht die festgelegte Stufe bei einem vorübergehenden Upstream-Fehler erneut, anstatt Ihnen den Fehler zurückzugeben.
Ein ungültiges retry gibt 400 invalid_retry zurück. FlexInference versucht nur einen echten Vor-Commit-Transportfehler von der festgelegten Stufe erneut: einen echten 429, einen echten 5xx oder eine Verbindung, die nie geöffnet wurde (upstream_unavailable). Es versucht keinen Client 4xx, einen Upstream-Authentifizierungsfehler (upstream_auth_failed), einen Upstream-Timeout (upstream_timeout) oder eine vom Client abgebrochene Anfrage erneut. Diese schlagen entweder beim erneuten Versuch auf die gleiche Weise fehl oder bedeuten, dass der Aufrufer bereits weg ist. Retry versucht die Stufe erneut, die Ihre Anfrage festgelegt hat, nicht den Flex-Abschnitt. Bei einer default-, priority- oder auto-Anfrage ist dies die von Ihnen benannte Stufe. Bei einer Daueranfrage, die den Flex-Wettlauf verliert, ist dies die Standardstufe, auf die Sie eskaliert haben. Der Flex-Versuch und die Eskalation sind die eigene Arbeit des Flex-Wettlaufs und zählen niemals gegen count. Das Eskalieren einer Stufe und das erneute Versuchen derselben Stufe sind separate Schritte, die sich verketten: Flex verliert gegen Standard, dann kann Standard sich selbst erneut versuchen. Wenn der Provider einen Retry-After-Header sendet, wartet FlexInference so lange anstelle des Backoff-Zeitplans, begrenzt auf 60 Sekunden, damit ein schlechter Wert Ihre Anfrage nicht blockieren kann.
Retry ist nur vor dem Commit. Es stoppt in dem Moment, in dem eine Stufe festgelegt wird, was die 200-Statuszeile sowohl für Streaming- als auch für Nicht-Streaming-Aufrufe ist. Sobald das erste Byte auf dem Weg zu Ihnen ist, versucht FlexInference niemals erneut, dieselbe Regel, die der Flex-Wettlauf nach dem Commit befolgt. Ein Fehler mitten im Stream oder ein Nicht-Streaming- 502 nach einem festgelegten 200 wird an Sie weitergeleitet.
Server-seitiges retry ist getrennt von jeder Wiederholungsschleife in Ihrem Client, und die beiden stapeln sich. Die FlexInference SDKs versuchen nicht erneut, aber ein Standard-OpenAI- oder Anthropic-SDK versucht standardmäßig zweimal erneut. Ein Client, der zweimal zusätzlich zu einem Server-count von 3 erneut versucht, führt zu bis zu sechs Upstream-Versuchen, da jeder Client-Versuch ein volles Server-Budget ausführt. Wenn Sie retry festlegen, stempelt FlexInference x-flexinference-retries auf die Antwort mit der Anzahl der durchgeführten erneuten Versuche, sodass Sie die max_retries Ihres Clients reduzieren können.

​
Abrechnung

Mit BYOK verwendet FlexInference Ihren gespeicherten verschlüsselten Provider-Schlüssel serverseitig; Sie senden keine Provider-Schlüssel pro Anfrage. Ihr Provider rechnet Ihr Konto mit dem Tarif der Stufe ab, die die Anfrage bedient hat. Sie zahlen Flex-Tarife, wenn Flex festgelegt wird, und Standardtarife nach der Eskalation. Ein Flex-Versuch kann einige Token verbrauchen, bevor er fehlschlägt. Ihr Provider rechnet diese Nutzung genauso ab, wie er es tun würde, wenn Sie Flex direkt aufrufen würden, und FlexInference schließt sie in die Nutzung ein. FlexInference fügt Ihren Token keinen Aufschlag hinzu. Es berechnet 20 % des Geldes, das es Ihnen spart, und berechnet nichts, wenn es keine Einsparungen gibt.

​
Was FlexInference ändert

FlexInference kann die Stufe ändern. Es ändert nicht die Bedeutung Ihrer Anfrage oder das Ergebnis des Providers. Es schreibt niemals den Status oder die Nachricht eines Providers um. Es normalisiert nur den Fehler-Envelope: Ein Fehler wird in der Form des von Ihnen aufgerufenen Endpunkts zurückgegeben (OpenAI bei Antworten und Chat, Anthropic bei Nachrichten, Google bei Interaktionen), der den Status und die Nachricht des Providers enthält, damit Ihr SDK ihn parsen kann. Siehe Fehler.
start_within ist erforderlich. Ohne es gibt die Anfrage 400 missing_start_within zurück, auch bei einem einfachen OpenAI SDK, das auf unsere Basis-URL zeigt. Wenn Sie einen Wert senden, den FlexInference nicht lesen kann, erhalten Sie invalid_start_within. Gültige Werte sind "default", "priority", "auto" oder eine Dauer wie "00h-00m-30s". Das bloße Wort standard war früher erlaubt und ist es nicht mehr, senden Sie stattdessen default. Eine vollständige Liste finden Sie unter Fehler.