D6 · Performance, Latency and Cost

Ce domaine représente environ 12 % de l’examen blanc OAI-API — à peu près 7 des 60 items — et reflète le cours Academy Optimize AI Application Performance (30 min). Il teste si vous savez rendre une application d’IA rapide, fiable et abordable en production : mettre en cache les prompts stables, batcher le travail non urgent, choisir le bon palier de traitement, décomposer un budget de latence, rétrograder (downshift) le modèle quand la qualité le permet, et faire le calcul de tokens qui décide du coût.

Ce que vous devez savoir

Le travail de performance est un ensemble de leviers que vous actionnez après que l’application fonctionne et qu’une évaluation protège la qualité. Le prompt caching réduit le coût et la latence quand un long préfixe se répète. Batch échange la latence contre une forte remise sur les jobs bulk non urgents. Le Flex processing offre du calcul moins cher pour le travail tolérant à la latence ; le fast mode vise une faible latence pour le travail interactif. Les predicted outputs accélèrent les réponses largement connues à l’avance. Vous décomposez un budget de latence pour trouver le vrai goulot d’étranglement, vous rétrogradez le modèle vers le moins cher qui passe encore l’évaluation, et vous étayez chaque décision par une comptabilité de tokens — le coût égale tokens ÷ 1 000 000 × prix/MTok, par requête et à l’échelle.

Objectifs d’apprentissage

À la fin de cette page, vous devriez être capable de :

1. Appliquer le prompt caching et structurer les prompts pour que le cache soit touché.
2. Choisir entre Batch, Flex processing et fast mode selon la tolérance à la latence.
3. Utiliser les predicted outputs là où une grande partie de la sortie est connue.
4. Décomposer un budget de latence pour trouver le vrai goulot d’étranglement.
5. Rétrograder le modèle et le reasoning effort sans casser l’évaluation.
6. Faire la comptabilité de tokens et calculer le coût à partir des prix réels.

6.1 L’ordre d’optimisation

1. Faire que ça marche       (sortie correcte)
2. Le protéger avec une éval (pour que l'optimisation ne casse pas silencieusement la qualité)
3. ENSUITE optimiser :
      coût   ── caching, downshift modèle/effort, batch, flex
      vitesse ── stream, fast mode, predicted outputs, réduire les tokens
4. Relancer l'éval après chaque changement

Optimiser avant d’avoir une évaluation signifie que vous ne pouvez pas dire si un modèle moins cher a discrètement ruiné la qualité. L’ordre compte.

6.2 Prompt caching

Quand de nombreuses requêtes partagent un long préfixe identique (un gros prompt système, un bloc d’instructions fixe, un document stable), le caching vous permet d’éviter de le retraiter — les tokens d’entrée mis en cache sont moins chers et plus rapides.

[  long préfixe stable (mis en cache)  ][ entrée utilisateur variable (non mise en cache) ]
        payer une fois, réutiliser              payer par requête

Règle de conception : placez le contenu stable en premier et le contenu variable en dernier, pour que le plus long préfixe possible soit cacheable. Réordonner un prompt pour déplacer le contenu variable en tête détruit le hit de cache.

6.3 Batch, Flex et fast mode

Le résultat peut-il attendre des heures ?  ── oui ──► Batch (le moins cher pour le bulk)
        │ non
Un certain délai est-il acceptable ?        ── oui ──► Flex processing
        │ non
Un utilisateur attend-il en direct ?        ── oui ──► fast mode + streaming

6.4 Predicted outputs

Quand vous connaissez déjà l’essentiel de la sortie — éditer un document, régénérer un fichier avec de petits changements, reformater un texte connu — les predicted outputs vous permettent de fournir le contenu attendu pour que le modèle le confirme/l’édite, réduisant substantiellement la latence par rapport à une régénération de zéro.

Usage typique : « appliquer ce petit changement à ce gros fichier », où 95 % de la sortie égale l’entrée.

6.5 Décomposer un budget de latence

« C’est lent » n’est pas actionnable. Décomposez le temps d’horloge en parties et attaquez la plus grande.

Latence totale = TTFT + génération + outil/récupération + réseau
                  ▲          ▲            ▲
            terme le plus grand ? attaquer CELUI-LÀ, puis remesurer.

6.6 Downshifting de modèle et d’effort

Le gain fiable le moins cher est généralement le downshifting : passer d’Astra/Sol à Terra/Luna, ou baisser le reasoning effort, et confirmer que l’évaluation passe toujours.

Chaque downshift est un changement → relancer l’évaluation (D3).

6.7 Comptabilité de tokens

Le coût est de l’arithmétique. Prix par million de tokens (septembre 2026) :

Somme travaillée — choisir un modèle pour un résumeur. 200 000 requêtes/jour, 2 000 tokens d’entrée + 300 de sortie chacune.

Par jour : entrée 200 000 × 2 000 = 400 000 000 tok = 400 MTok
           sortie 200 000 ×   300 =  60 000 000 tok =  60 MTok

Terra :  400 × $2  + 60 × $12  = $800 + $720   = $1,520/jour  (~$45,600/mois)
Luna :   400 × $0.20 + 60 × $1.20 = $80 + $72  =   $152/jour  (~$4,560/mois)
Sol :    400 × $4  + 60 × $20  = $1,600 + $1,200 = $2,800/jour (~$84,000/mois)

Si l’évaluation montre que Luna atteint le niveau requis pour le résumé, choisir Luna plutôt que Terra économise $1,368/jour ($41k/mois) pour la même qualité. Ce seul downshift, justifié par une évaluation, est la décision de coût à plus fort levier du domaine.

Cadre de décision

Utilisez le cadre CLIP pour optimiser sans casser la qualité.

La règle que le cours souligne : changer un levier, remesurer, ne garder que ce qui tient la qualité.

Erreurs fréquentes

Défi de mise en situation

Mise en situation. Votre produit a deux fonctionnalités d’IA. La fonctionnalité A est un chat interactif où les utilisateurs attendent les réponses ; elle utilise un prompt système de 6 000 tokens plus un petit message utilisateur, s’exécute sur gpt-5.6-sol à l’effort high, et paraît poussive. La fonctionnalité B classe un arriéré nocturne de 3 M de documents sur gpt-5.6-sol, et la facture mensuelle est alarmante. La direction veut les deux plus rapides et moins chères sans nuire à la qualité, et vous avez des évaluations pour les deux.

Trace de raisonnement d’expert.

1. La fonctionnalité A est un problème de latence ; décomposez-le. Le prompt système de 6 000 tokens est un préfixe fixe retraité à chaque tour, gonflant le time-to-first-token. Déplacez le contenu stable en tête et activez le prompt caching pour que le préfixe soit bon marché et rapide après le premier hit. Ensuite questionnez l’effort high : si l’évaluation passe à medium, rétrogradez l’effort pour réduire le temps de génération. Streamez la réponse pour qu’elle paraisse instantanée.
2. La fonctionnalité B est un problème de coût sans besoin de latence. Un arriéré nocturne peut attendre des heures, alors déplacez-le vers la Batch API pour la forte remise. Ensuite testez le downshifting du modèle : si l’évaluation montre que gpt-5.6-luna classe au niveau cible, la baisse de prix de Sol ($4/$20) à Luna ($0.20/$1.20) est de ~20× sur l’entrée et ~17× sur la sortie.
3. Calcul de tokens sur la fonctionnalité B. Disons 3 M de docs × (800 entrée + 40 sortie). Sol : 2,400 MTok × $4 + 120 MTok × $20 = $9,600 + $2,400 = $12,000 par exécution. Luna : 2,400 × $0.20 + 120 × $1.20 = $480 + $144 = $624. Batch ajoute une remise supplémentaire par-dessus. Le downshift Sol→Luna à lui seul est l’économie dominante.
4. Protéger la qualité. Chaque changement — caching, downshift d’effort, downshift de modèle, Batch — est validé en relançant l’évaluation respective. Si Luna manque le niveau requis de classification, s’arrêter à Terra.
5. Ne pas confondre les deux fonctionnalités. Batch ruinerait la fonctionnalité A (les utilisateurs attendent en direct) ; le fast mode/caching n’aiderait pas le coût de la fonctionnalité B. Adaptez le levier à la contrainte.

Décision conforme à l’examen : pour A, mettre en cache le préfixe stable, rétrograder l’effort si l’évaluation le permet, et streamer ; pour B, utiliser Batch et rétrograder le modèle vers le moins cher qui passe l’évaluation. Pas un réglage global unique pour les deux, pas de coupe sans relancer l’évaluation.

Pièges d’évaluation

Questions d’entraînement

Chaque item indique combien de réponses sélectionner. Engagez-vous avant de révéler.

Points clés à retenir

• N’optimisez qu’après qu’une évaluation protège la qualité, et relancez-la après chaque changement.
• Le prompt caching réduit le coût et la latence quand un long préfixe stable est placé en premier.
• Adaptez le palier à la tolérance à la latence : Batch (heures), Flex (bientôt), fast mode (maintenant) ; streamez pour les utilisateurs en attente.
• Les predicted outputs accélèrent les réponses dont la sortie est largement connue, comme de petites éditions de gros fichiers.
• Décomposez le budget de latence et attaquez le plus grand terme plutôt que de deviner.
• Rétrogradez le modèle et le reasoning effort vers l’option la moins chère que l’évaluation autorise.
• Le coût est de l’arithmétique : tokens ÷ 1 000 000 × prix/MTok × volume — un downshift de modèle justifié est généralement la plus grande économie.