Zurück

Referenzarchitektur: LLM-Observability und AI-Kostenverfolgung durch Bereitstellung von Langfuse auf OVHcloud MKS

Eléa Petton23.07.202615 Minuten Lesezeit
Referenzarchitektur: LLM-Observability und AI-Kostenverfolgung durch Bereitstellung von Langfuse auf OVHcloud MKS

Zusammenfassung

OVHcloud AI Endpoints stellt eine OpenAI-kompatible API bereit, die Anwendungen Zugang zu einem breiten Katalog an Open-Weight-Modellen bietet – darunter Qwen‑, Llama‑, Mistral‑ und gpt‑oss‑Modelle sowie Embedding‑, Guard‑ und Speech-Modelle –, ohne dass die damit arbeitenden Teams die Inferenzinfrastruktur selbst verwalten müssen. Es stellt die nutzungsbasierte Inferenzschicht dar, die von der vorliegenden Architektur überwacht wird.OVHcloud Managed Kubernetes Service (MKS)

beseitigt den betrieblichen Aufwand von Einrichtung und Instandhaltung der Kubernetes Control Plane: Node-Pools, Upgrades und Hochverfügbarkeit werden komplett von OVHcloud gemanagt. Sie selbst behalten die volle Kontrolle über alles, was auf den Worker-Nodes ausgeführt wird. Das macht ihn zum idealen Ort, um eine Stateless-Anwendung wie die Web‑ und Worker-Prozesse von Langfuse zu betreiben, während die Stateful-Bestandteile (Datenbanken, Objektspeicher) in angrenzenden OVHcloud Managed Services untergebracht sind.Langfuse

stellt die Observability-Schicht für Anwendungen bereit, die AI Endpoints nutzen. Da es sich bei der OpenAI-SDK-Integration um ein Drop-in-Replacement handelt (from langfuse.openai import openai anstatt import openai), lässt sich eine vorhandene OpenAI-kompatible Codebasis mit nur zwei geänderten Codezeilen so umstellen, dass sie auf AI Endpoints verweist – es ist also kein kompletter Rewrite erforderlich und ein vollständiges Tracing ist ebenfalls sichergestellt.Zusammen bilden diese drei Teile einen automatisch gehosteten Observability-Stack zur Kostenüberwachung für jede Anwendung, die auf AI Endpoints zugreift, ohne dass auch nur ein einziger Token aus den Prompt‑ oder Completion-Daten jemals die von Ihnen kontrollierte Infrastruktur verlässt.

Architekturübersicht

Langfuse-Architektur

Langfuse auf OVHcloud MKS für LLM-Observability und Verfolgung des Token-Verbrauchs

Die Web‑ und Worker-Deployments von Langfuse werden innerhalb des MKS-Clusters ausgeführt. Ingress‑ und Zertifikatsverwaltung laufen parallel dazu als separate, wiederverwendbare Cluster-Add-ons. Jede Stateful-Abhängigkeit – Postgres, Valkey, ClickHouse, Object Storage – ist ein OVHcloud Managed Service außerhalb des Clusters, der über TLS erreichbar ist.

Langfuse’s web and worker deployments run inside the MKS cluster. Ingress and certificate management run alongside them as separate, reusable cluster add-ons. Every stateful dependency – Postgres, Valkey, ClickHouse, object storage – is an OVHcloud managed service outside the cluster, reached over TLS.

1. Datenfluss

Setzt man alle Teile zusammen, verläuft eine verfolgte Anfrage wie folgt:

Datenfluss

Datenfluss

1. Die Anwendung ruft AI Endpoints direkt auf

Der Drop-in-Client openai.OpenAI() sendet die Anfrage direkt an die Inferenz-API. Langfuse bleibt dabei vollständig außerhalb dieses Aufrufs, sodass eine Störung von Langfuse in keiner Weise beeinträchtigen kann, ob die Anwendung eine vollständige Antwort (Completion) erhält.

2. AI Endpoints streamt die Antwort zurück

Der letzte Chunk enthält die Daten für den Token-Verbrauch.

3. Das SDK exportiert, was es gerade gesehen hat, als OpenTelemetry-Span-Batch

Dies geschieht asynchron via HTTPS an /api/public/otel/v1/traces auf der Langfuse-Instanz.

Dieser Prozess verläuft im Hintergrund und verursacht keine zusätzliche Latenz für die Antwort, die die Anwendung in Schritt 2 bereits empfangen hat.

4. Langfuse Web erfasst den Batch

Es gleicht den API-Schlüssel der Anfrage mit dem entsprechenden Projekt in Postgres ab (ein in Valkey zwischengespeicherter Lookup, keine neue Abfrage mit jedem Aufruf), schreibt den vollständigen Batch unverändert in den Object Storage und pusht nur einen Verweis dorthin in eine Valkey-Warteschlange.

5. Der Worker arbeitet diese Warteschlange unabhängig von einer bestimmten Anfrage nach seinem eigenen Zeitplan ab.

Er zieht den Verweis aus Valkey, ruft den kompletten Batch aus dem Object Storage ab, löst den gegebenenfalls über Postgres verknüpften Prompt-Management-Eintrag auf und speichert die Trace‑ und Generation-Einträge dauerhaft in ClickHouse ab (Modell, Tokenzahl, Latenz, Preise).

6. Der Worker übernimmt außerdem alles Geplante sowie alle Massenprozesse

Batch-Exporte und Medienuploads landen im S3, und zwar unabhängig davon, wann die ursprüngliche Anfrage gesendet wurde.

⚠️ Hinweis: Ab Schritt 3 kann nichts mehr Latenz zur Anfrage der Anwendung aus den Schritten 1 und 2 hinzufügen. Diese asynchrone Übertragung und die Tatsache, dass Web niemals darauf wartet, dass Postgres oder ClickHouse den Empfang eines Batch bestätigen, sind der Grund, warum Tracing auf dem kritischen Pfad keine Kosten verursacht.

2. AI Endpoints APIs

Alles Nachstehende ruft eine von zwei bestimmten OVHcloud AI Endpoints APIs auf:

Dies ist die API, mit der Ihre Anwendung tatsächlich kommuniziert. Sie implementiert das OpenAI-API-Interface, sodass jedes OpenAI-kompatible SDK damit verwendet werden kann, indem die base_url und der API-Schlüssel angepasst werden:
 

bash
import openai 
client = openai.OpenAI(
     api_key="<your-ai-endpoints-token>",
     base_url="https://oai.endpoints.kepler.ai.cloud.ovh.net/v1",
 )
 
 response = client.chat.completions.create(
     model="Qwen3.5-397B-A17B",
     messages=[{"role": "user", "content": "hello"}],
 )

Wenn Sie das OpenAPI-Schema direkt vom Gateway (GET /openapi.json) abrufen, können Sie sehen, dass das verfügbare Interface weit über reine Chat-Vorschläge hinausgeht.
 Es ist sinnvoll, die GET /v1/models-API mindestens einmal direkt aufzurufen, da sie alle Modelle anzeigt, auf die Ihr Token Zugriff gewährt.

Im folgenden Abschnitt geht es um die Katalog-API, über die Sie weitere Informationen zu den Modellen erhalten können, darunter detaillierte Preisinformationen, wie sie für die Kostenverfolgung erforderlich sind.

Auf dieser API basiert die Webkatalogseite von AI Endpoints. Es handelt sich um eine einfache GET-Anfrage, die keine Authentifizierung erfordert und eine vollständige Liste der Modelle zusammen mit den im Nutzerinterface des Katalogs angezeigten Metadaten ausgibt: Beschreibung, Benchmark-Ergebnisse, Herausgeber, Lizenz, Kontextgröße, Links zu Playground und Dokumentation sowie ein usage_information.pricing-Block:

bash
curl -s https://catalog.endpoints.ai.ovh.net/rest/v1/models_v2 | jq '.[0]'

Ausgabe:

bash
{
   "id": "qwen-3-5-397b",
   "name": "Qwen3.5-397B-A17B",
   "category": "Visual LLM",
   "metadata": {
     "aliases": ["Qwen/Qwen3.5-397B-A17B", "qwen3.5-397b-a17b"],
     "context": "262k",
     "usage_information": {
       "pricing": [
         {"price": 0.6, "price_unit": "million_input_tokens"},
         {"price": 3.6, "price_unit": "million_output_tokens"}
       ]
     }
   }
 }

Die beiden APIs ergänzen sich gegenseitig:

  • die Katalog-API ist ein einmaliger oder periodischer Pull zur Erstellung von lokalen Preistabellen und Metadaten
  • die Inferenz-API ist das, was eine laufende Anwendung mit jeder Anfrage aufruft

Die beiden APIs ergänzen sich gegenseitig:

  • die Katalog-API ist ein einmaliger oder periodischer Pull zur Erstellung von lokalen Preistabellen und Metadaten
  • die Inferenz-API ist das, was eine laufende Anwendung mit jeder Anfrage aufruft
Die Inferenz‑ und Katalog-APIs von AI Endpoints

Die Inferenz‑ und Katalog-APIs von AI Endpoints

⚠️ Hinweis: Bitte beachten Sie, dass die Preise von AI Endpoints in Euros angegeben sind.

Voraussetzungen

Bevor Sie anfangen, stellen Sie sicher, dass Sie:

  • Über einen OVHcloud Public Cloud Account verfügen
  • Einen OpenStack-User mit Administratorrechten haben
  • Einen AI Endpoints API-Schlüssel haben
  • Einen Domainnamen besitzen, den Sie auf einen Load Balancer verweisen lassen können
  • kubectl und helm installiert haben (mindestens Version 3.x)

Sie sind jetzt bereit, Langfuse mithilfe von OVHcloud MKS und anderen Managed Services zu deployen!

Architektur-Guide: Bereitstellung von Langfuse auf Managed Services der OVHcloud Public Cloud

Schritt 1 – Kubernetes-Cluster und OVHcloud Managed Services bereitstellen

Die Web‑ und Worker‑Prozesse von Langfuse an sich sind äußerst schlank. Die richtige Wahl der Ressourcen hängt daher fast ausschließlich von den verknüpften Managed Services ab. Im Folgenden werden die konkreten Schritte zur Einrichtung der einzelnen Managed Services erläutert.

Alles Nachstehende wird im OVHcloud Kundencenter im Public-Cloud-Bereich Ihres Projekts erstellt.

1. MKS-Cluster und Node-Pools erstellen

1.1. Cluster konfigurieren

Im OVHcloud Kundencenter erstellen Sie mithilfe des MKS einen Kubernetes-Cluster:

  • Name: langfuse-cluster
  • Standort: 1-AZ Region – Gravelines (GRA11)
  • Angebot: Free (oder Standard)
  • Netzwerk: Fügen Sie ein privates Netzwerk hinzu (z. B. 0000 - AI Private Network)
  • Version: die letzte stabile Version (z. B. 1.35)
1.2. Node-Pools erstellen

Konfigurieren Sie bei der Cluster-Erstellung die 2 Node-Pools.

Der erste ist np-system. Er führt Komponenten auf Cluster-Ebene aus, darunter Traefik (Ingress) und cert-manager (TLS-Zertifikate), sowie das standardmäßige Kubernetes-System daemonsets.

  • Name des Node-Pools: np-system
  • Flavor: B3-8
  • Anzahl der Nodes: 3
  • Autoscaling: Deaktiviert (OFF)

Der zweite Pool ist np-workload, der den Langfuse-Anwendungspods (Web + Worker) zugewiesen ist.

  • Name des Node-Pools: np-workload
  • Flavor: B3-16
  • Anzahl der Nodes: 1
  • Autoscaling: Deaktiviert (OFF)
1.3. Kubernetes-Zugriff konfigurieren

Sobald Ihre Nodes bereitgestellt sind, können sie die Kubeconfig-Datei herunterladen und kubectl mit ihrem MKS-Cluster konfigurieren.

bash
# configure kubectl with your MKS cluster
 export KUBECONFIG=/path/to/your/kubeconfig-xxxxxx.yml
 
 # verify cluster connectivity
 kubectl cluster-info
 kubectl get nodes
Returns:
NAME STATUS ROLES AGE VERSION
 np-system-node-388e55 Ready <none> 12d v1.35.2
 np-system-node-4c5326 Ready <none> 12d v1.35.2
 np-system-node-93bc1c Ready <none> 12d v1.35.2
 np-workload-node-3a76f7 Ready <none> 12d v1.35.2

2. Datenbanken konfigurieren

2.1. Postgres-Datenbank für Langfuse Transaktionsdaten

Gehen Sie in der OVHcloud Public Cloud in den Bereich Datenbanken, klicken Sie auf Dienst erstellen und konfigurieren Sie diesen wie folgt:

  • Engine: PostgreSQL
  • Version: 17
  • Standort: GRA
  • Dienstangebot: Business
  • Instanz: Db1-4
  • Storage: 80 GB (Standard)
  • Netzwerk: Öffentliches Netzwerk (Internet)

Bitte bewahren Sie die folgenden Informationen sicher auf, bevor Sie zum nächsten Schritt übergehen:
 - Host
 - Port
 - Datenbankname
 - Username
 - Passwort
 - URI

2.2. Valkey-Datenbank für Job-Caching und ‑Queuing

Gehen Sie in der OVHcloud Public Cloud in den Bereich Datenbanken, klicken Sie auf Dienst erstellen und konfigurieren Sie diesen wie folgt:

  • Engine: Valkey
  • Version: 8.1
  • Standort: GRA
  • Dienstangebot: Business
  • Instanz: Db1-4
  • Storage: 80 GB (Standard)
  • Netzwerk: Öffentliches Netzwerk (Internet)

Bitte bewahren Sie die folgenden Informationen sicher auf, bevor Sie zum nächsten Schritt übergehen:
 - Host
 - Port
 - Datenbankname
 - Username
 - Passwort
 - URI

2.3. ClickHouse, das Herzstück der Observability-Daten

Gehen Sie in der OVHcloud Public Cloud in den Bereich Analytics, klicken Sie auf Dienst erstellen und konfigurieren Sie diesen wie folgt:

  • Engine: ClickHouse
  • Version: 25.8
  • Standort: EU-WEST-PAR
  • Dienstangebot: Production
  • Instanz: B3-16
  • Storage: 100 GB (Standard)
  • Netzwerk: Öffentliches Netzwerk (Internet)

Bitte bewahren Sie die folgenden Informationen sicher auf, bevor Sie zum nächsten Schritt übergehen:
 - Host
 - Port
 - Datenbankname
 - Username
 - Passwort
 - URI

⚠ Hinweis: Die verwalteten Datenbanken von OVHcloud (Postgres, Valkey, ClickHouse) verweigern standardmäßig alle Verbindungen, bis Sie im Kundencenter auf der Seite „IP-Einschränkungen“ die zulässigen Quell-IPs hinzufügen. Denken Sie daran, die öffentlichen IPs Ihres MKS-Node-Pools zu allen drei Datenbanken hinzuzufügen, bevor Sie Langfuse deployen. Tun Sie das nicht, wird jede Verbindung vom Cluster sonst wegen Zeitüberschreitung ablaufen.

Gehen Sie für jede Datenbank in den Tab „Konfiguration“, um das IP-Whitelisting wie folgt vorzunehmen:

Whitelisting der öffentlichen IPs des MKS-Node-Pools

Whitelisting der öffentlichen IPs des MKS-Node-Pools

3. S3-kompatiblen Bucket als Storage-Backend einrichten

Gehen Sie in der OVHcloud Public Cloud in den Bereich Object Storage und erstellen Sie einen Objektcontainer:

  • Containertyp: S3-kompatible API
  • Standort: GRA

Bitte bewahren Sie die folgenden Informationen sicher auf, bevor Sie zum nächsten Schritt übergehen:
 - Bucket-Name
 - Endpoint
 - Zugriffsschlüssel
 - Secret Key

Schritt 2 – Namespaces und Quota konfigurieren

Erstellen Sie dedizierte Namespaces für den Ingress-Controller, den Zertifikatsmanager sowie für Langfuse selbst, und setzen Sie Grenzen für den Verbrauch des Langfuse-Namespace fest, damit ein außer Kontrolle geratener Workload nicht den gesamten Cluster lahmlegen kann.

Erstellen Sie zuerst:

Starten Sie dann das Deployment.

bash
kubectl apply -f deploy/bootstrap/namespaces.yaml
kubectl apply -f deploy/bootstrap/resourcequota.yaml

Schritt 3 – Ingress-Controller und Zertifikatsmanager installieren

Die vorliegende Architektur verwendet Traefik anstelle von ingress-nginx.Die vollständigen Installationsbefehle finden Sie in

deploy/ingress/install.sh. Sie können folgenden Befehl ausführen:. You can run:

bash
 bash deploy/ingress/install.sh

helm upgrade --install stellt automatisch einen neuen OVHcloud Load Balancer mit einer öffentlichen IP bereit. Warten Sie, bis dieser zugewiesen ist, bevor Sie fortfahren:

bash
kubectl -n traefik get svc traefik -w

cert-manager steuert die Ausgabe und Verlängerung von Zertifikaten. Installieren Sie ihn aus der OCI-Registry; sowohl OVHcloud als auch das Upstream-Projekt empfehlen diese vor dem inzwischen veralteten Helm-Repository.

Laden Sie das Skript cert-manager/install.sh herunter und führen Sie folgenden Befehl aus:

bash
bash cert-manager/install.sh

Erstellen Sie anschließend einen ClusterIssuer für Let's Encrypt; verwenden Sie hierzu Traefik als HTTP-01-„Solver“.

Legen Sie zunächst Ihre eigene E-Mail-Adresse in der cert-manager/cluster-issuer.yaml-Datei fest.

⚠️ Hinweis: Let's Encrypt verwendet diese für Benachrichtigungen zum Ablauf von Zertifikaten, und cert-manager wird automatisch einen Standardwert annehmen, sollten Sie vergessen, einen einzugeben. Dieser Schritt muss warten, bis cert-manager fertig eingerichtet ist und läuft und die Traefik-Ingress-Klasse vorliegt, damit der Resolver darauf verweisen kann. Führen Sie ihn daher erst aus, wenn die beiden oben beschriebenen Installationen abgeschlossen sind:

bash
kubectl apply -f cert-manager/cluster-issuer.yaml

⚠️ Hinweis: Sie müssen die Chart-Version explizit anpinnen (--version). Tun Sie das nicht, werden die beiden oben genannten Befehle automatisch die zum Zeitpunkt der Installation aktuellste verfügbare Version verwenden, wodurch das Deployment im Laufe der Zeit nicht exakt reproduziert werden kann.

Schritt 4 – DNS so konfigurieren, das es auf den Load Balancer verweist

Sobald der Traefik-Dienst über eine externe IP verfügt, erstellen Sie einen A-Eintrag für den Hostnamen, auf dem Langfuse erreichbar sein wird.

bash
kubectl -n traefik get svc traefik -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

Erstellen Sie den Eintrag langfuse.<ihre-domain>, um in Ihrer DNS-Zone auf diese IP zu verweisen, und stellen Sie sicher, dass richtig aufgelöst wird, bevor Sie fortfahren. Ist das nicht der Fall, wird die HTTP-01-Challenge des cert-managers unbemerkt fehlschlagen und es werden unendlich erneute Versuche gestartet.

Schritt 5 – Zugriffsdaten in einem Kubernetes-Secret speichern und Helm-Werte konfigurieren

Die Helm-Chart von Langfuse liest alle Login-Daten statt aus Klarwerten aus einem Secret, damit in der Werte-Datei keine sensiblen Daten enthalten sein müssen:

bash
kubectl -n langfuse create secret generic langfuse-secrets \
   --from-literal=LANGFUSE_SALT="$(openssl rand -base64 32)" \
   --from-literal=LANGFUSE_SECRET_KEY="$(openssl rand -hex 32)" \
   --from-literal=NEXTAUTH_SECRET="$(openssl rand -base64 32)" \
   --from-literal=POSTGRES_PASSWORD="<your-postgres-password>" \
   --from-literal=VALKEY_PASSWORD="<your-valkey-password>" \
   --from-literal=CLICKHOUSE_PASSWORD="<your-clickhouse-password>" \
   --from-literal=S3_ACCESS_KEY="<your-s3-access-key>" \
   --from-literal=S3_SECRET_KEY="<your-s3-secret-key>"

Die verwendete Chart ist die offizielle langfuse/langfuse-k8s-Chart. Die vollständige Datei finden Sie im OVHcloud GitHub-Repository public-cloud-examples:deploy/langfuse/values.yaml

⚠️ Hinweis: Jedes deploy: false sagt der Chart, dass sie keine eigenen Postgres/Valkey/ClickHouse/MinIO-Subcharts installieren und sich stattdessen mit den gemanagten Instanzen von OVHcloud verbinden soll. Das ist der Grund, warum es sich hierbei um ein Managed-Services-Deployment und nicht um ein selbstverwaltetes Deployment handelt.

Schritt 6 – Langfuse installieren

Rufen Sie die deploy/langfuse/values.yaml-Datei aus dem Repository ab und nehmen Sie die erforderlichen Änderungen vor:

  • <ihre-domain>
  • <ihr-postgresql-host>
  • <ihr-valkey-host>
  • <ihr-clickhouse-host>
  • <ihr-bucket>

Speichern Sie anschließend die aktualisierte values.yaml-Datei und führen Sie deploy/langfuse/install.sh aus:

bash
bash deploy/langfuse/install.sh

Dies ist der letzte Schritt der Installation: Sie benötigen den Namespace und das Secret aus den Schritten 2 und 5, die DNS-Auflösung aus Schritt 4 (sonst kann das TLS-Zertifikat nicht ausgegeben werden) und den ClusterIssuer aus Schritt 3, der bereits vorhanden sein muss.

Überprüfen Sie als Nächstes, dass der gesamte Deploymentprozess ordnungsgemäß ausgeführt wurde:

bash
kubectl -n langfuse get pods
curl -s https://langfuse.<your-domain>/api/public/health

{"status":"OK","version":"<chart appVersion>"} am Health-Endpunkt und beide Pods mit Status Running ohne Neustarts bedeutet der Stack läuft: Ingress, TLS, Postgres, Valkey, ClickHouse und S3 sind alle erreichbar.

Schritt 7 – Anwendung instrumentieren

1. Das SDK in Ihrer Anwendung einrichten

Ist Langfuse erreichbar, ist lediglich ein SDK-Wechsel nötig, und kein vollständiger Rewrite, um eine Anwendung auf Langfuse verweisen zu lassen. Für eine Anwendung, die bereits das openai-Python-SDK mit AI Endpoints nutzt:

bash
from dotenv import load_dotenv
 
 load_dotenv()  # OPENAI_API_KEY, OPENAI_BASE_URL, LANGFUSE_* must be loaded first
 
 from langfuse.openai import openai  # drop-in replacement for `import openai`
 
 client = openai.OpenAI()  # reads OPENAI_API_KEY / OPENAI_BASE_URL
 
 response = client.chat.completions.create(
     model="Qwen3.5-397B-A17B",
     messages=[{"role": "user", "content": "hello"}],
     stream=True,
     stream_options={"include_usage": True},
     name="chat-response",
     metadata={
         "langfuse_session_id": "session-123",
         "langfuse_user_id": "user-456",
         "langfuse_tags": ["feature:chat"],
     },
 )

⚠️ Hinweis: Verwenden Sie examples/.env.example und passen Sie diese .env-Datei mit Ihren eigenen Umgebungsvariablen an. Laden Sie dann die Umgebungsvariablen und konfigurieren Sie den Langfuse-Client, bevor Sie langfuse.openai importieren.

Vollständige und getestete Referenzimplementierungen dieses Musters – einschließlich Multi-Turn-Konversationen, Session/User-Tagging und Prompt Management in vier verschiedenen Nutzungsprofilen (Code-Generierung, FAQ, Dokumentzusammenfassung, Longform-Content) – finden Sie unter:

⚠️ Achtung: Falls Sie eine gestreamte Antwort nutzen, unterbrechen Sie die Iteration nicht direkt bei finish_reason == "stop". Mehrere OpenAI-kompatible Anbieter, darunter auch AI Endpoints, senden den Chunk mit dem Token-Verbrauch erst nach diesem Punkt; eine frühe Unterbrechung bedeutet, dass Langfuse diesen nie sieht und die Trace-Kosten als null angezeigt werden, obwohl tatsächlich Token verbraucht wurden.

Ein paar Ergänzungen machen eine funktionierende Integration zu einer wirklich nützlichen:

Funktionstabelle

2. Kostenverfolgung für den Verbrauch von AI Endpoints

Langfuse berechnet die Kosten pro Trace anhand einer Tabelle mit Modell-Preisen. Da keine Einträge für bei OVHcloud gehostete Modelle standardmäßig enthalten sind, wird jeder Trace als $0 angezeigt, bis Sie Langfuse selbst beigebracht haben, was jedes Modell kostet. Genau dafür ist die bereits erwähnte Katalog-API („https://catalog.endpoints.ai.ovh.net/rest/v1/models_v2“) da: einmal abrufen, den Preis jedes Modells in der Models API von Langfuse hinterlegen, und schon werden die Kosten automatisch für jeden weiteren Aufruf berechnet.

bash
import os
 import requests
 
 LANGFUSE_BASE_URL = os.environ["LANGFUSE_BASE_URL"]
 LANGFUSE_PUBLIC_KEY = os.environ["LANGFUSE_PUBLIC_KEY"]
 LANGFUSE_SECRET_KEY = os.environ["LANGFUSE_SECRET_KEY"]
 
 catalog = requests.get(
     "https://catalog.endpoints.ai.ovh.net/rest/v1/models_v2"
 ).json()
 
 for model in catalog:
     pricing = model.get("metadata", {}).get("usage_information", {}).get("pricing")
     if not pricing:
         continue
     prices = {
         {"million_input_tokens": "inputPrice", "million_output_tokens": "outputPrice"}[p["price_unit"]]: p["price"] / 1_000_000
         for p in pricing
         if p["price_unit"] in ("million_input_tokens", "million_output_tokens")
     }
     if not prices:
         continue
     requests.post(
         f"{LANGFUSE_BASE_URL}/api/public/models",
         auth=(LANGFUSE_PUBLIC_KEY, LANGFUSE_SECRET_KEY),
         json={
             "modelName": f"ovh-ai-endpoints/{model['id']}",
             "matchPattern": f"(?i)^({model['name']})$",
             "unit": "TOKENS",
             **prices,
         },
     )

Hierbei handelt es sich um einen einmaligen API-Aufruf und kein in diesem Repository gespeichertes Skript: Ist der Preis eines Modells einmal registriert, bleibt er in Langfuse hinterlegt und jeder Client kann ihn dort finden. Die vollständige Erklärung, einschließlich der Begründung, warum Preise in Euro angezeigt werden, obwohl Langfuse immer $ anzeigt, finden Sie in den Beispielen unter /README.md.

Sobald eine entsprechende Preisdefinition vorhanden ist, werden sofort Kosten für neue Traces angezeigt.

Bei einem echten Aufruf von Qwen3.5-397B-A17B: 

  • 28 Input-Token (0,60 € pro Million Token)
  • 1430 Output-Token (3,60 € pro Million Token)

Der von Langfuse errechnete Gesamtbetrag (calculatedTotalCost) beläuft sich auf genau: 28 x 0,0000006 + 1430 x 0,0000036 = 0,0051648 €

Kosten-Dashboard von Langfuse

Kosten-Dashboard von Langfuse

⚠️ Hinweis: Langfuse gibt Kosten immer mit $ als Präfix aus; es gibt keine Währungseinstellung pro Projekt. Falls die von Ihnen importierte Preistabelle in Euros angegeben ist (wie das bei den Preisen von OVHcloud AI Endpoints der Fall ist), wird jeder Betrag im Langfuse-Nutzerinterface mit einem Dollarzeichen angezeigt, auch wenn es sich eigentlich um einen Euro-Betrag handelt.

Sie können auch die verschiedenen Metriken für die Modell-Latenz einsehen:

Latenz-Dashboard von Langfuse

Latenz-Dashboard von Langfuse

Gehen Sie noch weiter und analysieren Sie die Traces, die Anfragen oder Operationen darstellen.

Tracing-Beispiel von Langfuse

Tracing-Beispiel von Langfuse

Geschafft! Sie haben nun Zugriff auf alle Langfuse-Funktionen in einer kontrollierten Umgebung.

Weiterführende Konfigurationen

  • Hochverfügbarkeit: Die vorliegende Architektur betreibt nur jeweils ein Web‑ und ein Worker-Replikat. Das reicht vielleicht aus, um die Einrichtung zu überprüfen, nicht jedoch für eine Pod-Räumung ohne Downtime. Erhöhen Sie die Zahl der Replikate für ein öffentliches Deployment auf 2 oder mehr für Web und fügen Sie ein entsprechend angepasstes PodDisruptionBudget hinzu – eine Konfiguration mit nur einem Replikat bietet keinerlei Schutz.
  • Autoscaling: Weder HPA noch KEDA ist standardmäßig aktiviert; aktivieren sie eines davon, falls das Anfragevolumen unvorhersehbar ist.
  • Kostenwarnungen: Dieselbe Models API, die zum initialen Befüllen der Preise verwendet wird, kann über die Metrics API von Langfuse auch in die andere Richtung abgefragt werden, um automatische Kostenwarnungen für ein bestimmtes Team oder Feature einzurichten und so ein manuelles Überprüfen des Kosten-Dashboards zu umgehen.
  • Netzwerkrichtlinien: In dieser Konfiguration sind keine Netzwerkrichtlinien definiert. Sie haben die Möglichkeit, den ausgehenden Datentraffic (Egress) aus dem Langfuse-Namespace auf die nötigen Managed-Service-Endpunkte zu begrenzen.

Fazit

Mit der vorliegenden Architektur verfügen Sie über ein Langfuse-Deployment, das:

  • Ohne selbstverwaltete Datenbanken auf OVHcloud MKS läuft – Postgres, Valkey, ClickHouse und Object Storage sind alles OVHcloud Managed Services
  • TLS automatisch über Traefik und cert-manager terminiert und Zertifikate ohne manuelle Eingriffe verlängert
  • Vollständige Traces, einschließlich Token-Verbrauch und Latenzen, für jede Anwendung erfasst, die OVHcloud AI Endpoints aufruft – und all das durch die Änderung von nur zwei SDK-Zeilen
  • Kosten anhand des AI Endpoints-Preiskatalogs je Modell, User und Sitzung zuweist, anstatt nur Schätzungen abzugeben
  • Jeden Prompt, jede Completion und jeden Kostenbetrag innerhalb der von Ihnen kontrollierten Infrastruktur behält
Teilen auf: