Volver

Arquitectura de referencia: Despliega Langfuse en OVHcloud MKS para la observabilidad de los LLM y el seguimiento de los costes de IA

Eléa Petton23/07/202617 minutos de lectura
Arquitectura de referencia: Despliega Langfuse en OVHcloud MKS para la observabilidad de los LLM y el seguimiento de los costes de IA

El contexto

OVHcloud AI Endpoints ofrece una API compatible con OpenAI que permite a las aplicaciones acceder a un amplio catálogo de modelos de peso abierto, incluyendo Qwen, Llama, Mistral, gpt-oss, y modelos de embedding, protección y voz, sin que los equipos tengan que gestionar la infraestructura de inferencia. Es la capa de inferencia basada en el consumo supervisada por esta arquitectura.

OVHcloud Managed Kubernetes Service (MKS) elimina la carga operativa de ejecutar el control plane de Kubernetes: OVHcloud se encarga de los pools de nodos, las actualizaciones y la alta disponibilidad, mientras que tú mantienes el control total sobre lo que se ejecuta en los nodos de trabajo. Es el lugar natural para alojar una aplicación sin estado como los procesos web y worker de Langfuse, mientras que los componentes con estado (bases de datos, almacenamiento de objetos) se alojan en los servicios administrados de OVHcloud.

Langfuse proporciona la capa de observabilidad para aplicaciones que utilizan AI Endpoints. Como su integración con el SDK de OpenAI funciona como un remplazo directo (desde langfuse.openai import openai en lugar de import openai), conectar un código existente compatible con OpenAI a AI Endpoints y obtener una trazabilidad completa de su ejecución requiere cambiar solo dos líneas, sin necesidad de reescribirlo.

En conjunto, estos tres componentes proporcionan una pila de observabilidad autogestionada y con atribución de costes para cualquier aplicación que utilice AI Endpoints, sin enviar un solo token de prompt o de respuesta fuera de la infraestructura que controlas.

Arquitectura Langfuse

Langfuse en OVHcloud MKS para la observabilidad de los LLM y el seguimiento del consumo de tokens

Descripción general de la arquitectura

Los despliegues web y worker de Langfuse se ejecutan dentro del clúster MKS. La gestión del tráfico entrante y de los certificados se ejecuta en paralelo, como complementos del clúster independientes y reutilizables. Cada dependencia Stateful - Postgres, Valkey, ClickHouse, Object Storage - es un servicio gestionado por OVHcloud fuera del clúster, al que se accede a través de TLS.

1. Flujo de datos

Al integrar todos los componentes, el flujo de una solicitud con trazabilidad es el siguiente:

dataflow

Flujo de datos

1. La aplicación llama a AI Endpoints directamente

El cliente openai.OpenAI() actúa como sustituto directo y envía la solicitud directamente a la API de inferencia. Langfuse queda totalmente fuera de esta llamada, por lo que un fallo de Langfuse nunca impedirá que la aplicación obtenga una respuesta.

2. AI Endpoints transmite la respuesta de vuelta

El último chunk contiene los datos de uso de tokens.

3. El SDK exporta la información que acaba de recopilar como un lote de spans de OpenTelemetry

Esto se hace de forma asíncrona, a través de HTTPS, a /api/public/otel/v1/traces en la instancia de Langfuse.

Este proceso se ejecuta en segundo plano y no añade latencia a la respuesta que la aplicación ya ha recibido en el paso 2.

4. Langfuse web ingiere el lote

Comprueba la clave API de la solicitud con el proyecto correspondiente en Postgres (una consulta cuyo resultado se almacena en caché en Valkey, en lugar de realizar una nueva consulta con cada llamada), escribe el lote sin modificar en el almacenamiento de objetos, y añade únicamente una referencia al lote a una cola de Valkey.

5. El worker procesa la cola según su propia programación, independientemente de cualquier solicitud específica

Obtiene la referencia de Valkey, recupera el lote completo desde el almacenamiento de objetos, identifica la entrada correspondiente de Prompt Management a la que está enlazada (si la hay) a través de Postgres, y almacena los registros de trazas y generación en ClickHouse (modelo, número de tokens, latencia y precios)

6. El worker también gestiona las tareas programadas o en bloque

Las exportaciones por lotes y las cargas de archivos multimedia se almacenan en S3 de forma independiente del momento en que se haya producido la solicitud original.

⚠️ Importante: Nada de lo que ocurre a partir del paso 3 puede añadir latencia a la solicitud de la aplicación en los pasos 1 y 2. Esta transferencia asíncrona y el hecho de que Web no tenga que esperar a Postgres ni a ClickHouse para confirmar la recepción de un lote son precisamente los motivos por los que la trazabilidad no añade ningún coste al flujo crítico de la aplicación.

2. Las API de AI Endpoints

Todo lo que se describe a continuación utiliza una de las dos API de AI Endpoints de OVHcloud:

Esta es la API con la que realmente se comunica tu aplicación. Implementa la interfaz de la API de OpenAI, por lo que cualquier SDK compatible con OpenAI puede utilizarse con ella cambiando la base_url y la clave de 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 obtienes directamente el esquema OpenAPI desde la pasarela (GET /openapi.json), comprobarás que la interfaz disponible va mucho más allá de las sugerencias de chat.
 Es útil llamar directamente a la API GET /v1/models al menos una vez: devuelve todos los modelos a los que tiene acceso tu token.

La siguiente sección se centra en la API de catálogo, que permite obtener información adicional sobre los modelos, incluyendo los detalles de precios, necesarios para realizar el seguimiento de los costes.

Esta es la API que proporciona los datos de la página web del catálogo «AI Endpoints». Se trata de una simple solicitud GET que no requiere autenticación y devuelve la lista completa de modelos junto con los metadatos que aparecen en la interfaz del catálogo: descripción, puntuaciones de referencia, editor, licencia, tamaño de contexto, enlaces al playground y a la documentación, así como un bloque usage_information.pricing:

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

Retornos:

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

Las dos APIs tienen funciones complementarias:

  • la API de catálogo se consulta de manera puntual o periódica para generar tablas de precios y metadatos locales
  • la API de inferencia es a la que una aplicación en producción llama en cada solicitud

Las dos APIs tienen funciones complementarias:

  • la API de catálogo se consulta de manera puntual o periódica para generar tablas de precios y metadatos locales
  • la API de inferencia es a la que una aplicación en producción llama en cada solicitud
API de inferencia y API de catálogo de AI Endpoints

API de inferencia y API de catálogo de AI Endpoints

⚠️ Importante: Los precios de AI Endpoints están en euros.

Requisitos

Antes de comenzar, asegúrate de tener:

  • Una cuenta de OVHcloud Public Cloud
  • Un usuario de OpenStack con el rol de Administrador
  • Una clave de API de AI Endpoints
  • Un nombre de dominio que puedas hacer que apunte a un balanceador de carga
  • kubectl instalado y helm instalado (al menos la versión 3.x)

¡ Ahora ya tienes todos los ingredientes para desplegar Langfuse con OVHcloud MKS, y otros servicios administrados!

Guía de arquitectura: Despliegue de Langfuse en los servicios administrados OVHcloud Public Cloud

Paso 1 – Aprovisionar el clúster Kubernetes y los servicios administrados de OVHcloud

Los procesos web y worker de Langfuse consumen pocos recursos por sí mismos. Por tanto, la elección de los recursos depende casi por completo de los servicios administrados que los rodean. A continuación se detallan los pasos prácticos necesarios para configurar cada uno de ellos.

Todo lo que figura a continuación se crea desde el área de cliente de OVHcloud , en la sección Public Cloud del proyecto.

1. Crear el clúster MKS y los pools de nodos

1.1. Configurar el clúster

Desde el área de cliente de OVHcloud, crea un clúster de Kubernetes utilizando el MKS:

  • Nombre: langfuse-cluster
  • Ubicación: Región 1-AZ – Gravelines (GRA11)
  • Plan Gratis (o Standard)
  • Red: asignar una Red privada(p. ej., 0000 - Red privada AI)
  • Versión: Última versión estable (por ejemplo, 1,35)
1.2. Crear pools de nodos

Durante la creación del clúster, configura los dos pools de nodos.

El primero es el np-system. Ejecuta componentes a nivel de clúster, incluyendo Traefik (entrada) y cert-manager (certificados TLS), así como los daemonsets system Kubernetes por defecto.

  • Nombre del pool de nodos: np-system
  • Flavor: B3-8
  • Número de nodos 3
  • Autoescalado: Desactivado (OFF)

El segundo es el np-workload, dedicado a los pods de la aplicación Langfuse (web + worker).

  • Nombre del pool de nodos: np-workload
  • Flavor: B3-16
  • Número de nodos 1
  • Autoescalado: Desactivado (OFF)
1.3. Configurar el acceso a Kubernetes

Una vez que los nodos estén disponibles, puedes descargar el archivo Kubeconfig y configurar kubectl con tu clúster 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. Configurar las bases de datos

2.1. Base de datos Postgre para los datos transaccionales de Langfuse

Desde la sección Bases de datos en OVHcloud Public Cloud, haz clic en Crear un servicio y configúralo de la siguiente manera:

  • Motor: PostgreSQL
  • Versión: 17
  • Ubicación: GRA
  • Plan de servicio: Business
  • Instancia: Db1-4
  • Almacenamiento: 80 GB (por defecto)
  • Red: Red pública (internet)

Por favor, guarda la siguiente información segura antes de pasar a la siguiente etapa:
 - host
 - puerto
 - nombre de la base de datos
 - nombre de usuario
 - contraseña
 - URI

2.2. Base de datos Valkey para el almacenamiento en caché y la gestión de colas de trabajos

Desde la sección Bases de datos en OVHcloud Public Cloud, haz clic en Crear un servicio y configúralo de la siguiente manera:

  • Motor: Valkey
  • Versión: 8.1
  • Ubicación: GRA
  • Plan de servicio: Business
  • Instancia: Db1-4
  • Almacenamiento: 80 GB (por defecto)
  • Red: Red pública (internet)

Por favor, guarda la siguiente información de forma segura antes de pasar a la siguiente etapa:
 - host
 - puerto
 - nombre de la base de datos
 - nombre de usuario
 - contraseña
 - URI

2.3. ClickHouse, el corazón de los datos de observabilidad

Desde la sección Analytics en OVHcloud Public Cloud, haz clic en Crear un servicio y configúralo de la siguiente manera:

  • Motor: ClickHouse
  • Versión: 25.8
  • Ubicación: EU-WEST-PAR
  • Plan de servicio: Production
  • Instancia: B3-16
  • Almacenamiento: 100 GB (por defecto)
  • Red: Red pública (internet)

Por favor, guarda la siguiente información de forma segura antes de pasar a la siguiente etapa:
 - host
 - puerto
 - nombre de la base de datos
 - nombre de usuario
 - contraseña
 - URI

⚠ Importante: Las bases de datos gestionadas por OVHcloud (Postgres, Valkey, ClickHouse) deniegan todas las conexiones por defecto hasta que añadas las IP de origen permitidas en la página "Restricciones de IP" de cada instancia en el área de cliente de OVHcloud. Recuerda agregar las IP públicas del pool de nodos MKS a las tres bases de datos antes de desplegar Langfuse. De lo contrario, todas las conexiones desde el clúster acabarán agotando el tiempo de espera.

En la pestaña Configuración de cada base de datos, aplica la lista blanca de IP tal y como se muestra en el ejemplo siguiente:

Lista blanca de las IPs públicas del pool de nodos MKS

Lista blanca de las IPs públicas del pool de nodos MKS

3. Crear un bucket compatible con S3 como backend de almacenamiento

En la sección Object Storage de OVHcloud Public Cloud, crea un contenedor de objetos:

  • Tipo de contenedor: API compatible con S3
  • Ubicación: GRA

Por favor, guarda la siguiente información de forma segura antes de pasar a la siguiente etapa:
 - nombre del bucket
 - endpoint
 - clave de acceso
 - clave secreta

Paso 2 – Inicializar los namespaces y las cuotas

Crea espacios de nombres específicos para el controlador de entrada, el administrador de certificados y el propio Langfuse, y limita los recursos que puede consumir el espacio de nombres de Langfuse para evitar que una carga de trabajo descontrolada pueda afectar al resto del clúster.

Primero, crea:

A continuación, inicia el despliegue.

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

Paso 3 - Instalar el controlador de entrada y el administrador de certificados

Esta arquitectura utiliza Traefik en lugar de ingress-nginx. en lugar de ingress-nginx.Los comandos completos de instalación se incluyen en 

deploy/ingress/install.sh. Puedes ejecutar:. You can run:

bash
 bash deploy/ingress/install.sh

helm upgrade --install proporciona un nuevo Load Balancer de OVHcloud con una IP pública automáticamente. Espera a que se le asigne antes de seguir adelante:

bash
kubectl -n traefik get svc traefik -w

cert-manager maneja la emisión y renovación de certificados. Instálalo desde el registro OCI, que tanto OVHcloud como el proyecto original recomiendan ahora frente al repositorio Helm anterior.

Descarga el script cert-manager/install.sh y ejecuta:

bash
bash cert-manager/install.sh

A continuación, crea un ClusterIssuer para Let's Encrypt, utilizando Traefik como el "solucionador" HTTP-01.

En primer lugar, define tu propia dirección de correo electrónico en el archivocert-manager/cluster-issuer.yaml.

⚠️ Importante: Let's Encrypt utiliza esto para las notificaciones de vencimiento, y el registro cert-manager aceptará tácitamente un valor predeterminado si olvidas especificar uno. Este paso no debe hacerse hasta que cert-manager esté funcionando y la clase de entrada de Traefik esté en su lugar para que el resolver pueda referenciarla. Por lo tanto, ejecútalo una vez que las dos instalaciones descritas anteriormente estén completas:

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

⚠️ Importante: Debes fijar la versión del diagrama explícitamente (--version). De lo contrario, los dos comandos anteriores utilizarán por defecto la versión más reciente disponible en el momento de la instalación, lo que impedirá reproducir exactamente el mismo despliegue en el futuro.

Paso 4 - Configurar el DNS para que apunte al balanceador de carga

Una vez que el servicio Traefik disponga de una IP externa, crea un registro A para el nombre de host en el que estará disponible Langfuse:

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

Crea en tu zona DNS el resgistro langfuse.<your-domain>-> esa IP, y comprueba que se resuelve antes de continuar. De lo contrario, el HTTP-01 challenge del cert-manager fallará sin mostrar ningún error y volverá a intentarlo indefinidamente.

Paso 5 - Guarda las credenciales en un secreto de Kubernetes y configura los valores de Helm

El gráfico Helm de Langfuse obtiene todas las credenciales de un secreto, en lugar de almacenarlas como valores en texto plano, por lo que no es necesario incluir ningún dato confidencial en el archivo de valores:

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

El gráfico utilizado es el gráfico oficial langfuse/langfuse-k8s. Puedes encontrar el archivo completo en el repositorio GitHub OVHcloud public-cloud-examples: deploy/langfuse/values.yaml

⚠️ Importante: Cada deploy: false dice al diagrama que no instale sus propios subdiagramas de Postgres/Valkey/ClickHouse/MinIO y se conecte en su lugar a las instancias gestionadas de OVHcloud. Eso es lo que convierte esto en un despliegue de servicios administrados en lugar de uno autogestionado.

Paso 6 - Instalar Langfuse

Recupera el archivo deploy/langfuse/values.yaml del repositorio y realiza los cambios necesarios:

  • <your-domain>
  • <your-postgresql-host>
  • <your-valkey-host>
  • <your-clickhouse-host>
  • <your-bucket>

A continuación, guarda los valores.yaml actualizados y, por último, ejecuta deploy/langfuse/install.sh:

bash
bash deploy/langfuse/install.sh

Esta es la etapa final de la instalación: requiere el espacio de nombres y el secreto de los pasos 2 y 5, la resolución DNS del paso 4 (de lo contrario, el certificado TLS no se puede emitir) y el ClusterIssuer del paso 3, que ya debe existir.

A continuación, verifica que todo el proceso de despliegue se haya llevado a cabo sin problemas:

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

{"status":"OK","version":"<chart appVersion>"} en el endpoint de salud, y ambos pods Running sin reinicios, significa que la pila está funcionando: ingress, TLS, Postgres, Valkey, ClickHouse y S3 son todos accesibles.

Paso 7 – Instrumentación de una aplicación

1. Configura SDK en tu aplicación

Una vez que se pueda acceder a Langfuse, dirigir una aplicación hacia él es una cuestión de un intercambio de SDK, no una reescritura. Para una aplicación que ya utilice el SDK de Python openai contra los puntos de extremo de IA:

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

⚠️ Importante: Utiliza ejemplos/.env.example y edite esto .env archivo con tus propias variables de entorno. A continuación, carga las variables de entorno y configura el cliente Langfuse antes de importar langfuse.openai.

Para implementaciones de referencia completas y probadas de este patrón, que cubren conversaciones de múltiples turnos, etiquetado de sesiones/usuarios y gestión de indicaciones en cuatro perfiles de uso diferentes (generación de código, preguntas frecuentes, resumen de documentos, contenido de formato largo), consulta:

⚠️ Atención: Si consumes una respuesta en streaming, no dejes de iterar tan pronto como finish_reason == "stop". Varios proveedores compatibles con OpenAI, incluido AI Endpoints, envían el fragmento que contiene los datos de uso de tokens después de ese punto. Interrumpir la ejecución antes de recibirlo hace que Langfuse nunca llegue a registrarlo y que el coste de la traza aparezca como cero, aunque realmente se hayan consumido tokens.

Unos pequeños ajustes convierten una integración funcional en una integración realmente útil:

Tabla de características

2. Seguimiento de costes para el uso de AI Endpoints

Langfuse calcula el coste por traza a partir de una tabla de precios de modelos, y no tiene ninguna entrada para modelos alojados en OVHcloud de forma predeterminada: cada traza mostrará $0 en coste hasta que le indiques el precio de cada modelo. Ese es precisamente el propósito de la API de catálogo ("https://catalog.endpoints.ai.ovh.net/rest/v1/models_v2“) que hemos mencionado antes: consúltala una vez, registra el precio de cada modelo con la API de Models de Langfuse y, a partir de ese momento, los costes se calcularán automáticamente para todas las llamadas posteriores.

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

Se trata de una llamada puntal a la API, no de un script mantenido en este repositorio: una vez que se registra el precio de un modelo, este queda almacenado en Langfuse y cualquier cliente puede consultarlo allí. Consulta los ejemplos/README.md para la justificación completa, incluyendo por qué los precios se muestran en euros a pesar de la visualización de Langfuse en dólares.

Una vez que existe una definición de precio coincidente, el coste aparece inmediatamente en nuevas trazas.

En una llamada real contra Qwen3.5-397B-A17B: 

  • 28 tokens de entrada (0,60 € por millón de tokens)
  • 1430 tokens de salida (3,60 € por millón de tokens)

El calculatedTotalCost de Langfuse muestra exactamente: 28 * 0.0000006 + 1430 * 0.0000036 = 0.0051648€

Langfuse Cost Dashboard

Langfuse Cost Dashboard

⚠️ Importante: Langfuse siempre muestra el coste con un prefijo de $; no hay configuración de divisa por proyecto. Si la tabla de precios que importas está en euros, como la estructura de precios de OVHcloud AI Endpoints, todas las cifras en la interfaz de Langfuse son importes en euros mostrados con un signo de dólar.

También puedes revisar las diferentes métricas para la latencia del modelo:

Langfuse Latency Dashboard

Langfuse Latency Dashboard

Da un paso más allá y analiza las trazas, que representan solicitudes o operaciones.

Ejemplo de trazado de Langfuse

Ejemplo de trazado de Langfuse

¡Enhorabuena! Ahora tienes acceso a todas las funcionalidades de Langfuse en un entorno controlado.

Para ir más allá

  • Alta disponibilidad: esta arquitectura ejecuta una única réplica web y una única réplica de worker, que es suficiente para validar la configuración, pero no permite que se pueda expulsar un pod sin interrupción del servicio. En un despliegue orientado al público, aumenta a 2 o más las réplicas de web y añade un PodDisruptionBudget con un tamaño acorde: uno configurado para para una sola réplica no ofrece ninguna protección.
  • Autoscaling: ni HPA ni KEDA están habilitados por defecto; habilita uno si el volumen de solicitudes es impredecible.
  • Alertas sobre costes: la misma API de modelos utilizada para iniciar los precios puede consultarse de nuevo a través de la API de métricas de Langfuse para crear alertas de costes automatizadas por equipo o por función, en lugar de revisar los dashboards manualmente.
  • Políticas de red: no se define ninguna en esta configuración; considera restringir la salida del espacio de nombres Langfuse solo a los puntos de extremo de servicio gestionados que necesites.

Conclusiones

Esta arquitectura te ofrece un despliegue de Langfuse que:

  • Funciona en OVHcloud MKS sin bases de datos autogestionadas: Postgres, Valkey, ClickHouse y Object Storage son todos servicios administrados de OVHcloud
  • Termina TLS automáticamente a través de Traefik y cert-manager, renovando certificados sin intervención manual
  • Captura todas las trazas, incluido el uso de tokens y la latencia, de cualquier aplicación que llame a los AI Endpoints de OVHcloud mediante un cambio de SDK de dos líneas
  • Permite atribuir los costes por modelo, usuario y sesión a partir de los precios del catálogo de AI Endpoints, sin recurrir a estimaciones
  • Mantiene todos los prompts, respuestas y datos de coste dentro de la infraestructura que controlas
Compartir en: