Accueil › Glossaire › Model Architecture

Model Architecture (Architecture du Modèle)

L’architecture d’un modèle d’IA (model architecture) désigne la structure interne du réseau de neurones : le nombre et le type de couches, les connexions entre elles, les mécanismes d’attention, la façon dont les données circulent de l’entrée à la sortie. C’est le « plan de construction » du modèle, distinct des poids (les valeurs apprises) et des données d’entraînement.

Pourquoi l’architecture compte

L’architecture est le premier choix fondamental dans la construction d’un modèle d’IA. Avant de collecter des données ou de lancer l’entraînement, il faut décider comment le réseau de neurones sera organisé. Ce choix détermine :

• La capacité du modèle : combien de patterns il peut apprendre et retenir
• L’efficacité d’entraînement : combien de FLOPs sont nécessaires pour atteindre un niveau de performance donné
• La vitesse d’inférence : combien de tokens par seconde le modèle peut générer
• La consommation mémoire : combien de GPU et de RAM sont nécessaires pour exécuter le modèle
• Les modalités supportées : texte seul, texte + images, texte + images + audio + vidéo

Deux modèles avec le même nombre de paramètres mais des architectures différentes peuvent avoir des performances radicalement différentes. L’architecture est souvent plus déterminante que la taille brute du modèle.

Le Transformer : l’architecture fondatrice

Depuis le papier « Attention Is All You Need » (Vaswani et al., 2017), le Transformer est l’architecture dominante pour les LLM et la plupart des modèles d’IA générative. Sa force : le mécanisme d’self-attention, qui permet à chaque token de « regarder » tous les autres tokens de la séquence, capturant les dépendances longue distance de façon massivement parallèle.

Un Transformer standard se compose de blocs empilés, chacun contenant :

1. Un module d’attention multi-têtes (multi-head attention), qui calcule les relations entre tokens
2. Un réseau feed-forward (FFN), qui transforme la représentation de chaque token
3. Des connexions résiduelles et des couches de normalisation

Les LLM modernes utilisent le Transformer en mode « decoder-only » : le modèle ne voit que les tokens précédents et prédit le suivant, token par token. C’est le cas de GPT, Claude, Llama, Mistral et Gemma.

Dense vs Mixture-of-Experts : le grand choix de 2025-2026

La distinction architecturale la plus importante aujourd’hui oppose les modèles « denses » aux modèles « Mixture-of-Experts » (MoE). La quasi-totalité des modèles frontier de 2025-2026 sont MoE.

Architecture dense

Dans un modèle dense, chaque paramètre est activé pour chaque token traité. Tous les neurones participent à chaque prédiction. C’est l’approche classique, utilisée par les premières versions de GPT, Llama 3.3, et les petits modèles Gemma.

Avantages : simple à implémenter, à fine-tuner et à optimiser. Tous les paramètres contribuent à chaque prédiction, ce qui maximise l’utilisation de la capacité du modèle.

Inconvénient majeur : le coût d’inférence est proportionnel au nombre total de paramètres. Un modèle dense de 400B de paramètres coûte 400B de paramètres de calcul pour chaque token. À grande échelle, cela devient prohibitif.

Architecture MoE (Mixture-of-Experts)

Un modèle MoE remplace le réseau feed-forward (FFN) de chaque bloc Transformer par un ensemble de « experts » (chacun étant un petit FFN spécialisé) et un « routeur » (gating network) qui décide quels experts activer pour chaque token.

Le principe : pour chaque token, seuls 1 à 4 experts (sur 8, 16 ou 128 au total) sont activés. Les autres restent dormants. Cela découple la capacité du modèle (paramètres totaux) du coût de calcul (paramètres actifs).

L’avantage est considérable : Mistral Large 3 possède la capacité d’un modèle de 675B paramètres, mais le coût d’inférence d’un modèle dense de ~41B. C’est ce qui permet de l’exécuter sur un seul nœud de 8 GPU H100, alors qu’un modèle dense de 675B serait impraticable.

Les défis de l’architecture MoE

Mémoire. Même si seuls quelques experts sont activés par token, tous les poids doivent être chargés en mémoire (ou paginés depuis le stockage). Un modèle MoE de 675B nécessite autant de RAM/VRAM qu’un modèle dense de 675B, même si son coût de calcul est bien inférieur.

Load balancing. Le routeur peut développer un biais vers certains experts, en envoyant la majorité des tokens à un petit nombre d’experts « favoris ». Cela sous-utilise les autres experts et dégrade les performances. Des techniques comme les « auxiliary losses » (pertes auxiliaires d’équilibrage) ou l’approche sans perte auxiliaire de DeepSeek (utilisant des termes de biais ajustés manuellement) adressent ce problème.

Fine-tuning. Les modèles MoE sont historiquement plus difficiles à fine-tuner que les modèles denses. Les mises à jour de gradient sont plus « éparses » (seuls les experts activés reçoivent des gradients), ce qui peut entraîner un surapprentissage. Les recherches récentes (notamment le papier ST-MoE) ont montré que fine-tuner les couches non-MoE (attention, normalisation) plutôt que les experts donne souvent de meilleurs résultats.

Composants architecturaux clés

Mécanismes d’attention

L’attention est le cœur du Transformer. Plusieurs variantes ont émergé pour réduire le coût et la mémoire :

• Multi-Head Attention (MHA) : le mécanisme original, avec des têtes d’attention indépendantes. Coûteux en mémoire (cache KV volumineux).
• Grouped-Query Attention (GQA) : partage les clés et valeurs entre groupes de têtes de requête. Réduit le cache KV. Utilisé par Llama 3, Gemma 3, Qwen 3.
• Multi-Head Latent Attention (MLA) : compresse les représentations clé-valeur dans un espace latent de dimension réduite. Innovation de DeepSeek V3.
• Sliding Window Attention : chaque token ne regarde qu’une fenêtre locale de tokens récents, au lieu de toute la séquence. Réduit drastiquement le coût pour les longs contextes. Utilisé par Mistral, Gemma 3 (alternance attention locale/globale à ratio 5:1).
• DeepSeek Sparse Attention (DSA) : mécanisme d’attention clairsemé à grain fin, réduisant le coût d’entraînement et d’inférence de ~50 % par rapport à l’attention dense. Innovation de DeepSeek V3.2.

Encodage positionnel

Les Transformers n’ont pas de notion intrinsèque de l’ordre des tokens. L’encodage positionnel résout ce problème. L’approche dominante est RoPE (Rotary Positional Embeddings), avec des fréquences de base ajustables pour supporter différentes longueurs de contexte. Gemma 3 utilise une fréquence de base de 1M (contre 10K pour Gemma 2), puis multiplie par 8 pour l’extension à 128K tokens.

Llama 4 utilise iRoPE (interleaved RoPE), qui alterne des couches avec et sans encodage positionnel, améliorant le traitement des séquences très longues (jusqu’à 10M tokens pour Scout).

Normalisation

Les couches de normalisation stabilisent l’entraînement. La tendance actuelle est à RMSNorm (Root Mean Square Normalization), plus simple et plus rapide que LayerNorm classique, avec QK-normalization pour stabiliser les scores d’attention à grande échelle. La plupart des modèles récents (DeepSeek, Llama 4, Gemma 3) utilisent cette approche.

Tokenizer

Le tokenizer convertit le texte en séquences de tokens numériques que le modèle peut traiter. Ce n’est pas à proprement parler un composant de l’architecture du réseau, mais il est intimement lié à celle-ci (la taille du vocabulaire détermine la dimension de la matrice d’embedding). Les tokenizers modernes utilisent BPE (Byte-Pair Encoding) ou SentencePiece, avec des vocabulaires allant de 32K à 262K tokens.

Architectures hybrides : la tendance 2026

Hybride MoE-dense

Plutôt qu’un choix binaire entre dense et MoE, certains modèles alternent les deux types de couches. Llama 4 Maverick alterne des blocs MoE et des blocs denses (environ un sur deux), combinant la spécialisation des experts avec la stabilité des couches denses. C’est un compromis qui facilite le fine-tuning tout en conservant l’efficacité du MoE.

Hybride Transformer-SSM (State Space Model)

Les State Space Models (SSM), comme Mamba, offrent une alternative aux Transformers pour le traitement des séquences longues. Leur coût est linéaire par rapport à la longueur de la séquence (contre quadratique pour l’attention standard), ce qui les rend très efficaces pour les très longs contextes.

Les architectures hybrides comme Jamba (AI21 Labs) et Nemotron 3 (NVIDIA) combinent des couches Transformer (pour la précision du rappel et l’attention sur les détails) avec des couches SSM/Mamba (pour l’efficacité sur les longs contextes). NVIDIA Nemotron 3, sorti en décembre 2025, est un hybride MoE-Mamba-Transformer qui publie à la fois les poids, le dataset et le code d’entraînement.

Fusion multimodale

L’architecture détermine aussi comment un modèle traite plusieurs modalités (texte, images, vidéo, audio). Deux approches coexistent :

Fusion tardive (late fusion) : un encodeur séparé (SigLIP pour les images, Whisper pour l’audio) convertit chaque modalité en tokens, puis le Transformer texte traite l’ensemble. C’est l’approche de Gemma 3 et PaliGemma.

Fusion précoce (early fusion) : les différentes modalités sont entraînées ensemble dès le départ, dans une architecture unifiée. C’est l’approche de Llama 4, qui intègre un encodeur vision MetaCLIP nativement dans l’architecture. La fusion précoce produit généralement de meilleures interactions intermodales, mais elle est plus coûteuse à entraîner.

Architecture et performance : ce qui compte vraiment

Un enseignement clé de 2025-2026 : l’architecture seule n’explique pas les performances. Le pipeline d’entraînement (données, curriculum, distillation, post-training RLHF) compte au moins autant. Gemma 3 4B, grâce à la distillation depuis Gemini 2.0, rivalise avec Gemma 2 27B malgré une architecture plus petite. DeepSeek V3.2 a été entraîné pour moins de 6 millions de dollars selon les rapports publiés, prouvant que l’optimisation du pipeline peut compenser un budget compute limité.

L’architecture fixe les limites de ce qui est possible. Le pipeline d’entraînement détermine à quel point ces limites sont atteintes. Les deux sont essentiels.

Impact de l’architecture sur le déploiement

Architecture et confidentialité

La plupart des éditeurs de modèles propriétaires ne publient pas les détails exacts de leur architecture. OpenAI n’a jamais confirmé officiellement l’architecture de GPT-4 ou GPT-5.4 (bien que de fortes présomptions indiquent qu’il s’agit de MoE). Anthropic ne publie pas les détails architecturaux de Claude. Google ne détaille pas l’architecture exacte de Gemini.

C’est un contraste frappant avec les modèles open weights, où les rapports techniques et le code source rendent l’architecture entièrement transparente. La communauté open source a bénéficié de rapports techniques détaillés de DeepSeek (architecture MLA, DSA), de Mistral (architecture MoE granulaire), et de Google (rapport technique Gemma 3).

Verdict

L’architecture d’un modèle d’IA est le fondement sur lequel tout le reste repose. Le Transformer reste l’architecture de base indiscutée, mais la variante MoE est devenue la norme pour les modèles frontier en 2025-2026, offrant une réduction de coût de calcul d’environ 70 % par rapport aux modèles denses de capacité comparable.

La prochaine évolution sera probablement la généralisation des architectures hybrides (Transformer + SSM + MoE), combinant la précision de l’attention, l’efficacité des State Space Models sur les longs contextes, et la spécialisation des experts. NVIDIA Nemotron 3 montre la direction.

Pour un praticien, la bonne nouvelle est que les choix architecturaux sont transparents pour la plupart des usages : vous téléchargez un modèle, vous l’exécutez avec vLLM ou Ollama, et l’architecture fait son travail en coulisses. Mais comprendre les bases vous aide à choisir le bon modèle pour votre cas d’usage, à anticiper les contraintes de déploiement, et à interpréter les benchmarks de façon éclairée.