Pour les grands modèles de langage, l'inférence se déroule en deux phases distinctes, et les comprendre explique la plupart des caractéristiques de performance que vous observerez. La première phase s'appelle le « prefill » ou « traitement du prompt » — le modèle lit votre prompt d'entrée complet et construit son état interne (le cache KV). Cette phase est limitée par le calcul et bénéficie du parallélisme des GPU parce que tous les tokens d'entrée peuvent être traités simultanément. La deuxième phase est le « decode » ou « génération » — le modèle produit les tokens de sortie un par un, chacun dépendant de tous les tokens précédents. Cette phase est limitée par la bande passante mémoire parce que le modèle doit lire ses poids depuis la VRAM pour chaque token, mais effectue relativement peu de calcul par lecture. C'est pourquoi le Time to First Token (TTFT) et les tokens par seconde sont mesurés séparément : ils reflètent des goulots d'étranglement fondamentalement différents.
L'économie de l'inférence est dominée par le concept de « débit vs. latence ». Si vous servez un chatbot où un seul utilisateur attend une réponse, vous voulez une faible latence — sortir ce premier token rapidement. Mais si vous faites du traitement par lots (résumer 10 000 documents pendant la nuit), vous voulez un haut débit — traiter autant de tokens par seconde que possible, même si chaque requête individuelle est plus lente. Les moteurs d'inférence comme vLLM et TensorRT-LLM utilisent une technique appelée « continuous batching » pour regrouper dynamiquement plusieurs requêtes, ce qui améliore considérablement le débit. Un seul H100 pourrait générer 40 tokens/seconde pour une requête, mais en regroupant intelligemment, le même GPU peut servir plus de 20 utilisateurs simultanés à une latence acceptable parce que la bande passante mémoire est partagée plus efficacement.
Le paysage du service d'inférence s'est scindé en approches distinctes. Les fournisseurs d'API dans le nuage (Anthropic, OpenAI, Google) exploitent des clusters massifs de GPU et vendent l'inférence comme service, facturée par token. Les fournisseurs spécialisés en inférence comme Groq misent sur du matériel sur mesure — le LPU (Language Processing Unit) de Groq est spécifiquement conçu pour la phase séquentielle de décodage et atteint une vitesse de génération de tokens remarquable. Du côté open source, llama.cpp a rendu l'inférence LLM accessible sur CPU et GPU grand public grâce à une quantification agressive, et des outils comme Ollama l'ont enveloppé dans une interface conviviale. Pour l'auto-hébergement en production, vLLM avec PagedAttention est devenu le choix par défaut, offrant un débit qui rivalise avec les offres commerciales quand il est bien configuré.
Une idée reçue courante est que l'inférence est « bon marché » comparée à l'entraînement. Pour une seule requête, oui — générer une réponse coûte une fraction de centime. Mais l'inférence est continue. Un chatbot populaire traite des millions de requêtes par jour, indéfiniment. OpenAI dépenserait maintenant plus en inférence qu'en entraînement. C'est pourquoi l'optimisation de l'inférence est un domaine si actif : le décodage spéculatif (utilisant un petit modèle « brouillon » pour prédire ce que le grand modèle va dire), la compression du cache KV et la mise en cache des préfixes (réutiliser le calcul pour les prompts système partagés) visent tous à tirer plus de réponses du même matériel. Chaque point de pourcentage d'amélioration de l'efficacité se traduit directement en millions de dollars économisés à grande échelle.