Ein model=auto – überlassen Sie die Frage “welches Modell” dem Gateway.
Der Auto Router (intelligentes Modell-Routing) wählt anhand des Anfrageninhalts in Echtzeit aus mehreren Hundert Modellen der Plattform das am besten geeignete aus. Sie setzen einfach model auf auto – kein Modell auswählen, keine Preise vergleichen, keine Modell-Iterationen verfolgen.
Abgerechnet wird nach dem tatsächlich genutzten Modell, ohne Aufpreis und ohne Änderung am Client-Code. Welches Modell genutzt wurde, steht im Antwort-Header und im Antwort-Body (siehe So bestätigen Sie das tatsächlich genutzte Modell) und ist vollständig nachvollziehbar.
Anwendungsfälle
- Allgemeine Anwendungen: Wenn Sie nicht wissen, welche Art von Anfragen Ihre Nutzer senden werden, überlassen Sie
autodie inhaltsbasierte Verteilung. - Kostenoptimierung: Lassen Sie einfache Aufgaben automatisch auf günstigere, schnellere Modelle fallen (
autoist standardmäßig kostenoptimiert). - Qualitätsoptimierung: Stellen Sie sicher, dass komplexe Anfragen an leistungsfähigere Modelle geleitet werden (
auto:quality_first). - Szenarien mit niedriger Latenz: Echtzeit-Sprache und mehrstufige Agent-Schleifen bevorzugen das schnellste Modell (
auto:latency_critical). - Einheitlicher Einstieg, keine Modellauswahl: Unterschiedliche Anfragetypen werden automatisch an das jeweils optimale Modell verteilt – Sie müssen weder eine “Aufgabe → Modell”-Zuordnungstabelle pflegen noch Modell-Iterationen verfolgen, Preise vergleichen oder Namen manuell wechseln.
Schnellstart
Setzen Siemodel auf auto; der restliche Request-Body ist identisch zu einem normalen Aufruf. Als base_url verwenden Sie https://aihubmix.com/v1.
So bestätigen Sie das tatsächlich genutzte Modell
Das ist der Vertrauensanker des intelligenten Routings: Sie wissen stets, welches Modell diese Anfrage letztlich verwendet hat.- Das Feld
modelim Antwort-Body enthält das tatsächlich genutzte Modell (z. B.mimo-v2.5-pro) und nichtauto. - Die Antwort-Header liefern die vollständige Entscheidungsinformation:
| Antwort-Header | Bedeutung | Beispielwert |
|---|---|---|
X-Aihubmix-Router-Resolved-Model | Das tatsächlich genutzte und entsprechend abgerechnete Modell | xiaomi-mimo-v2.5-pro |
X-Aihubmix-Router-Policy | Die in diesem Fall verwendete Strategie | cost_optimized |
X-Aihubmix-Router-Dimension | Die erkannte Aufgabendimension | text.overall |
X-Aihubmix-Router-Decision-Id | Eindeutige ID dieser Entscheidung, zur Fehlersuche | 05dbad09-33c5-42de-… |
X-Aihubmix-Router-Reason | Kurze Begründung der Entscheidung (Strategie / Dimension / Höchstwert / Anzahl Kandidaten) | policy=cost_optimized dim=text.overall top=0.182 survivors=20/33 |
X-Aihubmix-Router-Fallback | Erscheint nur, wenn das Fallback ohne Kandidaten ausgelöst wurde | true |
HTTP-Antwort-Header sind unabhängig von Groß-/Kleinschreibung: Die Tabelle oben verwendet konventionell die Großschreibung der Anfangsbuchstaben, die tatsächliche HTTP/2-Antwort liefert kleingeschrieben x-aihubmix-router-*; beides ist gleichwertig.
So lesen Sie die Routing-Entscheidung aus (mit curl die Antwort-Header anzeigen; mit dem SDK über das Roh-Antwortobjekt die Header abrufen):
reason: survivors=20/33 bedeutet, dass von 33 Kandidaten 20 die harte Filterung passiert haben und in die Bewertung gelangt sind; top=0.182 ist der innerhalb des Kandidatenpools normalisierte Gesamtscore des Gewinnermodells (Fähigkeit / Kosten / Latenz, gewichtet nach Strategie).
Das
Resolved-Model im Beispiel hängt von den aktuellen Kandidaten und Preisen des Online-Catalogs ab und ändert sich, wenn Modelle auf der Plattform hinzukommen oder abgeschaltet werden – genau das ist der Wert des intelligenten Routings: Sie müssen diese Änderungen nicht verfolgen. Damit Entscheidungen nachvollziehbar bleiben, richten Sie sich nach dem echten Modellnamen im Antwort-Header / Antwort-Body und nehmen Sie nicht an, dass er konstant bleibt.Routing-Strategien
auto ohne Suffix verwendet die Standardstrategie cost_optimized. Mit auto:<Strategie> können Sie die Gewichtung explizit festlegen:
| Schreibweise der Strategie | Schwerpunkt | Anwendungsfall |
|---|---|---|
auto (= auto:cost_optimized) | Kosten zuerst: bei ausreichender Fähigkeit das günstigste Modell wählen | Batch-Aufgaben, kostensensibel |
auto:balanced | Ausgewogen: Fähigkeit / Kosten / Latenz gleichermaßen berücksichtigen | Allgemein, sichere Wahl bei Unsicherheit |
auto:quality_first | Qualität zuerst: das leistungsfähigste Modell bevorzugen | Komplexes Reasoning, kritische Ausgaben |
auto:latency_critical | Niedrige Latenz zuerst: das schnellste Modell bevorzugen | Echtzeit-Sprache, Agent-Schleifen |
model an:
What is the meaning of life?, alle landen in der Dimension text.overall):
| Strategie | Genutztes Modell | top-Score |
|---|---|---|
auto (= cost_optimized) | xiaomi-mimo-v2.5-pro | 0.182 |
auto:balanced | claude-opus-4-6-think | 0.488 |
auto:latency_critical | claude-opus-4-6 | 0.646 |
auto:quality_first | claude-opus-4-6-think | 0.758 |
latency_criticalhat die Nicht--think-Variante gewählt – Thinking-Varianten haben eine höhere Reasoning-Latenz, und die Strategie für niedrige Latenz meidet sie gezielt. Man sieht: Die Strategiegewichtung wirkt real auf die Abwägung zwischen “Fähigkeit / Kosten / Latenz” und schaut nicht nur auf die Fähigkeit.
Auch der Inhalt verändert das Ergebnis: Wendet man dasselbeauto:quality_firstauf eine Code-Aufgabe an (die Anfrage im Beispiel oben), wechselt die Dimension vontext.overallzutext.coding, und in der Messung wirdclaude-opus-4-6-thinkgenutzt – Strategie und Anfrageninhalt bestimmen gemeinsam das endgültige Modell.
Ein unbekanntes Strategie-Suffix (z. B.
auto:fast) fällt auf die Standardstrategie cost_optimized zurück und löst keinen Fehler aus.Funktionsweise
Nach Eingang vonmodel=auto verwandelt das Gateway in drei Schritten die “Absicht” in ein “konkretes Modell”:
Anfragemerkmale extrahieren
Analysiert die Eingabe-/Ausgabemodalitäten dieser Anfrage (Text, Bild, Datei), die Inhaltsabsicht (Code, Mathematik, OCR, Diagramm, Sprache, ob Websuche usw.) sowie den Anfragenumfang (geschätzte Eingabe-/Ausgabe-Token) und fasst sie zu einer Aufgabendimension zusammen. Beispiele: eine Frage mit Code →
text.coding; mit Bild und OCR-Anforderung → vision.ocr; einfacher Text → text.overall.Kandidaten hart filtern
Modelle, die die harten Vorgaben nicht erfüllen, werden direkt ausgeschlossen: keine Unterstützung der benötigten Eingabe-/Ausgabemodalität, zu kleines Kontextfenster, durch den Circuit Breaker entfernt (siehe Zuverlässigkeit und Fehlertoleranz) oder nicht im Modellbereich, der für diesen Key verfügbar ist.
Strategiebasiert gewichtet bewerten
Für die Kandidaten, die die Filterung passieren, werden auf Basis von Fähigkeitsbewertungen aus branchenweit anerkannten Benchmarks, ergänzt um Echtzeit-Preis- und Performance-Daten, gemäß der gewählten Strategie die drei Dimensionen “Fähigkeit / Kosten / Latenz” gewichtet bewertet; das Modell mit dem höchsten Score wird genommen. Der endgültige Modellname wird in Request und Antwort-Header zurückgeschrieben.
quality_first, die Top 3 desselben Kandidatenpools, Daten aus dem Produktions-Entscheidungslog):
| Kandidatenmodell | Fähigkeitsscore | Relative Kosten | Latenz | Gesamtscore |
|---|---|---|---|---|
claude-opus-4-6-think | 1504 | 220 | 1963ms | 0.758 |
claude-opus-4-6 | 1498 | 220 | 822ms | 0.721 |
claude-fable-5 | 1510 | 484 | 11130ms | 0.600 |
Beachten Sie, dass claude-fable-5 den höchsten Fähigkeitsscore hat (1510), aber wegen höherer Kosten und größerer Latenz im Gesamtscore auf den dritten Platz gedrückt wird. Genau das ist der Sinn der gewichteten Bewertung: nicht “Fähigkeit über alles”, sondern eine strategiebasierte Abwägung zwischen Fähigkeit / Kosten / Latenz.
Die Dimensionserkennung erfolgt automatisch – das intelligente Routing bringt über 30 fein abgestufte Aufgabendimensionen mit (Code / Mathematik / OCR / Diagramm / Langtext / Chinesisch / Websuche …), weit feiner als eine “grobe Verteilung nach Modellfamilie”. Dasselbe auto leitet je nach Inhalt zu unterschiedlichen Dimensionen:
| Ihre Anfrage | Erkannte Dimension |
|---|---|
| Einfache Textfrage | text.overall |
| Mit Code, Programm schreiben / debuggen | text.coding |
| Mathematischer Beweis / Lösung | text.math |
| Sehr lange Frage (ca. 500+ Token) | text.longer_query |
| Frage auf Chinesisch | text.language.chinese |
| Bildeingabe + “What is in this image?” | vision.overall |
| Bildeingabe + “OCR…” / “Text erkennen” | vision.ocr |
| Bildeingabe + Diagramm / Flussdiagramm | vision.diagram |
| Websuche aktiviert | search.overall |
Auch Bildeingaben durchlaufen das intelligente Routing: Wenn Sie in
/v1/chat/completions ein Bild mitsenden, wird je nach Bildaufgabe an ein Modell mit starker Bildverständnisfähigkeit geleitet. In Produktion gemessen – „OCR this image” → vision.ocr, genutzt qwen3.5-397b-a17b; allgemeines Bildverständnis „What is in this image?” → vision.overall, genutzt gpt-5.4-mini. (Hier geht es um Bildverständnis; die Bildgenerierung /v1/images/* unterstützt auto derzeit nicht, siehe FAQ.)Zuverlässigkeit und Fehlertoleranz
Das intelligente Routing bringt mehrfache Fehlertoleranz mit, damit derauto-Pfad nie grundlos fehlschlägt:
Circuit Breaker: fehlerhafte Modelle automatisch entfernen
Circuit Breaker: fehlerhafte Modelle automatisch entfernen
Das Gateway führt für jedes Modell eine Fehlerratenstatistik über ein Schiebefenster. Wenn ein Modell innerhalb des Fensters ausreichend oft fehlschlägt und die Fehlerrate einen Schwellenwert überschreitet, wird es vorübergehend aus dem Kandidatenpool entfernt und nach einer Abkühlphase automatisch wiederhergestellt – so vermeidet man, weitere Anfragen an ein gerade spinnendes Modell zu senden. Das Fehlersignal stammt aus dem Fehler, den der Upstream für diese Anfrage zurückgibt; das gateway-eigene “kein verfügbarer Kanal” zählt nicht (das ist kein Problem des Modells selbst).
Fallback ohne Kandidaten: bei auto nie ein 400
Fallback ohne Kandidaten: bei auto nie ein 400
Sollte die harte Filterung einmal alle Kandidaten ausschließen (z. B. weil es für eine bestimmte Modalitätskombination vorübergehend kein verfügbares Modell gibt), löst das Gateway keinen Fehler aus, sondern weist je nach Ausgabetyp ein Fallback-Modell zu, um eine Antwort zu garantieren, und fügt dem Antwort-Header
X-Aihubmix-Router-Fallback: true hinzu, damit Sie es wissen.Berechtigungsschutz: ein beschränkter Key wird nicht durch das Fallback umgangen
Berechtigungsschutz: ein beschränkter Key wird nicht durch das Fallback umgangen
Wenn Ihr Key den verfügbaren Modellbereich einschränkt, liegt das vom intelligenten Routing (inklusive Fallback) gewählte Modell immer innerhalb dieses Bereichs. Gibt es im Bereich tatsächlich kein Modell, das diese Anfrage bedienen kann, wird klar ein 403 zurückgegeben, statt stillschweigend ein (womöglich teureres) Modell außerhalb des Bereichs zu verwenden.
Abrechnung
Abgerechnet wird zum regulären Preis des tatsächlich genutzten Modells; das intelligente Routing selbst erhebt keinerlei Aufpreis. Welches Modell letztlich antwortet, danach werden Preis, Fähigkeiten und Kontextlimits berechnet – dieses Modell ist genau der Wert im Antwort-HeaderX-Aihubmix-Router-Resolved-Model und im Feld model des Antwort-Bodys. Mit anderen Worten: Das intelligente Routing verwendet nicht “heimlich ein teures Modell”: Jede Nutzung steht in der Antwort und kann Posten für Posten abgeglichen werden.
Einschränkungen
-
Das intelligente Routing richtet sich derzeit an die Chat-Completions-Schnittstelle
/v1/chat/completions(Details siehe FAQ: Welche Schnittstellen werden unterstützt). -
?router=offoder der Request-HeaderX-Router-Offlässtmodel=autodirekt ein 400 zurückgeben – dies ist eine ausdrückliche Ablehnung der mehrdeutigen Nutzung “auto haben wollen und gleichzeitig das Routing abschalten”, statt sie stillschweigend zu ignorieren: -
Die Kandidatenmenge ändert sich dynamisch mit dem Plattform-Catalog: Dasselbe
autokann zu unterschiedlichen Zeitpunkten unterschiedliche Modelle nutzen (das ist beabsichtigt und über die Antwort-Header nachvollziehbar).
Unterschiede zu OpenRouter / LiteLLM
“Automatische Modellauswahl” ist nicht exklusiv für AIHubMix; OpenRouter und LiteLLM bieten ähnliche Fähigkeiten. Die Unterschiede liegen vor allem im Integrationsaufwand und in der Betriebsweise:| Unterscheidungsmerkmal | OpenRouter | LiteLLM | AIHubMix |
|---|---|---|---|
| Automatische Modellauswahl nach Anfrageninhalt | ✅ | ✅ | ✅ |
| Null Konfiguration, sofort einsatzbereit (keine Routing-Regeln / Utterances schreiben) | ✅ | ❌ | ✅ |
| Plattformbetrieben, kein selbst gebauter / selbst bereitgestellter Proxy nötig | ✅ | ❌ | ✅ |
| Mehrere Strategien für Kosten / Qualität / Latenz, Umschalten mit einem Parameter | ❌ | ❌ | ✅ |
| Entscheidung nachvollziehbar (Antwort-Header enthält dimension / policy / reason) | ❌ | ❌ | ✅ |
| Abrechnung nach dem letztlich genutzten Modell | ✅ | ❌ | ✅ |
Häufige Fragen (FAQ)
F: Welche Schnittstellen unterstützt das intelligente Routing? A: Derzeit unterstütztmodel=auto die OpenAI-kompatible Chat-Completions-Schnittstelle /v1/chat/completions. Schnittstellen wie Bildgenerierung / -bearbeitung (/v1/images/*), Audio, /v1/embeddings, /v1/rerank usw. unterstützen auto derzeit nicht; geben Sie dort bitte direkt ein konkretes Modell an.
F: Unterstützt das intelligente Routing Bildeingaben?
A: Ja. Eine Frage mit Bild (image_url) in /v1/chat/completions ist Bildverständnis und wird je nach Bildaufgabe an ein Modell mit starker Bildverständnisfähigkeit geleitet (vision.ocr / vision.diagram / vision.overall usw.). Zur Unterscheidung: Bildgenerierung läuft über die Schnittstelle /v1/images/* und unterstützt auto derzeit nicht.
F: Wie erfahre ich, welches Modell diese Anfrage tatsächlich verwendet hat?
A: Schauen Sie in den Antwort-Header X-Aihubmix-Router-Resolved-Model oder das Feld model im Antwort-Body – beide enthalten den echten Modellnamen. Siehe So bestätigen Sie das tatsächlich genutzte Modell.
F: Verwendet das intelligente Routing heimlich ein teures Modell?
A: Nein. Die Standardstrategie cost_optimized ist kostenoptimiert; zudem steht jedes genutzte Modell in der Antwort und wird zu seinem regulären Preis abgerechnet, Posten für Posten abgleichbar. Siehe Abrechnung.
F: Wie steuere / schätze ich die Kosten?
A: Drei sich ergänzende Mittel – ① das Standard-auto (cost_optimized) ist bereits kostenoptimiert; ② mit dem verfügbaren Modellbereich des Keys beschränken Sie die Kandidaten auf das von Ihnen akzeptierte Preisniveau, was einer Kostenobergrenze entspricht; ③ jede Nutzung wird zum regulären Preis des Modells im Antwort-Header Resolved-Model abgerechnet, Posten für Posten abgleichbar. Wenn Sie mehr Fähigkeit brauchen, verwenden Sie explizit auto:quality_first.
F: Was ist der Unterschied zwischen auto und „Modell-Mapping / Fallback”?
A: Modell-Mapping / Fallback ist ein fester Alias auf Key-Ebene + geordnetes Fallback bei Fehlern (jedes Mal dasselbe Ziel); das intelligente Routing wählt das Modell dynamisch je nach Anfrageninhalt. Ersteres löst “der Client kennt nur einen bestimmten Namen / das Hauptmodell ist ausgefallen, schalte auf das Backup”; Letzteres löst “mir ist egal welches, gib mir das passendste”.
F: Kann man das intelligente Routing auf einige wenige Modelle beschränken?
A: Ja – über die Einschränkung des verfügbaren Modellbereichs des Keys: Das intelligente Routing wählt nur unter den für diesen Key erlaubten Modellen; nicht erlaubte Modelle werden nicht genutzt.
F: Werden Streaming-Anfragen unterstützt?
A: Ja. Das Routing wird abgeschlossen, bevor die Anfrage den Upstream erreicht, und behandelt Streaming / Nicht-Streaming gleich.
F: Warum haben zwei Aufrufe desselben Satzes unterschiedliche Modelle genutzt?
A: Kandidatenmenge und Preise ändern sich dynamisch mit dem Plattform-Catalog, das ist beabsichtigt. Mit Decision-Id und Resolved-Model aus den Antwort-Headern lässt sich jede Entscheidung nachvollziehen.
F: Wie erreiche ich, dass eine Anfrage stabil dasselbe Modell nutzt (z. B. um den Prompt-Cache wiederzuverwenden)?
A: auto wählt das Modell dynamisch nach dem aktuellen Catalog und garantiert keine Determinismus. Wenn Sie stabil dasselbe Modell benötigen (z. B. weil Sie auf den Prompt-Cache des Upstreams angewiesen sind oder streng reproduzieren wollen), geben Sie direkt einen konkreten Modellnamen an oder beschränken Sie den verfügbaren Bereich des Keys auf ein einziges Modell – bei beiden Varianten ist die Nutzung deterministisch.
Verwandte Ressourcen
- Modell-Mapping und Fallback: fester Alias auf Key-Ebene + Fallback bei Fehlern, ergänzend zum intelligenten Routing.
- Einheitliche Inferenzparameter: über Modelle hinweg konsistente Request-Parameter.
- AIHubMix Modellseite: Modellnamen, Preise und
Input Modalitiesnachschlagen.