Checkliste zur Implementierung von KI-Observability: 5 Schritte bis zur Produktion

KI-Observability wird erst dann nützlich, wenn Ingenieurteams während eines Rollouts oder Vorfalls darauf reagieren können. Ein Dashboard voller Token-Zählungen und Latenz-Perzentile reicht nicht aus, wenn niemand beantworten kann, welche Anfrage die Validierung nicht bestanden hat, warum ein Fallback ausgelöst wurde oder ob ein Kostenanstieg durch Traffic, Retries oder ein Modell-Update verursacht wurde.

Diese Checkliste zur Implementierung von KI-Observability macht das Problem in fünf geordnete Schritte überschaubar:

1. Definieren Sie den Telemetrievertrag.
2. Instrumentieren Sie jeden Modellversuch.
3. Validieren Sie Qualität und Kosten.
4. Legen Sie Service-Level-Objectives und Alarme fest.
5. Führen Sie den Rollout mit Verantwortlichkeiten und Governance durch.

Die Reihenfolge ist wichtig. Teams, die mit Dashboards beginnen, stellen später oft fest, dass ihre Felder inkonsistent sind, ihre Traces Retries verbergen oder ihre Erfolgsmetrik unbrauchbare Ausgaben als gesunde Anfragen zählt.

Wenn Sie zuerst eine breitere Übersicht über Signale und Dashboard-Design benötigen, lesen Sie den Leitfaden zur Observability von LLM-APIs. Dieser Artikel konzentriert sich auf die Implementierungsreihenfolge und die Exit-Kriterien für jede Phase.

Checkliste zur Implementierung von KI-Observability auf einen Blick

Schritt 1: Definieren Sie den Telemetrievertrag, bevor Sie Dashboards auswählen

Beginnen Sie mit den Fragen, die Betreiber beantworten müssen, und definieren Sie dann den kleinsten gemeinsamen Datensatz, der diese beantwortet. Der Vertrag sollte Provider-Änderungen und Modell-Fallbacks überstehen. Provider-spezifische Felder können als optionale Attribute hinzugefügt werden, sollten aber stabile interne Bezeichnungen nicht ersetzen.

Erforderliche Felder auf Anfrageebene

Verwenden Sie eine interne request_id für die Produktoperation und eine trace_id für verteiltes Tracing. Fügen Sie für jeden Provider-Aufruf eine attempt_id hinzu.

{
  "telemetry_schema_version": "1.0",
  "request_id": "req_...",
  "trace_id": "...",
  "attempt_id": "attempt_1",
  "environment": "production",
  "feature": "support_reply",
  "route_policy": "quality_primary_cost_fallback",
  "provider": "provider_a",
  "requested_model": "model_alias",
  "response_model": "resolved_model_version",
  "prompt_version": "support_reply_v12",
  "attempt_number": 1,
  "streaming": true,
  "status": "completed",
  "validation_status": "passed"
}

Die exakte Antwort des Anbieters kann andere Namen verwenden. Normalisieren Sie diese Felder an der Schnittstelle, damit nachgelagerte Dashboards keine separaten Abfragen für jeden Anbieter benötigen.

OpenTelemetry pflegt Semantische Konventionen für generative KI für Spans, Metriken und Events. Verwenden Sie sie, wo sie passen, aber versionieren Sie auch Ihren internen Telemetrievertrag. Semantische Konventionen können sich weiterentwickeln, während Incident-Queries und historische Vergleiche verständlich bleiben müssen.

Trennen Sie begrenzte Dimensionen von Belegen mit hoher Kardinalität

Metriken benötigen begrenzte Labels. Gute Dimensionen sind unter anderem:

• environment
• feature
• provider
• model_family
• route_policy
• status
• error_type
• validation_status

Bewahren Sie Request-IDs, Trace-IDs, Provider-Request-IDs, Benutzer-IDs, Prompt-Fingerprints und Fehlermeldungen in Traces oder Logs auf – nicht als Metric-Labels. Andernfalls kann ein einzelnes Deployment Millionen von Time Series erzeugen und das Monitoring-System langsamer oder teurer machen als die Anwendung, die es überwacht.

Entscheiden Sie den Datenschutzmodus explizit

Machen Sie die Erfassung von Roh-Prompts nicht zum Standard. Definieren Sie eine Richtlinie auf Feldebene mit mindestens drei Modi:

Das OWASP Logging Cheat Sheet empfiehlt, sensible Daten wie Zugriffstokens, Passwörter und personenbezogene Informationen auszuschließen oder zu schützen. Wenden Sie dasselbe Prinzip auf KI-Telemetrie an: Gehen Sie niemals davon aus, dass ein Observability-Backend ein geeignetes Prompt-Archiv ist.

Exit-Kriterien für Schritt 1

• Ein versioniertes Schema existiert für Request-, Attempt-, Validierungs- und Kostenereignisse.
• Retries und Fallbacks verwenden separate attempt_id-Werte.
• Metrik-Labels sind begrenzt.
• Das Erfassen von Prompt und Ausgabe verfügt über einen expliziten Datenschutzmodus.
• Anbieter­spezifische Felder werden auf stabile interne Felder abgebildet.
• Die Zuständigkeit für das Schema und die Änderungsprüfung sind zugewiesen.

Schritt 2: Instrumentieren Sie den vollständigen Request-Pfad, nicht nur einen einzelnen SDK-Aufruf

Der Trace sollte bei der benutzerseitigen Operation beginnen und durch Retrieval, Routing, jeden Modellversuch, Validierung, Tool-Ausführung und Persistenz fortgeführt werden. Wenn nur der letzte SDK-Aufruf instrumentiert wird, bleiben die Entscheidungen verborgen, die die meisten Produktionsvorfälle verursachen.

Eine nützliche Span-Hierarchie sieht so aus:

POST /assistant/run
├── load_context
├── select_route
├── model_attempt 1
│   ├── stream_first_token
│   └── tool_call weather_lookup
├── validate_output
├── model_attempt 2 fallback
│   └── stream_first_token
└── persist_result

Latenz in Komponenten erfassen

Eine End-to-End-Dauer kann nicht zwischen Netzwerklatenz, Generierungszeit des Anbieters, Warteschlangenbildung, Validierung oder Tool-Ausführung unterscheiden. Erfassen Sie mindestens:

• Gesamtdauer, die für den Nutzer sichtbar ist
• Gateway- oder Warteschlangenverzögerung
• Dauer des Anbieter-Versuchs
• Zeit bis zum ersten Token bei gestreamten Antworten
• Zeit zwischen erstem und letztem Token
• Dauer der Validierung
• Dauer des Tool-Aufrufs

Definieren Sie beim Streaming die Uhr für den ersten Token präzise. Starten Sie sie, wenn Ihr Dienst die Anfrage akzeptiert, nicht erst nach Abschluss des Routings, wenn die Metrik die Benutzererfahrung abbilden soll.

Retries und Fallbacks sichtbar machen

Eine erfolgreiche Antwort nach drei Versuchen ist nicht gleichbedeutend mit einem Erfolg im ersten Versuch. Geben Sie pro Versuch einen Span aus und enthalten Sie:

• Versuchsnummer
• Grund für Retry oder Fallback
• Vorherige Fehlerkategorie
• Backoff-Dauer
• Ausgewählter Anbieter und Modell
• Zustand des Circuit Breakers
• Ob partieller Inhalt ausgegeben wurde

Partielles Streaming erfordert besondere Sorgfalt. Wenn Bytes den Client bereits erreicht haben, kann das lautlose erneute Ausführen einer Anfrage gegen ein anderes Modell Inhalte duplizieren oder inkonsistente Tool-Aktionen erzeugen. Der Trace sollte zeigen, ob das System gestoppt, abgeglichen oder fortgesetzt hat. Verwenden Sie das LLM API Fallback-Routing-Playbook, um dieses Verhalten vor der Aktivierung des automatisierten Failovers zu definieren.

Metriken aus normalisierten Ereignissen ausgeben

Erzeugen Sie Metriken aus den normalisierten Request- und Attempt-Datensätzen, anstatt in jeder Integration einzelne Zähler hinzuzufügen. Ein minimaler Metriksatz ist:

ai_requests_total
ai_attempts_total
ai_request_duration_seconds
ai_time_to_first_token_seconds
ai_input_tokens_total
ai_output_tokens_total
ai_validation_failures_total
ai_fallbacks_total
ai_estimated_cost_usd_total

Objekte zur Anbieter-Nutzung können sich unterscheiden, insbesondere bei gecachten Tokens oder Reasoning-Tokens. Bewahren Sie das rohe Usage-Objekt bei Bedarf in eingeschränktem Diagnose-Speicher auf, ordnen Sie jedoch die Felder, die für providerübergreifende Berichte benötigt werden, einem gemeinsamen Kosten-Datensatz zu.

Exit-Kriterien für Schritt 2

• Ein Trace verbindet den Produktvorgang mit jedem Modellversuch.
• Die Latenz bis zum ersten Token und die End-to-End-Latenz haben dokumentierte Start- und Stopp-Punkte.
• Wiederholungen, Fallbacks und Circuit-Breaker-Entscheidungen sind sichtbar.
• Tool-Aufrufe haben Child-Spans und Ergebnisfelder.
• Metriken werden aus normalisierten, versionierten Events abgeleitet.
• Lasttests bestätigen, dass Telemetrie keine unakzeptable Latenz oder Kardinalität erzeugt.

Schritt 3: Anwendungserfolg validieren und Kosten abgleichen

Transporterfolg ist nur eine Ebene des Zustands. Eine KI-Antwort kann HTTP 200 zurückgeben und dennoch den Produktvertrag verfehlen, weil sie leer, fehlerhaft formatiert, abgelehnt, nicht unterstützt oder unsicher auszuführen ist.

Eine validierte Erfolgs-Zustandsmaschine definieren

Verwenden Sie explizite Zustände statt eines einzelnen Booleschen Werts:

received
→ transport_succeeded
→ parsed
→ contract_validated
→ business_rule_validated
→ accepted

Fehler sollten an der richtigen Stelle stoppen, zum Beispiel:

transport_failed
parse_failed
schema_failed
tool_policy_failed
business_rule_failed
cancelled
timed_out

So kann das Team die Verfügbarkeit des Anbieters von der Anwendungsqualität unterscheiden. Ihr primärer Zuverlässigkeitsnenner sollten in der Regel akzeptierte Benutzeroperationen sein, nicht rohe Anbieterantworten.

Zuerst deterministische Validierer hinzufügen

Bevor Sie subjektive Modellbewertungen aufbauen, implementieren Sie Prüfungen, die reproduzierbare Ergebnisse liefern:

• JSON- oder Schema-Parsing
• Vorhandensein erforderlicher Felder
• Zulässige Tool-Namen und Argumenttypen
• Vorhandensein von Zitaten, wenn die Funktion Zitate erfordert
• Behandlung des Ablehnungszustands
• Grenzen für Ausgabelänge und -format
• Geschäftsregeln wie gültige IDs, Daten, Währungen oder Enum-Werte

Verknüpfen Sie stichprobenartige Offline-Auswertungen mit Produktions-Telemetrie über eine stabile Sample-ID. Platzieren Sie keinen unbegrenzten Bewertungstext in Metrik-Labels. Für Modelländerungen verwenden Sie einen wiederholbaren Multi-Model-Prompt-Testing-Workflow, damit Latenz und Kosten zusammen mit der Rate akzeptierter Ausgaben verglichen werden.

Kosten pro akzeptierter Aufgabe berechnen

Tokenkosten pro Anfrage sind nützlich, aber Kosten pro akzeptierter Aufgabe sind die bessere operative Kennzahl:

cost_per_accepted_task =
  total_cost_of_all_attempts / accepted_user_operations

Beziehen Sie fehlgeschlagene Versuche, Wiederholungen, Fallbacks und abgelehnte Ausgaben in den Zähler ein. Andernfalls erscheinen Zuverlässigkeitsprobleme als unerklärlicher Margenschwund.

Führen Sie zwei Kostenstände:

1. Geschätzte Kosten, die sofort aus der Response-Nutzung und einer versionierten Preistabelle berechnet werden.
2. Abgeglichenen Kosten, die später aus der Anbieterabrechnung oder Nutzungs-Exports aktualisiert werden, sobald verfügbar.

Speichern Sie die für jede Schätzung verwendete price_version oder den effektiven Zeitstempel. Ohne diese Angabe werden historische Kostenänderungen nach einer Preisaktualisierung nicht mehr erklärbar. Für das Design von Finanzen und Betrieb siehe den Leitfaden zum Management von KI-API-Ausgaben.

Exit-Kriterien für Schritt 3

• Akzeptierter Erfolg ist getrennt von HTTP-Erfolg.
• Deterministische Validatoren decken den kritischen Produktvertrag ab.
• Evaluierungsbeispiele können mit Produktionsanfragen verknüpft werden.
• Die Kosten umfassen jeden Versuch, einschließlich abgelehnter Ausgaben.
• Geschätzte und abgeglichene Kosten sind getrennte Felder.
• Preisversionen werden für die historische Analyse beibehalten.

Schritt 4: SLOs und Alarme rund um Nutzerergebnisse festlegen

Alarme sollten Nutzerschäden oder schnell eskalierende operative Risiken beschreiben. Ein einzelner Anbieterfehler schadet dem Nutzer nicht immer, wenn der Fallback innerhalb des Latenzbudgets erfolgreich ist. Umgekehrt kann ein vollständig verfügbarer Anbieter dennoch unbrauchbare Ergebnisse liefern.

Beginnen Sie mit vier Service-Level-Indikatoren

Definieren Sie Ziele nach Funktion und Risikoklasse. Ein synchroner Coding-Assistent, ein Hintergrund-Document-Classifier und ein Workflow für den Payment-Support sollten nicht dieselben Latenz- oder Validierungsziele haben.

Nutzen Sie Burn-Rate- und Change-Alarme

Statische Schwellenwerte erzeugen Rauschen. Kombinieren Sie sie mit Zeitfenstern und Baselines:

• Schneller Burn: Die validierte Erfolgsrate fällt innerhalb von 5–15 Minuten stark ab.
• Langsamer Burn: Das Fehlerrisiko-Budget wird über mehrere Stunden aufgebraucht.
• Change-Alarm: Die Erfolgsrate beim ersten Versuch sinkt nach einem Deployment oder einem Update der Routing-Richtlinie.
• Kostenanomalie: Die Kosten pro akzeptierter Aufgabe steigen, während der Traffic stabil bleibt.
• Routing-Anomalie: Der Fallback-Anteil oder der Provider-Mix ändert sich unerwartet.
• Qualitätsanomalie: Schema-, Tool-Policy- oder Geschäftsregel-Fehler überschreiten die Baseline.

Jeder Alarm sollte auf eine erste Diagnoseansicht verweisen, die Deployment-Version, Routing-Richtlinie, Provider, Modell, Fehlerkategorie, Validierungsphase, Wiederholungsanzahl und Kostendifferenz zeigt.

Runbooks schreiben, bevor Pager ausgelöst werden

Definieren Sie für jeden Pager:

1. Wer zuständig ist.
2. Welche Auswirkungen auf Nutzer er daraus ableitet.
3. Welche Query oder Trace-Ansicht zuerst geöffnet werden soll.
4. Welche jüngsten Änderungen geprüft werden sollen.
5. Welche sichere Maßnahme erlaubt ist: Rollback, einen Route deaktivieren, die Parallelität senken, einen Circuit öffnen oder auf einen verifizierten Fallback umschalten.
6. Welche Nachweise den Vorfall abschließen.

Exit-Kriterien für Schritt 4

• SLOs sind pro Funktion oder Risikoklasse definiert.
• Validierte Erfolgsrate und Erfolgsrate beim ersten Versuch sind beide sichtbar.
• Alarme verwenden Zeitfenster, Baselines oder Error-Budget-Burn.
• Kosten- und Fallback-Anomalien haben dedizierte Alarme.
• Jeder Pager verlinkt auf ein Runbook und die erste Diagnose-Query.
• Die Alarmverantwortung wird während einer On-Call-Übung getestet.

Schritt 5: Observability mit Governance ausrollen

Instrumentierung ist eine Produktionsänderung. Rollen Sie sie schrittweise aus, messen Sie den Overhead und machen Sie den Datenlebenszyklus zu einem Teil der Implementierung – nicht zu einer später hinzugefügten Richtlinie.

Use a staged rollout

1. Local and test: überprüfen Sie Feldnamen, Parent-Child-Spans, Redaction und Validatoren mit synthetischen Prompts.
2. Shadow telemetry: geben Sie ereignisse im Produktionsformat aus, ohne zu benachrichtigen oder Routing-Entscheidungen zu beeinflussen.
3. Small canary: aktivieren Sie Telemetrie für einen begrenzten Anteil des Produktionsverkehrs und prüfen Sie Kardinalität, Ingestion-Kosten und Trace-Vollständigkeit.
4. Feature rollout: erweitern Sie nach Produktfunktion oder Route, nicht über alle Workloads gleichzeitig.
5. Operational activation: aktivieren Sie SLO-Reporting und Alerts erst, wenn Basisdaten und Runbooks vorhanden sind.

Messen Sie den Telemetrie-Overhead während des Canary. Berücksichtigen Sie clientseitiges Batching, Exporter-Fehler, Warteschlangenlast und was passiert, wenn das Observability-Backend nicht verfügbar ist. Modellanfragen sollten nicht fehlschlagen, nur weil ein nicht kritischer Telemetrie-Exporter ausgefallen ist.

Govern retention and access

Definieren Sie die Aufbewahrung nach Datenklasse:

• Aggregierte Metriken können in der Regel länger aufbewahrt werden.
• Request-Metadaten sollten eine dokumentierte operative Aufbewahrungsfrist haben.
• Reduzierte Beispiele sollten kürzere Aufbewahrungszeiten und einen eingeschränkteren Zugriff haben.
• Roh-Prompts oder -Ausgaben benötigen, sofern überhaupt erlaubt, einen expliziten Zweck, Verschlüsselung, Audit-Logs, Löschverhalten und Incident-Prozeduren.

Halten Sie API-Keys und Provider-Zugangsdaten aus jedem Telemetriepfad heraus. Folgen Sie einem secure API key management-Muster, das Geheimnisse serverseitig speichert und verhindert, dass Header oder Umgebungsvariablen in Ereignisse serialisiert werden.

Treat schema and dashboards as code

Versionieren Sie das Telemetrie-Schema, Validierungsregeln, SLO-Definitionen, Dashboards und Alerts gemeinsam mit der Anwendung. Eine Änderung der Route-Policy sollte Implementierung und Observability im selben Release aktualisieren.

Benennen Sie einen Verantwortlichen für:

• Schema-Evolution
• Redaktionsregeln
• Kostentabellen
• Validator-Versionen
• Dashboard-Korrektheit
• Alert-Tuning
• Überprüfungen von Datenaufbewahrung und Zugriff

Step 5 exit criteria

• Shadow- und Canary-Phasen ohne unsichere Prompt-Erfassung abgeschlossen.
• Telemetrie-Overhead und das Verhalten bei Exporter-Fehlern wurden getestet.
• Aufbewahrung und rollenbasierter Zugriff sind nach Datenklasse dokumentiert.
• Geheimnisse und Autorisierungs-Header sind ausgeschlossen.
• Schemas, Validatoren, Dashboards und Alerts werden per Versionsverwaltung nachverfolgt.
• Ein benannter Verantwortlicher prüft Telemetrieänderungen nach Modell- oder Routing-Updates.

A 30-day AI observability rollout plan

Der Zeitplan ist bewusst sequenziell. Wenn sich der Telemetrievertrag in der letzten Woche ändert, pausieren Sie die Alarmaktivierung und reparieren Sie zuerst das Schema. Paging auf inkonsistenten Daten erzeugt falsches Vertrauen.

Häufige Implementierungsfehler

HTTP 200 als Erfolg zählen

Behebung: Fügen Sie Parsing-, Vertrags-, Tool-Policy- und Business-Rule-Validierung hinzu, bevor der Vorgang accepted wird.

Wiederholungen in einem einzigen Modell-Span verstecken

Behebung: Erstellen Sie einen Child-Span und einen Kosten-Eintrag pro Versuch. Bewahren Sie den Grund für Retry oder Fallback auf.

Jeden Prompt standardmäßig protokollieren

Behebung: Standardmäßig nur Metadaten-Telemetrie verwenden. Fügen Sie gesampelten, redigierten Inhalt nur für einen expliziten Anwendungsfall hinzu.

Request-IDs als Metrik-Labels verwenden

Behebung: Bewahren Sie Identifikatoren mit hoher Kardinalität in Traces und Logs auf. Verwenden Sie begrenzte Dimensionen für Metriken.

Kosten ohne Preisversionen schätzen

Behebung: Hängen Sie die Version der Preistabelle oder den wirksamen Zeitstempel an jede Schätzung an und gleichen Sie später ab.

Auf Provider-Fehler ohne Benutzerkontext alarmieren

Behebung: Benachrichtigen Sie bei validiertem Erfolg, Latenz, Burn der Fehlerbudget-Rate und unsicheren Kostenänderungen. Verwenden Sie Provider-Fehler als Diagnose, es sei denn, sie verursachen Auswirkungen für Nutzer.

Häufig gestellte Fragen

Was ist KI-Observability?

KI-Observability ist die Praxis, Modellanfragen über Metriken, Traces, strukturierte Ereignisse, Validierungsergebnisse, Routing-Entscheidungen, Token-Nutzung und Kosten mit Anwendungsresultaten zu verknüpfen. Sie geht über das gewöhnliche API-Monitoring hinaus, weil eine KI-Anfrage technisch erfolgreich sein kann, aber für das Produkt unbrauchbar ist.

Was sollte ein KI-Observability-Dashboard enthalten?

Beginnen Sie mit der validierten Erfolgsrate, der Erfolgsrate beim ersten Versuch, der End-to-End-Latenz, der Zeit bis zum ersten Token, dem Anteil an Retries und Fallbacks, Validierungsfehlern, Token-Nutzung und Kosten pro akzeptierter Aufgabe. Fügen Sie Provider- und Modellansichten für die Diagnose hinzu, aber halten Sie das primäre Dashboard an den benutzerseitigen Funktionen ausgerichtet.

Sollten Prompts und Modell-Ausgaben protokolliert werden?

Nicht standardmäßig. Verwenden Sie für den normalen Produktionsbetrieb Telemetrie nur mit Metadaten. Wenn Inhaltsbeispiele erforderlich sind, wenden Sie Redaktion, Sampling, Verschlüsselung, kurze Aufbewahrungsfristen, Zugriffskontrollen und einen expliziten Zweck an. Protokollieren Sie niemals Geheimnisse oder Autorisierungs-Header.

Wie überwachen Sie Streaming-KI-Antworten?

Messen Sie die Zeit bis zum ersten Token, die Zeit vom ersten bis zum letzten Token, den Abbruchstatus, die ausgegebenen Bytes oder Token und ob partielle Inhalte den Nutzer vor einem Fehler erreicht haben. Definieren Sie sicheres Verhalten für Retries und Fallbacks, nachdem das Streaming begonnen hat.

Wie sollten die Kosten von KI-APIs überwacht werden?

Erfassen Sie Eingaben, Ausgaben, zwischengespeicherte und andere vom Anbieter gemeldete Nutzungsdaten, sofern verfügbar; berechnen Sie eine sofortige Schätzung mithilfe einer versionierten Preistabelle; und gleichen Sie diese mit den Abrechnungsdaten des Anbieters ab. Verfolgen Sie die Kosten pro akzeptierter Aufgabe, damit fehlgeschlagene Versuche und abgelehnte Ausgaben sichtbar bleiben.

Wo sollte ein Multi-Modell-Gateway instrumentiert werden?

Instrumentieren Sie sowohl die Anwendungsoperation als auch das Gateway. Die Anwendung weiß, ob die Ausgabe nützlich war; das Gateway weiß, welches Modell, welcher Anbieter, welche Route, welcher Retry, welches Fallback und welcher Nutzungsdatensatz sie erzeugt haben. Verwenden Sie gemeinsame Request- und Trace-IDs, um beide Ebenen zu verknüpfen.

Setzen Sie die Checkliste in die Praxis um

Der schnellste Weg zu nützlicher KI-Observability besteht nicht darin, mehr Dashboards zu installieren. Es geht darum, sich darauf zu einigen, was eine erfolgreiche Benutzeraktion bedeutet, jeden Versuch zu verfolgen, der dazu beiträgt, und Qualität, Kosten sowie Routing-Entscheidungen in derselben Evidenzkette sichtbar zu machen.

Flatkey bietet einen mit OpenAI kompatiblen Zugang zu mehreren KI-Modellen über einen einzigen API-Schlüssel und Endpunkt. Wenn Ihr Team eine Multi-Modell-Architektur evaluiert, beginnen Sie mit der Flatkey-Integrationsanleitung und wenden Sie dann diese Checkliste auf die erste Produktionsfunktion an. Sie können sich auch die aktuellen Modellzugriffe und Preise ansehen, bevor Sie Kosten-Baselines und Fallback-Routen definieren.