Zum Hauptinhalt springen
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 auto die inhaltsbasierte Verteilung.
  • 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).
  • 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 Sie model auf auto; der restliche Request-Body ist identisch zu einem normalen Aufruf. Als base_url verwenden Sie https://aihubmix.com/v1.
curl https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "auto",
    "messages": [
      { "role": "user", "content": "What is the meaning of life?" }
    ]
  }'
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.
  • 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):
curl -i https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "auto",
    "messages": [
      { "role": "user", "content": "What is the meaning of life?" }
    ]
  }' | grep -i "^x-aihubmix-router"
Tatsächliche curl-Ausgabe (Produktionsumgebung, das genutzte Modell ändert sich mit dem aktuellen Online-Catalog):
x-aihubmix-router-decision-id: 05dbad09-33c5-42de-85b5-559fdb73eb4c
x-aihubmix-router-dimension: text.overall
x-aihubmix-router-policy: cost_optimized
x-aihubmix-router-reason: policy=cost_optimized dim=text.overall top=0.182 survivors=20/33
x-aihubmix-router-resolved-model: xiaomi-mimo-v2.5-pro
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 bevorzugenEchtzeit-Sprache, Agent-Schleifen
Um eine Strategie festzulegen, hängen Sie einfach das Suffix an model an:
# Qualität zuerst + Code-Aufgabe
curl -i https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "auto:quality_first",
    "messages": [
      { "role": "user", "content": "Write a Python function to reverse a linked list." }
    ]
  }' | grep -i "^x-aihubmix-router"
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 Strategie quality_first, die Top 3 desselben Kandidatenpools, Daten aus dem Produktions-Entscheidungslog):
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.
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
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; die Bildgenerierung /v1/images/* unterstützt auto derzeit nicht, siehe FAQ.)

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 (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:
    curl -i "https://aihubmix.com/v1/chat/completions?router=off" \
      -H "Authorization: Bearer <AIHUBMIX_API_KEY>" \
      -H "Content-Type: application/json" \
      -d '{"model":"auto","messages":[{"role":"user","content":"hi"}]}'
    # → HTTP/1.1 400 Bad Request
    # {"error":{"message":"auto requires router enabled; remove ?router=off / X-Router-Off", ...}}
    
  • 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).

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