LangFuse oder LangSmith: so überwachen und debuggen Sie KI-Anwendungen

Was ist KI-Observability, und warum reicht Ihr bestehendes Monitoring nicht?

KI-Observability ist die Überwachung von LLM-Anwendungen entlang von vier Größen: Ablauf, Latenz, Kosten, Antwortqualität. Klassisches APM misst Fehlerraten und Antwortzeiten. Ein Sprachmodell fällt aber selten mit einer Exception aus. Es antwortet falsch, mit HTTP 200. Genau diesen Fall sieht Ihr bestehendes Monitoring nicht.

Der erste Prototyp beeindruckt fast immer. Die Fragen kommen später, und sie klingen in jedem Projekt gleich: Warum hat das Modell im Kundengespräch etwas erfunden? Was kostet die API-Nutzung pro Tag? Warum dauert eine Antwort plötzlich acht Sekunden statt zwei? Welche Prompt-Version war eigentlich im Einsatz, als die Beschwerde kam?

Für klassische Software gibt es dafür Datadog, Sentry und Grafana. Für LLM-Anwendungen reichen diese Werkzeuge nicht, weil sich der Fehlerbegriff verschoben hat.

Die dritte Zeile ist die, die Budgets sprengt. Ein Prompt, der 400 statt 40 Zeilen Kontext mitschickt, verändert keine einzige Kennzahl in Ihrem APM. Auf der Modellrechnung steht am Monatsende das Zehnfache.

Was müssen Sie an einer LLM-Anwendung messen?

Fünf Dinge: den vollständigen Ablauf jedes Laufs, die Latenz je Schritt, die Token- und Eurokosten je Anfrage, die Antwortqualität über Bewertungen und die Fehlerquote. Ohne die ersten beiden suchen Sie Fehler im Dunkeln. Ohne die dritte sehen Sie eine Kostenexplosion erst auf der Rechnung.

Zielwerte hängen vom Anwendungsfall ab. Für interaktive Anwendungen rechnen wir mit unter drei Sekunden von Ende zu Ende und unter 200 Millisekunden für die Vektorsuche. Das sind Erfahrungswerte aus unseren Projekten, keine Norm. Wie man Agentenqualität systematisch bewertet statt sie zu behaupten, steht in KI-Agenten messen und bewerten.

Was leistet LangSmith, und für wen lohnt es sich?

LangSmith ist die Observability-Plattform des LangChain-Teams. Wer in LangChain oder LangGraph entwickelt, aktiviert vollständiges Tracing über eine Umgebungsvariable und sieht Agentenzyklen, Werkzeugaufrufe und Entscheidungspunkte ohne zusätzlichen Code. Das ist der kürzeste Weg zu brauchbaren Traces, den es derzeit gibt.

Neben dem Tracing gehören Datensatzverwaltung, LLM-as-a-judge, eigene Evaluatoren und Prompt-Versionierung zum Umfang. Seit Mai 2026 kommt die automatische Fehlergruppierung der LangSmith Engine dazu, die wiederkehrende Fehlermuster über viele Läufe zusammenfasst.

Preise, abgerufen am 14.08.2026

Die Zahlen stammen aus der Preisliste von LangSmith.

Wo LangSmith an Grenzen stößt

• Eigenbetrieb ist nur im Enterprise-Vertrag vorgesehen. Wer eine On-Premise-Vorgabe hat, kommt mit Developer oder Plus nicht weiter.
• Außerhalb von LangChain funktioniert die Anbindung, aber die Integrationstiefe ist geringer.
• Der Preis skaliert mit Traces und Nutzern zugleich. Bei sechs Entwicklern und hohem Volumen wird die Rechnung schnell zur eigenen Position im Budget.

Was leistet Langfuse, und warum ist es in der EU die naheliegende Wahl?

Langfuse ist unter MIT-Lizenz quelloffen, im Eigenbetrieb ohne Lizenzgebühr nutzbar und arbeitet mit jedem LLM-Framework. Für Teams mit Datenschutzvorgaben ist das der entscheidende Unterschied: Die Traces enthalten Prompts, Kontextdokumente und Modellantworten, also häufig personenbezogene Daten. Wo diese Daten liegen, ist eine Vertragsfrage.

Der Funktionsumfang deckt dasselbe Feld ab wie LangSmith. Traces auf OpenTelemetry-Basis, Sessions für mehrstufige Dialoge, numerische und kategoriale Scores aus automatischer Bewertung oder menschlichem Feedback, Prompt-Versionierung mit Labels, Datensätze für Regressionstests und Kostenberechnung je Modell. Bewertungen lassen sich als Gate in die CI/CD-Strecke hängen, sodass eine Prompt-Änderung mit gesunkener Qualität den Build stoppt.

Preise, abgerufen am 14.08.2026

Die Zahlen stammen aus der Preisliste von Langfuse.

Die Anbindung ist der zweite Grund für die Verbreitung. Die SDKs für Python und JavaScript bauen auf OpenTelemetry auf. Angebunden werden LangChain und LangGraph, LlamaIndex, das OpenAI SDK, das Anthropic SDK, Haystack, DSPy und das Vercel AI SDK. Eigener Code wird über den Dekorator @observe erfasst. Für ein Team, das mehrere Frameworks parallel betreibt, ist das der praktische Ausschlag.

Langfuse oder LangSmith: welche Unterschiede entscheiden wirklich?

Drei Unterschiede sind belastbar: die Lizenz, die Verfügbarkeit des Eigenbetriebs und die Framework-Bindung. Alles andere gleicht sich zwischen den beiden Plattformen weitgehend an. Wenn Ihre Vorgaben Eigenbetrieb oder EU-Datenresidenz verlangen, ist die Entscheidung bereits gefallen, bevor Sie Funktionslisten vergleichen.

Der folgende Funktionsvergleich stützt sich auf eine Gegenüberstellung von Langfuse mit Stand 07/2026. Die Quelle ist ein Wettbewerber und entsprechend interessengeleitet. Die Angaben zu Lizenz, Eigenbetrieb und Regionen haben wir gegen die Anbieterseiten geprüft, die Bewertung der Integrationstiefe ist Meinung, nicht Messung.

Wie sieht die Anbindung in Python aus?

Über Dekoratoren, ohne Umbau der Anwendungslogik. Das folgende Beispiel instrumentiert eine RAG-Strecke: Ein Elternspan umfasst den gesamten Lauf, darunter liegen Retrieval und Generierung als Kindspans. Die Zugangsdaten kommen aus Umgebungsvariablen, damit keine Schlüssel im Repository landen.

# pip install langfuse openai
# LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY und LANGFUSE_HOST
# liegen in der Umgebung. LANGFUSE_HOST zeigt entweder auf die
# EU-Cloud oder auf Ihre eigene Instanz.

from langfuse import get_client, observe
from openai import OpenAI

langfuse = get_client()
client = OpenAI()


@observe()
def kontext_abrufen(frage: str) -> list[str]:
    treffer = vektor_db.search(frage, top_k=5)
    langfuse.update_current_span(
        input=frage,
        output=treffer,
        metadata={"quelle": "qdrant", "top_k": 5},
    )
    return treffer


@observe(as_type="generation")
def antwort_erzeugen(frage: str, kontext: list[str]) -> str:
    antwort = client.chat.completions.create(
        model=einstellungen.llm_modell,
        messages=[
            {"role": "system", "content": f"Kontext: {kontext}"},
            {"role": "user", "content": frage},
        ],
    )
    langfuse.update_current_generation(
        metadata={"schritt": "antwort", "kontextlaenge": len(kontext)},
    )
    return antwort.choices[0].message.content


@observe()
def rag_pipeline(frage: str) -> str:
    kontext = kontext_abrufen(frage)
    return antwort_erzeugen(frage, kontext)

Das Ergebnis ist ein hierarchischer Trace. Für jeden Schritt sehen Sie Dauer, Tokenverbrauch und Kosten, und Sie können den konkreten Lauf später aus einer Beschwerde heraus rekonstruieren. Genau daran scheitern die meisten Nachforschungen ohne Tracing. Der Aufbau einer solchen Wissensstrecke steht in RAG-Systeme für die Unternehmens-Wissensdatenbank.

Welche Werkzeuge kommen sonst noch infrage?

Drei weitere Plattformen sind für europäische Projekte relevant, jede mit einem anderen Schwerpunkt. Braintrust setzt bei der Bewertung an, Arize Phoenix bei der RAG-Analyse, Helicone bei der Kostenkontrolle über einen Proxy. Keine davon ersetzt eine der beiden oben, sie lösen jeweils ein enger geschnittenes Problem. Weave von Weights & Biases steht am Ende, weil es nur für eine bestimmte Ausgangslage in Frage kommt.

Braintrust

Hier ist die Bewertung das Produkt, nicht das Zusatzmodul. Aus einem Produktionslauf wird per Klick ein Testfall, Experimente lassen sich über Datensätze und Scores vergleichen. Der Starter-Tarif kostet nichts und enthält laut Preisliste 10 USD Modellguthaben, 1 GB verarbeitete Daten und 10.000 Scores bei 14 Tagen Aufbewahrung. Pro liegt bei 249 USD im Monat.

Arize Phoenix

Quelloffen unter Apache 2.0, auf OpenTelemetry aufgebaut, per Docker oder Kubernetes selbst betreibbar. Die Stärke liegt in der Analyse von RAG-Strecken: Der visuelle Trace-Inspektor zeigt, welches Dokument abgerufen wurde und wie es in die Antwort eingeflossen ist. Wenn Ihr Hauptproblem lautet „der Abruf holt das Falsche“, ist Phoenix die schnellste Diagnose.

Helicone

Ein Proxy zwischen Ihrer Anwendung und dem Modellanbieter. Sie tauschen eine URL, danach wird jeder Aufruf protokolliert. Der Anbieter nennt auf seiner Preisseite einen kostenlosen Bereich und einen Sitzplatzpreis darüber, dazu Caching und Routing zur Kostensenkung. Die Latenz- und Einsparungsangaben sind Herstellerangaben, die wir nicht nachgemessen haben. Der Preis der Einfachheit: Was nicht durch den Proxy läuft, taucht auch nicht auf. Retrieval-Schritte und eigene Logik bleiben unsichtbar.

Weights & Biases Weave

Sinnvoll, wenn Ihr Team ohnehin mit W&B arbeitet und die LLM-Anwendungen im selben Werkzeug sehen will. Für ein Team ohne bestehende W&B-Installation ist der Umweg selten die Mühe wert.

Welchen regulatorischen Nutzen hat Tracing in der EU?

Artikel 12 der KI-Verordnung verlangt für Hochrisiko-Systeme eine automatische Ereignisprotokollierung über die gesamte Lebensdauer, damit Risiken und wesentliche Änderungen nachvollziehbar bleiben. Ein Tracing-System ist die technische Umsetzung dieser Pflicht. Es ersetzt keine Rechtsprüfung, erspart Ihnen aber ein Nachrüstprojekt.

Die Fristen haben sich verschoben. Die Verordnung (EU) 2026/1744 hat die Pflichten für Hochrisiko-Systeme auf den 02.12.2027 nach Anhang III und den 02.08.2028 nach Anhang I gelegt (Übersicht der Fristen). Der Wortlaut von Artikel 12 selbst ist davon unberührt. Die Transparenzpflichten nach Artikel 50 gelten seit dem 02.08.2026 unverändert.

Was der Datenschutz zusätzlich verlangt

Ihr Observability-Anbieter verarbeitet Prompts, Kontextdokumente und Antworten. Damit ist er Auftragsverarbeiter, und Sie brauchen einen Auftragsverarbeitungsvertrag nach Artikel 28 DSGVO mit den dort genannten Pflichtinhalten, von der Weisungsbindung bis zur Löschung nach Vertragsende. Bei einem Anbieter außerhalb der EU kommt die Prüfung des Drittlandtransfers dazu.

Genau hier trennen sich die beiden Kandidaten. Langfuse im Eigenbetrieb auf Ihrer eigenen Infrastruktur macht die ganze Frage zu einer internen Angelegenheit, weil kein Dritter die Daten sieht. Wer ohnehin über Datensouveränität nachdenkt, findet die Argumente in lokale KI-Modelle im Eigenbetrieb.

Wie treffen Sie die Entscheidung?

Über vier Fragen, in dieser Reihenfolge. Vorgaben zum Eigenbetrieb schlagen alles andere, danach kommt der Stack, dann der Schwerpunkt und zuletzt das Budget. Wer mit dem Budget anfängt, landet erfahrungsgemäß bei einem Werkzeug, das die eigentliche Vorgabe nicht erfüllt.

Zwei dieser Zeilen lassen sich kombinieren. Ein Proxy für die Kostensicht und ein SDK für die Ablauftiefe schließen sich technisch nicht aus. Zwei Systeme bedeuten allerdings zwei Rechnungen und zwei Oberflächen, in denen niemand nachschaut. Wir raten meistens ab.

Wie führen Sie Observability in ein laufendes Projekt ein?

In vier Schritten über etwa vier Wochen, ohne die Anwendung anzuhalten. Der Fehler, den wir am häufigsten sehen, ist der Versuch, sofort alles zu instrumentieren. Dann liegen nach zwei Wochen Millionen Spans vor, die niemand liest, und die erste Rechnung ist höher als erwartet.

Schritt 1: eine Strecke, echter Verkehr

Nehmen Sie den Ablauf, der am häufigsten Beschwerden erzeugt, und instrumentieren Sie nur diesen. Ein Elternspan, darunter Retrieval und Generierung. Sampling auf 100 Prozent, damit Sie in der Lernphase nichts verpassen. Nach zwei Wochen sehen Sie die reale Verteilung von Latenz und Kosten, nicht die geschätzte.

Schritt 2: Sitzungen und Nutzer verknüpfen

Ein einzelner Trace beantwortet selten die Frage, warum sich ein Kunde beschwert hat. Erst die Sitzung zeigt den Gesprächsverlauf. Setzen Sie eine Sitzungskennung und eine pseudonymisierte Nutzerkennung, keine Klarnamen und keine Mailadressen. Diese Entscheidung später nachzuholen ist teuer, weil alte Traces sich nicht rückwirkend zuordnen lassen.

Schritt 3: zwei Bewertungen, nicht zwanzig

Beginnen Sie mit Faithfulness und Antwortrelevanz, beides automatisch über ein Bewertungsmodell. Ergänzen Sie ein Daumen-hoch-Signal aus der Oberfläche. Mehr Kennzahlen erzeugen in den ersten Wochen mehr Diskussion als Erkenntnis. Wenn die beiden Werte stabil laufen, hängen Sie sie als Gate in die CI/CD-Strecke, damit eine Prompt-Änderung mit gesunkener Qualität nicht in die Produktion durchrutscht.

Schritt 4: Sampling und Aufbewahrung festlegen

Nach der Lernphase reicht meistens eine Teilmenge, ergänzt um alle Läufe mit Fehler oder niedriger Bewertung. Legen Sie die Aufbewahrungsdauer bewusst fest, denn sie ist zugleich eine Datenschutz- und eine Kostenentscheidung. Bei einem Hochrisiko-System nach der KI-Verordnung ist sie zusätzlich eine Compliance-Entscheidung, weil die Protokolle über die Lebensdauer des Systems verfügbar bleiben müssen.

Was kostet der Betrieb, und was kostet das Nichtmessen?

Die Werkzeuglizenz ist der kleinere Posten. Teuer wird die Nutzung selbst, und sie wird ohne Telemetrie unbemerkt teuer. TechCrunch berichtete am 05.06.2026, dass Uber sein gesamtes KI-Budget für Programmierwerkzeuge bereits im April aufgebraucht hatte und die Cursor-Verlängerung bei Priceline zum vier- bis fünffachen Preis zurückkam.

J.R. Storment, Geschäftsführer der FinOps Foundation, wird in demselben Artikel mit einem Satz zitiert, den wir in Projektgesprächen inzwischen regelmäßig hören: Unternehmen meldeten im Frühjahr, sie lägen beim Dreifachen ihres Jahresbudgets für Tokens, und es sei erst April.

Was ein Projekt bei uns kostet, hängt am Umfang, nicht am Observability-Werkzeug. Ein Chatbot mit Prozessanbindung liegt bei rund 2.600 bis 7.800 EUR, ein RAG-gestütztes Wissenssystem mit Zugriffssteuerung bei rund 7.800 bis 20.800 EUR, eine individuelle KI-Lösung mit Modellanpassung bei rund 13.000 bis 39.000 EUR. Alle Angaben sind Nettopreise, umgerechnet aus unserer HUF-Preisliste zum Kurs 385 HUF je EUR und als Richtwert zu verstehen. Verbindlich wird der Preis nach der Aufwandsabschätzung. Die vollständige Aufstellung steht unter Kosten der KI-Entwicklung 2026.

Welche Einsparungen sollten Sie nicht glauben?

In fast jedem Anbietertext zu diesem Thema stehen zwei Zahlen: 20 bis 40 Prozent Kostenersparnis durch Observability und ein Rückgang der Halluzinationsrate von 15 bis 20 auf unter 5 Prozent. Wir haben nach einer belastbaren Primärquelle gesucht und keine gefunden. Deshalb schreiben wir die Zahlen hier nicht als Versprechen hin.

Was sich belegen lässt, ist die Gegenrichtung. Gartner rechnet in einer Mitteilung vom 25.06.2025 damit, dass bis Ende 2027 mehr als 40 Prozent der agentischen KI-Projekte abgebrochen werden, und nennt als Gründe steigende Kosten, unklaren Geschäftsnutzen und unzureichende Risikokontrolle. Zwei dieser drei Gründe sind Messprobleme. Ohne Zahlen zu Kosten und Qualität lässt sich weder ein Budget verteidigen noch ein Risiko nachweisen.

Unsere ehrliche Einschätzung: Der belegbare Nutzen von Observability liegt in der Zeit. Eine Störung, deren Ursache ohne Traces einen halben Tag Rekonstruktion kostet, ist mit Traces in Minuten eingegrenzt. Wie stark das auf Ihre Kosten durchschlägt, hängt davon ab, wie oft Sie heute suchen müssen. Diese Zahl kennen Sie besser als wir.

Fazit

Die schlechteste Entscheidung ist, gar nicht zu messen. Wählen Sie ein Werkzeug, instrumentieren Sie eine Strecke und sehen Sie sich zwei Wochen echten Verkehr an. Danach wissen Sie mehr über Ihre Anwendung als aus jeder Werkzeugauswahl davor. Wenn Sie dabei Unterstützung wollen: Wir richten Tracing, Bewertung und Kostenkontrolle ein, mit AVV, EU-Hosting und Übergabe des Quellcodes. Was dazugehört, steht unter KI-Agenten-Entwicklung, ein Angebot erhalten Sie innerhalb von 24 Stunden über Angebot anfordern.

Häufige Fragen