LLM-Observability im Vergleich: Langfuse, Helicone, LangSmith, Phoenix, Lunary, Portkey, OpenLLMetry, Traceloop, HoneyHive, W&B Weave

Was ist LLM-Observability?

LLM-Observability ist die Disziplin, die jede Anfrage an ein Sprachmodell, jeden Tool-Call eines Agents und jeden RAG-Retrieval-Hop nachvollziehbar macht. Klassische Anwendungs-Telemetrie (Prometheus, Datadog) reicht hier nicht. Sie sieht zwar, dass ein HTTP-Aufruf 1.8 Sekunden gedauert hat, aber sie sieht nicht, dass Claude Opus dabei 24 Tools aufgerufen, drei davon mit invaliden Argumenten, und dass die finale Antwort auf einem Halluzinations-Pfad endete. Genau dafür sind LLM-Observability-Tools gebaut.

Vier Bausteine grenzen die Kategorie ab. Erstens Tracing: jeder Call wird als Span aufgezeichnet, inklusive Prompt, Antwort, Token-Verbrauch, Latenz, Modell-Version. Mehrstufige Agent-Calls werden als Baum dargestellt. Zweitens Cost-Tracking: Tokens werden auf Preise umgerechnet, aggregiert pro Mandant, Modell, Funktion. Drittens Prompt-Versionierung: Prompts liegen als versionierte Artefakte vor, nicht als Hardcoded-Strings im Code. Viertens Evaluation: gegen Goldstandards oder Heuristiken wird gemessen, ob neue Modell- oder Prompt-Versionen besser oder schlechter sind.

Im Mai 2026 ist das Feld konsolidiert. Langfuse hat sich als OSS-Marktführer etabliert (24.000 GitHub-Stars, EU-Cloud in Frankfurt), Helicone und Lunary sind die bequemen Einsteiger, LangSmith dominiert im LangChain-Lager, OpenLLMetry pluggt LLM-Telemetrie in den Standard OpenTelemetry-Pfad. Wir haben Langfuse und Helicone in Produktion bei mehreren Mandaten - die Erfahrungen fliessen direkt in diesen Vergleich ein.

Warum die Wahl entscheidend ist

Drei Faktoren machen LLM-Observability für Schweizer KMU zur Pflicht, nicht zur Kuer. Erstens: Cost-Drift. Eine RAG-Pipeline mit Claude Sonnet kostet pro Anfrage einige Rappen. Ein einziger Bug im Prompt-Template kann den Kontext aufblaehen - zum Beispiel weil ein Loop versehentlich 200 Chunks statt 8 in den Prompt schiebt - und damit die Monatskosten um den Faktor 25 explodieren lassen. Ohne Cost-Tracking pro Anwendung und Modell fällt das erst auf der Rechnung des LLM-Providers auf, und dann zu spät.

Zweitens: Halluzinations-Audit. Wenn ein Mandant fragt "Warum hat das System mir geantwortet, dass mein MWST-Satz 8.1% ist?", muss die Antwort revisionsfähig sein: welcher Prompt wurde verwendet, welche Quellen wurden geliefert, welches Modell hat geantwortet. Genau das ist das Tracing-Artefakt einer LLM-Observability-Plattform. Ohne diese Aufzeichnung wird jeder Fehler zur "das System hat einfach so gesagt"-Diskussion.

Drittens: Daten-Residenz. Prompts und Antworten enthalten oft sensible Mandantendaten. Ein US-gehostetes LLM-Tracking-Tool, das Prompts speichert, ist unter revDSG und je nach Mandat unter StGB 321 problematisch. EU-Hosting ist hier hart entscheidend - und das engt die Liste deutlich ein. Langfuse Cloud bietet eine Frankfurt-Region, Helicone hat EU-Hosting, Portkey ebenso. LangSmith, HoneyHive und Weave laufen primär in den USA. Wer Self-host bevorzugt, kann Langfuse, Helicone, Phoenix, Lunary und SigNoz mit OpenLLMetry komplett on-prem betreiben.

Die zehn Werkzeuge im Detail

Langfuse (MIT, Self-host plus Cloud, EU-Region Frankfurt): der OSS-Marktführer. Mai 2026 in Version 3.x mit S3-basiertem Storage für beliebige Skalierung. Cost-Tracking pro Modell, User, Tenant. Prompt-Management mit Versionierung, Tagging, A/B-Testing. Eval-Framework mit LLM-as-Judge und Custom-Scoring. Wir nutzen Langfuse Self-host auf Hetzner für mehrere Mandate. Klare Empfehlung als Default.

Helicone (Apache 2.0, Self-host plus Cloud, EU-Hosting verfügbar): Proxy-basiert oder SDK. Setup in unter zehn Minuten - einfach die LLM-API-Basis-URL ändern, und alle Calls fliessen durch Helicone. Bequemer Einstieg, gute Cost-Caps und Rate-Limits eingebaut. Weniger umfangreich im Eval-Framework als Langfuse, dafür schneller startklar.

LangSmith (proprietär Cloud, USA): das Erst-Werkzeug der LangChain-Community. Wer LangChain ohnehin nutzt, hat hier die tiefste Integration. Eval-Framework sehr ausgereift. Nachteil: nur Cloud, US-Hosting (kein EU-Tier Stand Mai 2026), Bindung an das LangChain-Ecosystem.

Phoenix (Arize) (Elastic-2.0 OSS plus Arize Cloud): aus dem ML-Observability-Lager. Open-Source-Variante komplett self-host-fähig, deckt Embeddings-Visualisierung und Drift-Detection ab - das ist stärker als bei den reinen LLM-Tools. Arize-Cloud-Variante für Enterprise mit Enterprise-Preisliste.

Lunary (Apache 2.0 plus Cloud): einfache OSS-Alternative. Funktional kleiner als Langfuse, aber sehr schlank und schnell aufgesetzt. Gut für Mandate, die nur Cost-Tracking und basale Traces brauchen und kein Eval-Framework.

Portkey (proprietär Cloud plus Self-host-Tier, EU-Hosting): kombiniert Gateway plus Observability. Routet zwischen Providern (OpenAI, Anthropic, Google) und trackt gleichzeitig. Vorteil: weniger Komponenten im Stack. Nachteil: Lock-in, weil Gateway und Observability zusammen entschieden werden müssen.

OpenLLMetry (Apache 2.0, SDK von Traceloop): kein eigenes Backend, sondern eine SDK-Schicht, die LLM-Telemetrie als OpenTelemetry-Spans exportiert. Das heisst: jeder OTLP-fähige Backend (SigNoz, Grafana Tempo, Datadog, Honeycomb) kann LLM-Traces empfangen. Standardisierung auf Semantic Conventions for GenAI. Beste Wahl, wenn der Rest des Stacks bereits OpenTelemetry spricht.

Traceloop (MIT SDK plus proprietäres Backend, Self-host plus Cloud): die Firma hinter OpenLLMetry. Eigenes Backend mit Eval und Prompt-Mgmt, aber auch komplett über OTLP konsumierbar. Doppelte Strategie: OSS-SDK für Anbindung, Cloud für das Komfort-Backend.

HoneyHive (proprietär Cloud, USA): AI-Eval- und Tracing-fokussiert, mit starkem Eval-Workflow für Production-Setups. Stand Mai 2026 in den USA gehostet - für CH-Mandate mit revDSG-Anspruch nur mit Auftragsverarbeitungs-Vertrag denkbar. Strenge Eval-Methodik.

Weights & Biases Weave (proprietär Cloud plus OSS-SDK): W&B ist seit Jahren der ML-Tracking-Standard und hat mit Weave die LLM-Erweiterung gebaut. Sehr gut, wenn das Team ohnehin W&B für ML-Experimente nutzt. Sonst Overkill - das Setup ist gross für reines LLM-Tracing.

Auswahl in sechs Schritten

1. 01Volumen schätzen: wie viele LLM-Calls pro Tag, welche Modelle, durchschnittliche Token-Zahl? Unter 1000 Calls/Tag reicht Free-Tier.
2. 02Daten-Residenz prüfen: müssen Prompts in CH/EU bleiben? Wenn ja, LangSmith und HoneyHive raus, Langfuse oder Helicone EU bzw. Self-host.
3. 03Eval-Bedarf klären: brauche ich nur Tracing und Cost, oder auch ein Eval-Framework? Wenn Eval gebraucht: Langfuse, LangSmith, HoneyHive, Phoenix.
4. 04OpenTelemetry-Strategie prüfen: spricht der Rest des Stacks bereits OTLP? Dann OpenLLMetry plus bestehendes Backend.
5. 05Gateway-Frage: brauche ich auch Multi-Provider-Routing? Wenn ja, Portkey oder LiteLLM plus Langfuse als getrennte Komponente.
6. 06PoC in einer Anwendung: eine produktive Pipeline eine Woche lang instrumentieren, Cost-Reports und Trace-Detailtiefe prüfen. Erst dann auf alle Pipelines ausrollen.

Empfehlung je Szenario

CH-Treuhand oder Anwaltskanzlei mit RAG-Pipeline, revDSG-streng: Langfuse Self-host auf Hetzner Falkenstein. Ein CPX21 Server (3 vCPU, 4 GB RAM, ca. CHF 12/Monat) reicht für mehrere zehntausend Traces pro Monat. Postgres und ClickHouse als Backend. Setup in einem Tag. Alle Prompts und Traces bleiben in der EU.

Schneller Einstieg, KMU ohne Self-host-Bereitschaft: Helicone EU-Cloud. Proxy-Modus, API-Basis-URL ändern, fertig. Kosten startet bei USD 20/Monat plus pro 1000 Requests. Cost-Caps und Rate-Limits eingebaut - praktisch für Schutz vor Pipeline-Bugs.

LangChain-First-Setup: LangSmith. Wenn der Code ohnehin LangChain oder LangGraph nutzt, ist LangSmith ohne Konfiguration aktiv. Aber: US-Hosting muss in der Datenfluss-Analyse abgesegnet sein.

OpenTelemetry-First-Strategie: OpenLLMetry SDK plus SigNoz (oder Grafana Tempo). LLM-Traces werden als normale OTLP-Spans aufgezeichnet, im gleichen Backend wie der Rest des Stacks. Spart eine separate Tool-Kategorie.

Multi-Provider-Setup, Gateway plus Observability in einem: Portkey EU-Region. Routet zwischen OpenAI, Anthropic, Google, Mistral und trackt gleichzeitig. Lohnt sich, wenn ohnehin ein Gateway gebraucht wird. Alternative: LiteLLM plus Langfuse als getrennte Komponenten - flexibler, dafür mehr Setup.

ML-Team, das ohnehin W&B nutzt: Weave. Klare Integration in bestehende W&B-Experiments. Anders: Phoenix, wenn Drift-Detection und Embeddings-Analyse zentral sind.

Wann LLM-Observability übertrieben ist

Wer einen einzigen ChatGPT-Wrapper mit unter 1000 Anfragen pro Monat betreibt, braucht kein dediziertes Tracking-Tool. Die OpenAI Usage Dashboard und ein paar Logs reichen. Auch wer noch in der Experimentier-Phase ist und nur Prototyp-Calls testet, sollte den Aufwand sparen, bis die Pipeline produktiv geht.

Der typische Fehler bei der Tool-Auswahl ist die zu frühe Wahl der teuren Cloud-Variante. LangSmith für fünf Beta-User ist Geldverschwendung. Genauso: HoneyHive oder W&B Weave für ein Treuhand-Büro mit zwei produktiven Pipelines ist Overengineering. Faustregel: wenn die monatlichen LLM-Kosten unter CHF 50 liegen, reicht Langfuse-Cloud-Hobby-Tier (Free) oder Helicone Free. Erst bei CHF 200 und mehr lohnt der Self-host-Aufwand oder ein kostenpflichtiges Tier.

Vorsicht auch beim Mischen mehrerer Observability-Tools auf demselben Stack. Wir haben Mandate gesehen, die parallel LangSmith, Langfuse Cloud und Helicone laufen liessen, "weil jedes etwas anderes kann". Das Ergebnis: drei Wahrheits-Quellen, drei UIs, dreifacher Cost-Reporting-Aufwand. Wir empfehlen ein primäres System pro Pipeline plus eventuell OpenLLMetry für den Standardisierungs-Layer.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Langfuse Documentation - Open-source LLM engineering platform · 2026-05
2. Helicone Documentation - LLM observability proxy · 2026-04
3. OpenLLMetry - OpenTelemetry semantic conventions for GenAI · 2026-04
4. LangSmith Documentation - LangChain observability · 2026-04
5. Arize Phoenix - open-source ML and LLM observability · 2026-03