- ▸ Un dépôt minuscule pour une question majeure
- ▸ Thèse : la simplicité n'est pas une réduction d'échelle
- ▸ Contexte historique : de nanoGPT à la pédagogie de l'os
- ▸ Analyse technique : pourquoi la BPE casse en dessous d'une certaine échelle
Un dépôt GitHub publié en avril 2026 propose de construire un modèle de langage de 10 millions de paramètres en moins d’une heure sur un ordinateur portable, sans GPU dédié ni dépendance cloud. Derrière la promesse pédagogique se cache une question technique épineuse : pourquoi le tokenizer de référence des grands laboratoires devient inutilisable à cette échelle ? Trois choix d’architecture, trois compromis, trois enseignements pour qui veut comprendre la mécanique réelle d’un LLM.
Points clés 1. Le projet
angelos-p/llm-from-scratchcible un modèle de 10M de paramètres entraînable en moins d’une heure sur un laptop, conçu pour une session de workshop unique. 2. La référence pédagogique nanoGPT vise la reproduction de GPT-2 et ses 124M de paramètres, soit un ordre de grandeur supérieur en taille de modèle. 3. La tokenisation BPE de GPT-2, avec son vocabulaire de 50 257 entrées, devient contre-productive sur de petits jeux de données : la majorité des bigrams de tokens y sont trop rares. 4. Le tutoriel propose en alternative une tokenisation caractère par caractère (~65 entrées de vocabulaire), adaptée à un corpus de l’ordre de 1 Mo type Shakespeare. 5. L’entraînement bascule automatiquement sur GPU Apple Silicon (MPS), GPU NVIDIA (CUDA) ou CPU selon le matériel disponible.
Un dépôt minuscule pour une question majeure
Au début du printemps 2026, un dépôt GitHub apparaît sans bruit : angelos-p/llm-from-scratch, daté du 4 avril. Le code y tient en quelques fichiers Python. La promesse, elle, est tranchée : un modèle de langage de dix millions de paramètres, fonctionnel, entraîné en moins d’une heure, sur un laptop ordinaire. Pas de cluster, pas de carte H100, pas d’API. Une session de travail, un noyau de code, un modèle qui parle.
Cette ambition pédagogique n’a rien d’anecdotique. Elle s’inscrit dans une lignée bien identifiée d’efforts visant à démystifier les grands modèles de langage en les ramenant à leur structure essentielle. Mais le détail compte : ce projet ne se contente pas de simplifier nanoGPT, la référence d’Andrej Karpathy. Il opère un choix d’architecture qui révèle un point aveugle des tutoriels classiques — la tokenisation, et son effondrement sur les petits corpus.
Thèse : la simplicité n’est pas une réduction d’échelle
L’idée reçue voudrait qu’apprendre à construire un LLM consiste à reproduire en miniature les choix techniques des grands laboratoires. C’est faux. À l’échelle d’un modèle de 10M de paramètres entraîné sur 1 Mo de texte, certaines briques de l’écosystème industriel deviennent activement contre-productives. La tokenisation BPE en est l’exemple le plus net. Comprendre pourquoi, c’est comprendre que la chaîne de valeur d’un LLM ne se compose pas indépendamment de l’échelle visée.
Contexte historique : de nanoGPT à la pédagogie de l’os
L’histoire des tutoriels « LLM from scratch » s’est cristallisée autour de nanoGPT, le projet d’Andrej Karpathy publié à l’origine pour reproduire GPT-2 et ses 124 millions de paramètres. La documentation du dépôt angelos-p/llm-from-scratch le rappelle explicitement : nanoGPT « cible la reproduction de GPT-2 (124M params) et couvre beaucoup de terrain ». Cette ambition reproductive est sa force et sa limite.
Sa force : nanoGPT démontre qu’un transformer décodeur fonctionnel tient en quelques centaines de lignes de Python et PyTorch. Il a fait école auprès de toute une génération d’ingénieurs ML qui ont pu, pour la première fois, lire l’intégralité du chemin entre un fichier texte brut et des poids entraînés générant du langage cohérent. Cette transparence radicale a contribué à dissiper le mystère qui entourait les premiers GPT, dont le code d’entraînement n’a jamais été publié intégralement par OpenAI.
Sa limite : 124 millions de paramètres restent un objet lourd. Reproduire GPT-2, même dans sa version la plus petite, exige une infrastructure de calcul, un volume de données et un temps d’entraînement qui excluent de fait le format atelier — celui où une vingtaine de personnes ouvrent leur laptop, suivent une démonstration, et repartent en ayant exécuté chaque étape elles-mêmes. C’est précisément le format que vise angelos-p/llm-from-scratch, qui se présente comme une version « strippée à l’essentiel » et calibrée pour « une session de workshop unique ».
Le passage de 124M à 10M de paramètres n’est pas qu’une question de mémoire vidéo. Il rebat les cartes sur les choix de prétraitement, sur le format du corpus, sur la nature même du signal que le modèle peut extraire. Et c’est là que la tokenisation, brique souvent traitée comme un détail technique en début de chaîne, devient un point de bascule.
Analyse technique : pourquoi la BPE casse en dessous d’une certaine échelle
La tokenisation par paires de bytes — Byte-Pair Encoding, ou BPE — est l’algorithme de référence des LLM modernes. GPT-2 l’utilise avec un vocabulaire de 50 257 tokens, chiffre devenu canonique. Le principe : analyser un grand corpus, identifier les paires de caractères ou de sous-mots qui co-occurrent fréquemment, et les fusionner itérativement en unités de plus en plus longues. Le résultat est un vocabulaire mixte où coexistent caractères isolés, fragments fréquents (« ing », « tion ») et mots entiers.
Cet équilibre fonctionne admirablement à grande échelle. Sur un corpus de plusieurs centaines de gigaoctets, la fréquence statistique permet au modèle d’apprendre les co-occurrences entre tokens — non plus seulement entre caractères. Le bigram « in »→« g » devient une régularité massivement attestée, exploitable par les couches d’attention. La compression sémantique opère.
À petite échelle, le mécanisme se retourne. La documentation du dépôt est sans détour : « la tokenisation BPE (vocabulaire de 50k de GPT-2) ne fonctionne pas sur de petits jeux de données — la plupart des bigrams de tokens y sont trop rares pour que le modèle apprenne des motifs ». Mécaniquement, un vocabulaire de 50 257 entrées génère un espace de bigrams théorique de l’ordre de 2,5 milliards de paires possibles. Si le corpus d’entraînement fait 1 Mo, soit grossièrement quelques centaines de milliers de tokens, l’écrasante majorité de ces bigrams n’apparaîtra jamais. Le signal d’apprentissage devient famélique.
Le projet propose en réponse une bifurcation explicite : pour les petits corpus, on revient à une tokenisation caractère par caractère, où chaque lettre, chaque ponctuation, chaque retour à la ligne devient un token distinct. Le tableau ci-dessous, repris de la documentation du dépôt, en synthétise la logique :
| Tokenizer | Taille de vocabulaire | Taille de dataset nécessaire |
|---|---|---|
| Caractère par caractère | ~65 | Petit (Shakespeare, ~1 Mo) |
| BPE (tiktoken) | 50 257 | Grand (TinyStories+, 100 Mo+) |
Le contraste est frappant : un facteur 770 entre les deux tailles de vocabulaire, un facteur d’au moins 100 entre les deux tailles de corpus recommandées. Le tokenizer caractère par caractère avec ses 65 entrées approximatives — alphabet ASCII, ponctuation, espaces, retours à la ligne — pulvérise la barrière statistique. Sur un texte de Shakespeare d’un mégaoctet, chaque bigram caractère-caractère apparaît des centaines, parfois des milliers de fois. Le modèle de 10M de paramètres dispose d’un signal dense, exploitable, calibré pour son volume de capacité.
Le dépôt prévoit également une bascule pédagogique : la cinquième partie du tutoriel couvre le passage à la BPE pour des datasets plus volumineux, type TinyStories. Le geste est intéressant car il refuse le faux dilemme. Il ne s’agit pas de dire qu’une méthode est supérieure à l’autre dans l’absolu, mais de montrer que le choix de la tokenisation est asservi à la taille du corpus et à la capacité du modèle. La leçon dépasse largement le cadre du workshop.
Pour Andrej Karpathy, ancien directeur de l’IA chez Tesla et auteur de nanoGPT, la pédagogie des LLM passe par cette mise à nu des compromis. La distinction opérée par angelos-p/llm-from-scratch prolonge cette filiation : elle refuse l’imitation de surface des grands modèles pour exposer la mécanique du choix.
Impact terrain : ce que change un workshop d’une heure
La portée du projet ne se mesure pas à son code, qui reste minimaliste, mais à ce qu’il déverrouille pour son public cible. L’entraînement d’un modèle de 10M de paramètres en moins d’une heure sur un laptop ordinaire transforme la question « qu’est-ce qu’un LLM ? » en exercice manuel. Trois conséquences s’enchaînent.
D’abord, l’accessibilité matérielle. Le code détecte automatiquement la présence d’un GPU Apple Silicon via le backend MPS de PyTorch, d’un GPU NVIDIA via CUDA, ou bascule sur CPU si aucun accélérateur n’est disponible. Cette polyvalence supprime une friction critique dans les ateliers en présentiel : l’animateur n’a plus à présupposer un matériel homogène. Un MacBook récent, un PC portable de gamer, une station Linux modeste — tous deviennent des plateformes d’entraînement viables, même si les durées varient sensiblement entre les trois cibles.
Ensuite, l’absence de dépendances externes. Pas d’API à appeler, pas de clé Hugging Face à provisionner, pas de bucket S3 à configurer. Le corpus d’entraînement type — un texte de Shakespeare d’environ 1 Mo — est trivial à intégrer dans le dépôt. Cette autonomie a une vertu pédagogique souvent sous-estimée : elle déplace le débogage de l’infrastructure vers le code lui-même. L’apprenant qui rencontre un problème ne lutte pas contre une couche d’abstraction tierce, il lit le tenseur qui dérape.
Enfin, la calibration en une session unique. Une heure d’entraînement maximum, plus le temps de mise en place, soit un atelier de deux à trois heures. Ce format correspond aux contraintes pédagogiques réelles des écoles d’ingénieurs, des bootcamps, des journées de formation interne en entreprise. Il rend possible une expérience complète — préparation des données, entraînement, génération — là où les tutoriels calés sur GPT-2 imposent soit de tronquer l’entraînement, soit d’utiliser des poids pré-calculés, ce qui rompt la chaîne d’apprentissage.
Cet impact terrain s’inscrit dans un contexte plus large où la demande de formation à l’IA générative explose en France comme à l’étranger, mais où la majorité des cursus se concentrent sur l’utilisation des modèles existants — le prompt engineering, le fine-tuning supervisé, l’orchestration d’agents. Les ressources permettant de comprendre la couche entraînement de bout en bout, sur un budget temps et matériel raisonnable, restent rares. Le format laptop-d’une-heure crée précisément ce point d’entrée.
Perspectives contradictoires : un modèle à 10M est-il vraiment un LLM ?
L’objection mérite d’être posée frontalement. Avec ses 10 millions de paramètres, le modèle issu du tutoriel se situe à plusieurs ordres de grandeur en dessous des LLM commerciaux actuels, dont les versions accessibles dépassent fréquemment la dizaine de milliards de paramètres. Le qualifier de LLM relève-t-il de l’abus de langage ?
Plusieurs voix dans la communauté de recherche poussent la critique plus loin. Pour elles, ce qui définit un LLM moderne ne tient pas seulement à son architecture transformer, mais à l’émergence de capacités — raisonnement multi-étapes, génération cohérente sur des milliers de tokens, transfert entre tâches — qui n’apparaissent qu’au-delà de seuils paramétriques élevés. Un modèle de 10M de paramètres, entraîné sur 1 Mo de Shakespeare, produira des sorties grammaticalement plausibles mais sémantiquement vides à l’échelle du paragraphe. Il n’est pas un assistant, il est un perroquet stochastique de courte mémoire.
Cette critique n’est pas illégitime, mais elle déplace le débat. Le projet angelos-p/llm-from-scratch ne prétend pas former un assistant utilisable. Il revendique explicitement une vocation pédagogique : montrer comment un transformer décodeur s’entraîne, comment les tokens circulent, comment la fonction de perte décroît. À ce titre, l’échelle 10M est suffisante pour exposer toute la mécanique sans en sacrifier aucune étape. La distinction entre « LLM industriel » et « architecture LLM réduite à des fins d’apprentissage » est une distinction de finalité, pas de nature technique.
Une seconde objection porte sur le choix de la tokenisation caractère par caractère. Certains praticiens estiment qu’enseigner cette voie revient à doter les apprenants d’un réflexe inadapté au monde réel, où la BPE et ses variantes — SentencePiece, Tiktoken — dominent sans partage. Le risque pédagogique : que l’apprenant assimile l’approche caractère-par-caractère comme la voie standard et bute ensuite sur les subtilités de la BPE en production.
Le tutoriel répond partiellement à cette critique en intégrant une cinquième partie consacrée précisément à la transition vers la BPE pour les corpus plus volumineux. La structure pédagogique ne fige donc pas l’apprenant dans le choix initial : elle le lui présente comme une étape calibrée, à dépasser dès que l’échelle des données le permet. Reste que la profondeur de cette cinquième partie n’est pas détaillée dans la documentation publique consultable, et que sa qualité conditionne en pratique la portée formative du projet dans son ensemble.
Prospective : la pédagogie comme contre-pouvoir
À mesure que les laboratoires industriels referment progressivement leurs poids et leurs corpus d’entraînement, la valeur d’un dépôt comme angelos-p/llm-from-scratch ne se mesure plus seulement à son utilité pédagogique immédiate. Elle se mesure aussi à ce qu’il préserve : une compréhension publique, accessible, manipulable, du fonctionnement réel des LLM. La distinction entre tokenisation BPE et caractère-par-caractère, banale en apparence, est précisément le genre de choix de conception qui s’évanouit derrière les API commerciales et que seuls les workshops permettent de saisir manuellement.
La question reste ouverte : combien de praticiens, demain, auront cette compréhension de bout en bout ? Et combien se contenteront d’orchestrer des modèles boîte-noire dont ils ignoreront jusqu’aux choix de vocabulaire ?
FAQ
Est-il vraiment possible de construire un LLM sans dépendances cloud externes ?
Oui. Le dépôt angelos-p/llm-from-scratch cible un modèle de 10 millions de paramètres entraînable sur un laptop en moins d’une heure, sans GPU dédié ni service distant. Le code détecte automatiquement le matériel disponible — GPU Apple Silicon via MPS, GPU NVIDIA via CUDA, ou CPU — et adapte l’entraînement en conséquence.
Pourquoi la tokenisation BPE de GPT-2 ne convient-elle pas aux petits corpus ?
Le vocabulaire BPE de GPT-2 compte 50 257 entrées, calibré pour des corpus de plusieurs dizaines à centaines de mégaoctets. Sur un dataset d’environ 1 Mo, la majorité des bigrams de tokens deviennent statistiquement trop rares : le modèle ne dispose pas d’un signal de co-occurrence suffisant pour apprendre des régularités. La tokenisation caractère par caractère, avec ~65 entrées, restaure ce signal.
Quel matériel minimum faut-il prévoir pour suivre le tutoriel ?
Un ordinateur portable suffit. Le code prend en charge automatiquement les GPU Apple Silicon via MPS, les GPU NVIDIA via CUDA, ou bascule sur CPU si aucun accélérateur n’est présent. Aucune dépendance externe ni service cloud n’est requis, ce qui rend le format adapté aux ateliers en présentiel sur matériel hétérogène.
Le projet remplace-t-il nanoGPT ?
Non. Selon sa propre documentation, nanoGPT vise la reproduction de GPT-2 et ses 124M de paramètres et couvre un périmètre bien plus large. angelos-p/llm-from-scratch se positionne comme une version simplifiée à l’essentiel, calibrée pour une session de workshop unique sur un modèle de 10M. Les deux projets répondent à des besoins pédagogiques différents et complémentaires.
Sources – GitHub — angelos-p/llm-from-scratch (https://github.com/angelos-p/llm-from-scratch), publication consultée le 4 avril 2026. – Documentation associée du dépôt : tableau comparatif des tokenizers, sections 1 à 5 du tutoriel, configuration de détection matérielle (MPS / CUDA / CPU). – Référence comparative : projet nanoGPT (Andrej Karpathy), cité par la documentation du dépôt comme cible pédagogique de reproduction GPT-2 (124M de paramètres).
