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, prioritaire, Scale), filtrez toujours sur l’offre que vous analysez.
Pourquoi :
Les offres ont des caractéristiques de performance différentes
Les offres prioritaire et Scale ont des SLA définis
Mélanger les offres masque les performances 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 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 la plus pertinente sur les offres prioritaire et Scale, qui ont des SLA définis. L’offre standard peut présenter une variation de latence plus importante et ne garantit pas la 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. Ce qu’il faut partager avec le support (si nécessaire)
Si vous contactez le support, indiquez :
ID d’organisations affectées (important)
Endpoints affectés, tels que Chat Completions ou Responses (important)
Modèles affectés (important)
Si cela concerne l’offre Scale ou prioritaire (important)
Plages horaires avec fuseau horaire pour la latence ou les erreurs (important)
x-request-id ou X-Client-Request-Id pertinent, si disponible
Horodatages avec fuseau horaire, ou au moins la date, pour les requêtes que vous fournissez
Si possible, indiquez également :
ID de projet lié aux requêtes
Si les requêtes de résidence des données sont affectées, et lesquelles
Descriptions des tendances que vous observez
Pour le type de problème, indiquez :
Erreurs : pourcentage approximatif de requêtes échouées ou en erreur, codes de réponse, messages d’erreur et temps nécessaire pour recevoir la réponse d’erreur.
Latence : percentiles affectés (P50 / P90 / P95 / P99), leur niveau par rapport à la référence habituelle 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 manière dont vous avez déterminé que les taux d’erreur ou la latence étaient plus élevés que prévu.
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.
L’offre prioritaire 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 les performances de l’offre payante.
À 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 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é.