Jeff, le brief IA pédagogique

💡 Le Point de vue Mitchell Hashimoto

Slop Is Good

Mitchell Hashimoto, cofondateur de HashiCorp (Terraform, Vagrant) et auteur de l'émulateur de terminal Ghostty, défend une position à rebours du consensus : le "slop" généré par l'IA est une bonne chose. Le slop, c'est ce code produit vite et mal, qu'on n'assume pas, et que le discours dominant traite comme une pollution.

Son argument : le slop est précisément ce qui rend possible l'expérimentation rapide et parallèle. Il développe en ce moment un système dont toute la partie visible, l'interface et l'habillage technique, est, dit-il, du "slop sans aucune honte". Horrible, mais cela lui permet de concentrer la qualité sur le cœur du produit tout en livrant aux testeurs une version utilisable, en restant transparent sur ce qui est bâclé.

Même logique pour les extensions de ce système. Il a lancé des agents en boucle pendant une nuit, qui ont généré des dizaines d'extensions. Leur qualité est mauvaise, et le système qui sert à les créer n'est même pas terminé. Mais il peut désormais tester un écosystème complet, et le jour où il en changera les règles, il régénérera l'ensemble. Le coût d'un changement ne se mesure plus en jours de travail, seulement en tokens consommés par les agents.

Sa nuance compte autant que sa thèse. Le slop reste un outil, ni bon ni mauvais en soi. Il n'enverrait pas ce code dans le projet d'un tiers sans prévenir, ni à des clients sans relecture ni transparence, et n'accepterait jamais un premier jet en l'état, "presque toujours mauvais". La compétence n'est pas de produire du slop, c'est de savoir où il a sa place.

Petite remarque 1 : le compute en + ne sert pas qu'à servir les clients. C'est aussi ce qui permet aux ingénieurs des labos d'explorer, de tester leurs idées à une certaine échelle. Manque de compute et vous devez rationner vos expériences. + de compute = + d'exploration = + de découvertes.

Petite remarque 2 : Je vois bien Karpathy dire : bon ok, je vous rejoins mais je veux une partie de COLOSSUS pour faire mumuse

PS : Parce que ça m'a fait rire

DwarfStar 4

Frontière locale

Ces dernièrs temps, un projet a retenu mon attention. Il s'appelle DS4, pour DwarfStar 4, et il est signé antirez.

antirez, c'est Salvatore Sanfilippo, le développeur italien qui a écrit Redis. Du très solide. Derrière DS4, une conviction : l'IA est devenue trop importante pour rester un service qu'on loue à quelqu'un d'autre. Elle devrait pouvoir tourner chez soi, sur sa propre machine.

DS4 est un moteur d'inférence : le programme qui fait tourner un modèle de langage. Et il a une particularité. Il ne fait tourner qu'UN seul modèle, optimisé SUR MESURE pour lui, jusqu'à le faire tenir sur une (très chère) machine personnelle. Mais machine personnelle tout de même.

Le modèle : DeepSeek V4 Flash.

284 milliards de paramètres au total
13 milliards de paramètres actifs
1 million de tokens dans sa fenêtre de contexte

Un modèle quasi-frontière. Généraliste. Qu'on croyait réservé au cloud. Et antirez le fait tourner sur un Mac récent avec 128 Go de mémoire (oui, je sais, tu n'as pas de mac avec 128 Go de mémoire. Moi non plus).

Faire tourner un modèle en local, ce n'est pas nouveau. Depuis deux ans, on installe des modèles sur sa machine. Des modèles corrects, sans plus. Pas mauvais en code. Mais posez leur une question d'histoire, de géographie, de culture générale, ils déraillent facilement.

Mais ce qu'antirez décrit de son expérience avec DS4, c'est autre chose :

Il n'est pas seul. Armin Ronacher, (européen lui-aussi, créateur de Flask - un framework web python populaire - et contributeur de Pi), a joué avec le modèle :

antirez a une image pour situer ça. Imaginez deux expériences. A, le petit bon modèle local d'avant. B, le modèle de frontière que vous payez en ligne, le Claude ou le GPT que vous utilisez tous les jours. Son verdict sur DS4 :

284 milliards de paramètres. Un paramètre, c'est un nombre à virgule. Stocké chacun sur 16 bits (2 octets), le format habituel, et le modèle pèse environ 570 gigaoctets. Aucune machine personnelle n'avale ça. Pour que DS4 tienne, il a fallu compresser.

Premier étage : ne pas tout utiliser à la fois.

Celui-là, antirez n'y est pour rien. Il tient à la façon dont DeepSeek a conçu le modèle, une architecture qui porte un nom : « Mixture of Experts ». Le modèle range ses 284 milliards de paramètres en 256 experts. Pour traiter un mot, un aiguilleur, le routeur, en active réellement six, + (innovation DeepSeek) un expert permanent (toujours activé). 284 milliards stockés, 13 seulement d'activés à l'inférence (Et c'est le nombre activé qui détermine le nb de calculs à faire).

Cette activation partielle casse un vieux dilemme. Avant, les modèles locaux étaient « denses » : tout s'activait à chaque mot. Il fallait choisir. Petit et rapide, mais ignorant. Ou vaste et savant, mais trop lent. Or le nombre de paramètres dit en gros ce qu'un modèle a emmagasiné. 284 milliards contre 30, c'est l'écart entre savoir coder et savoir parler d'autre chose.

Deuxième étage : arrondir les nombres.

13 milliards de paramètres activés, c'est moins que 284. Mais les 284 doivent quand même tenir en mémoire, prêts à servir.

Alors on arrondit. Chaque paramètre est un nombre, stocké d'habitude sur 16 bits (2 octets). La quantification, c'est le stocker sur moins de bits. À 2 bits, il ne reste que quatre valeurs possibles par paramètre. Quatre. C'est une "caricature" du nombre d'origine. Mais 2, comme tu le sais sûrement, c'est 8x + petit que 16, dc ça occupe 8 fois moins de place en mémoire. C'est la technique utilisée pour faire tourner les modèles en local. Quand tu vois Q4, Q5, Q2, Q8... c'est le nb de bits par paramètre, le niveau de compression en quelque sorte.

MAIS, et c'est là où la vision d'antirez prend tout son sens (rappel: un serveur d'inférence pour un et un seul modèle), antirez ne compresse pas tous les paramètres de la même façon. Seuls les "experts" descendent à 2 bits. C'est là qu'est la masse du modèle, dc l'essentiel du gain. Les voies que tous les mots empruntent, elles, gardent une bien meilleure résolution. L'attention, l'expert permanent, la couche de sortie : 8 ou 16 bits selon le composant, jamais 2. Le routeur lui-même (qui décide quels experts activer) reste à sa précision d'origine, intact.

C'est brillant, et on ne peut le faire vraiment bien qu'en optimisant pour une architecture, pour un modèle bien précis.

Résultat, 570 gigaoctets ramenés à environ 80. Ça rentre dans une machine à 128 gigaoctets de mémoire.

Tout le projet repose sur ce principe. Servir un seul modèle. Et optimiser tout ce qui peut l'être pour ce modèle en local

Faire tenir le modèle en mémoire, c'est une chose. Mais un modèle de langage, on lui parle, on lui donne des documents à lire. Reste donc une deuxième prouesse.

Un MILLION de tokens de contexte. Un contexte aussi long sur une machine personnelle, c'est encore + étonnant que le reste. Le contexte long a jusqu'ici été la spécialité des gros modèles en ligne, et pour une raison mécanique. Quand un modèle lit, il garde une trace de tout ce qu'il a déjà parcouru, une forme d'antisèche, pour ne pas tout recalculer à chaque nouveau mot qu'il produit. Cette antisèche gonfle avec la longueur du texte. Sur un très long contexte, elle finit par peser aussi lourd que le modèle lui-même.

DeepSeek V4 Flash répond, là encore, par la compression. Le modèle ne conserve pas tout le passé avec la même netteté. Les mots récents restent en haute résolution, dans une petite fenêtre nette. Le passé lointain est résumé, compressé en blocs plus grossiers. C'est, au fond, la manière dont notre propre mémoire travaille : dernières minutes sont précises, l'an dernier n'est qu'une silhouette. L'antisèche d'un contexte d'un million de tokens tient alors dans environ 26 gigaoctets. Assez peu pour qu'on puisse la ranger sur le disque de la machine et la recharger d'une session à l'autre, au lieu de la reconstruire à chaque fois.

L'attention ordinaire garde tout le passé en pleine résolution, et finit par s'effondrer quand le contexte s'allonge. La compression de DS4 est ce qui fait passer ce million de tokens du statut de ligne sur une fiche technique à celui de capacité pontentiellement utilisable, chez soi.

« Chez soi », soit. Mais sur quelle machine ? Le modèle compressé pèse 80 gigaoctets, l'antisèche d'un contexte rempli en réclame 26 de plus. Il faut un ordinateur capable de garder tout ça en mémoire d'un seul tenant. Et cette fois, le logiciel a fait sa part : tout se joue sur le matériel.

Sur un PC classique, même un PC de joueur, la carte graphique a sa propre mémoire, séparée de celle du reste de l'ordinateur. Même très haut de gamme, elle plafonne autour de 24 gigaoctets. Un modèle de 80 Go, elle ne peut pas l'accueillir. Point final.

Un mot d'histoire. En 2020, Apple a cessé d'équiper ses Mac de processeurs Intel pour concevoir les siens, les puces M, regroupées sous le nom d'Apple Silicon. Elles ne sortaient pas de nulle part : depuis une dizaine d'années déjà, Apple dessinait les processeurs de ses iPhone et de ses iPad. Les Mac ont hérité de cette architecture née dans le monde du mobile, où tout est réuni sur une seule puce, pour tenir dans un téléphone et consommer le moins d'énergie possible. Le but visé, alors, c'était l'autonomie et la finesse des portables. Faire tourner un modèle de 80 gigaoctets chez soi n'était la préoccupation de personne. Le hasard fait parfois bien les choses : ce choix, fait pour de tout autres raisons, se révèle aujourd'hui un atout que personne n'avait anticipé.

Ces puces M sont bâties autrement qu'un PC. Le processeur et la partie graphique partagent la même mémoire, physiquement, la même puce. On appelle ça la mémoire unifiée. Un Mac Studio peut embarquer 128, 256, jusqu'à 512 gigaoctets, tous accessibles d'un bloc. Pour faire tourner un gros modèle chez soi, la question n'est pas la puissance de calcul brute. C'est la capacité mémoire. Et là-dessus, aujourd'hui, Apple est à peu près seul sur le créneau.

DS4 ne fait tourner qu'un seul modèle. DeepSeek V4 Flash, et rien d'autre.

antirez aurait pu écrire un moteur générique, capable d'avaler n'importe quel modèle. C'est ce que font la plupart des outils du domaine. Le local n'est d'ailleurs pas né avec lui : la route a été ouverte en 2023 par Georgi Gerganov, avec un projet appelé llama.cpp, c'est lui qui a rendu possible de faire tourner ces modèles sur des machines normales, puis sur Mac, et qui a imposé le format de fichier devenu standard, le GGUF. antirez le dit noir sur blanc dans son repo : DS4 n'existerait pas sans ce chemin-là.

La différence, c'est le virage. Gerganov a construit le moteur générique, celui qui fait tourner à peu près n'importe quoi. antirez prend l'option inverse. Un moteur, un seul modèle, optimisé jusqu'à l'os pour lui. Tout, du chargement des poids jusqu'à la façon de gérer les appels d'outils, est taillé sur mesure.

C'est la vieille philosophie d'Unix, faire une chose et la faire bien. La généralité a un coût caché : à vouloir tout faire à peu près, on fait tout à moitié. antirez parie l'inverse.

Le projet est très récent. antirez le répète lui-même : c'est du code beta, ça va bouger pendant des mois. Le modèle, de son côté, est appelé à être remplacé par de meilleures versions de DeepSeek V4 Flash.

La version qui tient sur 128 gigaoctets est la version partiellement compressée à 2 bits. Elle est bonne, mais elle paye sa compression par une légère perte de qualité.

C'est une piste. Une piste sérieuse, intéressante, ouverte par quelqu'un qui sait ce qu'il fait, et qui a suscité pas mal d'engouements.

antirez referme son propre billet sur cette phrase :

A suivre.

PS : antirez commence aussi à faire des tests avec DeepSeek V4 Pro mais sur Mac Studio avec 512 Go de mémoire unifiée.