Langfuse self-hosted: LLM-Observability und Tracing on-premise neben Ihrem GPU-Server

LLM-Tracing self-hosted mit Langfuse und der Unterschied zu vLLM-Metriken

Langfuse ist eine Open-Source-Plattform für das Tracing von LLM-Anwendungen und lässt sich im eigenen Netz selbst betreiben: Die Dokumentation hält fest, dass Langfuse keinen Internetzugang benötigt („Langfuse does not require internet access“). Ein selbst gehostetes Langfuse speichert jede Anfrage eines RAG-Assistenten oder Agenten als Trace, einen Baum aus Schritten mit Eingaben, Ausgaben, Laufzeiten, Token-Zahlen und Kosten.

Eine Frage an einen internen Assistenten wird zu einem Trace mit einem Span für den Embedding-Aufruf, einem für die Vektorsuche, einem für den Reranker, je einem pro Tool-Aufruf und einem für die Antwort des Modells. Ist eine Antwort falsch oder langsam, zeigt der Trace, welcher Schritt die Ursache war.

Das ist eine andere Aufgabe als die Serving-Metriken der Inferenz-Engine. Unser Leitfaden zu vLLM-Metriken mit Prometheus und Grafana behandelt Warteschlangenlänge, Time to First Token und Cache-Auslastung: Zähler und Histogramme über alle Anfragen, ohne Anfragetext. Sie zeigen, dass die Latenz im 95. Perzentil um 10:40 Uhr gestiegen ist. Ein Langfuse-Trace einer langsamen Anfrage von 10:40 Uhr zeigt, dass das Retrieval 40 statt 8 Textabschnitte geliefert hat und der Prompt auf 30.000 Token gewachsen ist. Beides ergänzt sich und richtet sich an unterschiedliche Rollen: Das Plattformteam beobachtet die Metriken, das Team, das den Assistenten baut, liest die Traces.

Langfuse deckt auch die Arbeit rund um die Traces ab: Prompt-Verwaltung mit Versionen und Labels, Datensätze mit Testfragen, Bewertungen (Scores), die Menschen oder ein LLM als Richter an Traces hängen, und Dashboards zu Kosten und Latenz. Das LLM-Gateway vor Ihren Modellen führt das Abfrageprotokoll darüber, wer was gefragt hat; Langfuse sieht die Schritte der Anwendung innerhalb jeder Anfrage. Protokolliert das Gateway bereits jeden Aufruf, legen Sie fest, welches der beiden Systeme Prompt-Text speichert, damit dieselben personenbezogenen Daten nicht in zwei Speichern mit zwei Aufbewahrungsregeln liegen.

Komponenten eines selbst betriebenen Langfuse v4: PostgreSQL, ClickHouse, Redis, S3

Die Self-Hosting-Übersicht nennt sechs Teile. Nur der Web-Container muss für Nutzer und SDKs erreichbar sein; die übrigen bleiben in einem internen Netz.

Self-Hosting-Dokumentation von Langfuse (Übersicht, Infrastrukturseiten zu PostgreSQL, ClickHouse, Cache und Blob Storage, Abschnitt „minimum infrastructure requirements“ im Scaling-Leitfaden), gelesen am 25. Oktober 2026; neueste Version laut GitHub-Releases am 25. Oktober 2026.

Zusammengezählt ergeben die Mindestwerte nach unserer Addition 11 CPU-Kerne und 25,5 GiB Arbeitsspeicher, MinIO im eigenen Betrieb eingerechnet. Keiner der Dienste nutzt eine GPU. Drei Einstellungen verdienen bei einer neuen Installation Aufmerksamkeit. ClickHouse muss mit der Zeitzone UTC laufen, sonst liefern Abfragen falsche oder leere Ergebnisse. Redis braucht maxmemory-policy=noeviction, damit Jobs in der Queue nicht verdrängt werden. Und der S3-Bucket ist Pflicht: Langfuse schreibt bei jeder Ingestion-Anfrage die Rohdaten hinein und liest sie zurück, um fehlgeschlagene Ingestion-Jobs zu wiederholen; der Bucket wächst also, bis eine Lifecycle-Regel alte Objekte löscht (Langfuse Cloud nutzt laut derselben Seite 30 Tage).

Wer Langfuse v3 betreibt, sollte die Mindestversionen beachten: v3 lief mit ClickHouse ab 24.3, v4 verlangt 25.12. Planen Sie das Datenbank-Upgrade vor dem Langfuse-Upgrade und lesen Sie die Release Notes: v4.20.0 etwa ersetzte die Variablen LANGFUSE_AWS_BEDROCK_* und verkürzte die Standard-Sitzungsdauer auf 14 Tage.

Docker Compose oder Kubernetes

Die Docker-Compose-Variante besteht aus einem Klon des Repositorys und docker compose up auf einer Maschine. Der Leitfaden von Langfuse nutzt eine VM mit mindestens 4 Kernen und 16 GiB Arbeitsspeicher und als Beispiel 100 GiB Festplatte, stellt die Oberfläche auf Port 3000 und MinIO auf Port 9090 bereit, hält Worker, MinIO-Konsole und Datenbanken auf 127.0.0.1 und markiert jedes zu ersetzende Geheimnis mit # CHANGEME. Die Grenzen nennt er klar: Dem Compose-Setup fehlen Hochverfügbarkeit, Skalierung und Backup („lacks high-availability, scaling capabilities, and backup functionality“). Compose passt damit für einen Pilot mit einem Team und schlecht, sobald mehrere Anwendungen von den Traces abhängen.

Für den Produktivbetrieb verweist die Dokumentation auf Kubernetes mit dem Helm-Chart. Die ClickHouse-Seite empfiehlt mindestens drei ClickHouse-Replikas mit drei Keeper-Replikas, nennt als Produktivbeispiel 2 CPU-Kerne und 8 bis 16 GiB Arbeitsspeicher mit 100 GiB Speicher pro Replika und warnt, dass sich die Zahl der Replikas im Betrieb nicht ohne Handarbeit oder Ausfallzeit erhöhen lässt. Langfuse unterstützt keine ClickHouse-Cluster mit mehreren Shards. Das im Helm-Chart mitgelieferte ClickHouse und die Docker-Variante mit einem Container werden von der Community unterstützt; offiziell unterstützt sind ClickHouse Cloud, BYOC und der Kubernetes-Operator. Ein Unternehmen, das alles selbst betreibt, betreibt also ClickHouse selbst und sollte dieses Wissen einplanen.

Wir würden Langfuse auf eine VM oder einen Kubernetes-Cluster neben den GPU-Server stellen, nicht auf ihn. CPU-Kerne und Arbeitsspeicher eines GPU-Servers sind auf die Karten ausgelegt (mindestens sechs Kerne pro GPU und doppelt so viel Systemspeicher wie GPU-Speicher in unseren Referenz­konfigurationen, nach NVIDIAs Leitfaden für zertifizierte Systeme), und ein Treiber-Update oder ein Neustart des GPU-Servers sollte den Trace-Speicher nicht mitnehmen. Bei jedem selbst betriebenen ClickHouse verdienen außerdem die Systemtabellen Beachtung: Laut Scaling-Leitfaden haben trace_log, text_log und weitere System-Log-Tabellen standardmäßig keine TTL, Langfuse liest sie nicht, und sie können den Plattenplatz dominieren.

Traces senden: SDKs, LiteLLM und OpenTelemetry

Es gibt drei übliche Wege, die sich kombinieren lassen.

1. SDK in der Anwendung. Für Python-Code, der eine OpenAI-kompatible API aufruft, dokumentiert Langfuse einen Drop-in-Import, from langfuse.openai import openai, konfiguriert mit LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY und LANGFUSE_BASE_URL. Er zeichnet Prompts und Antworten, Latenzen, API-Fehler und Token-Verbrauch auf. Bei gestreamten Antworten kommt der Verbrauch nur mit stream_options={"include_usage": True}. Die Integrationsseite nennt nur die gehosteten APIs von OpenAI; die Unterstützung anderer OpenAI-kompatibler Server wie vLLM nennt sie nicht, testen Sie es also mit Ihrem.
2. Über das Gateway. Der Proxy von LiteLLM sendet jeden Aufruf, den er weiterleitet, an Langfuse, wenn in der Konfiguration callbacks: ["langfuse_otel"] steht und Schlüssel und Host von Langfuse als Umgebungsvariablen gesetzt sind. Das erfasst die Modellaufrufe aller Anwendungen hinter dem Gateway, aber nicht die Retrieval- und Tool-Schritte innerhalb einer Anwendung.
3. OpenTelemetry. Langfuse nimmt OTLP unter /api/public/otel an (ab v3.22.0), authentifiziert per HTTP Basic Auth aus öffentlichem und geheimem Schlüssel. Es akzeptiert HTTP/JSON und HTTP/protobuf; gRPC wird noch nicht unterstützt, ein vorgeschalteter OpenTelemetry Collector oder Exporter muss also HTTP verwenden. Der Header x-langfuse-ingestion-version=4 lässt Spans in Echtzeit erscheinen; ohne ihn können die Daten laut Dokumentation bis zu zehn Minuten brauchen. Langfuse bildet die GenAI-Attribute von OpenTelemetry wie gen_ai.request.model und gen_ai.usage.* ab und weist darauf hin, dass sich diese Konventionen noch ändern.

Für RAG und Agenten liefert der Weg über die Anwendung die nützlichsten Traces, denn nur die Anwendung weiß, welche Dokumente sie abgerufen und welches Tool sie aufgerufen hat. Langfuse empfiehlt, Nutzer-ID, Sitzungs-ID, Release und Tags an jeden Span weiterzugeben, nicht nur an den Wurzel-Span, damit Filter funktionieren. Es warnt auch davor, Passwörter, API-Schlüssel oder personenbezogene Daten in OpenTelemetry-Baggage zu legen, das an nachgelagerte Dienste weitergereicht wird.

Wir liefern die GPU-Server für die Modelle, die Sie tracen, und richten Modelle und Retrieval über unseren Private-AI/ML-Service ein; senden Sie uns Ihre Modelle, Anwendungen und das Anfragevolumen, und unser Team antwortet mit einer Serverkonfiguration.

Prompts in Traces: Maskierung, Zugriff, Aufbewahrung und Telemetrie

Ein Trace eines internen Assistenten enthält die Frage des Nutzers, die aus Ihren Dokumenten abgerufenen Textstellen und die Antwort des Modells. In den meisten Unternehmen sind das personenbezogene Daten und manchmal Geschäftsgeheimnisse. Die Lizenz entscheidet, wie viel Kontrolle Sie ohne Kosten bekommen. Die LICENSE-Datei stellt alles außerhalb der ee-Verzeichnisse unter die MIT-Expat-Lizenz, und Langfuse erklärt, dass alle Kernfunktionen und APIs in der Open-Source-Version ohne Einschränkungen verfügbar sind. Die Seite zum Lizenzschlüssel nennt die Funktionen, die einen Enterprise-Schlüssel brauchen: RBAC-Rollen pro Projekt, geschützte Prompt-Labels, Aufbewahrungs­richtlinien, Audit-Logs, serverseitiges Maskieren, Anpassung der Oberfläche, Organisationsersteller, die Organisations-API und SCIM, die Instanz-API und den FIPS-Modus.

Seiten von Langfuse zu Lizenzschlüssel, Data Masking, Authentifizierung und Telemetrie, gelesen am 25. Oktober 2026. Die Authentifizierungsseite kennzeichnet SSO nicht als Enterprise-Funktion.

Maskieren Sie zuerst in der Anwendung. Clientseitiges Maskieren entfernt Daten, bevor sie an Langfuse gesendet werden, und hält sie damit aus dem S3-Bucket ebenso heraus wie aus ClickHouse. Der serverseitige Callback der Enterprise-Edition gilt nur für Ereignisse, die über den OpenTelemetry-Endpunkt eingehen, und lässt Ereignisse standardmäßig durch: Schlägt der Callback fehl, wird das Ereignis unmaskiert gespeichert, es sei denn, die Fail-closed-Option (..._CALLBACK_FAIL_CLOSED=true) verwirft es. Langfuse selbst nennt ihn ein zentrales Sicherheitsnetz, keinen Ersatz für clientseitiges Maskieren.

Die Anmeldung funktioniert über Keycloak, Authentik, Okta, GitLab und andere Anbieter oder über einen eigenen OAuth-Anbieter mit AUTH_CUSTOM_CLIENT_ID, AUTH_CUSTOM_CLIENT_SECRET und AUTH_CUSTOM_ISSUER. Setzen Sie AUTH_DISABLE_SIGNUP=true, damit niemand ein Konto außerhalb Ihres Identity Providers anlegt, und AUTH_DISABLE_USERNAME_PASSWORD=true, sobald SSO funktioniert. Ohne die Enterprise-Rollen sieht jeder mit Zugriff auf ein Projekt alle Traces darin; trennen Sie sensible Anwendungen deshalb in eigene Projekte.

Ohne die Aufbewahrungsfunktion ist das Löschen Ihre Aufgabe: ein geplantes Löschen über die API oder eine TTL, die Ihr Datenbankteam setzt, dazu die Lifecycle-Regel im S3-Bucket. Wie lange Prompt-Text aufbewahrt werden darf, entscheidet Ihr Datenschutz­beauftragter; unser Leitfaden zur DSFA für ein internes LLM behandelt die Folgenabschätzung.

Der Web-Container der Open-Source-Version sendet höchstens alle 12 Stunden ein aggregiertes Telemetrie-Ereignis an eu.posthog.com: die Version, bis zu 30 E-Mail-Domains mit Nutzerzahlen und die Anzahl der Traces, Scores und anderer Objekte. Langfuse erklärt, dass keine rohen Traces, Prompts, Observations, Scores oder Datensatzinhalte gesendet werden. Die Update-Prüfung an langfuse.com ist nicht konfigurierbar und scheitert ohne Internetzugang ohne Folgen. Unser Artikel zu Telemetrie in selbst gehosteten KI-Tools zeigt, wie ein Egress-Filter den Rest blockiert.

Transport- und Speicherverschlüsselung richten Sie selbst ein. Langfuse terminiert HTTPS nicht selbst und empfiehlt dafür einen Load Balancer oder ein Service Mesh; ENCRYPTION_KEY schützt gespeicherte Zugangsdaten für LLM-APIs, nicht die Traces. Für die Platten darunter gilt unser Leitfaden zum Verschlüsseln eines GPU-Servers mit LUKS und TPM, der für einen Trace-Server genauso passt.

Speicher und Sizing: ein Beispiel

Langfuse veröffentlicht keine Größe pro Trace, weil sie von den Prompts abhängt. Ein Beispiel mit angenommenen Werten zeigt die Größenordnung. Ein interner Assistent für 300 Personen, die je 20 Fragen am Tag stellen, schreibt 6.000 Traces am Tag. Belegt ein Trace mit abgerufenen Textstellen, Antwort und Metadaten unkomprimiert 40 KB, sind das 240 MB am Tag und etwa 87,6 GB im Jahr in ClickHouse vor der Kompression, dazu die Rohereignisse im S3-Bucket: 7,2 GB bei einer Lifecycle-Regel von 30 Tagen. Das sind unsere Beispielwerte und unsere Rechnung; ClickHouse komprimiert die Daten, messen Sie also die echte Größe pro Trace im Pilot und rechnen Sie davon hoch.

Docker-Compose-Leitfaden, Scaling-Leitfaden und ClickHouse-Seite von Langfuse, gelesen am 25. Oktober 2026; Summen nach unserer Addition.

Der Scaling-Leitfaden nennt das Signal für Wachstum: Eine Worker-Last über 50 Prozent auf einem Container mit 2 CPUs bedeutet Sättigung, und die Queue-Tiefe langfuse.queue.ingestion.depth ist die wichtigste Skalierungsmetrik. Bei hoher Ingestion lassen sich die Ingestion-Pfade in ein zweites Web-Deployment abtrennen.

Evaluierungen mit eigenen Modellen

Der LLM-Playground und die Evaluierungen mit einem LLM als Richter rufen eine LLM-API auf. Die Netzwerkseite sagt, dass dieser Endpunkt im selben Netz laufen kann; der Richter kann also ein Modell auf Ihrem eigenen GPU-Server hinter dessen OpenAI-kompatibler API sein. So bleiben die Evaluierungs-Prompts, die Ihre Traces enthalten, im Unternehmen. Ein Richtermodell belegt GPU-Kapazität wie jeder andere Nutzer: Bewertet es jeden Produktiv-Trace, verdoppeln sich die Modellaufrufe; bewerten Sie deshalb eine Stichprobe oder lassen Sie Evaluierungen nachts gegen Datensätze laufen. Unser Leitfaden zur LLM-Evaluierung vor Modellwechseln behandelt Testsätze, Richtermodelle und ihre veröffentlichten Verzerrungen; Datensätze und Scores in Langfuse sind ein Ort, sie abzulegen.

Bei einem Server mit zwei Karten der NVIDIA RTX PRO 6000 Blackwell Server Edition legt eine mögliche Aufteilung das Produktivmodell auf eine Karte und einen Richter in eine MIG-Instanz mit 24 GB auf der anderen; unser Leitfaden zu MIG-Profilen nennt die Instanzgrößen. Wie groß ein Richtermodell sein muss, um Antworten gut zu bewerten, ist zu testen, denn ein kleiner Richter kann falschen Antworten zustimmen.

Was wir liefern

Sie können die GPU-Server bei uns kaufen: Unser Team legt die Konfiguration nach Ihrer Last und Ihrem Budget aus und antwortet innerhalb eines Werktages. Wir bauen sie auf Bestellung mit zwei, vier oder acht Karten der RTX PRO 6000 Server Edition oder mit H200 NVL, vor der Lieferung montiert und getestet, mit einem EU-Vertrag und einer EU-Rechnung und mit Herstellergarantie auf jede Komponente, abgewickelt über uns; Mengen und Lieferzeit werden mit dem Angebot schriftlich bestätigt. Unser Service Private AI/ML mit unserem Engineering-Partner Vixen.UNO setzt Modelle und Retrieval on-premise auf und baut die Plattform darum, einschließlich Protokollierung von Anfragen und Antworten. Beschreiben Sie die Anwendungen, die Sie tracen möchten, und wir schlagen vor, wo Modelle und Trace-Speicher laufen.

FAQ