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 plus d’une offre (standard, priorité, Scale), filtrez toujours sur l’offre que vous examinez.
Pourquoi :
Les offres ont des caractéristiques de performance différentes
Les offres Priority et Scale ont des SLA définis
Mélanger les offres masque la performance de l’offre payante
C’est particulièrement important pour l’analyse de la latence.
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.
Dépannage de la latence
L’analyse de la latence est la plus pertinente pour les offres prioritaire et Scale, qui ont des SLA définis. L’offre standard peut présenter une variation de latence plus importante et n’offre pas de latence garantie.
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. Ce qu’il faut transmettre au soutien (au besoin)
Si vous communiquez avec le soutien, incluez :
ID d’organisation touchés (important)
Endpoints touchés, comme Chat Completions ou Responses (important)
Modèles touchés (important)
Si cela concerne l’offre Scale ou Priority (important)
Plages horaires avec fuseau horaire pour la latence ou les erreurs (important)
x-request-id ou X-Client-Request-Id pertinent, s’il est disponible
Horodatages avec fuseau horaire, ou au moins la date, pour les requêtes que vous fournissez
Si possible, incluez aussi :
ID du projet lié aux requêtes
Si les requêtes de résidence des données sont touchées, et lesquelles
Descriptions des tendances que vous observez
Pour le type de problème, incluez :
Erreurs : pourcentage approximatif des requêtes qui échouent ou génèrent des erreurs, codes de réponse, messages d’erreur et temps nécessaire pour recevoir la réponse d’erreur.
Latence : percentiles touchés (P50 / P90 / P95 / P99), ampleur de l’écart 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 façon dont vous avez déterminé que les taux d’erreurs 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.
L’offre Priority ou l’offre Scale semble lente
Cause possible : les métriques sont mélangées entre les offres, ce qui signifie que le trafic de l’offre standard masque la performance de l’offre payante.
Vérifiez :
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é.