Smart Routing
Wählen Sie automatisch das günstigste / schnellste / qualitativ hochwertigste Modell, das Ihre Vorgaben erfüllt. Sie beschreiben, worauf es Ihnen ankommt; wir wählen aus.
Warum Smart Routing
StellarCloud bietet mehrere LLMs mit unterschiedlichen Kompromissen zwischen Preis, Qualität und Latenz. Ein bestimmtes Modell in jedem Agenten fest zu verdrahten, macht Sie abhängig:
- Die Kosten steigen, weil Sie für einfache Aufgaben überdimensionieren
- Die Qualität leidet, weil Sie ein kleines Modell für schwierige Anfragen verwenden
- Sie müssen Dutzende Konfigurationen umschreiben, sobald ein besseres Modell erscheint
Smart Routing löst dies, indem es pro Anfrage auf Basis Ihrer deklarierten Präferenzen auswählt.
So funktioniert es
Anstatt ein bestimmtes Modell festzulegen, geben Sie eine Routing-Policy an ("model": "@route:cheap-first"). Der Router betrachtet Ihre Anfrage, wägt sie gegen die Vorgaben Ihrer Policy ab, wählt das Modell, das diese am besten erfüllt, und liefert die Completion samt Metadaten darüber, was verwendet wurde.
Integrierte Policies
| Policy | Verhalten |
|---|---|
@route:cheap-first | Wählt das günstigste Modell, das die Aufgabe plausibel bewältigen kann. Eskaliert nur, wenn die Qualitätsschwellen verfehlt werden. |
@route:fast-first | Wählt das Modell mit der geringsten Latenz. Tauscht Qualität gegen Geschwindigkeit. |
@route:best | Wählt immer das qualitativ hochwertigste Modell. Verwenden Sie dies, wenn die Kosten zweitrangig sind. |
@route:balanced | Standard-Policy. Eine sinnvolle Wahl im mittleren Bereich, sofern die Anfrage kein Frontier-Reasoning, keinen langen Kontext und keine starke mehrsprachige Verarbeitung erfordert. |
@route:code | Optimiert für Codegenerierung und Tool-Calling. |
@route:long-context | Wählt das Modell mit dem größten Kontextfenster. |
Eigene Policies
Definieren Sie Ihre eigenen Routing-Regeln. Dimensionen, die Sie einschränken können:
- Budget — maximale Kosten pro Anfrage, maximale tägliche / monatliche Ausgaben
- Latenz — P50- / P95-Ziel
- Qualitätsuntergrenze — eine Mindest-Benchmark-Bewertung (aus einem internen Eval-Set)
- Kontextgröße — Routing nach erwarteter Prompt-Länge
- Sprache — bestimmte Sprachen an bestimmte Modelle leiten
- Modell-Allowlist — auf eine Teilmenge von Modellen beschränken
- Fallback-Kette — wenn das primäre Modell ausfällt oder das SLO überschreitet, das nächste versuchen
Fallbacks
Jede Routing-Entscheidung hat eine implizite Fallback-Kette. Wenn das gewählte Modell ausfällt, rate-limitiert ist oder einen Fehler zurückgibt, versucht der Router das nächste infrage kommende Modell. Sie erhalten immer eine Antwort (oder einen definitiven Fehler) — vorübergehende Anbieterausfälle bekommen Sie nie zu sehen.
Observability
Die Metadaten der Antwort verraten Ihnen:
- Welches Modell gewählt wurde
- Warum (Policy + welche Vorgabe ausschlaggebend war)
- Welche Alternativen in Betracht gezogen wurden
- Geschätzte Kosten vs. tatsächliche Kosten
Dashboards zeigen die Verteilung der Modellnutzung im Zeitverlauf — nützlich für die Kostenoptimierung und um Fälle zu erkennen, in denen eine Policy zu selten oder zu häufig routet.
Wann Smart Routing nicht verwendet werden sollte
- Regulatorische Festlegung — wenn Compliance aus Audit-Gründen ein bestimmtes Modell erfordert, verdrahten Sie es fest
- Reproduzierbarkeit — bei Workflows, in denen das exakte Modell Teil des „Rezepts“ ist (z. B. eine reproduzierbare Forschungs-Pipeline), wählen Sie explizit
- Feingranulares Benchmarking — während des A/B-Tests eines Modells für eine bestimmte Aufgabe wählen Sie explizit
Modelle evaluieren
Für Ihre eigenen Workloads stellen wir ein Eval-Harness bereit:
- Erstellen Sie ein Testset aus Ihren echten Anfragen
- Lassen Sie alle Kandidatenmodelle dagegen laufen
- Bewerten Sie mit einer Metrik Ihrer Wahl (Exact Match, LLM-as-Judge, menschliche Labels)
- Sehen Sie, welches Modell bei Ihrem spezifischen Workload gewinnt
Nutzen Sie die Ergebnisse, um Ihre Routing-Policy zu optimieren — oder um eine feste Verdrahtung zu rechtfertigen.