Liens importants
Tableau de bord d’état du service (actuellement disponible uniquement pour les clients Enterprise API)
Commencer avec les bons paramètres par défaut
Lorsque vous ouvrez le tableau de bord d’état du service, les valeurs par défaut sont :
Tous les projets
30 derniers jours
Résolution horaire
Cette vue est utile uniquement pour s’orienter. Une résolution pertinente des problèmes nécessite toujours un filtrage.
Filtrer avant d’analyser
Un filtrage correct est l’étape la plus importante. La plupart des mauvaises interprétations viennent du mélange de modèles, d’offres ou de projets.
Filtrer par modèle (un à la fois)
Filtrez toujours sur un seul modèle.
Pourquoi :
Les problèmes sur des modèles à faible trafic peuvent être masqués par un trafic plus important
Les modèles à fort volume peuvent faire paraître des problèmes localisés comme globaux
Les différents modèles ont des objectifs de performance différents
Remarque : sélectionner plusieurs modèles les agrège ; cela ne permet pas de passer de l’un à l’autre.
Filtrer par offre
Si vous utilisez plusieurs offres (standard, mode Rapide, anciennement traitement prioritaire, offre Scale), filtrez toujours selon l’offre que vous examinez.
Pourquoi :
Les offres présentent des caractéristiques de performance différentes
Le mode Rapide et l’offre Scale disposent de SLA définis
Le mélange des offres masque les performances des offres payantes
C’est particulièrement important pour l’analyse de la latence.
Pour les modèles existants, le trafic du mode Rapide apparaît toujours comme prioritaire dans le tableau de bord d’utilisation.
Filtrer par projet
Par défaut, l’état du service affiche tous les projets.
Pour résoudre les problèmes, filtrez sur le ou les projets où le problème a été observé.
Pourquoi :
Un seul projet à fort volume peut dominer les métriques.
Les projets affectés plus petits peuvent être masqués par du trafic sans rapport.
Ne laissez « Tous les projets » sélectionné que si vous pensez que le problème touche réellement toute l’organisation.
Résolution des erreurs
Utiliser la vue des requêtes HTTP
Pour analyser les erreurs :
Filtrez par modèle et par offre.
Ouvrez l’onglet Requêtes HTTP au lieu de l’onglet Disponibilité.
Cette vue affiche le nombre total de requêtes et le nombre d’erreurs par code d’état HTTP. Zoomez jusqu’à une résolution à la minute pour identifier les pics ou changements précis.
Interpréter les taux d’erreur, pas les nombres
Certaines erreurs sont attendues dans tout système de production. Concentrez-vous sur le pourcentage d’erreurs, et non sur les totaux bruts.
Plus votre volume total est élevé, plus le nombre potentiel d’erreurs est important, même avec un taux d’erreur extrêmement faible.
Lorsque des erreurs sont absentes de l’état du service
Si vous voyez des erreurs côté client mais aucune donnée correspondante dans l’état du service :
Les requêtes n’ont probablement pas atteint OpenAI.
Le problème se situe généralement en amont (délais d’expiration, proxys, réseau).
C’est fréquent avec des délais d’expiration côté client agressifs.
Résolution des problèmes de latence
L’analyse de la latence est surtout pertinente pour le mode Rapide et l’offre Scale, qui disposent de SLA définis. L’offre standard peut présenter une plus grande variation de latence et ne bénéficie d’aucune garantie de latence.
Métriques clés
Pour afficher chaque métrique, cliquez sur l’onglet correspondant :
Vitesse des tokens : tokens générés par seconde ; indépendante de la taille du prompt.
Temps de requête : durée totale de la requête ; fortement influencée par la taille de sortie et le raisonnement.
Temps jusqu’au premier token (TTFT) : temps écoulé avant la génération du premier token ; fortement influencé par la taille du prompt d’entrée non mis en cache et par le raisonnement.
Examinez toujours les percentiles P50 / P75 / P95. Les moyennes peuvent masquer l’impact réel sur les utilisateurs.
6. Corréler la latence avec l’utilisation des tokens
L’état du service indique quand le comportement a changé. Les données d’utilisation aident à expliquer pourquoi.
Dans le tableau de bord d’utilisation, procédez comme suit pour vous assurer de consulter les données pertinentes pour votre vue dans le tableau de bord d’état du service :
Filtrez sur le même projet et le même modèle.
Regroupez par offre, le cas échéant.
Concentrez-vous sur les tokens de sortie, qui influencent le plus fortement la latence.
Pour une analyse plus approfondie, exportez les données d’activité et examinez les tokens par requête au fil du temps.
7. Informations à communiquer à l’assistance (si nécessaire)
Si vous contactez l’assistance, indiquez :
ID des organisations concernées (important)
Points de terminaison concernés, comme Chat Completions ou Responses (important)
Modèles concernés (important)
S’il s’agit du mode Rapide ou de l’offre Scale (important)
Plages horaires avec fuseau horaire pour la latence ou les erreurs (important)
x-request-id ou X-Client-Request-Id pertinents, si disponibles
Horodatages avec fuseau horaire, ou au moins la date, des requêtes fournies
Si possible, indiquez également :
ID du projet associé aux requêtes
Si des requêtes de résidence des données sont concernées, et lesquelles
Description des tendances observées
Selon le type de problème, indiquez :
Erreurs : pourcentage approximatif de requêtes en échec ou générant une erreur, codes de réponse, messages d’erreur et délai de réception de la réponse d’erreur.
Latence : percentiles concernés (P50 / P90 / P95 / P99), leur niveau par rapport à la référence du client et exemples de requêtes lentes avec horodatages d’envoi et de réception.
Les deux : captures d’écran ou tableau des données d’erreur ou de latence, ainsi que la méthode utilisée pour déterminer que les taux d’erreur ou la latence dépassaient les valeurs attendues.
Scénarios courants de résolution de problèmes
Des délais d’expiration surviennent mais l’état du service semble normal
Cause possible : les requêtes expirent avant d’atteindre OpenAI.
À vérifier :
Paramètres de délai d’expiration du client ou du proxy
Modifications du réseau local ou de l’équilibreur de charge
Présence d’erreurs 499 dans le tableau de bord d’état du service (elles peuvent apparaître comme des erreurs 5xx dans vos propres systèmes).
Latence accrue sans déploiement
Cause possible : la taille des tokens de sortie ou l’utilisation du raisonnement a augmenté et/ou le trafic a basculé entre des offres.
À vérifier :
Nombre moyen de tokens de sortie par requête dans le tableau de bord d’utilisation (nécessite de télécharger les données et de diviser les tokens de sortie par le nombre total de requêtes).
Percentiles du temps de requête et du TTFT dans le tableau de bord d’état du service.
Le mode Rapide ou l’offre Scale semble lent
Cause possible : les métriques de plusieurs offres sont mélangées, si bien que le trafic de l’offre standard masque les performances des offres payantes.
À vérifier :
Les filtres sont limités à une seule offre et à un seul modèle.
Comparaison du débit de tokens entre les offres.
Hausse des erreurs 5XX
Cause probable : défaillances transitoires affectant un faible pourcentage du trafic.
À vérifier :
Pourcentage du taux d’erreur
Si le volume de trafic a changé au même moment
Le problème n’affecte qu’un seul projet
Cause probable : configuration ou schéma d’utilisation propre au projet.
À vérifier :
Filtrage au niveau du projet
Comparaison avec les projets non affectés
Points clés à retenir
Filtrez par modèle, offre et projet lorsque c’est pertinent avant d’interpréter les métriques.
Utilisez les percentiles, et non les moyennes, pour l’analyse de la latence.
De faibles taux d’erreur sont attendus.
Des données manquantes indiquent généralement des problèmes en amont.
Les données d’utilisation peuvent aider à expliquer pourquoi la latence a changé ; l’état du service montre quand le comportement a changé.