Wenn LLMs Teil der Produktionsinfrastruktur werden, reicht klassisches Monitoring nicht mehr aus. Das Nadelöhr ist nicht mehr der Anwendungscode, sondern die Routing- und Modellauswahl-Schicht – und genau dort wird Observability benötigt.
In LLM-Systemen beginnt die Degradierung nicht mit dem Ausfall von HTTP-Endpunkten, sondern mit der Ansammlung nicht offensichtlicher Effekte: steigende Latenz bei einzelnen Modellen, Kostensprünge durch Routing, Timeouts bei bestimmten Prompts, Rate Limits beim Provider. Wenn eine Anwendung mehrere Modelle und Provider nutzt, verliert der traditionelle Ansatz mit Logs und Metriken innerhalb des Services schnell an Zusammenhang. Der Ingenieur sieht Symptome, aber nicht den Entscheidungskontext – mit welchem Modell wurde die Anfrage bearbeitet, warum gab es ein Fallback, wie hoch waren die Kosten.
Bei OpenRouter setzt man darauf, Observability in die Infrastrukturschicht zu verlagern – dorthin, wo Routing und Lastverteilung zwischen den Modellen stattfinden. Die Schlüsselidee: Teams sollen nicht jeden Aufruf manuell instrumentieren müssen, sondern die Tracing-Generierung erfolgt automatisch auf API-Ebene. Das reduziert den operativen Aufwand und beseitigt Diskrepanzen zwischen dem tatsächlichen Systemverhalten und dem, was im Code instrumentiert ist. Der Trade-off ist klar: weniger Flexibilität bei individueller Telemetrie, aber deutlich höhere Konsistenz und Vollständigkeit der Daten.
Die Umsetzung basiert auf OpenTelemetry. Das Broadcast-Feature in OpenRouter erstellt automatisch einen Trace für jede Anfrage und sendet diesen über einen OTLP-Endpoint an externe Systeme wie Grafana Cloud. Wichtig: Es ist kein SDK und keine Codeänderung in der Anwendung erforderlich – das Tracing wird auf Account-Ebene aktiviert. Im Trace werden Attribute erfasst, die spezifisch für LLM-Lasten sind: Modell, Provider, Tokens, Kosten, Latenz sowie Prompt und Completion (sofern der Privacy Mode nicht aktiviert ist). Auf Seiten von Grafana Cloud wird dies über Tempo verarbeitet und steht in TraceQL zur Verfügung, sodass mit LLM-Traces wie mit verteilten Systemen gearbeitet werden kann.
Der praktische Nutzen zeigt sich in mehreren Szenarien. Erstens: Kostentransparenz – Ausgaben können nach Modellen, API-Keys oder Nutzerattributen aufgeschlüsselt werden, ohne separate Billing-Analysen. Zweitens: Latenzmanagement – der Vergleich von p50/p95/p99 zwischen Modellen ermöglicht Routing nach SLA statt nach Bauchgefühl. Drittens: Debugging – der Trace zeigt sofort, ob es sich um ein Rate Limit, einen Provider-Fehler oder ein Problem in der Anfrage handelt. Schließlich: Planung – auf Basis aggregierter Daten zu Tokens und Aufrufhäufigkeit lassen sich Lasten prognostizieren und die Modellwahl-Strategie überdenken.
Metriken im klassischen Sinne sind hier zweitrangig – der Wert liegt in der Datenkonsistenz. Selbst ohne formalisierte KPIs erhalten Teams ein ganzheitliches Bild vom Verhalten der LLM-Last: Wo wird Geld ausgegeben, wo geht Zeit verloren und wo verhält sich das System instabil. Das verschiebt Observability von der Ebene „Grafiken anschauen“ hin zur Ebene architektonischer Entscheidungen.