Accueil › Glossaire › Decoder-Only

Decoder-Only (Transformer)

L’architecture decoder-only est une variante du Transformer qui n’utilise que la partie décodeur du modèle original, avec une attention causale (masquée) qui empêche chaque token de « voir » les tokens suivants. C’est l’architecture de quasiment tous les LLM génératifs modernes : GPT, Claude, LLaMA, Mistral, DeepSeek et Grok.

Le Transformer original et ses trois variantes

Le Transformer original, proposé par Vaswani et al. en 2017 dans « Attention Is All You Need », était une architecture encoder-decoder conçue pour la traduction automatique. L’encodeur traite la séquence d’entrée, le décodeur génère la séquence de sortie. Depuis, trois variantes ont émergé :

Le decoder-only est devenu l’architecture dominante pour les LLM à partir de GPT-2 (2019) et a consolidé sa position avec GPT-3 (2020). En 2026, la quasi-totalité des modèles génératifs frontier utilisent cette architecture. Le passage de l’encoder-decoder au decoder-only n’a pas été motivé par une supériorité théorique démontrée, mais par le succès empirique de la série GPT et la simplicité de l’objectif d’entraînement (prédire le prochain token).

Comment fonctionne un decoder-only

L’attention causale : le mécanisme central

La différence fondamentale entre un decoder-only et les autres architectures est l’attention causale (aussi appelée masked self-attention). Dans l’attention standard (bidirectionnelle), chaque token peut « regarder » tous les autres tokens de la séquence, y compris ceux qui viennent après lui. Dans l’attention causale, chaque token ne peut voir que les tokens qui le précèdent et lui-même.

Techniquement, cela se réalise en ajoutant un masque à la matrice d’attention avant le softmax. Ce masque est une matrice triangulaire inférieure qui met à -∞ les positions correspondant aux tokens futurs, les rendant effectivement invisibles après le softmax (probabilité = 0).

Structure d’un bloc decoder-only

Chaque bloc d’un decoder-only contient deux sous-couches principales, entourées de connexions résiduelles et de normalisations :

1. Attention causale multi-têtes. La couche de multi-head attention calcule les scores d’attention entre tous les tokens précédents. L’attention est effectuée en parallèle sur plusieurs « têtes », chacune pouvant se concentrer sur des aspects différents du contexte (syntaxe, sémantique, relations longue distance). Les architectures modernes utilisent la Grouped-Query Attention (GQA), qui partage les projections clé/valeur entre groupes de têtes pour réduire la taille du KV-cache sans sacrifier la qualité.

2. Réseau feed-forward (FFN). Un petit réseau de neurones appliqué individuellement à chaque vecteur de token. Il projette le vecteur dans un espace ~4× plus grand, applique une activation non-linéaire (SwiGLU dans les architectures modernes), puis le reprojette à la taille originale. C’est cette couche FFN qui contient la majorité des paramètres du modèle et qui est remplacée par une couche MoE dans les modèles sparse.

Ces deux sous-couches sont complétées par :

Normalisation. RMSNorm (plus efficace que LayerNorm) appliquée avant chaque sous-couche (Pre-Norm), contrairement à l’architecture originale qui normalisait après (Post-Norm).

Connexion résiduelle. L’entrée de chaque sous-couche est ajoutée directement à sa sortie (y = F(x) + x), ce qui stabilise l’entraînement des réseaux profonds en permettant au gradient de circuler sans dégradation.

Encodage positionnel. Puisque le Transformer n’a pas de notion intrinsèque d’ordre, un encodage positionnel est nécessaire. Les architectures modernes utilisent RoPE (Rotary Position Embeddings), qui encode les positions de manière relative et permet une meilleure extrapolation vers des séquences plus longues que celles vues à l’entraînement.

Le processus de génération autorégressif

La génération de texte dans un decoder-only est autoréressive : le modèle génère un token à la fois, en conditionnant chaque prédiction sur tous les tokens précédents.

Le processus complet :

Étape 1 : Tokenisation. Le texte d’entrée est découpé en tokens via un tokenizer (typiquement BPE). Chaque token est mappé à un identifiant numérique.

Étape 2 : Embedding. Les identifiants sont convertis en vecteurs denses via une table d’embeddings apprise. L’encodage positionnel (RoPE) est ajouté.

Étape 3 : Passage à travers les blocs. La séquence de vecteurs traverse les N blocs du decoder (typiquement 32 à 128 blocs pour les grands modèles). Chaque bloc applique l’attention causale puis le FFN.

Étape 4 : Prédiction. La sortie du dernier bloc passe par une couche de classification (« LM head ») qui produit un vecteur de la taille du vocabulaire. Le softmax convertit ce vecteur en distribution de probabilité sur les tokens possibles.

Étape 5 : Échantillonnage. Un token est sélectionné selon une stratégie d’échantillonnage (température, top-p, top-k). Ce token est ajouté à la séquence et le processus reprend à l’étape 3.

L’entraînement d’un decoder-only

Causal Language Modeling (CLM)

L’objectif d’entraînement d’un decoder-only est le Causal Language Modeling : pour chaque position dans la séquence, le modèle doit prédire le token suivant. La perte est une cross-entropy entre la distribution prédite et le vrai token.

L’efficacité de cet objectif est remarquable : chaque séquence d’entraînement de longueur L génère L-1 signaux de perte (un pour chaque position sauf la première). Tous les tokens contribuent simultanément au gradient grâce au masque causal, qui garantit que la prédiction à chaque position ne « triche » pas en regardant les tokens suivants. C’est bien plus efficient que l’objectif de Masked Language Modeling (MLM) utilisé par BERT, où seuls 15 % des tokens (ceux masqués) génèrent un signal de perte.

Pré-entraînement, instruction tuning et alignement

L’entraînement d’un LLM decoder-only se déroule en plusieurs phases :

Pré-entraînement. Le modèle est entraîné sur un corpus massif de texte (des centaines de milliards à des dizaines de milliers de milliards de tokens) avec l’objectif CLM. Il apprend la structure du langage, le raisonnement, les faits. C’est de loin la phase la plus coûteuse.

Instruction tuning (fine-tuning supervisé). Le modèle est fine-tuné sur des paires (instruction, réponse) pour lui apprendre à suivre des consignes plutôt qu’à simplement compléter du texte. Sans cette étape, un modèle pré-entraîné continuera un texte au lieu de répondre à une question.

Alignement (RLHF, DPO). Le modèle est aligné avec les préférences humaines pour être utile, honnête et inoffensif. Cette étape utilise des techniques comme le RLHF (Reinforcement Learning from Human Feedback) ou le DPO (Direct Preference Optimization).

Pourquoi le decoder-only domine les LLM

Simplicité architecturale

Un decoder-only n’a qu’un seul type de bloc (attention causale + FFN), là où un encoder-decoder a trois types de sous-couches (attention bidirectionnelle dans l’encodeur, attention causale dans le décodeur, et cross-attention entre les deux). Cette simplicité facilite le scaling : pour agrandir le modèle, il suffit d’empiler plus de blocs identiques ou d’augmenter la dimension cachée.

Unification compréhension et génération

Le decoder-only traite tous les tokens de manière uniforme. Il n’y a pas de distinction structurelle entre l’entrée (la question) et la sortie (la réponse) : les deux sont une séquence unique traitée de gauche à droite. Cette unification simplifie l’entraînement et le pipeline d’inférence. L’encoder-decoder, lui, traite input et output avec deux réseaux différents, ajoutant de la complexité.

Scaling empiriquement supérieur

Des études comparatives montrent que l’avantage du decoder-only sur l’encoder-decoder devient plus prononcé à grande échelle. Un article d’octobre 2025 (RedLLM) compare rigoureusement les deux architectures à différentes tailles et montre que si l’encoder-decoder a un léger avantage à faible budget de calcul, le decoder-only domine quand le budget augmente. L’hypothèse est que l’objectif de langage causal est plus efficient pour exploiter les tokens d’entraînement que l’objectif de corruption/reconstruction utilisé par les encoder-decoders.

Capacités zero-shot émergentes

Le decoder-only, entraîné simplement à prédire le token suivant, développe des capacités émergentes remarquables à grande échelle : raisonnement, traduction, résumé, programmation, sans avoir été explicitement entraîné pour ces tâches. GPT-2 (2019) a été le premier à démontrer ce phénomène, et chaque génération suivante l’a amplifié. Ces capacités émergentes sont un argument fort en faveur de la simplicité de l’objectif CLM.

Variantes modernes du decoder-only

L’architecture decoder-only a évolué depuis GPT-1 (2018) tout en gardant ses fondamentaux. Voici les principales modifications adoptées par les modèles modernes :

Le point clé : malgré ces évolutions, la structure fondamentale reste celle de GPT-1. Les modifications sont des raffinements, pas des ruptures. Comme le résume un ingénieur de Stack Overflow : « Les LLM évoluent vite. Leur architecture sous-jacente, beaucoup moins. »

Decoder-only vs. encoder-decoder : le débat

Le passage massif de l’encoder-decoder au decoder-only n’a pas fait l’unanimité dans la communauté de recherche. Certains arguments nuancent cette domination :

L’encoder-decoder a des atouts théoriques. Son encodeur bidirectionnel produit des représentations plus riches du contexte d’entrée, car chaque token « voit » toute la séquence (pas seulement les tokens précédents). Pour les tâches de traduction, de résumé ou de Q&A extractif, cette compréhension bidirectionnelle est un avantage structurel.

L’encoder-decoder brille après instruction tuning. Les travaux de Wang et al. (2022) montrent qu’à budget de calcul comparable (en donnant à l’encoder-decoder 2× plus de paramètres pour compenser son architecture en deux parties), l’encoder-decoder surpasse significativement le decoder-only après instruction tuning.

Mais le decoder-only scale mieux. L’étude RedLLM (octobre 2025) confirme que l’avantage du decoder-only augmente avec le budget de calcul. À petite échelle, les deux se valent. À grande échelle, le decoder-only domine. C’est probablement la raison pratique de son adoption universelle : les labos qui investissent massivement dans l’entraînement obtiennent de meilleurs résultats avec le decoder-only.

Decoder-only et MoE : une combinaison naturelle

Il faut comprendre que dense vs. sparse et decoder-only vs. encoder-decoder sont deux axes orthogonaux. Un modèle decoder-only peut être dense (LLaMA 3.1, Claude) ou MoE (DeepSeek V3, Mistral Large 3). Dans les deux cas, la structure des blocs est decoder-only (attention causale + FFN/MoE).

En pratique, quasiment tous les modèles MoE sont aussi decoder-only. Le Switch Transformer fait exception (il est basé sur T5, un encoder-decoder), mais il est l’un des rares. Les modèles frontier combinent systématiquement decoder-only + MoE pour maximiser à la fois la simplicité architecturale et l’efficacité de scaling.

Les deux phases de l’inférence : prefill et decode

L’inférence d’un decoder-only se décompose en deux phases distinctes, avec des profils de performance très différents :

Prefill (remplissage). Le modèle traite l’intégralité du prompt d’entrée en une seule passe parallèle. Tous les tokens du prompt sont traités simultanément (grâce au masque causal qui assure que chaque position ne voit que les tokens précédents). Cette phase est compute-bound : le goulot d’étranglement est la capacité de calcul du GPU. Le KV-cache est rempli pour tous les tokens du prompt.

Decode (décodage). Le modèle génère les tokens de réponse un par un, de manière autoréressive. Chaque nouveau token nécessite une passe du modèle, mais grâce au KV-cache, seul le calcul pour le nouveau token est effectué (les tokens précédents sont déjà en cache). Cette phase est memory-bandwidth-bound : le goulot d’étranglement est la vitesse de lecture des poids du modèle et du KV-cache depuis la mémoire GPU.

Cette distinction est cruciale pour l’optimisation. Le framework NVIDIA Dynamo exploite cette dualité en assignant le prefill et le decode à des GPU différents, chacun optimisé pour son profil de charge. C’est d’autant plus important pour les modèles MoE, où le prefill et le decode ont des patterns de routage différents.

Limites du decoder-only

Compréhension contextuelle plus faible que l’encoder-only. L’attention causale empêche un token de voir le contexte futur, ce qui limite la compréhension globale de l’entrée. Pour la classification de texte ou l’extraction d’entités, un modèle encoder-only (BERT) avec son attention bidirectionnelle reste souvent supérieur à taille comparable.

Génération séquentielle lente. La nature autoréressive force une génération token par token, chaque token dépendant du précédent. C’est fondamentalement séquentiel et constitue un goulot d’étranglement de latence. Des techniques comme le speculative decoding et le parallel decoding tentent de contourner cette limitation.

Redondance de calcul sur l’entrée. Dans un decoder-only, l’entrée et la sortie sont traitées par le même réseau. Pour des tâches comme la traduction où l’entrée nécessite une compréhension profonde et la sortie une génération fluide, l’encoder-decoder avec ses deux réseaux spécialisés peut être plus efficient.

Verdict

Le decoder-only est l’architecture qui a rendu les LLM possibles tels que nous les connaissons. Sa simplicité (un seul type de bloc, un seul objectif d’entraînement) combinée à ses propriétés de scaling exceptionnelles en fait le choix par défaut pour tout modèle de langage génératif en 2026.

Ce n’est pas nécessairement l’architecture théoriquement optimale pour toutes les tâches : l’encoder-decoder a des avantages sur les tâches seq-to-seq, et l’encoder-only domine pour les embeddings et la classification. Mais le decoder-only a un avantage pratique décisif : il fait tout « assez bien » avec une architecture simple qui scale remarquablement. Et dans un monde où le scaling est le levier principal d’amélioration, « simple et scalable » bat « optimal mais complexe ».