Architecture d'un LLM : le transformer expliqué simplement
On parle partout de « transformer », d'« attention », de « paramètres » sans jamais dire ce que ces mots recouvrent. Ce guide ouvre le capot d'un LLM et explique son architecture avec des analogies simples, sans une seule équation. À la fin, vous comprendrez la llm architecture de l'intérieur — et surtout pourquoi ces choix de conception déterminent la VRAM que le modèle réclame et la vitesse à laquelle il répond sur votre machine.
#Pourquoi comprendre l'architecture d'un LLM
On peut faire tourner un LLM en local sans rien savoir de son fonctionnement interne — un ollama run suffit. Mais dès qu'on veut choisir le bon modèle pour sa machine, tous les mots des fiches techniques deviennent des obstacles : « 32 couches », « 7 milliards de paramètres », « MoE 8x7B », « attention à 32 têtes ». Ce sont ces chiffres qui décident si un modèle tiendra dans votre carte graphique ou ramera sur votre processeur.
La bonne nouvelle : l'architecture qui domine tous les LLM actuels — le transformer — repose sur une poignée d'idées qu'on peut expliquer sans mathématiques. Comprendre ces idées, c'est passer de « je copie une commande sans savoir » à « je sais pourquoi ce modèle demande 9 Go de VRAM et pas 40 ».
#Le transformer en une image
Ton ChatGPT privé et gratuit sur ta machine en 1 heure — LM Studio, Ollama, Open WebUI, tes documents, sans cloud.
- Espace en ligne à vie
- PDF + fichiers
- Remboursé 30 j
Un LLM moderne est un transformer : une machine qui prend un texte en entrée et prédit le mot suivant, encore et encore. Le nom vient de l'article « Attention Is All You Need » (Google, 2017), qui a introduit cette architecture. Tous les modèles que vous croisez — Llama, Qwen, Mistral, Gemma, DeepSeek, Phi — en sont des variantes.
Imaginez une chaîne de montage. À l'entrée, votre phrase découpée en morceaux. Chaque poste de la chaîne (une « couche ») enrichit la compréhension du texte, en tenant compte du contexte. À la sortie, le modèle propose le morceau suivant le plus probable. On répète l'opération pour chaque nouveau morceau généré. C'est tout — le reste n'est que du détail sur ce que fait chaque poste.
- Entrée
- Votre texte, découpé en tokens (petits morceaux de mots).
- Empilement de couches
- Chaque couche affine la représentation du texte. Un modèle en a des dizaines.
- Attention
- Le mécanisme central de chaque couche : il fait « regarder » chaque mot vers les autres.
- Sortie
- Une probabilité pour chaque token possible ; le modèle en choisit un, l'ajoute au texte, recommence.
#De vos mots aux tokens
Un LLM ne voit pas des lettres ni même des mots entiers : il voit des tokens. Un token, c'est un fragment de texte fréquent — parfois un mot court entier (« chat »), parfois un bout de mot (« anti », « constitution »), parfois un espace ou une ponctuation. En français, comptez grossièrement 3 tokens pour 2 mots.
Chaque token est ensuite transformé en une liste de nombres, appelée « embedding ». C'est la traduction du texte en une langue que la machine sait manipuler : des coordonnées dans un espace où les mots proches par le sens sont proches géographiquement. « Roi » et « reine » y sont voisins ; « roi » et « brocoli » sont éloignés.
#L'attention, le cœur du transformer
L'attention est l'idée qui a tout changé. Prenez la phrase « La souris a mangé le fromage parce qu'elle avait faim ». À qui renvoie « elle » ? À la souris, évidemment. Pour le savoir, il faut relier « elle » à « souris », plusieurs mots en arrière. C'est exactement ce que fait l'attention : pour chaque mot, elle décide quels autres mots de la phrase sont pertinents, et combien les prendre en compte.
Analogie : à une réunion, quand vous entendez un pronom ambigu, votre cerveau balaie ce qui a été dit avant pour retrouver de qui on parle. L'attention fait pareil, en parallèle, pour tous les mots à la fois. Chaque mot « pose une question » (de quoi ai-je besoin pour être compris ?) et « reçoit des réponses » des autres mots, pondérées par leur pertinence.
On parle souvent de « têtes d'attention » (attention heads). Une tête, c'est une manière de regarder les relations ; en avoir plusieurs (32 têtes, 64 têtes…) permet au modèle de suivre plusieurs types de liens en même temps — la grammaire d'un côté, le sujet du texte de l'autre, les références temporelles encore ailleurs.
#Les couches empilées
Une seule couche d'attention comprend des relations simples. La puissance vient de l'empilement : la sortie d'une couche devient l'entrée de la suivante. Un petit modèle en a une vingtaine, un gros modèle plusieurs dizaines. Chaque couche combine deux blocs : l'attention (qui relie les mots entre eux) et un réseau « feed-forward » (qui traite chaque mot individuellement, comme un mini-cerveau qui réfléchit à ce qu'il vient de lire).
Analogie : la lecture à plusieurs niveaux. La première couche repère les mots et la grammaire. Les couches du milieu construisent le sens des phrases. Les dernières saisissent l'intention, le ton, ce qui doit venir ensuite. Plus il y a de couches, plus le modèle peut raisonner en profondeur — mais plus il y a de calcul à faire à chaque token généré.
- Bloc d'attention
- Relie les mots entre eux (le contexte).
- Bloc feed-forward
- Transforme chaque mot en profondeur (les « connaissances » du modèle).
- Nombre de couches
- La « profondeur ». Plus il y en a, plus le modèle est capable — et lent.
- Largeur (dimension cachée)
- La taille des listes de nombres. Plus elle est grande, plus le modèle est « large » et lourd.
#Les paramètres, c'est quoi au juste
Quand on lit « 7B » ou « 70B », le B veut dire « milliards » (billion en anglais) et désigne le nombre de paramètres. Un paramètre est un nombre réglable à l'intérieur du modèle — un des innombrables boutons ajustés pendant l'entraînement. Ces boutons encodent tout ce que le modèle « sait » : grammaire, faits, styles, raisonnements.
Analogie : imaginez une console de mixage géante avec des milliards de curseurs. L'entraînement consiste à régler chaque curseur pour que, sur des milliards d'exemples de texte, le modèle prédise le bon mot suivant. Une fois figés, ces réglages sont les « poids » (weights) que vous téléchargez quand vous faites un ollama pull.
Plus un modèle a de paramètres, plus il peut mémoriser et nuancer — mais plus il occupe de mémoire et plus il est lent, car chaque token généré traverse tous ces paramètres. C'est le lien direct entre le chiffre « 7B » et les exigences matérielles de votre machine.
#Dense vs MoE : deux façons de câbler le modèle
Jusqu'ici, on a décrit un transformer « dense » : chaque token traverse la totalité des paramètres. Simple, mais coûteux — un 70B dense sollicite ses 70 milliards de paramètres à chaque mot généré.
L'architecture MoE (Mixture of Experts) casse cette règle. Au lieu d'un seul gros bloc feed-forward par couche, elle en met plusieurs (les « experts ») et n'en active que quelques-uns pour chaque token, choisis par un petit aiguilleur (le « router »). Analogie : plutôt qu'un généraliste qui répond à tout, un cabinet de spécialistes où l'on ne consulte que les deux médecins pertinents pour votre cas.
- Dense
- Tous les paramètres travaillent à chaque token. Ex. : Llama 3 8B, Qwen 14B, Gemma 27B.
- MoE
- Beaucoup de paramètres au total, mais peu actifs par token. Ex. : Mixtral 8x7B, DeepSeek V3, Llama 4 Scout.
- Notation MoE
- « 30B-A3B » = 30 milliards de paramètres au total, mais seulement 3 milliards actifs (A = active) par token.
La conséquence est majeure pour le local : un MoE se comporte comme un petit modèle pour la vitesse (peu de paramètres actifs), tout en gardant la culture d'un gros modèle (beaucoup de paramètres au total). Le hic, c'est la VRAM : il faut charger l'intégralité des experts en mémoire, même si l'on n'en active qu'une fraction à la fois.
#Pourquoi tout ça décide de la VRAM et de la vitesse
On arrive au nœud pratique. Deux ressources comptent en local : la mémoire (tenir le modèle) et le calcul (répondre vite). L'architecture les gouverne toutes les deux.
#La mémoire : les poids doivent tenir
Pour être rapide, un modèle doit tenir entièrement dans la VRAM de votre GPU (ou la mémoire unifiée d'un Mac Apple Silicon). Sinon, une partie déborde sur le processeur et la RAM, et la vitesse s'effondre. La taille dépend du nombre de paramètres et de la quantization.
- 3B en Q4
- ≈ 2 Go de VRAM
- 7B en Q4
- ≈ 5 Go
- 14B en Q4
- ≈ 9 Go
- 32B en Q4
- ≈ 19 Go
- 70B en Q4
- ≈ 40 Go
Ajoutez la mémoire du contexte (le KV cache), qui grandit avec la longueur du prompt. Un long contexte peut réclamer plusieurs gigaoctets supplémentaires — à ne pas oublier quand on est juste à la limite de sa carte.
#La vitesse : combien de paramètres actifs par token
La vitesse de génération (tokens par seconde) dépend surtout des paramètres réellement activés à chaque token. C'est pourquoi un 8B dense et un 30B-A3B MoE peuvent avoir une vitesse comparable : tous deux n'activent que ~3 à 8 milliards de paramètres par token. Le MoE demandera juste beaucoup plus de VRAM pour loger tous ses experts.
- RTX 3060 12 Go
- Confortable jusqu'à un 14B en Q4. Carte d'entrée idéale.
- RTX 4070 / 4080 (12–16 Go)
- 14B à l'aise, 32B en Q4 serré sur la 4080.
- RTX 4090 24 Go
- 32B en Q4 confortable, 70B hors de portée en pur GPU.
- Mac M4 Pro 24–48 Go unifiés
- La mémoire unifiée sert de VRAM : jusqu'à un 70B en Q4 sur les configs 48 Go.
#Lire une fiche de modèle ligne par ligne
Vous avez maintenant les clés pour décoder une fiche technique. Prenons un exemple type, comme on en trouve sur Hugging Face ou la bibliothèque Ollama :
- architecture: decoder-only
- Le standard des LLM génératifs : le modèle ne fait que prédire la suite du texte (pas de partie « encodeur » séparée).
- parameters: 14B
- 14 milliards de paramètres. Repère mémoire : ~9 Go en Q4, il faut au moins une carte 12 Go.
- type: dense
- Tous les paramètres sont actifs à chaque token. Si c'était un MoE, vous verriez une notation type 30B-A3B.
- layers: 40
- 40 couches empilées. C'est la profondeur : plus il y en a, plus le raisonnement est fin, plus c'est lent.
- attention_heads: 40
- 40 têtes d'attention par couche — autant de manières de relier les mots en parallèle.
- context_length: 32768
- 32k tokens de contexte, soit ~24 000 mots. Attention : remplir ce contexte consomme de la VRAM en plus.
- quantization: Q4_K_M
- Précision réduite à ~4 bits par paramètre. Le meilleur compromis qualité/taille pour le local.
- size_on_disk: 9 GB
- Ce que vous téléchargez et ce qu'il faut loger en mémoire pour la vitesse maximale.
Avec ces sept lignes, vous pouvez déjà répondre à la seule question qui compte : « est-ce que ça tourne bien sur ma machine ? ». Ici : 14B en Q4 = ~9 Go de poids + le contexte → une RTX 3060 12 Go ou mieux, et ça tourne vite.
#Pour aller plus loin
Vous connaissez maintenant l'anatomie d'un LLM. Trois guides prolongent naturellement ces bases : le premier détaille la notation MoE et son impact concret, le deuxième explique le choix de quantization qui décide de la taille sur disque, le troisième revient sur la fenêtre de contexte évoquée ici.
Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.