Liens importants
Tableau de bord de l’état du service (actuellement offert uniquement aux clients API Entreprise)
Commencez avec les bons paramètres par défaut
Lorsque vous ouvrez le tableau de bord de l’état du service, les paramètres par défaut sont :
Tous les projets
30 derniers jours
Résolution horaire
Cette vue est utile uniquement pour s’orienter. Un dépannage pertinent nécessite toujours un filtrage.
Filtrer avant d’enquêter
Un filtrage adéquat 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 à volume plus élevé
Les modèles à volume élevé peuvent donner l’impression que des problèmes localisés sont 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 les données selon l’offre examinée.
Pourquoi :
Les offres ont des caractéristiques de performance différentes
Le Mode rapide et l’offre Scale ont des accords de niveau de service définis
Combiner les offres masque les performances des offres payantes
Cela est particulièrement important pour l’analyse de la latence.
Pour les modèles existants, le trafic du Mode rapide figure encore comme prioritaire dans le tableau de bord Utilisation.
Filtrer par projet
Par défaut, l’état du service affiche tous les projets.
Pour le dépannage, filtrez sur le ou les projets où le problème a été observé.
Pourquoi :
Un seul projet à volume élevé peut dominer les métriques.
Les projets touchés plus petits peuvent être masqués par du trafic non lié.
Ne laissez « Tous les projets » sélectionné que si vous croyez que le problème touche réellement toute l’organisation.
Dépannage des erreurs
Utiliser la vue des requêtes HTTP
Pour examiner les erreurs :
Filtrez par modèle et par offre.
Ouvrez l’onglet Requêtes HTTP plutôt que 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 repérer les pics ou changements granulaires.
Interprétez les taux d’erreurs, 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 élevé, même avec un taux d’erreurs extrêmement faible.
Lorsque les 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 est généralement en amont (délais d’expiration, proxys, réseau).
C’est courant 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 ont des accords de niveau de service définis. L’offre standard peut présenter une plus grande variation de latence et n’offre aucune garantie à cet égard.
Métriques clés
Pour afficher chaque métrique, cliquez sur l’onglet pertinent :
Vitesse des tokens : tokens générés par seconde; indépendante de la taille de l’invite.
Temps de requête : durée totale de la requête; fortement influencée par la taille de la sortie et le raisonnement.
Temps avant le premier token (TTFT) : temps écoulé avant la génération du premier token; fortement influencé par la taille de l’invite d’entrée non mise en cache et 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 montre 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 de l’é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 ont la plus grande incidence sur 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. Renseignements à transmettre au soutien (au besoin)
Si vous communiquez avec le soutien, indiquez :
Les ID d’organisation touchés (important)
Les points de terminaison touchés, comme Chat Completions ou Responses (important)
Les modèles touchés (important)
S’il s’agit du Mode rapide ou de l’offre Scale (important)
Les périodes, avec le fuseau horaire, pour la latence ou les erreurs (important)
Les x-request-id ou X-Client-Request-Id pertinents, le cas échéant
Les horodatages avec le fuseau horaire, ou au moins la date, des requêtes fournies
Si possible, indiquez également :
L’ID de projet associé aux requêtes
Si des requêtes assujetties à la résidence des données sont touchées, et lesquelles
Une description des tendances observées
Selon le type de problème, indiquez :
Erreurs : pourcentage approximatif de requêtes qui échouent ou génèrent une erreur, codes de réponse, messages d’erreur et délai de réception de la réponse d’erreur.
Latence : centiles touchés (P50 / P90 / P95 / P99), leur écart par rapport à la valeur de référence du client et exemples de requêtes lentes avec les 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 étaient plus élevés que prévu.
Scénarios de dépannage courants
Des délais d’expiration surviennent, mais l’état du service semble normal
Cause possible : les requêtes expirent avant d’atteindre OpenAI.
Vérifiez :
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 de l’état du service (elles peuvent apparaître comme des erreurs 5xx dans vos propres systèmes).
La latence a augmenté sans déploiement
Cause possible : la taille des tokens de sortie ou l’utilisation du raisonnement a augmenté, et/ou le trafic a été déplacé entre les offres.
Vérifiez :
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 de l’état du service.
Le Mode rapide ou l’offre Scale semble lent
Cause possible : les mesures de différentes offres sont combiné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 de la vitesse des tokens entre les offres.
Hausse des erreurs 5XX
Cause probable : défaillances temporaires touchant un faible pourcentage du trafic.
Vérifiez :
Pourcentage du taux d’erreurs
Si le volume de trafic a changé au même moment
Le problème ne touche qu’un seul projet
Cause probable : configuration ou modèle d’utilisation propre au projet.
Vérifiez :
Filtrage au niveau du projet
Comparaison avec les projets non touchés
Points clés à retenir
Filtrez par modèle, offre et projet, le cas échéant, avant d’interpréter les métriques.
Utilisez les percentiles, et non les moyennes, pour l’analyse de la latence.
De faibles taux d’erreurs sont attendus.
Les 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é.