En juillet 2026, un projet open source nommé TurboFieldfare a suscité un vif intérêt sur Hacker News, accumulant plus de 608 points et plus de 200 commentaires. La raison en est frappante : il a permis de faire fonctionner un grand modèle de langage de 26 milliards de paramètres sur un ordinateur Mac doté de seulement 8 Go de RAM, tout en ne consommant qu’environ 2 Go de mémoire vive.
26 milliards de paramètres. 2 Go de RAM. Mettre ces deux chiffres côte à côte paraît tout à fait contradictoire.
Grand modèle ne rime pas nécessairement avec GPU surpuissant. C’est le message central que cet article souhaite transmettre.
Une tâche en apparence impossible
Rappelons le contexte. Gemma 4 est une famille de modèles open source publiée par Google DeepMind au début de l’année 2026. L’une des déclinaisons, baptisée « Gemma 4 26B-A4B », repose sur une architecture de mélange d’experts (MoE, Mixture-of-Experts). Même après une compression par 4, ce modèle nécessite encore 14 Go d’espace disque.
Or, la plupart des ordinateurs portables Mac grand public disposent de 8 Go de RAM — dont 3 à 4 Go sont déjà accaparés par le système d’exploitation, ce qui laisse très peu de place pour les modèles de langage.
Les outils d’inférence traditionnels (comme llama.cpp ou MLX) chargent l’intégralité du modèle en mémoire avant l’exécution. Un modèle de 14 Go ne peut tout simplement pas être chargé sur une machine de 8 Go — le système d’exploitation n’autorisant aucune application à occuper la totalité de la mémoire. Cette voie était une impasse dès le départ.
La question est donc devenue : Existe-t-il un moyen d’exécuter le modèle sans le charger entièrement en mémoire RAM ?
Andrey Mikhaylov, créateur de TurboFieldfare et ingénieur iOS/Metal, a apporté une réponse affirmative. Après plusieurs semaines de travail et 103 expériences, il a écrit un moteur d’inférence intégralement à partir de zéro, en utilisant le langage Swift et le framework graphique Metal d’Apple. Le résultat : 5 à 6 tokens par seconde sur un MacBook Air M2, et jusqu’à 31 à 35 tokens par seconde sur le dernier M5 Pro.
Non seulement le système fonctionne, mais la vitesse est parfaitement exploitable. Il ne s’agit pas d’une étude théorique, mais d’une réalisation d’ingénierie directement téléchargeable et utilisable.
L’atout caché des modèles MoE : Taillés pour le streaming
Pour comprendre cette avancée, il convient d’analyser le fonctionnement des architectures à mélange d’experts (MoE).
Un modèle traditionnel se comporte comme un « généraliste » : pour chaque mot généré, la totalité des paramètres du modèle participe aux calculs. C’est l’équivalent d’une grande entreprise où chaque employé devrait valider chaque projet, ce qui s’avère extrêmement inefficace.
Les modèles MoE fonctionnent différemment. On peut les comparer à une entreprise comptant 128 départements spécialisés. Lorsqu’une tâche arrive, un répartiteur appelé « routeur » analyse le besoin et n’active que les 8 départements les plus pertinents. Les 120 autres départements restent en veille.
Sur les 26 milliards de paramètres du modèle, seuls 3,8 milliards environ sont réellement sollicités lors de chaque étape de calcul. C’est le sens de la notation « A4B » dans « 26B-A4B » : Active 4 Billion (environ 4 milliards de paramètres actifs par étape).
Cette caractéristique architecturale a dicté la stratégie de TurboFieldfare : Puisqu’on n’utilise jamais plus d’un dixième des experts à la fois, pourquoi laisser les 90 % de poids restants encombrer la mémoire RAM ?
Trois optimisations clés pour faire tenir 14 Go dans 2 Go de RAM
Les frameworks d’inférence classiques gardent les poids des 128 experts chargés en RAM en permanence. C’est comme si une entreprise réservait des bureaux pour les 120 employés inactifs, occupant un étage entier sans nécessité.
L’approche de TurboFieldfare est directe : Seuls ceux qui travaillent prennent place à leur bureau.
1. Compression par 4 : Allègement des données
Les poids des modèles contiennent une forte redondance numérique. De même qu’une photo 4K compressée en 1080p paraît identique pour la plupart des utilisateurs, les poids peuvent être quantifiés de façon agressive.
TurboFieldfare utilise une quantification 4 bits — réduisant la précision des paramètres de 16 bits à 4 bits, divisant la taille par quatre. C’est ainsi qu’a été obtenue la taille de 14 Go pour les poids compressés. Le routeur conserve une précision de 8 bits afin de maintenir la précision d’aiguillage, tandis que le corps des experts est entièrement en 4 bits, garantissant une qualité de réponse satisfaisante.
2. Streaming SSD : La RAM ne conserve que la partie partagée
C’est la pièce maîtresse du projet sur le plan de l’ingénierie.
TurboFieldfare ne conserve en RAM que les 1,35 Go de composants partagés (couches de calcul communes et cache KV), tandis que les poids des 128 experts restent stockés sur le SSD. Lors de chaque génération de token, il lit depuis le SSD uniquement les 8 experts nécessaires à cet instant.
Cependant, un obstacle physique se dresse : le temps d’accès d’un SSD se compte en millisecondes, alors que celui de la RAM est en nanosecondes — une différence d’un facteur de plusieurs dizaines de milliers. Si chaque lecture devait bloquer et attendre de manière synchrone le SSD, la vitesse de génération deviendrait inutilisable.
3. Cache intelligent + Chevauchement temporel
L’auteur a conçu trois niveaux d’optimisation pour combler cet écart de vitesse :
Cache d’experts. Bien que 8 experts soient requis à chaque étape, la génération de tokens consécutifs fait souvent appel aux mêmes experts. TurboFieldfare réserve 16 emplacements de cache par couche et s’appuie sur l’algorithme LFU (Least Frequently Used) pour gérer la rétention. Les accès réussis au cache évitent d’effectuer une nouvelle lecture sur le SSD. Les mesures montrent que ce cache a permis de faire passer le temps de lecture des experts de 166 ms à 88 ms par token.
Lecture anticipée parallèle (pread). S’en remettre au découpage en pages à la demande (mmap) pour laisser le système gérer les accès semble élégant, mais s’est révélé désastreux à l’essai — la vitesse s’effondrant à 0.5 tok/s lors des démarrages à froid. L’auteur a opté pour des appels système pread concurrents pour déclencher activement les lectures, portant la vitesse à 3,97 tok/s. Ce choix découle de mesures réelles et non de postulats théoriques.
Chevauchement temporel (Pipelining). Pendant que le SSD lit les données des experts, le GPU ne reste pas inactif : il calcule les couches partagées du modèle. Lorsque le calcul des couches partagées s’achève, les données provenant du SSD viennent tout juste d’arriver. Ce séquençage minutieux masque presque entièrement le temps d’attente. Un chevauchement à grain grossier (lecture groupée avant calcul) s’est avéré plus stable et plus efficient qu’un traitement individuel.
103 expériences, une majorité d’échecs
L’ingénierie de terrain diffère de la rédaction d’articles scientifiques. Les publications présentent le chemin victorieux ; l’ingénierie impose d’explorer toutes les voies sans issue.
La documentation de TurboFieldfare consigne en détail les résultats de 103 expériences, et l’auteur partage en toute transparence les tentatives séduisantes sur le papier mais inefficaces en pratique :
Le mappage mémoire (mmap) semblait élégant. Laisser l’OS gérer le chargement réduisait le code au minimum. Résultat réel : 0,5 tok/s au démarrage à froid, équivalant à un blocage.
Noyaux coopératifs SIMD. Faire collaborer plusieurs threads sur un même expert visait une meilleure clarté de code. Résultat : le temps de calcul GPU a doublé, passant de 230 ms à 527 ms. L’idée a été abandonnée.
Préchargement d’experts inter-couches. Si la couche N choisit les experts A et B, peut-on anticiper ceux de la couche N+1 ? L’analyse a montré que le choix des experts entre deux couches adjacentes n’avait pratiquement aucune corrélation, avec une précision de prédiction d’à peine 7 %.
Asynchronisme à grain fin. Déclencher les calculs dès la lecture d’un expert individuel introduisait un surcoût de synchronisation qui ralentissait le traitement global et modifiait les résultats. La solution à grain grossier s’est finalement imposée.
La valeur de ces échecs équivaut à celle des succès. Ils illustrent une vérité fondamentale : Seule compte l’optimisation qui a été validée par la mesure sur le terrain.
Pourquoi est-ce important ?
La portée de TurboFieldfare réside dans la démonstration d’une réalité :
L’inférence de grands modèles de langage n’exige pas obligatoirement des GPU hors de prix.
Grâce à une optimisation logicielle poussée — streaming SSD, cache intelligent et noyaux adaptés au matériel —, un ordinateur portable ordinaire peut devenir un nœud d’inférence IA performant.
Aujourd’hui, les GPU haut de gamme sont monopolisés par un petit nombre d’acteurs, affichant des tarifs très élevés et des pénuries durables. Des projets comme TurboFieldfare ouvrent une autre voie : au lieu de dépendre d’un matériel toujours plus coûteux, repousser les limites physiques grâce à un meilleur logiciel.
Cela rappelle l’industrie du jeu vidéo des années 1990. À l’époque, les jeux en 3D nécessitaient des stations de travail graphiques professionnelles, jusqu’à ce que les cartes 3D grand public permettent aux PC standard de les exécuter. TurboFieldfare marque les débuts d’une évolution similaire, prouvant à l’ensemble du secteur que l’inférence IA n’a pas à rester verrouillée par le matériel.
Le projet compte désormais plus de 900 étoiles sur GitHub et la communauté commence à fournir de nombreuses données de test. L’auteur envisage également des versions pour iPhone et iPad afin d’exécuter des LLM en local sur les appareils mobiles.
Peut-être que dans un avenir proche, votre smartphone, ou même vos écouteurs, abriteront un assistant IA de plusieurs dizaines de milliards de paramètres fonctionnant avec seulement quelques dizaines de mégaoctets de RAM. TurboFieldfare constitue une pierre sur ce chemin, mais indique une direction particulièrement claire.
Liens de référence :
- GitHub : Dépôt TurboFieldfare
- Discussion HN (item?id=49098510)
- Rapport technique Gemma 4
- Guide visuel de Gemma 4 par Maarten Grootendorst
- Document d’architecture système TurboFieldfare
- Journal des expériences d’optimisation TurboFieldfare (103 expériences)
