Retour

Architecture de référence : déployer Langfuse sur OVHcloud MKS pour l'observabilité des LLM et le suivi des coûts d'IA

Eléa Petton23/07/202617 min de lecture
AI Endpoints
Architecture de référence : déployer Langfuse sur OVHcloud MKS pour l'observabilité des LLM et le suivi des coûts d'IA

Contexte

OVHcloud AI Endpoints propose une API compatible OpenAI qui ouvre aux applications l'accès à un large catalogue de modèles à poids ouverts (open-weight), parmi lesquels Qwen, Llama, Mistral et gpt-oss, ainsi que des modèles d'embedding, de guard et de speech, sans que les équipes aient à gérer la moindre infrastructure d'inférence. C'est la couche d'inférence, facturée à l'usage, que supervise cette architecture.

OVHcloud Managed Kubernetes Service (MKS) vous libère de la charge opérationnelle liée à l'exploitation du control plane Kubernetes. OVHcloud prend en charge les node pools, les mises à niveau et la haute disponibilité, tandis que vous gardez la maîtrise totale de ce qui tourne sur les nœuds de travail (worker nodes). C'est donc l'environnement naturel pour héberger une application stateless comme les processus web et worker de Langfuse, pendant que les composants stateful (bases de données, stockage d’objets) résident dans les services managés OVHcloud, à proximité immédiate.

Langfuse apporte la couche d'observabilité aux applications qui s'appuient sur AI Endpoints. Comme son intégration avec le SDK OpenAI fonctionne comme un remplacement direct (from langfuse.openai import openai à la place de import openai), faire pointer vers AI Endpoints une base de code déjà compatible OpenAI, et en obtenir un tracing complet, tient en deux lignes modifiées plutôt qu'en une réécriture.

Réunis, ces trois éléments forment une stack d'observabilité auto-hébergée, avec attribution des coûts, pour n'importe quelle application qui appelle AI Endpoints, sans qu'un seul token de prompt ou de complétion ne quitte l'infrastructure que vous maîtrisez.

Architecture de Langfuse

Langfuse sur OVHcloud MKS pour l'observabilité des LLM et le suivi de la consommation de tokens

Vue d'ensemble de l'architecture

Les déploiements web et worker de Langfuse s'exécutent au sein du cluster MKS. La gestion de l'ingress et des certificats s'exécute à leurs côtés, sous forme d'add-ons de cluster distincts et réutilisables. Chaque dépendance stateful (Postgres, Valkey, ClickHouse, Object Storage) est un service managé OVHcloud situé en dehors du cluster, joint via TLS.

1. Flux de données

Une fois les composants réunis, voici le parcours d'une requête tracée :

dataflow

Flux de données

1. L'application appelle AI Endpoints directement

Le client openai.OpenAI(), utilisé tel quel, envoie la requête directement à l'API d'inférence. Langfuse reste entièrement en dehors de cet appel, de sorte qu'une panne de son côté n'empêche jamais l'application d'obtenir une complétion.

2. AI Endpoints renvoie la réponse

Le dernier chunk contient les données de consommation de tokens.

3. Le SDK exporte ce qu'il vient d'observer sous forme de lot de spans OpenTelemetry

L'opération se fait de manière asynchrone, en HTTPS, vers /api/public/otel/v1/traces sur l'instance Langfuse.

Ce traitement s'exécute en arrière-plan et n'ajoute aucune latence à la réponse que l'application a déjà reçue à l'étape 2.

4. Le service web de Langfuse ingère le lot

Il vérifie la clé d'API de la requête par rapport à son projet dans Postgres (une recherche mise en cache dans Valkey, et non une nouvelle requête à chaque appel), écrit le lot brut tel quel dans le stockage d’objets, puis ne place qu'une référence vers celui-ci dans une file d'attente Valkey.

5. Le worker vide cette file d'attente à son propre rythme, découplé de toute requête particulière

Il récupère la référence depuis Valkey, extrait le lot complet du stockage d’objets, résout l'entrée Prompt Management à laquelle il est éventuellement rattaché via Postgres, puis enregistre durablement les traces et les générations dans ClickHouse (modèle, nombre de tokens, latence, prix).

6. Le worker prend aussi en charge tout ce qui est planifié ou traité en masse

Les exports par lots et les envois de médias arrivent dans S3 indépendamment du moment où la requête initiale a eu lieu.

⚠️ Remarque : rien à partir de l'étape 3 ne peut ajouter de latence à la requête de l'application aux étapes 1 et 2. Ce transfert asynchrone, et le fait que le service web ne se bloque jamais sur Postgres ni ClickHouse pour accuser réception d'un lot, expliquent à eux seuls pourquoi le tracing n'a aucun coût sur le chemin critique.

2. Les API d'AI Endpoints

Tout ce qui suit appelle l'une des deux API distinctes d'OVHcloud AI Endpoints :

C'est l'API à laquelle votre application s'adresse réellement. Elle implémente la surface d'API OpenAI, de sorte que n'importe quel SDK compatible OpenAI fonctionne avec elle en modifiant simplement le base_url et la clé d'API :
 

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"}],
 )

Si vous récupérez le schéma OpenAPI directement depuis la passerelle (GET /openapi.json), vous constaterez que l'interface disponible va bien au-delà des suggestions de chat.
 Il est utile d'appeler l'API GET /v1/models directement au moins une fois : elle renvoie tous les modèles auxquels votre token donne accès.

La section suivante se concentre sur l'API de catalogue, qui permet d'obtenir davantage d'informations sur les modèles, notamment les détails de tarification, indispensables au suivi des coûts.

C'est l'API qui alimente la page web du catalogue « AI Endpoints ». Il s'agit d'une simple requête GET, sans authentification, qui renvoie la liste complète des modèles ainsi que les métadonnées affichées dans l'interface du catalogue : description, scores de benchmark, éditeur, licence, taille de contexte, liens vers le playground et la documentation, ainsi qu'un bloc usage_information.pricing :

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

Renvoie :

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"}
       ]
     }
   }
 }

Les deux API sont complémentaires :

  • l'API de catalogue se consulte ponctuellement ou périodiquement pour construire des tables de prix et des métadonnées en local ;
  • l'API d'inférence est celle qu'une application en production appelle à chaque requête.

Les deux API sont complémentaires :

  • l'API de catalogue se consulte ponctuellement ou périodiquement pour construire des tables de prix et des métadonnées en local ;
  • l'API d'inférence est celle qu'une application en production appelle à chaque requête.
API d'inférence et de catalogue d'AI Endpoints

API d'inférence et de catalogue d'AI Endpoints

⚠️ Remarque : les prix d'AI Endpoints sont exprimés en euros.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

  • un compte OVHcloud Public Cloud ;
  • un utilisateur OpenStack doté du rôle Administrator ;
  • une clé d'API AI Endpoints ;
  • un nom de domaine que vous pouvez faire pointer vers un load balancer ;
  • kubectl installé et helm installé (au moins la version 3.x).

Vous disposez désormais de tous les ingrédients pour déployer Langfuse à l'aide d'OVHcloud MKS et d'autres services managés.

Guide d'architecture : déploiement de Langfuse sur les services managés OVHcloud Public Cloud

Étape 1 : provisionner le cluster Kubernetes et les services managés OVHcloud

Les processus web et worker de Langfuse sont légers en eux-mêmes. Le choix des ressources dépend donc presque entièrement des services managés qui les entourent. Ce qui suit détaille les étapes concrètes de mise en place de chacun d'eux.

Tout ce qui suit se crée dans l'espace client OVHcloud, dans la section Public Cloud de votre projet.

1. Créer le cluster MKS et les node pools

1.1. Configurer le cluster

Depuis votre espace client OVHcloud, créez un cluster Kubernetes à l'aide de MKS :

  • Nom : langfuse-cluster
  • Emplacement : région 1-AZ, Gravelines (GRA11)
  • Offre : Free (ou Standard)
  • Réseau : rattachez un réseau privé (par exemple 0000 - AI Private Network)
  • Version : dernière version stable (par exemple 1.35)
1.2. Créer les node pools

Lors de la création du cluster, configurez les 2 node pools.

Le premier est le np-system. Il exécute les composants au niveau du cluster, notamment Traefik (ingress) et cert-manager (certificats TLS), ainsi que les daemonsets système Kubernetes par défaut.

  • Nom du node pool : np-system
  • Flavor : B3-8
  • Nombre de nœuds : 3
  • Autoscaling : désactivé (OFF)

Le second est le np-workload, dédié aux pods de l'application Langfuse (web + worker).

  • Nom du node pool : np-workload
  • Flavor : B3-16
  • Nombre de nœuds : 1
  • Autoscaling : désactivé (OFF)
1.3. Configurer l'accès à Kubernetes

Une fois vos nœuds provisionnés, vous pouvez télécharger le fichier Kubeconfig et configurer kubectl avec votre cluster MKS.

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. Configurer les bases de données

2.1. Base de données Postgres pour les données transactionnelles de Langfuse

Dans la section Bases de données d'OVHcloud Public Cloud, cliquez sur Créer un service et configurez-le comme suit :

  • Moteur : PostgreSQL
  • Version : 17
  • Emplacement : GRA
  • Offre de service : Business
  • Instance : Db1-4
  • Stockage : 80 Go (par défaut)
  • Réseau : réseau public (Internet)

Conservez précieusement les informations suivantes avant de passer à l'étape suivante :
 - host
 - port
 - nom de la base de données
 - identifiant
 - mot de passe
 - URI

2.2. Base de données Valkey pour la mise en cache et la mise en file d'attente des tâches

Dans la section Bases de données d'OVHcloud Public Cloud, cliquez sur Créer un service et configurez-le comme suit :

  • Moteur : Valkey
  • Version : 8.1
  • Emplacement : GRA
  • Offre de service : Business
  • Instance : Db1-4
  • Stockage : 80 Go (par défaut)
  • Réseau : réseau public (Internet)

Conservez précieusement les informations suivantes avant de passer à l'étape suivante :
 - host
 - port
 - nom de la base de données
 - identifiant
 - mot de passe
 - URI

2.3. ClickHouse, le cœur des données d'observabilité

Dans la section Analytics d'OVHcloud Public Cloud, cliquez sur Créer un service et configurez-le comme suit :

  • Moteur : ClickHouse
  • Version : 25.8
  • Emplacement : EU-WEST-PAR
  • Offre de service : Production
  • Instance : B3-16
  • Stockage : 100 Go (par défaut)
  • Réseau : réseau public (Internet)

Conservez précieusement les informations suivantes avant de passer à l'étape suivante :
 - host
 - port
 - nom de la base de données
 - identifiant
 - mot de passe
 - URI

⚠ Remarque : les bases de données managées OVHcloud (Postgres, Valkey, ClickHouse) refusent toutes les connexions par défaut, tant que vous n'avez pas ajouté les adresses IP source autorisées sur la page « Restrictions IP » de chaque instance, dans l'espace client OVHcloud. Gardez à l'esprit que vous devez ajouter les adresses IP publiques de votre node pool MKS aux trois bases de données avant de déployer Langfuse, faute de quoi chaque connexion depuis le cluster expirera tout simplement (timeout).

Dans l'onglet Configuration de chaque base de données, appliquez la restriction par liste blanche d'IP comme dans l'exemple ci-dessous :

liste blanche des adresses IP publiques du node pool MKS

liste blanche des adresses IP publiques du node pool MKS

3. Créer un bucket compatible S3 comme backend de stockage

Dans la section Object Storage d'OVHcloud Public Cloud, créez un conteneur d'objets :

  • Type de conteneur : API compatible S3
  • Emplacement : GRA

Conservez précieusement les informations suivantes avant de passer à l'étape suivante :
 - nom du bucket
 - endpoint
 - clé d'accès
 - clé secrète

Étape 2 : initialiser les namespaces et le quota

Créez des namespaces dédiés pour le contrôleur d'ingress, le gestionnaire de certificats et Langfuse lui-même, puis plafonnez ce que le namespace de Langfuse peut consommer, afin qu'une charge de travail incontrôlée ne puisse pas mettre à mal le reste du cluster.

Commencez par créer :

Lancez ensuite le déploiement.

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

Étape 3 : installer le contrôleur d'ingress et le gestionnaire de certificats

Cette architecture utilise Traefik plutôt qu'ingress-nginx. Les commandes d'installation complètes sont fournies dans deploy/ingress/install.sh.

bash
 bash deploy/ingress/install.sh

helm upgrade --install provisionne automatiquement un nouveau OVHcloud Load Balancer doté d'une IP publique. Attendez qu'elle soit attribuée avant de poursuivre :

bash
kubectl -n traefik get svc traefik -w

cert-manager gère l'émission et le renouvellement des certificats. Installez-le depuis le registre OCI, désormais recommandé aussi bien par OVHcloud que par le projet en amont, de préférence à l'ancien dépôt Helm.

Téléchargez le script cert-manager/install.sh et exécutez :

bash
bash cert-manager/install.sh

Créez ensuite un ClusterIssuer pour Let's Encrypt, en utilisant Traefik comme « solver » HTTP-01.

Commencez par définir votre propre adresse e-mail dans le fichier cert-manager/cluster-issuer.yaml.

⚠️ Remarque : Let's Encrypt s'en sert pour les notifications d'expiration, et le registre cert-manager acceptera tacitement une valeur par défaut si vous oubliez d'en indiquer une. Cette étape doit attendre que cert-manager soit lui-même opérationnel et que la classe d'ingress Traefik soit en place, afin que le resolver puisse y faire référence. Exécutez-la donc une fois les deux installations décrites ci-dessus terminées :

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

⚠️ Remarque : vous devez épingler explicitement la version du chart (--version). Sinon, les deux commandes ci-dessus utiliseront par défaut la version la plus récente disponible au moment de l'installation, ce qui empêche de reproduire le déploiement à l'identique dans le temps.

Étape 4 : configurer le DNS pour pointer vers le load balancer

Une fois que le service Traefik dispose d'une IP externe, créez un enregistrement A pour le nom d'hôte sur lequel Langfuse sera servi :

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

Créez langfuse.<votre-domaine> pointant vers cette IP dans votre zone DNS, et vérifiez que la résolution fonctionne avant de continuer. Sinon, le challenge HTTP-01 de cert-manager échouera silencieusement et réessaiera indéfiniment.

Étape 5 : stocker les identifiants dans un secret Kubernetes et configurer les valeurs Helm

Le chart Helm de Langfuse lit chaque identifiant depuis un secret plutôt que depuis des valeurs en clair, de sorte qu'aucune donnée sensible n'a besoin de figurer dans le fichier de valeurs :

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>"

Le chart utilisé est le chart officiel langfuse/langfuse-k8s. Vous trouverez le fichier complet dans le dépôt GitHub OVHcloud public-cloud-examples : deploy/langfuse/values.yaml

⚠️ Remarque : chaque deploy: false indique au chart de ne pas installer ses propres sous-charts Postgres/Valkey/ClickHouse/MinIO, et de se connecter à la place aux instances managées OVHcloud. C'est ce qui fait de ce déploiement un déploiement sur services managés plutôt qu'auto-géré.

Étape 6 : installer Langfuse

Récupérez le fichier deploy/langfuse/values.yaml depuis le dépôt et apportez les modifications nécessaires :

  • <votre-domaine>
  • <votre-host-postgresql>
  • <votre-host-valkey>
  • <votre-host-clickhouse>
  • <votre-bucket>

Enregistrez ensuite le values.yaml mis à jour, puis exécutez enfin deploy/langfuse/install.sh :

bash
bash deploy/langfuse/install.sh

Il s'agit de l'étape finale de l'installation : elle requiert le namespace et le secret des étapes 2 et 5, la résolution DNS de l'étape 4 (sans laquelle le certificat TLS ne peut pas être émis), ainsi que le ClusterIssuer de l'étape 3, qui doit déjà exister.

Vérifiez ensuite que l'ensemble du processus de déploiement s'est déroulé sans accroc :

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

{"status":"OK","version":"<chart appVersion>"} sur le endpoint de santé, et les deux pods en Running sans redémarrage, signifie que la stack est opérationnelle : ingress, TLS, Postgres, Valkey, ClickHouse et S3 sont tous accessibles.

Étape 7 : instrumenter une application

1. Configurer le SDK dans votre application

Une fois Langfuse accessible, faire pointer une application vers lui est une simple affaire de remplacement de SDK, pas de réécriture. Pour une application qui utilise déjà le SDK Python openai avec AI Endpoints :

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"],
     },
 )

⚠️ Remarque : utilisez examples/.env.example et modifiez ce fichier .env avec vos propres variables d'environnement. Chargez ensuite les variables d'environnement et configurez le client Langfuse avant d'importer langfuse.openai.

Pour des implémentations de référence complètes et testées de ce schéma, couvrant les conversations multi-tours, le marquage session/utilisateur et la Prompt Management sur quatre profils d'usage différents (génération de code, FAQ, résumé de documents, contenu long format), voir :

⚠️ Avertissement : si vous consommez une réponse en streaming, n'arrêtez pas l'itération dès que finish_reason == "stop". Plusieurs fournisseurs compatibles OpenAI, dont AI Endpoints, envoient le chunk contenant la consommation de tokens après ce point. S'interrompre trop tôt signifie que Langfuse ne le voit jamais, et le coût de la trace s'affiche à zéro alors que des tokens ont bel et bien été consommés.

Quelques ajouts transforment une intégration fonctionnelle en une intégration utile :

Tableau des fonctionnalités

2. Suivi des coûts d'utilisation d'AI Endpoints

Langfuse calcule le coût par trace à partir d'une table de prix des modèles, et il ne comporte aucune entrée pour les modèles hébergés par OVHcloud d'origine : chaque trace affiche un coût de 0 $ tant que vous ne lui avez pas indiqué le coût de chaque modèle. C'est précisément à cela que sert l'API de catalogue (« https://catalog.endpoints.ai.ovh.net/rest/v1/models_v2 ») vue précédemment : interrogez-la une fois, enregistrez le prix de chaque modèle via la Models API de Langfuse, et le coût se calcule automatiquement pour chaque appel suivant.

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,
         },
     )

Il s'agit d'un appel d'API ponctuel, et non d'un script conservé dans ce dépôt : une fois le prix d'un modèle enregistré, il réside dans Langfuse même et n'importe quel client peut l'y retrouver. Voir examples/README.md pour l'explication complète, notamment la raison pour laquelle les prix ressortent en euros malgré l'affichage en $ de Langfuse.

Dès qu'une définition de prix correspondante existe, le coût apparaît immédiatement sur les nouvelles traces.

Sur un appel réel contre Qwen3.5-397B-A17B : 

  • 28 tokens en entrée (0,60 € par million de tokens)
  • 1430 tokens en sortie (3,60 € par million de tokens)

Le calculatedTotalCost de Langfuse ressort exactement à : 28 * 0,0000006 + 1430 * 0,0000036 = 0,0051648 €

Tableau de bord des coûts de Langfuse

Tableau de bord des coûts de Langfuse

⚠️ Remarque : Langfuse affiche toujours les coûts avec un préfixe $, il n'existe aucun réglage de devise par projet. Si la table de prix que vous importez est en euros, comme l'est la tarification d'OVHcloud AI Endpoints, chaque montant dans l'interface de Langfuse est une somme en euros affichée avec un signe dollar.

Vous pouvez également consulter les différentes métriques de latence des modèles :

Tableau de bord de la latence de Langfuse

Tableau de bord de la latence de Langfuse

Allez encore plus loin et analysez les traces, qui représentent des requêtes ou des opérations.

Exemple de tracing dans Langfuse

Exemple de tracing dans Langfuse

Félicitations ! Vous avez désormais accès à toutes les fonctionnalités de Langfuse dans un environnement maîtrisé.

Aller plus loin

  • Haute disponibilité : cette architecture exécute un seul réplica web et un seul réplica worker, ce qui suffit à valider la configuration mais ne laisse aucune marge pour l'éviction d'un pod sans interruption de service. Passez à 2 réplicas ou plus sur le web pour un déploiement exposé au public, et ajoutez un PodDisruptionBudget dimensionné en conséquence : un PodDisruptionBudget configuré pour un seul réplica ne protège rien.
  • Autoscaling : ni HPA ni KEDA ne sont activés par défaut. Activez l'un des deux si le volume de requêtes est imprévisible.
  • Alertes sur les coûts : la même Models API utilisée pour initialiser les prix peut être interrogée en retour via l'API de métriques de Langfuse, afin de construire des alertes de coût automatisées par équipe ou par fonctionnalité, plutôt que de consulter les tableaux de bord manuellement.
  • Politiques réseau : aucune n'est définie dans cette configuration. Envisagez de restreindre le trafic sortant du namespace Langfuse aux seuls endpoints des services managés dont il a besoin.

Conclusion

Cette architecture vous offre un déploiement de Langfuse qui :

  • s'exécute sur OVHcloud MKS sans aucune base de données auto-gérée (Postgres, Valkey, ClickHouse et Object Storage sont tous des services managés OVHcloud) ;
  • termine le TLS automatiquement grâce à Traefik et cert-manager, en renouvelant les certificats sans intervention manuelle ;
  • capture des traces complètes, y compris la consommation de tokens et la latence, depuis n'importe quelle application appelant OVHcloud AI Endpoints, via une modification de SDK de deux lignes ;
  • attribue le coût par modèle, par utilisateur et par session, en s'appuyant sur la tarification du catalogue d'AI Endpoints plutôt que sur des estimations ;
  • conserve chaque prompt, chaque complétion et chaque montant de coût au sein d'une infrastructure que vous maîtrisez.
Partager sur :