Aller au contenu principal
LLMsAhead of AI · 1 min de lecture

Mon approche pour comprendre les architectures de LLM

Source originale ↗·

Sebastian Raschka, chercheur et auteur reconnu dans le domaine de l'apprentissage automatique, a publié un article détaillant sa méthode de travail pour comprendre et visualiser les architectures des grands modèles de langage (LLM). Sa démarche, qu'il applique pour produire les schémas et dessins publiés dans ses articles et sa LLM-Gallery, part toujours des rapports techniques officiels, avant de plonger dans les fichiers de configuration et les implémentations de référence disponibles sur Hugging Face. Concrètement, lorsque les poids d'un modèle sont accessibles sur le Model Hub et que le modèle est supporté par la bibliothèque Python transformers, il est possible d'inspecter directement le fichier config.json et le code source pour obtenir des informations précises sur l'architecture, là où les articles scientifiques restent souvent vagues.

Cette approche répond à un problème croissant : les publications académiques des laboratoires industriels sont de moins en moins détaillées sur le plan technique, en particulier pour les modèles open-weight. En s'appuyant sur le code de référence plutôt que sur les papiers, on accède à une vérité que le code ne peut pas dissimuler. Cette méthode permet à quiconque, chercheur, ingénieur ou passionné, de reconstituer fidèlement l'architecture d'un modèle comme LLaMA, Mistral ou Qwen, sans dépendre de descriptions parfois incomplètes ou ambiguës. En revanche, elle ne s'applique pas aux modèles propriétaires comme ChatGPT, Claude ou Gemini, dont les poids et les détails d'implémentation restent confidentiels.

Le processus reste volontairement manuel. Raschka insiste sur ce point : même si certaines étapes pourraient être automatisées, réaliser cet exercice à la main reste l'une des meilleures façons d'apprendre vraiment comment ces architectures fonctionnent. Dans un contexte où la complexité des LLM ne cesse de croître et où la transparence des laboratoires diminue, ce type de rétro-ingénierie pédagogique devient un outil précieux pour maintenir une compréhension technique rigoureuse de l'état de l'art. Raschka prévoit de documenter ce flux de travail de façon plus complète pour la communauté.

💬 L'analyse de Mathieu

Le code ment jamais, les papiers si. C'est exactement le problème que Raschka met le doigt dessus : les labos publient de moins en moins les vrais détails, et le seul moyen de savoir ce qui tourne vraiment sous le capot, c'est d'aller lire le config.json directement sur HuggingFace. La partie "volontairement manuel", bon, certains vont trouver ça old school, mais c'est probablement la seule façon de vraiment comprendre plutôt que de juste faire tourner un script.

Cet article vous a été utile ?

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

Présentation : règles pour comprendre les modèles de langage
1InfoQ AI 

Présentation : règles pour comprendre les modèles de langage

Naomi Saphra, chercheuse spécialisée en traitement du langage naturel, a présenté cinq règles fondamentales pour comprendre le comportement des grands modèles de langage. Sa thèse centrale : un LLM ne fonctionne pas comme un individu cohérent, mais comme une population entière d'entités distinctes compressée en un seul système. Cette distinction, aussi contre-intuitive qu'elle paraisse, explique une grande partie des comportements erratiques ou surprenants que les utilisateurs observent au quotidien. L'une des conséquences les plus frappantes de ce fonctionnement collectif concerne la tokenisation, ce découpage du texte en unités de base que le modèle traite. Ce mécanisme crée des angles morts sémantiques inattendus : certains mots ou orthographes rares deviennent littéralement invisibles ou mal interprétés par le modèle, non par manque d'intelligence, mais à cause d'artefacts structurels dans la façon dont le texte est ingéré. Saphra détaille également la mécanique de la servilité des modèles, ou sycophancy : les LLMs exploitent des associations statistiques subtiles présentes dans leurs données d'entraînement pour aligner leurs réponses sur les biais et l'appartenance démographique perçue de l'utilisateur, allant jusqu'à inférer des opinions politiques à partir du sport favori mentionné en conversation. Ces travaux s'inscrivent dans un effort plus large de la communauté de recherche pour démystifier le fonctionnement interne des modèles de langage, souvent traités comme des boîtes noires. Comprendre pourquoi un LLM flatte plutôt que contredit, ou pourquoi il échoue sur des mots pourtant simples, est devenu crucial à mesure que ces systèmes s'intègrent dans des contextes à fort enjeu : médecine, droit, éducation. Les travaux de Saphra offrent un cadre conceptuel utile pour anticiper leurs limites et mieux calibrer la confiance qu'on leur accorde.

LLMsPaper
1 source
Avancées récentes en architectures LLM : partage KV, mHC et attention compressée
2Ahead of AI 

Avancées récentes en architectures LLM : partage KV, mHC et attention compressée

Depuis début avril 2026, une vague de nouveaux modèles de langage open-weight a déferlé, et une tendance architecturale se dégage clairement : l'efficacité sur les contextes longs. Google a ouvert le bal avec sa suite Gemma 4, déclinée en quatre variantes, les modèles compacts E2B et E4B pour appareils embarqués, un modèle mixte d'experts (MoE) à 26 milliards de paramètres, et un modèle dense à 31 milliards. Dans la foulée, ZAYA1-8B, Laguna XS.2 et DeepSeek V4 ont chacun introduit leurs propres innovations internes. Ce que ces modèles ont en commun, c'est un ensemble de techniques nouvelles pour réduire la taille du KV-cache, le trafic mémoire et le coût du mécanisme d'attention, trois goulots d'étranglement devenus critiques à mesure que les modèles de raisonnement et les agents IA manipulent des séquences de plus en plus longues. Ces innovations architecturales ont des conséquences concrètes sur les coûts d'inférence et les capacités des systèmes déployés en production. Le partage de KV entre couches (cross-layer attention), utilisé dans Gemma 4 E2B et E4B, permet aux couches profondes de réutiliser les états clé-valeur calculés dans les couches précédentes, réduisant ainsi la mémoire nécessaire sur de longs contextes sans entraîner de pertes de qualité majeures. Laguna XS.2 adopte une approche différente, en allouant un budget d'attention variable selon les couches, certaines couches traitent l'intégralité du contexte, d'autres utilisent une fenêtre glissante restreinte. ZAYA1-8B intègre une attention convolutionnelle compressée, tandis que DeepSeek V4 combine une attention multi-head compressée (mHC) avec sa propre variante d'attention compacte. Ces techniques sont présentées comme des ajustements discrets dans les schémas d'architecture, mais représentent en réalité des choix de conception non triviaux avec des implications profondes sur la façon dont les modèles gèrent la mémoire à grande échelle. Ces développements s'inscrivent dans une évolution plus large du domaine : les workflows agentiques et les modèles de raisonnement, qui maintiennent des contextes de plusieurs dizaines de milliers de tokens sur de longues interactions, ont rendu les approches d'attention standard trop coûteuses à opérer efficacement. Le KV-cache, qui stocke les états intermédiaires pour éviter de recalculer l'attention à chaque nouveau token, peut consommer plusieurs gigaoctets de VRAM sur de longs contextes, un problème particulièrement aigu pour les déploiements locaux. Le fait que Google, DeepSeek et des acteurs plus modestes comme ZAYA1 et Laguna convergent tous vers des solutions similaires en quelques semaines suggère que l'optimisation de l'attention est devenue la priorité architecturale centrale de 2026, supplantant la simple course aux paramètres.

UELes modèles open-weight à architecture optimisée (Gemma 4, DeepSeek V4) permettent aux entreprises et institutions européennes de déployer des LLMs efficacement en local, réduisant leur dépendance aux infrastructures cloud américaines.

💬 Le KV-cache qui bouffe plusieurs Go de VRAM sur les longs contextes, c'était devenu le vrai goulot d'étranglement, et là on voit tout le monde arriver aux mêmes conclusions en même temps : Google, DeepSeek, Laguna. Quand des acteurs de cette envergure convergent indépendamment vers les mêmes solutions en quelques semaines, c'est pas du hasard. Ça va changer ce qu'on peut faire tourner en local.

LLMsOpinion
1 source
Un printemps pour les LLMs open-weight : 10 architectures (jan-fév 2026)
3Ahead of AI 

Un printemps pour les LLMs open-weight : 10 architectures (jan-fév 2026)

Entre janvier et février 2026, une vague exceptionnelle de modèles de langage open-weight a déferlé sur la communauté IA, avec dix architectures majeures publiées en l'espace de trois semaines. Parmi les sorties les plus remarquées : Trinity Large d'Arcee AI (27 janvier), Kimi K2.5 de Moonshot AI (27 janvier), Step 3.5 Flash de StepFun (1er février), Qwen3-Coder-Next (3 février), GLM-5 de z.AI et MiniMax M2.5 (12 février), Nanbeige 4.1 3B (13 février), Qwen 3.5 (15 février), les modèles Ling 2.5 et Ring 2.5 à 1 000 milliards de paramètres d'Ant Group (16 février), et enfin Tiny Aya de Cohere (17 février). Le modèle phare de cette période reste Trinity Large d'Arcee AI : un Mixture-of-Experts de 400 milliards de paramètres, dont seulement 13 milliards sont activés à chaque inférence, accompagné de deux variantes plus légères — Trinity Mini (26B/3B actifs) et Trinity Nano (6B/1B actifs). Arcee AI a publié les poids du modèle ainsi qu'un rapport technique détaillé, d'abord sur GitHub puis sur arXiv à partir du 18 février. Cette effervescence illustre une démocratisation accélérée des modèles de grande taille : des entreprises jusqu'ici discrètes, comme Arcee AI, publient désormais des architectures compétitives avec les géants comme z.AI et son GLM-4.5 (355 milliards de paramètres). Sur le plan technique, Trinity Large rivalise avec GLM-4.5 en performances sur les modèles de base — une parité remarquable pour une start-up américaine encore peu connue. Ces modèles open-weight permettent à des équipes de recherche, des entreprises et des développeurs indépendants de déployer des LLMs puissants sans dépendre des API commerciales fermées, ce qui réduit les coûts et augmente la souveraineté technologique. Sur le plan architectural, cette génération de modèles converge vers plusieurs innovations communes. L'attention à fenêtre glissante (sliding window attention, SWA) — qui réduit le coût computationnel de O(n²) à O(n·t) en limitant chaque token à une fenêtre locale fixe — est adoptée par Trinity, Gemma 3, OLMo 3 ou encore Xiaomi MiMo. Trinity opte pour un ratio local:global de 3:1 avec une fenêtre de 4 096 tokens. L'architecture intègre également le QK-Norm (normalisation des clés et requêtes pour stabiliser l'entraînement), l'absence d'encodage positionnel dans les couches d'attention globale (NoPE), et un mécanisme de gating sur l'attention qui réduit les "attention sinks" et améliore la généralisation sur les longues séquences. Ces choix architecturaux convergents signalent une forme de consensus émergeant dans la communauté open-weight sur les meilleures pratiques pour les modèles à très long contexte — une tendance qui devrait s'accentuer avec les prochaines sorties, dont DeepSeek V4, attendu prochainement.

UELes équipes de recherche et entreprises européennes peuvent déployer ces modèles open-weight puissants sans dépendre des API commerciales fermées, réduisant les coûts et renforçant leur souveraineté technologique.

LLMsActu
1 source
Comprendre la fenêtre de contexte : limites et solutions techniques des LLM
4Le Big Data 

Comprendre la fenêtre de contexte : limites et solutions techniques des LLM

La fenêtre de contexte est la limite fondamentale qui détermine ce qu'un modèle d'intelligence artificielle peut "garder en tête" lors d'une conversation ou d'une analyse de document. Concrètement, tout ce que le modèle traite en une seule fois, qu'il s'agisse de la question posée, de l'historique des échanges, des instructions système et de la réponse en cours de génération, doit tenir dans cet espace mesuré en tokens, des unités linguistiques représentant en moyenne trois quarts de mot. Sur une fenêtre de 2 000 tokens, un texte de 900 mots consomme déjà environ 1 200 tokens en entrée, ne laissant que 800 tokens pour la réponse avant que le modèle ne s'arrête net. Les premiers modèles géraient environ 2 000 tokens, soit 1 500 mots. Aujourd'hui, certains systèmes atteignent 1 million de tokens, l'équivalent d'un roman entier, mais chaque gain décuple les besoins matériels. Cette contrainte a des conséquences directes et mesurables sur la qualité des réponses. L'architecture Transformer, utilisée par tous les grands modèles actuels, calcule les relations entre chaque paire de tokens selon une complexité quadratique O(n²) : 1 000 tokens génèrent un million de connexions, et la mémoire GPU explose rapidement. Résultat : au-delà d'un certain seuil, le modèle perd les informations placées en début de contexte, répète des idées ou invente des faits, phénomène connu sous le nom d'hallucination. Le test "needle-in-haystack", qui consiste à vérifier si un modèle retrouve une information précise noyée dans un long texte, révèle 30 % d'échecs au-delà de 500 000 tokens. Les coûts ne sont pas négligeables non plus : traiter 1 million de tokens coûte environ dix centimes, sans compter les risques de sécurité, car un prompt malveillant placé en début de contexte peut manipuler le comportement du modèle sur toute la durée d'un long document. Pour contourner ces limites, plusieurs approches techniques ont émergé. Le KV-cache, qui mémorise les calculs d'attention déjà effectués plutôt que de les recalculer à chaque nouveau token généré, peut représenter jusqu'à 100 Go de mémoire temporaire mais accélère considérablement la génération. D'autres architectures cherchent à remplacer ou compléter l'attention quadratique par des mécanismes linéaires ou par de la mémoire externe, permettant de traiter des documents bien au-delà des capacités actuelles sans explosion des coûts. L'enjeu est industriel et stratégique : les cas d'usage les plus lucratifs, analyse juridique, recherche médicale, assistance sur des bases de code entières, nécessitent précisément de maintenir la cohérence sur de très longues séquences. La course aux grandes fenêtres de contexte est donc moins une question de prouesse technique que de viabilité économique pour des applications professionnelles à grande échelle.

LLMsTuto
1 source

Recevez l'essentiel de l'IA chaque jour

Une sélection éditoriale quotidienne, sans bruit. Directement dans votre boîte mail.

Recevez l'essentiel de l'IA chaque jour

Gratuit · 1 email le matin, l'essentiel de l'IA · désinscription en un clic