Chapitre 9 — Performance, mise à l'échelle et coûts

Ceci est la Partie 9 d'une série qui parcourt LLM Primer I: How Generative AI Works. Hier, nous avons parcouru les motifs d'application. Aujourd'hui, nous parlons de ce que coûte vraiment faire tourner ces applications — les réalités opérationnelles qui déterminent si une fonctionnalité LLM est livrée ou meurt tranquillement en pilote.

Plus grand n'est pas toujours mieux

L'intuition que les modèles plus grands sont toujours plus capables est essentiellement correcte — et essentiellement trompeuse. Les modèles plus grands performent en moyenne mieux sur la plupart des benchmarks. Mais les gains rétrécissent à mesure que la taille du modèle grandit. Un modèle avec deux fois plus de paramètres est rarement deux fois meilleur. Souvent il n'est que marginalement meilleur, tout en coûtant plusieurs fois plus à faire tourner.

Pour beaucoup d'applications réelles, un modèle plus petit avec un bon prompting, une bonne recherche et une bonne évaluation surpasse un modèle plus grand laissé tomber dans un pipeline moins bien conçu. C'est le seul insight pratique le plus important du Chapitre 9, et le livre prend le temps de le défendre parce qu'il va à l'encontre du récit marketing de chaque labo de frontière.

Latence et throughput tirent dans des directions opposées

Deux métriques dominent les opérations LLM. La latence est le temps entre la requête et la première réponse. Le throughput est combien de requêtes par seconde le système peut traiter.

Le compromis entre eux est structurel. Pour obtenir un haut throughput, vous batcher les requêtes — en faisant tourner beaucoup d'entre elles en parallèle sur le GPU. Pour obtenir une basse latence, vous traitez chaque requête individuellement dès qu'elle arrive. Choisissez l'un et vous sacrifiez l'autre.

La plupart des systèmes réels atterrissent quelque part au milieu en utilisant une technique appelée batching continu, qui ajoute de nouvelles requêtes à un batch déjà en vol. La génération en streaming — renvoyer les tokens à l'utilisateur au fur et à mesure qu'ils sont produits plutôt que d'attendre la réponse complète — aide la latence perçue même quand le temps réel de génération est inchangé. Le livre détaille quels choix de conception sont appropriés pour quels types de produits.

L'équation réelle du coût

Faire tourner un LLM n'est pas comme faire tourner un logiciel normal, et l'une des leçons les plus coûteuses du déploiement d'IA est de l'apprendre à la dure. Avec le logiciel traditionnel, une fois que vous avez construit le système, les utilisateurs supplémentaires sont quasiment gratuits ; le serveur tourne, qu'un utilisateur ou mille y tapent. Avec un LLM, chaque requête coûte de la vraie puissance de calcul. Les coûts montent linéairement avec l'utilisation.

Les principaux moteurs de coût sont faciles à énumérer. Les entrées plus longues coûtent plus (le calcul d'attention monte avec la longueur d'entrée). Les sorties plus longues coûtent plus (chaque token de sortie nécessite une autre passe avant dans le modèle). Les modèles plus grands coûtent plus (plus de paramètres signifie plus de FLOPs par token). Les modèles de raisonnement coûtent plus (ils génèrent beaucoup de tokens intermédiaires avant la réponse finale). Ces facteurs ne s'additionnent pas ; ils se multiplient.

Le livre comprend un tableau d'exemple résolu de coûts montrant comment la facture mensuelle d'une application change à travers des scénarios réalistes — petit chatbot, RAG milieu de gamme, système agentique avec raisonnement. Les chiffres exacts bougent ; la forme de la courbe est durable.

Quantification, en langage simple

L'une des astuces d'ingénierie les plus puissantes pour réduire les coûts est la quantification. Les paramètres du modèle sont normalement stockés en nombres à virgule flottante — souvent en précision 16 ou 32 bits. La quantification les stocke avec moins de précision, souvent 8 bits ou même 4 bits par nombre, avec des facteurs d'échelle soigneusement choisis qui limitent la perte d'information.

L'effet est spectaculaire. Un modèle quantifié utilise beaucoup moins de mémoire, ce qui signifie qu'il rentre sur du matériel plus petit et tourne plus vite (parce que la bande passante mémoire, pas le calcul brut, est souvent le goulet d'étranglement). La perte de qualité est petite quand c'est bien fait — typiquement quelques points de pourcentage sur les benchmarks, parfois imperceptible en pratique.

Plusieurs techniques connexes — pruning, distillation, sparsité — poussent l'efficacité plus loin. La distillation en particulier est comment vous obtenez un petit modèle qui imite un beaucoup plus grand. Le livre couvre chaque technique et quand chacune est appropriée.

Déploiement edge et sur appareil

La plupart des LLM en production tournent dans des centres de données cloud. Certaines applications ne le peuvent pas. Les assistants vocaux temps réel, les applications avec des contraintes strictes de confidentialité, les appareils qui ont besoin de fonctionner sans connectivité réseau — ceux-ci bénéficient de faire tourner un modèle directement sur le matériel de l'utilisateur.

Le déploiement edge est sa propre discipline d'ingénierie. La mémoire est contrainte. L'énergie est précieuse. La puissance de calcul disponible est bien plus petite que celle d'un centre de données. Le livre montre comment la compression lourde, la sélection soigneuse de modèle et les architectures hybrides (petit modèle local pour le travail routinier, modèle cloud pour les cas difficiles) rendent cela possible.

Ce que prépare le Chapitre 9

À la fin du Chapitre 9, vous pouvez modéliser le coût et la performance de toute application LLM proposée avant de la construire. Vous savez quelles décisions de conception comptent le plus pour le coût, lesquelles pour la latence, et quels compromis sont négociables versus fondamentaux. Vous pouvez lire les pages de tarification des fournisseurs et comprendre ce qui est vraiment facturé.

Cela prépare la prochaine question naturelle — une fois que vous pouvez faire tourner un système à l'échelle, comment vous assurez-vous que vous devriez ?

Prochaine étape — Chapitre 10 : Sécurité, éthique et confiance. Demain, nous regardons les hallucinations, le biais, la sécurité des prompts, l'explicabilité et les cadres de gouvernance qui transforment les applications LLM en produits responsables. Y compris les contrôles que les déploiements à enjeux élevés utilisent réellement.