Zum Hauptinhalt springen
Ein model=auto – überlassen Sie die Frage “welches Modell” dem Gateway.
Der LLM 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

  • Automatische Verteilung nach Kontext: weist je nach aktuellem Kontext des Nutzers automatisch das am besten geeignete Modell zu — besonders nützlich für Agents / Apps, die Modelle viele Male aufrufen und die Modellwahl für jeden Schritt nicht im Voraus fest verdrahten können.
  • Kostenoptimierung: Lassen Sie einfache Aufgaben automatisch auf günstigere, schnellere Modelle fallen (auto ist standardmäßig kostenoptimiert).
  • Qualitätsoptimierung: Stellen Sie sicher, dass komplexe Anfragen an leistungsfähigere Modelle geleitet werden (auto:quality_first).
  • Latenzkritische Szenarien: Mehrrunden-Agent-Schleifen, interaktive Echtzeit-Chats und andere latenzempfindliche Szenarien 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 Sie model auf auto; der restliche Request-Body ist identisch zu einem normalen Aufruf. Als base_url verwenden Sie https://aihubmix.com/v1.
Das intelligente Routing schließt die Analyse ab, bevor die Anfrage den Upstream erreicht, und behandelt Streaming- (stream: true) und Nicht-Streaming-Anfragen gleich, ohne zusätzliche Parameter; die gesamte Entscheidung verursacht nur etwa 1 ms Overhead und ist bei der End-to-End-Latenz praktisch nicht spürbar.

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. Methode 1 · AIHubMix-Konsole „Logs”: Unter console.aihubmix.com/logs zeigt jede Anfrage direkt den echten getroffenen und abgerechneten Modellnamen — kein Code nötig, mit bloßem Auge prüfbar. Methode 2 · Response-Felder (praktisch für programmatischen Zugriff):
  • Das Feld model im Antwort-Body enthält das tatsächlich genutzte Modell (z. B. mimo-v2.5-pro) und nicht auto.
  • Die Antwort-Header liefern die vollständige Entscheidungsinformation:
Antwort-HeaderBedeutungBeispielwert
X-Aihubmix-Router-Resolved-ModelDas tatsächlich genutzte und entsprechend abgerechnete Modellxiaomi-mimo-v2.5-pro
X-Aihubmix-Router-PolicyDie in diesem Fall verwendete Strategiecost_optimized
X-Aihubmix-Router-DimensionDie erkannte Aufgabendimensiontext.overall
X-Aihubmix-Router-Decision-IdEindeutige ID dieser Entscheidung, zur Fehlersuche05dbad09-33c5-42de-…
X-Aihubmix-Router-ReasonKurze 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-FallbackErscheint nur, wenn das Fallback ohne Kandidaten ausgelöst wurdetrue
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):
Tatsächliche curl-Ausgabe (Produktionsumgebung, das genutzte Modell ändert sich mit dem aktuellen Online-Catalog):
So lesen Sie 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 StrategieSchwerpunktAnwendungsfall
auto (= auto:cost_optimized)Kosten zuerst: bei ausreichender Fähigkeit das günstigste Modell wählenBatch-Aufgaben, kostensensibel
auto:balancedAusgewogen: Fähigkeit / Kosten / Latenz gleichermaßen berücksichtigenAllgemein, sichere Wahl bei Unsicherheit
auto:quality_firstQualität zuerst: das leistungsfähigste Modell bevorzugenKomplexes Reasoning, kritische Ausgaben
auto:latency_criticalNiedrige Latenz zuerst: das schnellste Modell bevorzugenAgent-Schleifen, interaktiver Echtzeit-Chat
Eine Strategie ist keine feste „Modellliste”, sondern eine andere Gewichtung von Fähigkeit / Kosten / Latenz. auto grenzt zunächst anhand des Inhalts deiner Anfrage die Aufgabendimension ein und wählt dann in Echtzeit das beste Modell aus dem Kandidatenpool von Hunderten Modellen auf der Plattform gemäß der gewählten Strategie — dieselbe Strategie trifft also je nach Inhalt unterschiedliche Modelle. Die aktuell im Pool befindlichen Modelle und die Bewertungen je Dimension lassen sich über den Endpunkt Modellumfang der LLM-Router-Strategie abfragen. Die Tabelle „gleiche Anfrage, unterschiedliche Strategien → unterschiedliche Treffer” unten veranschaulicht genau das; welches Modell jeweils gewinnt, richtet sich nach dem echten Modellnamen in den Response-Headern / Konsolen-Logs. Um eine Strategie festzulegen, hängen Sie einfach das Suffix an model an:
Gleiche Anfrage, unterschiedliche Strategie → unterschiedliches Modell (in Produktion gemessen, derselbe Satz What is the meaning of life?, alle landen in der Dimension text.overall):
StrategieGenutztes Modelltop-Score
auto (= cost_optimized)xiaomi-mimo-v2.5-pro0.182
auto:balancedclaude-opus-4-6-think0.488
auto:latency_criticalclaude-opus-4-60.646
auto:quality_firstclaude-opus-4-6-think0.758
latency_critical hat 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 dasselbe auto:quality_first auf eine Code-Aufgabe an (die Anfrage im Beispiel oben), wechselt die Dimension von text.overall zu text.coding, und in der Messung wird claude-opus-4-6-think genutzt – 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 von model=auto verwandelt das Gateway in drei Schritten die “Absicht” in ein “konkretes Modell”:
1

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.
2

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.
3

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.
Reales Bewertungsbeispiel (unter der quality_first-Strategie, Top 3 desselben Kandidatenpools; Beispieldaten basierend auf historischen Produktions-Entscheidungslogs):
KandidatenmodellFähigkeitsscoreRelative KostenLatenzGesamtscore
claude-opus-4-6-think15042201963ms0.758
claude-opus-4-61498220822ms0.721
claude-fable-5151048411130ms0.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.
claude-fable-5 war ein vorläufiges Vorschau-Basismodell (staged preview baseline) und ist inzwischen eingestellt (deprecated) und wird nicht mehr angeboten; seine historische Bewertung bleibt hier nur, um den gewichteten Scoring-Mechanismus zu veranschaulichen — echte Anfragen treffen dieses Modell nicht mehr.
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 AnfrageErkannte Dimension
Einfache Textfragetext.overall
Mit Code, Programm schreiben / debuggentext.coding
Mathematischer Beweis / Lösungtext.math
Sehr lange Frage (ca. 500+ Token)text.longer_query
Frage auf Chinesischtext.language.chinese
Bildeingabe + “What is in this image?”vision.overall
Bildeingabe + “OCR…” / “Text erkennen”vision.ocr
Bildeingabe + Diagramm / Flussdiagrammvision.diagram
Websuche aktiviertsearch.overall
Bildgenerierung (/v1/images/generations)text_to_image.overall
Bildbearbeitung (/v1/images/edits, Bildeingabe → Bildausgabe)image_edit.single_image
Diese Dimensionsnamen stammen aus maßgeblichen Branchen-Leaderboards, die die Detailfähigkeiten von Modellen aufschlüsseln; auto schickt jede Art von Anfrage an das in dieser Fähigkeit stärkste Modell. Häufige Domänen, zum Beispiel:
  • Text: text.coding = Code schreiben / debuggen, text.math = Mathe lösen, text.longer_query = Langtext, text.language.chinese = Chinesisch, text.occupational.legal / text.occupational.medicine = juristische / medizinische Berufsszenarien.
  • Vision: vision.ocr = Text in Bildern erkennen, vision.diagram = Diagramme / Flussdiagramme verstehen, vision.overall = allgemeines Bildverständnis.
Die Dimensionserkennung arbeitet mit konservativem Matching (hohe Genauigkeit, niedrige Fehlerquote): Long-Tail-Anfragen und unscharfe Anfragen landen in einer allgemeineren Dimension (z. B. text.overall / vision.overall), statt erzwungen eingeordnet zu werden, was Fehlrouting vermeidet.
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; auch die Bildgenerierung /v1/images/* unterstützt auto, siehe FAQ.)

Score-Rangliste und Modell-Pool

Die Modell-Rangliste pro Dimension und der aktuelle Modell-Pool lassen sich interaktiv auf der LLM-Router-Seite einsehen oder direkt über die login-freien offenen Endpunkte abrufen: Modellumfang der LLM-Router-Strategie und Modellanbieter-Icons. Die Rangliste zeigt dieselbe Menge wie die Routing-Kandidaten: Es erscheinen nur aktuell routbare Modelle, die Punktzahlen sind innerhalb jeder Dimension auf 0–100 normalisiert, und die Rangliste wird laufend mit dem Modell-Pool aktualisiert.

Zuverlässigkeit und Fehlertoleranz

Das intelligente Routing bringt mehrfache Fehlertoleranz mit, damit der auto-Pfad nie grundlos fehlschlägt:
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).
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.
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-Header X-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 sowie die Schnittstellen zur Bildgenerierung / -bearbeitung /v1/images/* (Details siehe FAQ: Welche Schnittstellen werden unterstützt).
  • ?router=off oder der Request-Header X-Router-Off lässt model=auto direkt 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 auto kann zu unterschiedlichen Zeitpunkten unterschiedliche Modelle nutzen (das ist beabsichtigt und über die Antwort-Header nachvollziehbar). Der aktuelle Kandidatenumfang lässt sich über den Endpunkt Modellumfang der LLM-Router-Strategie abfragen.

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:
UnterscheidungsmerkmalOpenRouterLiteLLMAIHubMix
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ützt model=auto die OpenAI-kompatible Chat-Completions-Schnittstelle /v1/chat/completions sowie die Schnittstellen zur Bildgenerierung / -bearbeitung (/v1/images/generations, /v1/images/edits). 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 = Text in Bildern erkennen, vision.diagram = Diagramme / Flussdiagramme verstehen, vision.overall = allgemeines Bildverständnis usw.). Auch die Bildgenerierung unterstützt auto: Setzen Sie auf den Schnittstellen /v1/images/* das model auf auto, und die Anfrage wird nach Bildgenerierungs-Dimensionen (z. B. text_to_image.overall) geroutet. 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; der aktuelle Kandidatenumfang lässt sich über den Endpunkt Modellumfang der LLM-Router-Strategie abfragen. 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