02 · Modèles d'IA, jetons, coûts et latence

Version : 1.0 · Date : 2026-10-23 · Parcours SUPPORT-IA (support N2/N3 de chatbots IA sur Azure)

En une phrase : un chatbot RAG enchaîne plusieurs familles de modèles (OCR, embeddings, reranker, chat ou reasoning), chacune avec son quota, son prix et ses pannes ; tout se mesure en jetons (entrée, entrée en cache, sortie, raisonnement), et savoir lire le champ usage, les en-têtes de limite et les métriques de latence suffit à expliquer la plupart des incidents de coût, de lenteur et de 429.

Ce chapitre suppose les bases de Foundry vues dans le cours AI-103 : familles de modèles et choix d'un modèle (AI-103, 01), deployment types (AI-103, 02), quotas et 429 (AI-103, 03), paramètres de génération et latence (AI-103, 07). Ici, on prend l'angle support : comprendre, mesurer, diagnostiquer.

Noms à jour (relevé du 23/10/2026) : Azure AI Foundry s'appelle désormais Microsoft Foundry ; les Azure AI services sont devenus les Foundry Tools (ex. Azure Document Intelligence in Foundry Tools) ; les modèles Azure OpenAI sont rangés dans Foundry Models sold by Azure. Les anciennes pages restent sous l'étiquette (classic). Les deux noms circulent encore dans le code et la documentation interne d'un client.

1. Les familles de modèles#

1.1 Chat et génération#

Un modèle de chat prend une liste de messages (system ou developer, user, assistant, résultats d'outils) et produit la suite la plus probable, jeton par jeton. Deux API : Chat Completions (historique) et Responses (recommandée pour les nouveaux développements, outils et raisonnement). En support, l'API utilisée change le nom des champs à lire (section 4.2).

1.2 Reasoning models#

Les reasoning models génèrent des reasoning tokens avant la réponse visible. Ce qu'il faut savoir :

Piège support : « le bot répond vide de temps en temps » avec un reasoning model = presque toujours un plafond de sortie trop bas. Le raisonnement a consommé tout le budget avant la réponse visible.

1.3 Embeddings#

Un embedding est un vecteur de nombres réels qui représente le sens d'un texte : deux textes proches ont des vecteurs proches (similarité cosinus pour les modèles Azure OpenAI). Règles à connaître par cœur :

1.4 Multimodal#

gpt-4o, gpt-4.1 et les GPT-5 acceptent du texte et des images en entrée. Une image est convertie en jetons selon sa taille et le paramètre detail (low coûte un forfait de jetons, high dépend des dimensions). En support : un pic de jetons d'entrée sans hausse du nombre de requêtes vient souvent d'images envoyées en haute résolution.

1.5 OCR et Document Intelligence#

Azure Document Intelligence in Foundry Tools (v4.0, API 2024-11-30 GA) est le service d'extraction le plus courant dans l'ingestion RAG :

L'analyse est asynchrone : POST …/documentModels/prebuilt-layout:analyze renvoie 202 et un en-tête Operation-Location que l'on interroge jusqu'à succeeded. Le détail de l'ingestion est au chapitre 03.

D'autres modèles du catalogue font aussi de l'OCR vers Markdown (mistral-document-ai-2512 : 30 pages ou 30 Mo par appel ; mistral-ocr-4-0 et Cohere-parse-v5 en preview), et Azure Content Understanding est le chemin recommandé par Microsoft pour les nouveaux skillsets d'Azure AI Search (AI-103, 10).

1.6 Rerankers#

Un reranker (cross-encoder) lit la question et chaque candidat ensemble pour produire un score de pertinence plus fin que la similarité vectorielle. Deux options sur Azure :

2. Quel modèle Foundry pour quelle tâche#

Le catalogue évolue chaque mois (relevé du 23/10/2026 : séries gpt-6, gpt-5.6, gpt-5.5, gpt-5.4, gpt-5, gpt-4.1, o3/o4-mini, gpt-oss, plus DeepSeek, Meta, Mistral, Cohere, Moonshot, Microsoft). Ce qui compte en support n'est pas de connaître tous les noms, mais de savoir quelle famille est derrière chaque étape et où vérifier ses caractéristiques.

Où vérifier, pour un modèle donné : la page Foundry Models sold by Azure (fenêtre de contexte, sortie max, API supportées), la page Region availability (région et deployment type), le cycle de vie (preview, GA, date de retrait). Microsoft ne recommande pas les modèles preview en production : ils sont mis à niveau automatiquement et ne suivent pas le cycle standard.

# Lister les modèles déployables dans une région (lecture seule)
az cognitiveservices model list --location westeurope --query "[].{name:model.name, version:model.version, format:model.format}" -o table

# Lister les deployments d'une ressource Foundry et leur capacité (lecture seule)
az cognitiveservices account deployment list -g <rg> -n <foundry-resource> \
  --query "[].{name:name, model:properties.model.name, version:properties.model.version, sku:sku.name, capacity:sku.capacity}" -o table

3. Déploiements, quotas et 429#

3.1 Deployment types en une table#

Les données au repos restent toujours dans la géographie de la ressource ; le type ne change que le lieu de traitement. Détail, arbre de décision et spillover : AI-103, 02.

3.2 TPM, RPM : comment la limite est calculée#

• Le quota est attribué par abonnement, région, modèle et deployment type, en TPM ; chaque deployment en reçoit une part. Le RPM est dérivé du TPM selon un ratio fixé par modèle (anciens modèles de chat : 6 RPM pour 1 000 TPM).
• À l'arrivée de chaque requête, le service estime le maximum de jetons : invite + max_tokens + best_of. Cette estimation s'ajoute au compteur de la minute. Un max_tokens de 4 000 consomme 4 000 jetons de limite, même si la réponse en fait 200.
• Le RPM est contrôlé sur des fenêtres de 1 ou 10 secondes : 600 RPM = pas plus de 10 requêtes dans une seconde.
• Une requête rejetée (400) peut compter dans la limite. Les métriques de jetons, elles, ne montrent que les jetons facturés des requêtes réussies.

D'où le classique « 429 alors que les métriques sont sous le quota ».

3.3 Lire un 429#

flowchart TD
    A["HTTP 429 reçu"] --> B{"Message d'erreur ?"}
    B -- "Rate limit is exceeded" --> C{"Métriques de jetons<br/>proches du TPM ?"}
    C -- Oui --> D["Quota réellement atteint :<br/>TPM du deployment, rééquilibrage,<br/>demande de quota, PTU"]
    C -- Non --> E{"max_tokens élevé<br/>ou rafales sur 1 à 10 s ?"}
    E -- Oui --> F["Baisser max_tokens,<br/>lisser le trafic"]
    E -- Non --> G{"x-ratelimit-limit-tokens<br/>inférieur au TPM configuré ?"}
    G -- Oui --> H["Ajustement temporaire :<br/>retry avec retry-after-ms"]
    G -- Non --> I["Ouvrir un ticket si persistant"]
    B -- "temporarily unable / high demand" --> J["Capacité du service :<br/>retry, PTU si critique"]
    B -- "429 sur un deployment PTU" --> K["Utilisation à 100 % :<br/>spillover ou retry"]

# Lire les en-têtes de limite d'un appel (client OpenAI v1, authentification Entra ID, aucune clé)
from openai import OpenAI
from azure.identity import DefaultAzureCredential, get_bearer_token_provider

token = get_bearer_token_provider(DefaultAzureCredential(), "https://ai.azure.com/.default")
client = OpenAI(base_url="https://<resource>.openai.azure.com/openai/v1/", api_key=token, max_retries=0)  # retry géré ailleurs

raw = client.chat.completions.with_raw_response.create(
    model="<deployment>", messages=[{"role": "user", "content": "ping"}], max_completion_tokens=50)
for h in ("x-ratelimit-limit-tokens", "x-ratelimit-remaining-tokens", "x-ratelimit-remaining-requests"):
    print(h, raw.headers.get(h))
print(raw.parse().usage)                       # jetons facturés de cet appel

Le SDK openai réessaie 2 fois par défaut les 429 et erreurs transitoires (backoff exponentiel, respect de retry-after). Avec une bibliothèque de retry externe (tenacity, Polly) ou une AI gateway qui réessaie déjà, mettre max_retries=0 côté client pour éviter les tempêtes de retry.

À retenir pour l'entretien : un 429 n'est pas une panne. On lit le message (quota ou capacité ?) et les en-têtes (limite effective, marge, délai), puis on agit : max_tokens, répartition, quota, PTU, ou simple retry.

3.4 Les autres quotas d'une chaîne RAG#

4. Les jetons#

4.1 Qu'est-ce qu'un jeton ?#

Un jeton (token) est l'unité que le modèle lit et écrit : un mot court, un morceau de mot, un signe de ponctuation. Les modèles GPT utilisent une tokenisation en sous-mots (Byte-Pair Encoding) : « hamburger » donne trois jetons (« ham », « bur », « ger »), « pear » un seul, et beaucoup de jetons commencent par une espace. Ordre de grandeur donné par Microsoft : un jeton ≈ quatre caractères pour un texte anglais courant. Le ratio change avec la langue, le code, les chiffres : on mesure, on ne suppose pas.

4.2 Les types de jetons#

Exemple réel de bloc usage (Chat Completions, page Microsoft du prompt caching) : prompt_tokens: 1566 dont cached_tokens: 1408, completion_tokens: 1518 dont reasoning_tokens: 576. Lecture : 158 jetons d'entrée payés plein tarif, 1 408 au tarif remisé, 1 518 jetons de sortie dont 942 visibles.

4.3 Fenêtre de contexte et sortie maximale#

La fenêtre de contexte est le nombre total de jetons qu'un modèle traite dans une requête : entrée, raisonnement et sortie partagent ce budget. La sortie maximale est un plafond, pas une réservation.

Deux symptômes différents à ne pas confondre :

Pour un chatbot, l'entrée grossit à chaque tour (historique) : sans stratégie de troncature ou de résumé de l'historique, une conversation longue finit en context_length_exceeded ou devient chère et lente.

5. Le coût#

5.1 Le modèle de prix#

Ce qui est facturé même en cas d'échec (FAQ officielle) : une requête 400 due au content filter ou à la limite d'entrée, un 408 (timeout) ; une réponse 200 avec finish_reason: content_filter (entrée + sortie générée). Pas facturé : 401 (authentification), 429 (limite de débit), car le service n'a rien traité.

Prix exacts : ils changent souvent ; toujours lire la page officielle Azure OpenAI pricing au moment du calcul. Les exemples ci-dessous utilisent des prix fictifs pour la méthode.

5.2 Exemple chiffré : une question au chatbot#

Hypothèses (prix fictifs, à remplacer par la page de prix) : entrée 1,00 $ / 1M jetons, entrée en cache 0,10 $ / 1M, sortie 8,00 $ / 1M. Requête RAG typique :

Calcul :

• entrée non cachée : (5 840 − 2 304) × 1,00 / 1 000 000 = 0,003536 $ ;
• entrée en cache : 2 304 × 0,10 / 1 000 000 = 0,000230 $ ;
• sortie : 1 000 × 8,00 / 1 000 000 = 0,008000 $ ;
• total ≈ 0,0118 $ par question, soit ≈ 1 177 $ pour 100 000 questions par mois.

Ce que montre le calcul :

1. La sortie pèse 68 % du coût avec seulement 15 % des jetons : raisonnement et verbosité sont les premiers leviers.
2. Le cache économise ici ≈ 15 % (sans cache : 0,0138 $). Il compte davantage quand le préfixe stable est long.
3. Passer de 5 à 10 chunks ajoute 2 500 jetons d'entrée (+ 0,0025 $, soit + 21 %) et du bruit pour le modèle.

# Coût d'une requête à partir du bloc usage (prix à renseigner depuis la page officielle)
PRIX = {"in": 1.00, "cached": 0.10, "out": 8.00}           # $ par million de jetons (fictifs)

def cout(u) -> float:
    cached = u.input_tokens_details.cached_tokens or 0      # Responses API
    return ((u.input_tokens - cached) * PRIX["in"] + cached * PRIX["cached"] + u.output_tokens * PRIX["out"]) / 1_000_000

5.3 Dimensionner le TPM pour la même charge#

Pic de 20 questions par minute sur ce chatbot :

Le même trafic « consomme » 44 % de limite en plus avec un max_completion_tokens surdimensionné : c'est la cause n° 1 des 429 « inexplicables ».

6. La latence#

6.1 La formule#

TTLT = TTFT + (TBT × jetons générés) (formule officielle).

Microsoft le dit explicitement : chaque jeton d'invite ajoute peu de temps comparé à chaque jeton généré, et le modèle et le nombre de jetons générés sont les deux principaux facteurs. Un TTLT qui monte avec les jetons de sortie n'est pas une régression ; un TTLT qui monte sans hausse des jetons signale une pression de capacité (429, PTU saturé, ajustement temporaire). Ne pas utiliser la métrique héritée Latency (catégorie Cognitive Services - HTTP Requests), trompeuse pour Azure OpenAI.

6.2 Exemple chiffré#

Valeurs d'exemple (à mesurer sur votre deployment) : TTFT 0,6 s, TBT 10 ms.

Le streaming ne réduit pas le temps total : il réduit le temps perçu (le texte s'affiche dès le premier jeton visible). Avec un reasoning model, il faut aussi réduire l'effort ou demander au modèle un court préambule pour afficher quelque chose plus tôt.

# Mesurer TTFT et TTLT côté client, en streaming, avec l'usage en fin de flux
import time
t0 = time.perf_counter(); ttft = None
stream = client.chat.completions.create(
    model="<deployment>", stream=True, stream_options={"include_usage": True},
    messages=[{"role": "user", "content": "Explique le RAG en 5 lignes."}])
for chunk in stream:
    if chunk.choices and chunk.choices[0].delta.content and ttft is None:
        ttft = time.perf_counter() - t0                    # premier jeton visible
    if chunk.usage:                                        # dernier chunk : usage complet
        print(f"TTFT={ttft:.2f}s TTLT={time.perf_counter() - t0:.2f}s sortie={chunk.usage.completion_tokens}")

6.3 Leviers officiels contre la latence#

Modèle plus rapide (mini, nano), moins de jetons générés (consigne de concision, verbosity, effort de raisonnement plus bas), max_tokens bas, stop sequences, n = 1, streaming (latence perçue), prompt caching (TTFT), un deployment par type de charge (les appels courts n'attendent pas les longs), Provisioned pour une latence stable, et revoir le content filtering pour les cas à faible risque (le filtrage ajoute de la latence).

7. Prompt caching#

7.1 Les règles (Azure OpenAI, relevé du 23/10/2026)#

7.2 Structurer l'invite pour en profiter#

1. Stable au début : system prompt, consignes, exemples few-shot, définitions d'outils, schéma de sortie.
2. Variable à la fin : date, identifiant de session ou d'utilisateur, extraits RAG de la question, question.
3. Historique en ajout seul (append-only) : ne pas réécrire ni réordonner les tours précédents.
4. Ne pas glisser d'horodatage, de GUID ou de nom d'utilisateur dans le system prompt : c'est l'anti-modèle le plus fréquent.
5. Garder un flux régulier de requêtes au même préfixe ; un deployment par type de charge améliore aussi le taux de cache.

7.3 Mesurer#

Piège : un cached_tokens qui tombe à 0 après une mise en production = le début du prompt a changé (nouvelle version du system prompt, outil ajouté en tête, variable injectée). Comparer les 1 024 premiers jetons avant / après.

8. Paramètres de génération#

Un reasoning model refuse temperature, top_p et les pénalités : une erreur 400 après un changement de modèle vient souvent d'un paramètre resté dans le code. Détails et exemples : AI-103, 07.

9. Content filters et erreurs HTTP#

Les guardrails (ex-content filters) de Foundry analysent l'entrée et la sortie (haine, violence, contenu sexuel, auto-agression, jailbreak, injection indirecte, contenu protégé). Configuration et catégories : AI-103, 04.

10. Lire les jetons dans les logs et dans Langfuse#

10.1 Azure Monitor (ressource Foundry / Azure OpenAI)#

Les métriques sont gardées 30 jours ; pour les croiser dans Log Analytics, un diagnostic setting doit envoyer les métriques (table AzureMetrics) :

// Jetons d'entrée et de sortie par deployment et par heure (métriques exportées par diagnostic setting)
AzureMetrics
| where ResourceProvider == "MICROSOFT.COGNITIVESERVICES"
| where MetricName in ("ProcessedPromptTokens", "GeneratedTokens")
| summarize Jetons = sum(Total) by MetricName, bin(TimeGenerated, 1h)
| render timechart

Dans Application Insights, les jetons n'apparaissent que si l'application les trace (instrumentation OpenTelemetry GenAI, ou attributs ajoutés au span de l'appel). Vérifier ce que le code envoie avant de chercher.

10.2 Langfuse#

Pièges Langfuse en support : coût à 0 ou absent = pas d'usage ingéré ou aucun match_pattern ne correspond au nom de modèle enregistré (avec Azure, ce nom peut être celui du deployment, propre au client) ; coût sous-estimé sur un reasoning model = usage non ingéré ; jetons en double = format OpenAI « inclusif » (cached compris dans prompt) envoyé à plat sans conversion. Toujours comparer le coût Langfuse à Cost Management, qui fait foi pour la facture.

11. Erreurs fréquentes#

12. Lab#

Objectif : mesurer jetons, cache, coût et latence d'un deployment de test (abonnement de test, rien en production).

1. Déployer un modèle en Global Standard avec une petite capacité (ou réutiliser un deployment de test) ; donner à son compte le rôle Cognitive Services OpenAI User.
2. Écrire un system prompt stable de plus de 1 024 jetons (consignes + exemples) et envoyer 5 questions différentes à quelques secondes d'intervalle, en Responses API.
3. Pour chaque réponse, afficher input_tokens, cached_tokens, output_tokens, reasoning_tokens, TTFT et TTLT (code des sections 5.2 et 6.2). Attendu : cached_tokens = 0 à la 1re requête, puis ≥ 1 024 (multiple de 128 au-delà) ensuite.
4. Ajouter la date et l'heure au début du system prompt, relancer. Attendu : cached_tokens retombe à 0.
5. Avec un reasoning model, comparer reasoning={"effort": "low"} et "high" sur la même question : jetons de raisonnement, TTLT, coût calculé.
6. Mettre max_output_tokens à 50 sur l'effort high. Attendu : status: incomplete, parfois sans texte.
7. Dans Azure Monitor, afficher GeneratedTokens et Time to Last Byte découpés par deployment.

Coût : quelques centimes. Nettoyage : supprimer le deployment de test.

13. Questions d'entretien#

1. Quelle différence entre un modèle de chat et un reasoning model, et quel impact en support ? Le reasoning model génère des jetons de raisonnement cachés avant la réponse ; ils sont facturés en sortie et rallongent la latence. En support : coût et latence plus variables, paramètres refusés (temperature, max_tokens), réponses incomplete si le plafond est trop bas. On règle reasoning_effort avant de changer de modèle.

2. Qu'est-ce qu'un jeton et pourquoi tout se compte en jetons ? L'unité de lecture et d'écriture du modèle (sous-mot, ≈ 4 caractères en anglais). Le prix, la limite de débit (TPM), la fenêtre de contexte et la latence s'expriment en jetons. On les lit dans usage, jamais en estimant à partir du nombre de mots.

3. On a des 429 mais le graphe de jetons est à 40 % du quota. Explication ? La limite se calcule à l'arrivée sur une estimation (invite + max_tokens), le RPM sur des fenêtres de 1 à 10 s, et les métriques ne montrent que les jetons facturés des requêtes réussies. Je lis le message (quota ou capacité), les en-têtes x-ratelimit-*, je vérifie max_tokens et les rafales.

4. Comment distinguer un 429 de quota d'un 429 de capacité ? Par le message : « Rate limit is exceeded » = quota du deployment ; « temporarily unable to process / high demand » = capacité du service. Et par x-ratelimit-limit-tokens inférieur au TPM configuré = ajustement temporaire. Demander du quota ne règle pas un 429 de capacité ; retry ou PTU.

5. Comment fonctionne le prompt caching sur Azure OpenAI ? Automatique sur les modèles pris en charge, à partir de 1 024 jetons dont les 1 024 premiers identiques ; incréments de 128 jusqu'à GPT-5.5 ; cache vidé après 5 à 10 min d'inactivité (24 h en rétention étendue) ; jamais partagé entre abonnements ; jetons lus en cache remisés (jusqu'à 100 % en PTU). Visible dans cached_tokens. On met le contenu stable au début.

6. Pourquoi la sortie domine-t-elle la latence et le coût ? Chaque jeton de sortie est généré séquentiellement (TTLT = TTFT + TBT × jetons générés) et coûte plus cher qu'un jeton d'entrée. L'invite est traitée en parallèle et pèse surtout sur le TTFT.

7. Le streaming rend-il le modèle plus rapide ? Non. Il réduit le temps perçu (premier jeton affiché tôt), pas le temps total. Avec un reasoning model, le premier jeton visible arrive après le raisonnement.

8. Quel deployment type pour un chatbot interne européen ? Data Zone Standard (traitement dans la zone EU) pour démarrer, Data Zone Provisioned si le volume est stable et la latence critique, avec spillover vers Standard. Global Standard si la résidence n'est pas exigée.

9. Quelle est la différence entre context_length_exceeded et finish_reason: length ? Le premier est un 400 : l'entrée dépasse la limite, rien n'est généré. Le second est un 200 : la sortie a atteint son plafond, la réponse est tronquée. Correction différente : réduire l'entrée (historique, chunks) ou monter le plafond de sortie.

10. Comment estimer le coût mensuel d'un chatbot ? Jetons moyens par question (entrée, dont cache ; sortie, dont raisonnement) × prix par million × nombre de questions, plus Document Intelligence (pages), AI Search (SU + semantic ranker), embeddings d'indexation et de requête. Puis comparer avec Cost Management.

11. Pourquoi mon coût Langfuse ne correspond-il pas à la facture ? Coût inféré à partir d'une model definition (prix ou match_pattern faux, nom de deployment Azure non reconnu), jetons de raisonnement non ingérés, prix modifié après coup (non rétroactif). Cost Management fait foi.

12. Le bot renvoie parfois une réponse vide avec un HTTP 200. Que regardez-vous ? finish_reason (content_filter ou length), et pour la Responses API status et incomplete_details.reason. Puis reasoning_tokens : souvent un plafond de sortie consommé par le raisonnement.

13. Un 400 content_filter sur une question anodine ? L'entrée contient aussi les extraits RAG et l'historique : un document indexé peut déclencher le filtre (ou une injection indirecte). Je lis les catégories dans l'erreur et la trace des chunks envoyés. La requête est facturée.

14. Quand choisir des PTU ? Débit élevé et constant, besoin de latence stable ou d'un SLA de latence. On dimensionne avec le capacity calculator et un benchmark, on surveille Provisioned-managed Utilization V2, on active le spillover. Les 429 en PTU sont un signal de régulation normal.

14. Fiche à retenir#

• Familles : chat, reasoning (jetons cachés facturés en sortie), embeddings (même modèle et même dimension partout), multimodal, OCR (Document Intelligence prebuilt-layout → Markdown), reranker (semantic ranker 0–4).
• Jetons : entrée, entrée en cache, sortie, raisonnement ; lire usage (Chat : prompt_tokens… ; Responses : input_tokens…).
• Contexte partagé entre entrée, raisonnement et sortie ; context_length_exceeded (400) ≠ length / incomplete (200).
• Limite de débit = estimation invite + max_tokens ; RPM sur 1 à 10 s ; 429 quota ≠ 429 capacité ; retry-after-ms.
• Coût = prix par million × (entrée non cachée, en cache, sortie) ; Batch −50 % ; PTU à l'heure ; 400 content filter facturé, 429 non.
• Latence : TTLT = TTFT + TBT × jetons générés ; toujours une latence avec un nombre de jetons.
• Prompt caching : ≥ 1 024 jetons identiques en tête, automatique, 5–10 min, cached_tokens ; stable au début, variable à la fin.
• Reasoning : reasoning_effort, plafond max_output_tokens / max_completion_tokens, pas de temperature.
• Erreurs : 400 (payload, contexte, filtre), 401 (jeton, audience, rôle), 403 (réseau, abus), 404 (deployment), 429, 5xx.
• Langfuse : usage_details / cost_details, ingéré > inféré, match_pattern, reasoning non devinable ; Cost Management fait foi.

Références#

Relevé du 23/10/2026.

• Foundry Models sold by Azure (modèles, fenêtres de contexte, Cohere, Mistral, model router) : https://learn.microsoft.com/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure
• Deployment types for Microsoft Foundry Models : https://learn.microsoft.com/azure/foundry/foundry-models/concepts/deployment-types
• Overview of Microsoft Foundry Models : https://learn.microsoft.com/azure/foundry/concepts/foundry-models-overview
• Manage Azure OpenAI quota (rate limits, 429, en-têtes) : https://learn.microsoft.com/azure/foundry/openai/how-to/quota
• Azure OpenAI 429: token and request rate limits explained : https://learn.microsoft.com/microsoft-cloud/dev/dev-proxy/concepts/azure-openai-429-token-rate-limit
• Azure OpenAI reasoning models : https://learn.microsoft.com/azure/foundry/openai/how-to/reasoning
• Prompt caching : https://learn.microsoft.com/azure/ai-foundry/openai/how-to/prompt-caching
• Performance and latency : https://learn.microsoft.com/azure/foundry/openai/how-to/latency
• Azure OpenAI monitoring data reference : https://learn.microsoft.com/azure/foundry/openai/monitor-openai-reference
• Plan to manage costs for Azure OpenAI : https://learn.microsoft.com/azure/ai-foundry/openai/how-to/manage-costs
• Azure OpenAI FAQ (facturation des appels en échec) : https://learn.microsoft.com/azure/ai-foundry/openai/faq
• What is Azure OpenAI (jetons texte et image) : https://learn.microsoft.com/azure/ai-foundry/openai/overview
• Content filtering overview : https://learn.microsoft.com/azure/ai-foundry/openai/concepts/content-filter
• Content streaming (Asynchronous Filter, facturation) : https://learn.microsoft.com/azure/foundry/openai/concepts/content-streaming
• Troubleshoot common HTTP errors for Azure OpenAI : https://learn.microsoft.com/azure/foundry/openai/how-to/troubleshoot-errors
• Document Intelligence layout model : https://learn.microsoft.com/azure/ai-services/document-intelligence/prebuilt/layout?view=doc-intel-4.0.0
• Document Intelligence read model (formats, limites) : https://learn.microsoft.com/azure/ai-services/document-intelligence/prebuilt/read?view=doc-intel-4.0.0
• Document Intelligence service quotas and limits : https://learn.microsoft.com/azure/ai-services/document-intelligence/service-limits?view=doc-intel-4.0.0
• Semantic ranking in Azure AI Search : https://learn.microsoft.com/azure/search/semantic-search-overview
• Azure OpenAI pricing (prix à jour) : https://azure.microsoft.com/pricing/details/azure-openai/
• Langfuse, token and cost tracking : https://langfuse.com/docs/observability/features/token-and-cost-tracking