L'optimisation en IA est en réalité trois disciplines distinctes qui partagent un nom. L'optimisation d'entraînement consiste à rendre le processus d'apprentissage plus rapide et moins cher. L'optimisation d'inférence consiste à faire en sorte que le modèle entraîné réponde plus vite et utilise moins de matériel. L'optimisation de service consiste à gérer efficacement de nombreux utilisateurs simultanés. La plupart des gens confondent les trois parce que les techniques se recoupent parfois, mais les objectifs et les contraintes sont différents. Une optimisation d'entraînement comme le gradient checkpointing échange du temps de calcul contre de la mémoire — on recalcule les activations pendant la passe arrière au lieu de les stocker. Cela a du sens quand on est limité par la mémoire GPU pendant un entraînement de plusieurs jours. Cela n'en aurait aucun pendant l'inférence, où il n'y a pas de passe arrière. Comprendre quelle phase on optimise, et quelle ressource on échange contre quelle autre, est la base pour prendre de bonnes décisions ici.
Si vous ne pouviez apprendre qu'une seule technique d'optimisation, la quantification serait celle à choisir. L'idée est simple : les modèles sont entraînés en virgule flottante haute précision (typiquement bfloat16, qui utilise 16 bits par paramètre), mais ils peuvent tourner en précision bien plus basse sans perte de qualité catastrophique. Un modèle de 14 milliards de paramètres en bfloat16 occupe environ 28 Go de VRAM. Quantifiez-le en 4 bits (Q4_K_M dans la notation de llama.cpp) et il tient en moins de 9 Go — soudainement il tourne sur un seul GPU grand public. Le compromis de qualité existe mais est plus petit qu'on ne le penserait. Les méthodes de quantification modernes comme GPTQ, AWQ et GGUF sont calibrées contre des données réelles pour que les poids les plus importants conservent une précision plus élevée. Dans des tests à l'aveugle, la plupart des utilisateurs ne peuvent pas distinguer un modèle en pleine précision de sa version quantifiée en 4 bits pour les tâches quotidiennes. L'écart se manifeste sur les cas limites — chaînes de raisonnement complexes, connaissances factuelles de niche, tâches multilingues — mais pour la plupart des cas d'utilisation en production, la quantification est de la performance gratuite.
Au-delà de la quantification, les plus grandes accélérations d'inférence viennent de la façon dont on gère les requêtes plutôt que de la façon dont on réduit le modèle. Le traitement par lots continu — l'approche utilisée par vLLM et TensorRT-LLM — permet au serveur de traiter plusieurs requêtes simultanément, remplissant les cycles GPU inactifs qui seraient autrement gaspillés pendant qu'une requête attend son prochain token. L'optimisation du cache KV (comme PagedAttention) empêche la surcharge mémoire du cache clé-valeur de croître linéairement avec la longueur de la séquence, ce qui est essentiel pour les applications à long contexte. Le décodage spéculatif utilise un petit modèle « brouillon » rapide pour générer plusieurs tokens candidats, puis le grand modèle les vérifie en un seul passage — si le modèle brouillon devine juste (ce qui arrive souvent pour le texte prévisible), on obtient plusieurs tokens pour le coût d'un seul appel au grand modèle. Ces techniques se composent. Une pile de service bien réglée utilisant le traitement par lots continu, la quantification et le décodage spéculatif peut servir le même modèle à cinq à dix fois le débit d'une implémentation naïve.
Pour la plupart des équipes, l'optimisation est fondamentalement une question de coût par requête. Faire tourner un modèle de 70 milliards de paramètres sur un cluster d'A100 coûte de l'argent sérieux — environ 8 à 15 $ par GPU par heure aux prix du nuage. L'optimisation détermine si ce cluster gère 50 requêtes par seconde ou 500. La distillation est un autre levier : on entraîne un modèle « élève » plus petit à imiter les sorties d'un modèle « enseignant » plus grand sur votre tâche spécifique. Un modèle distillé de 8 milliards de paramètres qui atteint 90 % de la qualité du modèle de 70 milliards sur votre cas d'utilisation particulier coûte une fraction à faire tourner. Le flux de travail pratique que de nombreuses équipes suivent est : prototyper avec le plus grand modèle disponible via API, mesurer quel niveau de qualité est réellement nécessaire, puis travailler à rebours — quantifier, distiller, ou passer à un modèle plus petit jusqu'à atteindre le point d'équilibre où la qualité est acceptable et le coût soutenable. Les équipes qui sautent ce processus et passent directement au plus grand modèle en production dépensent presque toujours trop.