> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aihubmix.com/llms.txt
> Use this file to discover all available pages before exploring further.
# LLM Router (intelligentes Modell-Routing)
> AIHubMix LLM Router: model auf auto — das Gateway wählt pro Anfrage das beste Modell. Kosten / Qualität / Latenz, Abrechnung nach genutztem Modell.
> 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](#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`.
```bash curl theme={null}
curl https://aihubmix.com/v1/chat/completions \
-H "Authorization: Bearer " \
-H "Content-Type: application/json" \
-d '{
"model": "auto",
"messages": [
{ "role": "user", "content": "What is the meaning of life?" }
]
}'
```
```python Python (openai SDK) theme={null}
from openai import OpenAI
client = OpenAI(
api_key="",
base_url="https://aihubmix.com/v1",
)
resp = client.chat.completions.create(
model="auto", # Modellauswahl dem Gateway überlassen
messages=[
{"role": "user", "content": "What is the meaning of life?"},
],
)
print(resp.choices[0].message.content)
print("Tatsächlich genutztes Modell:", resp.model) # nicht "auto", sondern der echte Modellname
```
```javascript Node.js (openai SDK) theme={null}
import OpenAI from "openai";
const client = new OpenAI({
apiKey: "",
baseURL: "https://aihubmix.com/v1",
});
const resp = await client.chat.completions.create({
model: "auto", // Modellauswahl dem Gateway überlassen
messages: [
{ role: "user", content: "What is the meaning of life?" },
],
});
console.log(resp.choices[0].message.content);
console.log("Tatsächlich genutztes Modell:", resp.model); // echter Modellname
```
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](https://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-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):
```bash curl theme={null}
curl -i https://aihubmix.com/v1/chat/completions \
-H "Authorization: Bearer " \
-H "Content-Type: application/json" \
-d '{
"model": "auto",
"messages": [
{ "role": "user", "content": "What is the meaning of life?" }
]
}' | grep -i "^x-aihubmix-router"
```
```python Python (openai SDK) theme={null}
# Den oben erstellten client wiederverwenden; nur with_raw_response liefert die Antwort-Header
raw = client.chat.completions.with_raw_response.create(
model="auto",
messages=[
{"role": "user", "content": "What is the meaning of life?"},
],
)
print("Genutztes Modell:", raw.headers.get("x-aihubmix-router-resolved-model"))
print("Strategie:", raw.headers.get("x-aihubmix-router-policy"))
print("Dimension:", raw.headers.get("x-aihubmix-router-dimension"))
completion = raw.parse() # in ein normales completion-Objekt parsen
print("body.model:", completion.model)
```
```javascript Node.js (openai SDK) theme={null}
// Den oben erstellten client wiederverwenden; nur .withResponse() liefert die rohen Antwort-Header
const { data: completion, response } = await client.chat.completions
.create({
model: "auto",
messages: [
{ role: "user", content: "What is the meaning of life?" },
],
})
.withResponse();
console.log("Genutztes Modell:", response.headers.get("x-aihubmix-router-resolved-model"));
console.log("Strategie:", response.headers.get("x-aihubmix-router-policy"));
console.log("Dimension:", response.headers.get("x-aihubmix-router-dimension"));
console.log("body.model:", completion.model);
```
Tatsächliche curl-Ausgabe (Produktionsumgebung, das genutzte Modell ändert sich mit dem aktuellen Online-Catalog):
```text theme={null}
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:` 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 | Agent-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](/de/api/RouterEndpoints/leaderboard) 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:
```bash curl theme={null}
# Qualität zuerst + Code-Aufgabe
curl -i https://aihubmix.com/v1/chat/completions \
-H "Authorization: Bearer " \
-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"
```
```python Python (openai SDK) theme={null}
raw = client.chat.completions.with_raw_response.create(
model="auto:quality_first", # Qualität zuerst
messages=[
{"role": "user", "content": "Write a Python function to reverse a linked list."},
],
)
print(raw.headers.get("x-aihubmix-router-resolved-model"))
print(raw.headers.get("x-aihubmix-router-dimension"))
```
```javascript Node.js (openai SDK) theme={null}
const { response } = await client.chat.completions
.create({
model: "auto:quality_first", // Qualität zuerst
messages: [
{ role: "user", content: "Write a Python function to reverse a linked list." },
],
})
.withResponse();
console.log(response.headers.get("x-aihubmix-router-resolved-model"));
console.log(response.headers.get("x-aihubmix-router-dimension"));
```
**Gleiche Anfrage, unterschiedliche Strategie → unterschiedliches Modell** (in Produktion gemessen, derselbe Satz `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_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":
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`.
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](#zuverlässigkeit-und-fehlertoleranz)) oder nicht im Modellbereich, der für diesen Key verfügbar ist.
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):
| 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.
`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 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` |
| 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 Bild**verständnis**; auch die Bild**generierung** `/v1/images/*` unterstützt `auto`, siehe [FAQ](#häufige-fragen-faq).)
***
## Score-Rangliste und Modell-Pool
Die Modell-Rangliste pro Dimension und der aktuelle Modell-Pool lassen sich interaktiv auf der [LLM-Router-Seite](https://aihubmix.com/llm-router/auto?lang=en) einsehen oder direkt über die login-freien offenen Endpunkte abrufen: [Modellumfang der LLM-Router-Strategie](/de/api/RouterEndpoints/leaderboard) und [Modellanbieter-Icons](/de/api/RouterEndpoints/vendors). 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](#häufige-fragen-faq)).
* `?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:
```bash theme={null}
curl -i "https://aihubmix.com/v1/chat/completions?router=off" \
-H "Authorization: Bearer " \
-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). Der aktuelle Kandidatenumfang lässt sich über den Endpunkt [Modellumfang der LLM-Router-Strategie](/de/api/RouterEndpoints/leaderboard) 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**:
| 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ü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 Bild**verstä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 Bild**generierung** 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](#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](#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](https://docs.aihubmix.com/de/api/Model-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](/de/api/RouterEndpoints/leaderboard) 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
* [Modell-Mapping und Fallback](https://docs.aihubmix.com/de/api/Model-Mapping-Fallback): fester Alias auf Key-Ebene + Fallback bei Fehlern, ergänzend zum intelligenten Routing.
* [Einheitliche Inferenzparameter](https://docs.aihubmix.com/de/api/unified-inference): über Modelle hinweg konsistente Request-Parameter.
* [AIHubMix Modellseite](https://aihubmix.com/models): Modellnamen, Preise und `Input Modalities` nachschlagen.
* [Modellumfang der LLM-Router-Strategie](https://docs.aihubmix.com/de/api/RouterEndpoints/leaderboard): login-freier Zugriff auf die öffentliche Teilmenge von 23 Unterdimensionen (der 30+ Routing-Dimensionen) und den routbaren Modell-Pool.