Pourquoi le traçage est indispensable sur la passerelle

Lorsqu'un appel LLM est lent, coûteux ou erroné, vous devez comprendre ce qui s'est réellement passé. Un garde-fou a-t-il modifié le prompt ? Combien de temps le modèle a-t-il pris par rapport au réseau ? Qu'est-ce que la passerelle a envoyé au fournisseur ? La journalisation et le traçage des requêtes sur la Passerelle IA répondent à ces questions pour chaque appel.

Comme chaque requête transite déjà par la passerelle, vous bénéficiez de cette visibilité sans avoir à instrumenter manuellement chaque application.

Contrôler ce qui est journalisé

Ladocumentation sur la journalisation des requêtes vous permettent de contrôler quelles requêtes sont journalisées. Le contrôle le plus simple s'effectue par requête, en utilisant l'en-tête X-TFY-LOGGING-CONFIG avec une valeur JSON sous forme de chaîne. Définissez « enabled » sur « true » pour journaliser la requête ou sur « false » pour l'ignorer.

Un point important à noter : la valeur de cet en-tête est un JSON sous forme de chaîne de caractères, et non un objet JSON brut, car la plupart des SDK sérialisent les en-têtes sous forme de chaînes. Les anciens modes de journalisation globale sont remplacés par une configuration de journalisationbasée sur des règles, qui vous permet de contrôler la journalisation par sujet, modèle ou métadonnée, et de masquer les valeurs sensibles.

Visualiser les journaux de requêtes

Pour consulter les requêtes journalisées dans l'interface, accédez à AI Gateway, puis à Monitor, et enfin à Requests. Vous obtiendrez la liste de tous les appels journalisés, que vous pourrez ouvrir pour inspecter chaque requête en détail.

Traces et spans : explications

Ladocumentation sur le traçage décrit une trace comme le cycle de vie complet d'une requête à mesure qu'elle transite par les services interagissant avec le LLM. En général, une trace correspond à un appel API unique d'une application.

Un span est une unité de travail individuelle au sein de cette trace, comme un appel de fonction, une requête HTTP ou une inférence de modèle. Une trace est une arborescence de spans avec des relations parent-enfant, où un span enfant est généralement provoqué par son parent. TrueFoundry fournit un backend de collecte OpenTelemetry qui stocke ces traces ainsi qu'une interface pour les interroger et les analyser ; il peut recevoir des traces provenant de n'importe quel SDK compatible OpenTelemetry.

Can you explain why your last slow request was slow?

We will open a live trace on your traffic and walk the span tree with you.

Book a demo

Lire une trace unique

‍

Ladocumentation sur l'inspection des traces examinons un exemple concret : une complétion de chat avec une barrière de protection pour la rédaction des données personnelles (PII), capturée sous forme de cinq spans formant une hiérarchie.

‍

• Span ChatCompletion (racine) représente le cycle de vie complet de la requête du point de vue du client. Dans cet exemple, elle dure environ 7 secondes et contient les métriques de jetons, le coût, ainsi que les entrées et sorties.
• Span Guardrail est un enfant de la racine et représente le traitement de la rédaction des PII, durant moins d'une demi-seconde.
• Span d'appel réseau Guardrail correspond à l'appel HTTP réel vers le service de barrière de protection, incluant la méthode HTTP et le code de statut.
• Span Modèle est un frère du span de la barrière de protection et représente l'inférence du modèle, occupant la majeure partie du temps de la requête.
• Span d'appel réseau Modèle correspond à l'appel HTTP réel vers le fournisseur, par exemple une requête POST vers le point de terminaison de complétion de chat du fournisseur.

‍

Dans ce même exemple, l'entrée est visiblement expurgée, passant d'un nom à un espace réservé, ce qui démontre le fonctionnement de bout en bout de la barrière de protection PII au sein de la trace.

‍

Une trace de complétion de chat montrant les spans de la barrière de protection, du modèle et du réseau sortant.

‍

D'une trace unique aux métriques à l'échelle de la flotte

‍

Les traces individuelles servent au débogage. Pour les tendances, le tableau de bord analytique agrège ces mêmes données. Les onglets couvrent la vue d'ensemble, les métriques de modèle, les métriques MCP, les métriques de barrière de protection, les métriques de routage et les métriques de cache.

‍

Les métriques de modèle peuvent être regroupées par modèles, modèles virtuels, utilisateurs, comptes virtuels, équipes ou métadonnées. Les vues de latence décomposent la latence des requêtes, le temps jusqu'au premier jeton, la latence entre les jetons et le temps par jeton de sortie. Associé aux traces par requête, cela vous offre à la fois le microscope et le tableau de bord.

‍

Métriques de modèle dans le tableau de bord analytique, regroupables par équipe, utilisateur, modèle, et plus encore.

‍