ki-engineeering/09-modelle-und-routing.md

Modelle und Routing

Adaptation-Stufe steht (Kapitel 08). Im nächsten Meeting landet trotzdem der Satz: „Wir nehmen das stärkste Modell — dann wird’s schon.“ Drei Monate später frisst ein unkritischer Klassifikationspfad das Budget, der Fallback bei Provider-Outage ist „500 an den Client“, und niemand weiß, welche Model-ID gestern noch in Prod hing.

Modellwahl ist Dependency-Management unter Unsicherheit — nicht Fan-Club und nicht einmalige Vendor-Demo.

These 7 / Kern in einem Satz: Model Routing mappt Tasks auf Model-Tiers (und Hosting-Pfade) nach Qualität, Latenz, Kosten und Risiko — das teuerste Modell auf 100 % Traffic ist selten Architektur, und Model-Updates sind Breaking Changes (T9).

Lebende Entscheidung: templates/adr-model-hosting.md. Change-Prozess: model-change-checklist.md. Keine Vendor-Hitliste in diesem Kapitel — Rankings und Preise veralten; Tiers und Decision Frames bleiben (Stand August 2026).

---

Bridge: Klassisches SE → AI Engineering

Klassisches SE	In AI Engineering …
Instance-Größe / Service-Tier	Model-Tier pro Workload (nicht ein Default für alles)
Primary + Replica / Multi-AZ	Primary-Model + Fallback-Provider oder -Tier
Circuit Breaker, Retry, Timeout	dasselbe plus Token-Budget und Qualitäts-Gate
Feature-Flag / Canary Deploy	Canary für Model- und Prompt-Version
Vendor lock-in bei Cloud-API	Lock-in bei API-Shape, Eval-Annahme, Context-Limits
Self-host DB vs. Managed	API vs. Self-Host für Inferenz (Ops-Last ehrlich rechnen)
SLA des Providers	Availability und stiller Quality Drift nach Model-Swap
Cost = reserved + usage	Cost ≈ Tokens × Tier × Retries × Tools (+ GPU bei Self-Host)

Die Brücke: behandelt das Modell wie eine kritische, versionierte Dependency mit Unit Economics — nicht wie eine austauschbare String-Konstante MODEL=….

---

Model-Tiers (statt Rankings)

Ein Model-Tier ist eine Rolle in eurer Architektur. Welches konkrete Produkt heute in „Strong“ sitzt, ändert sich; die Rolle bleibt.

Tier	Typische Aufgabe	Optimiert für	Typisches Risiko, wenn falsch eingesetzt
Fast/Cheap	Klassifikation, Routing, einfache Extraktion, Guardrail-Vorfilter, High-QPS	Latenz, €/Request	zu schwach für mehrstufiges Reasoning → stille Fehler
Balanced	Default für die meisten Produkt-Tasks mit Schema/RAG	Preis-Leistung	„immer Balanced“ ohne Messung = verpasstes Sparen oder verpasste Qualität
Strong	Schwere Reasoning-, Planungs-, schwierige Tool-Wahl, eskalierte Fälle	Task Success auf harten Cases	100 % Traffic → Kosten- und Latency-Explosion
Specialized	Embeddings, Code, Vision, Speech, Rerank, Domain-Modelle, kleine FT-Varianten	Aufgabe/Modalität	General-LLM missbrauchen, wo Spezialist besser/billiger ist

Zuordnung ist euer Job, nicht die Marketing-Seite des Anbieters. Dieselbe API-Familie kann mehrere Tiers abdecken; Self-Host und API können denselben Tier bedienen.

Tier-Wahl an Spec und Ladder koppeln

Adaptation / Pattern	Tier-Tendenz (Start)	Hinweis
Structured Extraktion, endliche Labels	Fast/Cheap → Balanced	Eval auf Feldern schlägt Bauchgefühl
Grounded Answer (RAG)	Balanced; Strong bei harten Queries	Retrieval-Qualität oft wichtiger als Tier-Sprung
Tool-Workflow, bekannte Schritte	Balanced + Strong nur an kritischen Knoten	nicht jeden Knoten „Strong“
Produkt-Agent	Balanced Default, Strong on escalate	Steps × Strong = Budget-Falle
Nur Entwurf, niedrige Wirkung	Fast/Cheap oder Balanced	UX-Framing wichtiger als Frontier

Regel: Erst Ladder und Pattern, dann Tier. Ein Strong-Modell heilt selten fehlendes RAG oder kaputte Tool-Contracts.

---

Model Routing: Strategien

Model Routing = zur Laufzeit (oder pro Use-Case-Config) entscheiden: welches Modell / welcher Tier / welcher Provider diesen Request bedient.

1. Single-Model (pro Capability)

Eine feste model_id (gepinnt) pro Feature oder pro Schritt-Typ.

• Pro: einfach, evalbar, wenig Überraschung
• Contra: teuer oder zu schwach im Mittel; Outage = Totalausfall ohne Fallback
• Passt: niedriges Volumen, klare Spec, Team am Anfang

2. Statisches Task-Routing

Config: Intent/Endpoint A → Tier X, B → Tier Y. Kein LLM wählt das Modell.

• Pro: reviewbar, testbar, kostentransparent
• Contra: falsche Routing-Regeln = systematische Fehlallokation
• Passt: professioneller Default, sobald >1 Workload-Profil existiert

3. Cascade (billig zuerst, teuer bei Bedarf)

Fast/Cheap → Validate / Confidence-Heuristik
    → ok? fertig
    → sonst Balanced oder Strong (einmal, mit Budget)

• Pro: Unit Economics; Strong nur wo nötig
• Contra: doppelte Latenz im Eskalationsfall; „Confidence“ des Modells ist oft kalibrierungsschwach — lieber harte Signale (Schema-Fail, Retrieval-miss, Policy-Hit, User-retry)
• Passt: hohes Volumen, gemischte Schwierigkeit

4. Fallback-Kette (Resilienz)

Bei Timeout, 429, 5xx, Region-Outage: anderer Provider, anderes Modell derselben Fähigkeitsklasse, degradierter Modus (Cache, Template, Queue, Mensch).

• Pro: Availability und On-Call-Ruhe
• Contra: Output-Verteilung wechselt — Eval muss beide Pfade kennen
• Passt: production-kritische Pfade; nie nur „retry same forever“

5. Shadow / Canary Routing

Teil des Traffics (oder parallel ohne User-Sicht) auf Kandidat-Model; Vergleich Qualität/Kosten/Latenz.

• Pro: T9 operationalisiert
• Contra: doppelte Kosten im Shadow; Privacy: gleiche Datenklassen-Regeln
• Passt: vor jedem nennenswerten Model-Change (model-change-checklist.md)

Decision Frame: Welche Routing-Strategie?

Situation	Eher …
Ein Feature, Start	Single + Pin + später Fallback
Mehrere Task-Typen	Statisches Task-Routing
80 % easy, 20 % hard	Cascade mit harten Escalation-Signals
SLO Availability hoch	Fallback-Kette cross-model/provider
Model-Update bevorsteht	Canary/Shadow vor 100 %

Routing-Logik gehört in den Control Flow (Model-Access-Schicht, Kapitel 07) — nicht in einen System-Prompt „wähle selbst das beste Modell“, außer ihr baut bewusst einen Meta-Router mit Eval und Caps.

---

API vs. Self-Hosting

Zwei Extreme und der häufige Hybrid. Entscheidung ist Betriebs- und Risikoprofil, nicht Ideologie.

Kriterium	Managed API (Provider)	Self-Host (eigene/infra GPU/CPU oder dedizierte Instanz)
Time-to-value	schnell	langsam (Serving, Autoscaling, Upgrades)
Ops-Last	niedrig–mittel (Keys, Limits, Observability)	hoch (GPU, Batching, Versionen, On-Call Infra)
Variable Kosten	Tokens/Requests transparent	CapEx/GPU-Stunden; Unterlast teuer, Überlast queue
Residenz / Vertragsdetail	Provider-Region, DPA, Training-on-data-Policies prüfen	mehr Kontrolle, mehr eigene Verantwortung
Peak / Spikes	Provider-Limits, 429-Handling	skalieren müsst ihr
Model-Auswahl	Katalog des Providers	was ihr serven und lizenzieren könnt
Quality updates	Provider shippt — für euch oft Breaking Change	ihr kontrolliert Timing; Verantwortung für Patches

Wann API defaultet

• mehrere Tiers/Modelle, unklare Last, kleines Platform-Team
• Time-to-value und Eval-Iteration wichtiger als GPU-Auslastung
• Compliance mit gewähltem Provider und Region lösbar

Wann Self-Host (oder dedizierte Instanz) ernst wird

• harte Residenz-/Luftspalt-Anforderungen
• stabil hohes Volumen, bei dem GPU-Unit-Economics nach Rechnung gewinnen
• Spezialmodell/FT-Serving, das API nicht anbietet
• Latenz zu eigenem VPC kritisch und messbar besser

Hybrid (häufig reif)

Pfad	Hosting
Fast/Cheap High-QPS intern	Self-Host oder günstige API
Strong / seltene Eskalation	API
Embeddings	oft separates Specialized-Serving (API oder self)
Batch-Nachtjob	wo €/Token oder GPU-Idle besser ist

Anti-Illusion: „Self-Host = billiger“ ohne Lastprofil, Utilization und Personen-Kosten ist Folie, keine Architektur. Rechnet € pro erfolgreichem Task inkl. Menschen und Idle — grob, aber schriftlich im ADR.

Vertiefung Serving-Mechanik (Timeouts, Streaming, Rate Limits): Kapitel 21. Unit Economics und SLOs: Kapitel 23.

---

Pinning, Versionen, Multi-Provider

Pin the contract

• Model-ID / Version in Config pinnen (kein stilles latest in Prod)
• Prompt-Version und Model-Version gemeinsam in Traces
• SemVer-Hoffnung bei Foundation Models ist begrenzt: Provider-Updates können Verhalten ändern, auch bei ähnlichem Namen (T9)

Multi-Provider ohne Chaos

Abstraktion auf eure Interface-Ebene (Messages, Tools, Structured Output) — nicht Copy-Paste von drei SDKs in den Use-Case.

• gemeinsame Timeouts, Retry-Budget, Error-Taxonomie
• Fallback nur auf eval-bekannte Paare
• Kosten- und Token-Accounting provider-normalisiert (so gut es geht)

Was Routing nicht ersetzt

• fehlende Spec und Eval (T3)
• schlechten Context (T4)
• AuthZ und Tool-Least-Privilege (T8)
• Ownership bei Incidents (T10)

Ein anderes Modell ist ein Hebel — selten die erste Ursache.

---

Patterns und Trade-offs

Pattern: Tier-Matrix pro Feature

Tabelle im Repo: Use-Case × Default-Tier × Fallback × Escalate-wenn × Budget-Cap.

Trade-off: Pflegeaufwand; ohne sie routet jedes Team ad hoc und die Rechnung erklärt die Architektur.

Pattern: Escalate on hard signals

Eskaliere zu Strong bei Schema-Fail nach Repair-Cap, leerem Retrieval, Safety-Unsicherheit, explizitem User-„nochmal genauer“ — nicht bei „Modell ist unsicher“ allein.

Trade-off: weniger unnötige Strong-Calls; ihr müsst Signale instrumentieren.

Pattern: Degraded mode ist ein Feature

Bei Totalausfall: cached Antwort, Template, „nur Mensch“, read-only. In der Spec benennen.

Trade-off: weniger peinliche 500er; UX und Produkt müssen Degraded akzeptieren.

Decision Frame: Primary wählen

Wenn dominant …	Primary-Tendenz
€ und QPS	Fast/Cheap + Cascade
p95 interaktiv	Fast/Cheap oder Balanced; Strong async/eskalieren
Task Success auf harten Cases	Balanced/Strong; Eval-getrieben
Residenz / Luftspalt	Self-Host oder region-fix API
Ops-Team dünn	API + gutes Fallback; Self-Host später

Trade-off: ein Provider vs. zwei

Ein Provider	Zwei (oder mehr)
weniger Integration	bessere Fallback-Optionen
ein Vertrags- und Eval-Fokus	Divergenz in Verhalten und Tool-Support
Outage = Schmerz	Routing- und Test-Komplexität

Zweiter Provider lohnt, wenn Availability- oder Verhandlungsgründe die Komplexität tragen — nicht aus Prinzip.

---

Anti-Patterns

Anti-Pattern	Symptom	Besser
Strong-by-Default	ein Frontier-Modell für alles	Tiers + Routing nach Task
Latest in Prod	model: latest / unpinned	pin + Change-Checklist
Vendor-Leaderboard als ADR	„Platz 1 im Blog“ = Entscheidung	eigene Golden Sets, eigene €/Task
Routing im Prompt	„nutze das beste Modell“ ohne Control Flow	Routing im Harness, geloggt
Fallback ohne Eval	Notfall-Modell nie getestet	beide Pfade im Golden Set / Shadow
Self-Host aus Prinzip	GPU-Cluster vor Lastprofil	ADR mit €/Task und Ops-Kapazität
API aus Bequemlichkeit trotz Rot-Residenz	Compliance-Hoffnung	Hosting der Datenklasse anpassen
Cascade auf Soft-Confidence	Eskalation nach Modell-Selbstlob	harte Signale + Caps
Model-Swap heilt Architektur	jeder Bug → neues Modell	Context, Ladder, Contracts zuerst
Kein Cost-Attribution	eine Rechnung, zehn Features	feature_key + model_id in Accounting

---

Production Notes

Cost. Routing ist einer der größten Hebel auf Unit Economics (T7): Fast/Cheap für den Bauch der Verteilung, Strong für den Schwanz. Caps pro Request und pro Feature; Alerts bevor die Monatsrechnung die Architektur reviewt. Details Kapitel 23.

Latency. Cascade und Multi-Hop erhöhen p95 im Eskalationspfad — in der Spec getrennt budgetieren (default path vs. escalated). Streaming ändert UX, nicht die Token-Rechnung und nicht die Modellwahl allein.

Observability. Pflichtfelder pro Request: model_id, model_tier, provider, routing_reason (single|task|cascade|fallback|canary), Prompt-Version, Tokens, Latency, Fallback-Flag. Ohne routing_reason debuggt ihr Mythen. Minimum: observability-minimum.md.

Security / Privacy. Hosting-Entscheidung = wo Prompts und Outputs liegen. Residenz, Retention, „training on your data“, Admin-Zugriff — in ADR und Vertrag, nicht im Slack. Tool-Outputs und PII gelten für jeden Provider-Pfad gleich (Kapitel 20).

Lifecycle. Jeder Model-Change: Offline-Eval, Safety, Cost-Estimate, Canary, Rollback (model-change-checklist.md, Kapitel 24). Pin bricht absichtlich Komfort — das ist Feature, nicht Bürokratie (T9).

---

Key Takeaways

• Model-Tiers (Fast/Cheap · Balanced · Strong · Specialized) ersetzen Vendor-Hitlisten als Architektur-Sprache.
• Routing (Task, Cascade, Fallback, Canary) sitzt im Control Flow; Strong-by-Default ist selten optimal.
• API vs. Self-Host nach Residenz, Last, Ops und €/Task entscheiden — oft hybrid; nie aus Ideologie.
• Pin + Eval + Canary: Model-Updates sind Breaking Changes (T9).
• ADR festhalten: adr-model-hosting.md.

Praktische nächste Schritte

1. Liste eure AI-Capabilities und ordne jeder einen Default-Tier + grobes Volumen zu (auch Schätzung).
2. Definiert eine Fallback-Regel für den kritischsten Pfad (Timeout/5xx → …) und testet sie einmal end-to-end.
3. Pinnt Production-model_ids; entfernt latest wo es noch existiert.
4. Füllt templates/adr-model-hosting.md für das Feature mit dem höchsten €- oder Risiko-Anteil.
5. Als Nächstes Context und Memory: Daten- und Kontextarchitektur — oft der größere Qualitätshebel als der nächste Tier-Sprung (T4).