Comprendre les LLM pour bien les exploiter

Les grands modèles de langage (large language models, LLM) arrivent dans l'infrastructure de deux façons : comme charge de travail à héberger (des serveurs gourmands en GPU et en mémoire) et comme outil pour exploiter (assistants, agents). Dans les deux cas, l'ingénieur infra doit comprendre ce qui se passe sous le capot pour dimensionner, budgéter et sécuriser. Cette leçon est théorique.

Ce que vous saurez à la fin : expliquer ce que fait un LLM (jetons, prédiction, contexte), régler les paramètres de génération, estimer la mémoire et le matériel nécessaires pour un modèle, comprendre la quantification, et connaître les limites (hallucinations) qui conditionnent tout usage en production.

1. Ce que fait un LLM

Un LLM prédit, jeton par jeton, la suite la plus probable d'un texte. Un jeton (token) est un morceau de mot : en français, comptez environ un jeton pour 3 à 4 caractères. Le modèle ne « consulte » rien : tout ce qu'il sait vient de son entraînement (figé à une date) et de ce qu'on lui donne dans la requête.

Le contexte (context window) est la quantité de texte que le modèle voit à la fois : la question, les instructions, l'historique de la conversation, les documents fournis, et sa propre réponse. Il se mesure en jetons (de quelques milliers à plus d'un million selon les modèles). Au-delà, le texte le plus ancien est perdu.

2. Les paramètres de génération

Paramètre	Effet
temperature	0 : la réponse la plus probable, presque déterministe ; plus haut : plus varié, plus créatif
top_p	ne tire qu'au sein des jetons qui cumulent cette probabilité (0.9 : les plus probables)
max_tokens	longueur maximale de la réponse : borne aussi le coût et la durée
stop	séquences qui arrêtent la génération

Pour de l'exploitation (classer une alerte, produire du YAML, extraire un champ), une température basse et un format de sortie imposé (JSON, schéma) donnent des réponses stables.

3. Le vocabulaire de l'API

La plupart des serveurs (commerciaux ou auto-hébergés : vLLM, Ollama…) exposent une API compatible OpenAI :

curl -s http://modele:8000/v1/chat/completions -H 'Content-Type: application/json' -d '{
  "model": "qwen3-8b",
  "messages": [
    {"role": "system", "content": "Tu es un assistant d'\''exploitation Kubernetes. Réponds en français, brièvement."},
    {"role": "user",   "content": "Que signifie CrashLoopBackOff ?"}
  ],
  "temperature": 0.2,
  "max_tokens": 300
}'

Le message system fixe le rôle et les règles ; les messages user et assistant forment la conversation. La réponse indique le nombre de jetons consommés (usage) : c'est l'unité de facturation des API, et la mesure du travail d'un serveur auto-hébergé.

4. Dimensionner : la mémoire d'abord

Un modèle est décrit par son nombre de paramètres (8 milliards, 70 milliards…). Pour le faire tourner, ses poids doivent tenir en mémoire du GPU (VRAM) :

mémoire des poids ≈ nombre de paramètres × octets par paramètre
  8 milliards × 2 octets (FP16/BF16) ≈ 16 Go
  8 milliards × 0,5 octet (4 bits)   ≈  4 à 5 Go
 70 milliards × 2 octets             ≈ 140 Go  → plusieurs GPU

S'y ajoute le cache KV : la mémoire des jetons déjà traités, pour chaque requête en cours. Il grandit avec la longueur du contexte et le nombre de requêtes simultanées ; il peut dépasser la taille des poids. Prévoyez donc de la marge au-delà des poids.

La quantification stocke les poids sur moins de bits (8, 4) : beaucoup moins de mémoire, une perte de qualité souvent faible pour 8 bits, à évaluer pour 4 bits. Formats courants : GGUF (llama.cpp, Ollama), AWQ et GPTQ (vLLM), FP8 sur les GPU récents.

5. Débit et latence

Deux phases : le préremplissage (lire tout le contexte, coûteux en calcul) et le décodage (produire un jeton après l'autre, limité par la bande passante mémoire). On mesure :

• le délai avant le premier jeton (time to first token) : ce que l'utilisateur ressent ;
• les jetons par seconde par requête et au total ;
• le nombre de requêtes simultanées tenues avant que la latence ne s'effondre.

Un CPU peut faire tourner un petit modèle quantifié (tests, faible charge) ; en production, un GPU s'impose en général. Le regroupement continu (continuous batching) des serveurs comme vLLM traite de nombreuses requêtes ensemble et multiplie le débit d'un même GPU.

6. Les limites à garder en tête

• Hallucinations : le modèle produit un texte plausible, pas forcément vrai (une option de commande qui n'existe pas, une version inventée). Toute sortie qui agit sur un système se vérifie.
• Connaissances figées : il ignore ce qui est postérieur à son entraînement et tout ce qui est propre à votre entreprise ; le RAG (leçon IA.3) y répond.
• Non-déterminisme : la même question peut donner deux réponses différentes.
• Sensibilité aux instructions cachées dans les données qu'on lui fait lire (injection de prompt, leçon IA.6).

7. API ou auto-hébergement ?

	API d'un fournisseur	Modèle ouvert auto-hébergé
Qualité	les modèles les plus performants	bonne, et en progrès rapide
Coût	à l'usage (jetons)	GPU à payer, utilisés ou non
Données	sortent de votre infrastructure (selon contrat)	restent chez vous
Exploitation	aucune	la vôtre : mises à jour, capacité, astreinte

Beaucoup d'équipes combinent les deux : une API pour les tâches difficiles, un modèle interne pour les données sensibles ou les gros volumes simples.

Validez la leçon avec le questionnaire.