Anbieter sortieren und Fallback steuern
Verstehen Sie die Preis-, Latenz- und Durchsatz-Rankings von ShareAI, geordnete Anbieter, nicht verfügbare Messungen und sichere Fallback-Grenzen.
Auf dieser Seite
Preis#
Das Preis-Ranking vergleicht den anwendbaren Eingabestufenpreis plus den Basis-Ausgabepreis. Es ist keine Vorhersage der Gesamtrechnung der Anfrage. Überprüfen Sie die Eingabe-, Ausgabe- und Cache-Preise für den ausgewählten Anbieter und Ihre erwartete Arbeitslast.
Latenz und Durchsatz#
Die Latenz basiert auf der beobachteten verstrichenen Zeit abgeschlossener Anfragen, nicht auf der Zeit bis zum ersten Token. Der Durchsatz basiert auf beobachteten Ausgabetokens pro verstrichener Sekunde. Die jüngsten Beobachtungen umfassen ein Fünf-Minuten-Fenster. Diese Messungen leiten das Routing; sie garantieren keine Antwortzeit oder Kapazität.
Anbieter ohne die erforderlichen Preis- oder Leistungsbeobachtungen werden in beide Richtungen nach den gemessenen Anbietern eingeordnet. Stabile Kennungen lösen Gleichstände auf.
Reihenfolge vor Sortierung#
Eine explizite Anbieterreihenfolge hat Vorrang vor der Sortierung. Innerhalb der verbleibenden berechtigten Optionen bestimmt die ausgewählte Sortierung die Rangfolge. Ignorierte Anbieter, nur externe Anbieter, nicht unterstützte Operationen und durch Schlüsselberechtigungen ausgeschlossene Anbieter bleiben unberechtigt.
| Richtlinie | Berechtigte Optionen |
|---|---|
allow_fallbacks: true | Andere berechtigte Anbieter können berücksichtigt werden, innerhalb jeder harten Einschränkung. |
allow_fallbacks: false mit order | Nur die Anbieter, die explizit in der Reihenfolge aufgeführt sind. |
allow_fallbacks: false ohne order | Nur der erstplatzierte Anbieter. |
Fallback behält dasselbe Modell bei#
Der Anbieter-Fallback ändert die berechtigte Infrastruktur für das genau angeforderte Modell. Es wechselt nicht zu einem anderen Modell-Tag. Jede Wahl des Upstream-Anbieters innerhalb des ShareAI-Anbieters ist getrennt von der öffentlichen Creator-Identität und der Ausführungsanbieter-Richtlinie.
Unterbrochene Anfragen bearbeiten#
Das Routing versucht nicht automatisch einen erneuten Versuch nach erfolgreicher Übermittlung, einer unsicheren Antwort oder einer teilweisen Ausgabe. Dies vermeidet doppelte Arbeit und Kosten. Bewahren Sie die Teilausgabe auf und lassen Sie die Anwendung entscheiden, ob eine neue Anfrage gestartet werden soll. Vermeiden Sie unbegrenzte Wiederholungsschleifen.
Beispiele#
JSON
{
"provider": {
"sort": {
"by": "latency",
"direction": "asc"
},
"allow_fallbacks": true
}
}
Um den höchsten Durchsatz zu bevorzugen, verwenden Sie {"by":"throughput","direction":"desc"}. Kehren Sie eine Richtung nur um, wenn diese Reihenfolge Ihrem beabsichtigten Test oder Ihrer Arbeitslast entspricht.
Zuletzt aktualisiert am 16. September 2026