AI
AgentOps : diagnostiquer les limites de débit Azure OpenAI avant de changer de modèle
Un runbook de production pour qualifier le throttling Azure OpenAI ou Microsoft Foundry avec quota, capacité de déploiement, traces agent, retries, fallback, validation et rollback avant de changer de modèle.
Un agent IA qui ralentit brutalement ou produit des réponses incomplètes n’a pas forcément besoin d’un nouveau modèle. En production, le premier suspect est souvent plus opérationnel : un déploiement Azure OpenAI est throttlé, un agent Foundry appelle trop d’outils dans un même tour, les retries amplifient la charge, un batch concurrence le trafic interactif, ou un fallback change silencieusement la qualité de réponse.
Le cas d’usage est un assistant interne utilisé par des équipes exploitation, support ou engineering. Il lit des sources approuvées, appelle des outils bornés et s’appuie sur Azure OpenAI ou Microsoft Foundry pour raisonner. Les utilisateurs signalent des timeouts, des réponses partielles ou des rafales de 429 et 503 pendant les incidents. Le but du runbook est de décider s’il faut régler le trafic, séparer les workloads, ajouter de la capacité, modifier le fallback ou rollbacker le dernier changement agent avant de changer de modèle.
Figer le workload en échec
Commencez par un seul chemin agent. Un incident de limite de débit devient impossible à diagnostiquer quand chat interactif, évaluations, ingestion, résumés et retries d’outils sont mélangés.
Workload a qualifier
Agent: ops-assistant-prod
Environnement: production
Chemin utilisateur: conversation de diagnostic incident
Deploiement modele: gpt-4.1-prod ou deploiement approuve equivalent
Chemin outils: retrieval, requete logs, action draft
Symptome: 429, timeout, reponse tronquee ou reponse fallback
Changement recent: prompt, schema outil, index retrieval, batch evaluation ou quota deploiement
Preuves requises avant changement de modele
Trace agent avec conversation ID et tool call IDs
Statut de reponse Azure OpenAI et metadonnees de retry
Volume de tokens par classe de requete
Trafic concurrent pendant la fenetre incident
Chemin fallback et comportement visible utilisateur
Cas de validation qui reproduit ou invalide le probleme
Rollback prompt, outil, trafic ou deploiementLa première décision utile est le périmètre. Si seules les évaluations sont throttlées, ne changez pas l’agent interactif. Si un seul chemin outil explose la consommation de tokens, ne déplacez pas tout l’assistant vers un autre déploiement.
Séparer quota et comportement
Le quota n’est pas seulement un réglage Azure. Le comportement de l’agent peut le consommer plus vite que prévu : chunks de retrieval trop longs, échecs d’outils répétés, retries sans jitter, conversations parallèles ou campagne d’évaluation lancée en pleine journée.
Causes possibles
Capacite de deploiement trop basse pour le pic de trafic
Requetes par minute au-dessus des limites du deploiement
Tokens par minute en hausse apres changement de prompt ou retrieval
Erreurs outil qui provoquent des boucles de raisonnement
Politique de retry client qui cree des rafales synchronisees
Evaluations, batchs ou indexing sur le meme deploiement
Fallback vers un deploiement plus petit ou incompatible
Incident regional ou dependance lente qui augmente latence et retries
Ne pas conclure trop vite
429 ne prouve pas que le modele est mauvais
Plus de quota ne corrige pas une tempete de retries
Un modele plus rapide ne corrige pas un contexte surdimensionne
Un fallback qui reussit ne prouve pas que la qualite est acceptableTraitez la limite de déploiement et le chemin agent comme un seul système. La capacité peut devoir augmenter, mais seulement après compréhension du profil de requêtes.
Capturer les traces avant de relancer
Avant de rejouer le même prompt utilisateur, capturez la conversation en échec. La trace doit expliquer combien d’appels modèle ont été faits, quels outils ont été appelés, quelle taille le contexte a atteinte et si un fallback a été utilisé.
{
"conversation_id": "conv-20260707-0812",
"agent": "ops-assistant-prod",
"environment": "production",
"model_deployment": "gpt-4.1-prod",
"request_class": "interactive_incident_diagnosis",
"retrieval_chunks": 8,
"tool_calls": ["search_runbook", "query_logs"],
"prompt_tokens": 18400,
"completion_tokens": 1200,
"response_status": 429,
"retry_count": 3,
"fallback_used": false,
"backend_correlation_id": "aoai-req-7f3c",
"user_visible_result": "timeout_before_final_answer"
}Si ces données ne sont pas disponibles, la première correction est l’observabilité. Augmenter le quota sans traces peut rendre la même panne plus coûteuse et plus difficile à voir.
Vérifier déploiement et quota
Comparez la configuration du déploiement avec le trafic observé. L’objectif n’est pas de mémoriser toutes les valeurs de quota. L’objectif est de prouver si le workload en échec dépasse son enveloppe assignée.
RESOURCE_GROUP="rg-ai-prod"
ACCOUNT_NAME="aoai-prod-west"
DEPLOYMENT_NAME="gpt-4-1-prod"
az cognitiveservices account deployment show --resource-group "$RESOURCE_GROUP" --name "$ACCOUNT_NAME" --deployment-name "$DEPLOYMENT_NAME" --output json
az monitor metrics list --resource "/subscriptions/<subscription-id>/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.CognitiveServices/accounts/$ACCOUNT_NAME" --metric "TotalCalls,TokenTransaction,ThrottledCalls" --interval PT1M --aggregation Total --output tableUtilisez les métriques et dimensions disponibles dans votre workspace et votre région. Gardez les preuves reliées au nom de déploiement et à la fenêtre temporelle de la trace agent.
Inspecter retries et fallback
Les retries sont utiles seulement s’ils réduisent une panne transitoire. Dans un incident de quota, des retries agressifs peuvent multiplier le problème. Le fallback peut protéger l’expérience utilisateur, mais il doit être explicite et évalué.
retry_policy:
applies_to:
- transient_429
- transient_503
max_attempts: 2
backoff: exponential_with_jitter
retry_budget_per_conversation: 1
do_not_retry:
- schema_validation_error
- authorization_denied
- context_too_large
fallback_policy:
allowed_when:
- primary_deployment_throttled
- fallback_evaluation_passed
fallback_deployment: gpt-4.1-mini-prod
user_visible_behavior: "answer_with_limited_confidence_and_trace"
blocked_for:
- production_write_decision
- security_exception
- rollback_recommendation_without_human_reviewLe fallback ne doit jamais devenir une baisse de qualité invisible sur une action à risque. Pour un brouillon ou un résumé, il peut être acceptable. Pour une recommandation d’écriture en production, il doit généralement bloquer, demander validation ou rester en draft.
Réduire la pression tokens avant d’ajouter de la capacité
Quand le throttling suit un changement de prompt, retrieval ou outil, la correction la moins risquée consiste souvent à réduire les tokens inutiles.
Controles de pression tokens
Les chunks retrouves sont pertinents et dedupliques
Les extraits de runbook ont une limite de taille
Les sorties outil sont resumees avant reinjection
La memoire de conversation est bornee par la tache, pas par tout l'historique
Les evaluations ne tournent pas sur le deploiement production
Les batchs de resume ont un deploiement ou un horaire separe
L'agent s'arrete apres un echec outil au lieu de boucler
Bloquer l'augmentation de capacite quand
Un changement de prompt a double la taille de contexte
Un outil retourne des logs bruts sans compression
Les retries ne sont pas bornes
Les evaluations partagent le meme deploiement que les incidents
L'equipe ne distingue pas charge interactive et batchLa capacité reste une réponse valide, mais elle ne doit pas masquer une stratégie de contexte cassée.
Valider avec un trafic contrôlé
Ne validez pas la correction avec une conversation chanceuse. Rejouez un petit jeu de cas représentatifs : question normale, diagnostic lourd en retrieval, échec outil, scénario fallback et cas de refus.
validation_cases:
- id: normal_diagnosis
expected:
status: success
fallback: false
max_model_calls: 2
- id: retrieval_heavy_incident
expected:
status: success
retrieved_chunks_within_limit: true
answer_cites_sources: true
- id: tool_backend_unavailable
expected:
status: graceful_hold
retry_count_within_budget: true
no_write_action: true
- id: primary_deployment_throttled
expected:
status: fallback_or_hold
fallback_trace_visible: true
production_write_blocked: true
- id: broad_action_request
expected:
status: refused
no_capacity_escalation: trueLa validation doit prouver disponibilité et contrôle. Une correction qui rend les réponses rapides mais autorise un fallback dangereux n’est pas prête.
Décider réglage, capacité, séparation ou rollback
Gardez la décision opérationnelle explicite. Un incident de limite de débit peut se résoudre de plusieurs façons, avec des risques différents.
Regler le trafic
La hausse tokens vient du retrieval, du prompt ou d'une sortie outil
Les retries ont amplifie l'incident
Les batchs peuvent sortir de la fenetre de pic
Les regles fallback doivent mieux borner les risques
Scaler ou demander du quota
Le trafic interactif est valide et soutenu
La consommation tokens correspond au cas d'usage
Evaluations et batchs sont deja separes
Les traces prouvent que l'enveloppe de deploiement est trop petite
Separer les deploiements
Le trafic incident concurrence evaluations ou batchs
Les classes de requetes ont des politiques differentes de latence et de risque
Le fallback exige un deploiement valide separement
Rollbacker
Le throttling commence apres changement prompt, retrieval, outil ou routage
La version precedente restaure latence et baisse des 429 en test
Le fallback a change la qualite de reponse sans validation
L'observabilite ne reconstruit pas appels modele et retriesChanger de modèle n’est qu’une option. Souvent, le meilleur geste de production consiste à séparer les classes de trafic, réduire le contexte, corriger les retries ou rollbacker le changement agent qui a créé la hausse.
Valider après rollback ou promotion
Après décision, gardez une courte fenêtre de surveillance. Le but est de prouver que le comportement utilisateur récupère sans élargir la frontière d’action de l’agent.
Validation post-changement
Les appels throttles reviennent au niveau de base
La latence interactive rentre dans l'enveloppe attendue
Le nombre de retries reste dans le budget
Les decisions fallback sont visibles dans les traces
Les recommandations d'ecriture production exigent toujours une approbation
Evaluations et batchs n'utilisent pas le deploiement incident
La note incident conserve trace IDs, metriques, cas de validation et decision
Rollback incomplet quand
Les 429 disparaissent mais le fallback cache des reponses moins fiables
Le volume de tokens reste inexpliqué
Les batchs partagent encore le meme deploiement
L'ancien prompt ou index retrieval peut etre redeploye automatiquementConclusion
Le throttling Azure OpenAI dans un agent n’est pas seulement un problème de quota. C’est un problème de comportement de production qui traverse taille de prompt, retrieval, boucles d’outils, politique de retry, fallback, capacité de déploiement et observabilité.
La décision devient sûre quand les preuves sont visibles : réglez le trafic quand l’agent gaspille des tokens, séparez les déploiements quand les workloads se concurrencent, demandez de la capacité quand la demande valide dépasse l’enveloppe, et rollbackez quand un changement récent a créé la hausse. Le but n’est pas seulement d’avoir moins de 429. C’est de garder un agent disponible sans affaiblir silencieusement les contrôles autour des actions de production.