Aller au contenu principal

Arbitrages coût et latence

Intermédiaire
What you'll learn
  • Le triangle coût/qualité/vitesse — pourquoi vous ne pouvez jamais maximiser les trois à la fois
  • Les six plus grands leviers pour dépenser là où ça compte et économiser partout ailleurs
  • Comment une cascade « le moins cher d'abord » achemine 90 % du volume vers un petit modèle et coupe le coût d'environ 70 % sans faire chuter la qualité sur les cas difficiles
  • Les gains spécifiques à la latence (streaming, parallélisme, cache, async) qui redéfinissent la vitesse perçue
  • Pourquoi « optimiser à l'aveugle » brûle la qualité — mesurer d'abord, se protéger avec des évals ensuite

Qualité, coût et vitesse tirent à hue et à dia. Vous ne pouvez pas maximiser les trois à la fois — mais vous pouvez dépenser chacun là où cela compte et économiser partout ailleurs.

Le triangle​

Un modèle plus gros est plus intelligent mais plus lent et plus cher ; un plus petit est rapide et bon marché mais moins capable. La bonne ingénierie consiste à diriger chaque tâche vers le bon point de ce triangle.

Les plus grands leviers (à peu près dans l'ordre)​

Guided walkthrough1 of 6
  1. Ne faites pas tourner Opus pour de la classification. Commencez avec Sonnet, descendez à Haiku pour les étapes simples/à fort volume, réservez Opus pour les parties difficiles. Le levier unique le plus important — voir /docs/api/choosing-a-model.

Exemple travaillé : une cascade « le moins cher d'abord »​

La cascade est le levier que les gens sautent parce qu'il paraît vague. Rendons-le concret. Disons que vous devez trier 100 000 e-mails de support. L'approche naïve fait passer chaque e-mail par votre modèle le plus fort. Une cascade achemine la plupart du volume vers un modèle bon marché et n'escalade que les cas difficiles :

Supposons que le modèle bon marché résout 90 % des cas seul et qu'un modèle plus fort coûte environ 5× plus par token. En comptant en unités de coût relatives (1 = un passage bon marché sur un e-mail) :

  • Tout-fort : 100k × 5 = 500k unités de coût.
  • Cascade : 100k × 1 (chaque e-mail reçoit le passage bon marché) + 10k × 5 (les 10 % qui escaladent) = 150k unités de coût.

Cela fait environ 70 % d'économie, et les cas véritablement difficiles reçoivent quand même votre meilleur modèle. Les multiplicateurs et la répartition sont illustratifs — mettez vos propres décomptes de tokens et tarifs et mesurez le taux réel d'escalade avec les évals. La leçon tient quoi qu'il en soit : les économies viennent de la rareté avec laquelle vous payez le tarif cher, pas du tarif lui-même.

Gains spécifiques à la latence​

Pro tip
  • Streamez les réponses — les utilisateurs voient les premiers tokens instantanément, donc la vitesse perçue bondit même quand le temps total est inchangé (/docs/api/streaming).
  • Parallélisez les sous-appels indépendants — une requête qui se déploie vers trois outils finit en max(latence), pas somme(latence).
  • Mettez en cache le travail répété et pré-calculez quand vous le pouvez — les tokens les plus rapides sont ceux que vous n'avez pas à générer.
  • Choisissez un modèle plus petit pour le chemin interactif ; déplacez le gros travail en async pour que l'utilisateur n'attende pas dessus.
  • Réduisez les tokens de sortie max pour les endpoints interactifs — les générations longues sont la source dominante de latence de queue.

Ne pas optimiser à l'aveugle​

Mesurez d'abord : où passent réellement les tokens et les secondes ? Puis optimisez la plus grosse ligne. Et revérifiez la qualité avec des évals après toute réduction de coût — une configuration moins chère qui se trompe n'est pas moins chère.

Vérifiez-vous

0/4
  1. Quel est GÉNÉRALEMENT le plus grand levier de coût unique ?
  2. Dans une cascade « le moins cher d'abord », d'où viennent réellement les économies ?
  3. Vous voulez que l'utilisateur ait l'impression qu'une réponse est plus rapide. Quel levier aide LE PLUS sans changer le choix du modèle ?
  4. Vous avez coupé les coûts en passant de Sonnet à Haiku sur un workflow. Quelle est l'étape suivante requise ?
Key takeaways
  • Le triangle est réel : qualité, coût et vitesse tirent à hue et à dia — l'ingénierie signifie diriger chaque tâche vers le bon point, pas maxer les trois.
  • Bien dimensionner le modèle est le plus grand levier unique ; les cascades le multiplient en ne payant les tarifs flagship que sur la minorité difficile.
  • La mise en cache des prompts, un max_tokens serré, et la réduction des entrées via RAG se composent avec le choix du modèle.
  • La perception de latence est un axe distinct — le streaming, les sous-appels parallèles, et le gros travail asynchrone refaçonnent l'UX sans changer le coût brut.
  • Chaque réduction de coût doit être gardée par des évals — une configuration moins chère qui se trompe n'est pas moins chère.

Suite​