LLM auto hébergées · 13 October 2026

FreeToken : faire tourner un MoE de 284B sur un PC de gamer — autopsie d’une promesse (enfin) documentée

Vous rêvez de faire tourner un modèle à 284 milliards de paramètres sur votre PC de gamer, sans vendre un rein pour une RTX 4090 ? Un projet nommé FreeToken prétend exactement cela : faire résider le modèle en RAM système et n’utiliser la VRAM que comme un cache dynamique. Longtemps, la promesse relevait du slogan marketing. Mais depuis la publication d’un article arXiv signé UC Berkeley et UT Austin, et la mise en ligne d’un dépôt GitHub passé de 0 à plus de 2 200 étoiles en une semaine, le dossier s’est considérablement épaissi. Nous avons épluché les sources, les benchmarks disponibles et les limites physiques pour démêler le vrai du faux.

Le GPU à 3000 € est-il mort ? L’irruption de FreeToken dans le paysage de l’IA locale

En 2026, le fossé entre les modèles de langage de pointe et le matériel grand public n’a jamais été aussi large. Un modèle dense de 70 milliards de paramètres en précision 16 bits exige environ 140 Go de VRAM — soit l’équivalent de plusieurs RTX 4090 empilées, pour un coût total dépassant les 2 900 $ selon les configurations courantes. Les modèles MoE (Mixture of Experts) de nouvelle génération atteignent des tailles vertigineuses : le DeepSeek V4-Flash, publié le 31 juillet 2026, compte 284 milliards de paramètres au total, même si seuls 13 milliards sont actifs par jeton. Le GLM-5.2 de Z.ai monte encore d’un cran, avec 753 milliards de paramètres. Face à cela, le particulier dispose en moyenne de 16 à 32 Go de RAM système et de 6 à 12 Go de VRAM sur une carte graphique d’entrée de gamme. L’écart semble infranchissable.

C’est dans cette brèche que s’engouffre FreeToken, un moteur d’inférence open source développé par le collectif FlashML-org. Son postulat de départ est aussi simple qu’audacieux : et si le modèle complet résidait en RAM système, la VRAM ne servant plus que de cache haute vitesse pour les experts les plus sollicités ? Fini le partitionnement statique des couches entre CPU et GPU, fini la nécessité d’une VRAM monumentale. Le projet promet de faire tourner des modèles MoE de frontière sur un simple PC de bureau, avec une carte graphique modeste.

La question centrale que tout utilisateur se pose est légitime : s’agit-il d’une révolution technique crédible ou d’un énième mirage marketing ? Pour y répondre, il faut plonger dans les mécanismes précis, confronter les chiffres annoncés aux données vérifiables, et examiner les contraintes physiques qui pourraient bien réduire cette promesse à une simple optimisation marginale.

Genèse d’un projet : de UC Berkeley à l’article arXiv 2608.16157

FreeToken n’est pas un produit commercial sorti de nulle part. Le projet est hébergé sur GitHub sous l’organisation FlashML-org, avec une documentation officielle disponible sur freetoken.wiki et un site produit sur flashml.ai. Une citation arXiv — 2608.16157 — est associée au projet, et cette fois les sources indépendantes confirment l’essentiel : selon BetterStack, l’article a été publié le 17 août 2026 par une équipe de l’UC Berkeley et de l’UT Austin, et le dépôt a été libéré en open source sous licence Apache 2.0. Les auteurs incluent des noms de premier plan de la recherche système et IA : Song Han, Matei Zaharia et Ion Stoica. Le papier cite également les adresses de correspondance de Shuo Yang (Berkeley) et Chenfeng Xu (UT Austin).

Le problème initial que FreeToken cherche à résoudre est bien réel. En 2024, l’état de l’art pour l’inférence locale reposait sur llama.cpp, qui permettait d’offloader certaines couches du modèle vers le GPU via l’option --n-gpu-layers. Mais cette approche statique présentait une limite structurelle : une fois la VRAM saturée, le reste des couches restait définitivement sur CPU, créant un goulot d’étranglement permanent. Pour un modèle comme Mixtral 8x7B, dont les poids en 4 bits occupent environ 26 Go, une carte avec 8 Go de VRAM ne pouvait accueillir qu’une fraction des couches, le reste étant condamné à une exécution CPU lente. Les utilisateurs avec 32 Go de RAM et 6-8 Go de VRAM se retrouvaient dans une impasse : impossible de charger le modèle complet en VRAM, et une exécution CPU seule rédhibitoire.

FreeToken part d’un constat différent : dans un modèle MoE, chaque token n’active qu’une fraction des experts. Pour DeepSeek V4-Flash, seuls 13 milliards de paramètres sur 284 sont sollicités à chaque étape. Dès lors, pourquoi charger l’intégralité du modèle en VRAM ? Il suffit de garder en mémoire GPU les experts les plus récemment utilisés, et de rapatrier les autres depuis la RAM système à la demande. C’est exactement ce que propose le moteur : une co-exécution dynamique où la VRAM devient un cache, et la RAM le stockage principal.

Sous le capot : le cache LRU, la politique q*, le double buffering et la fin du partitionnement statique

Le mécanisme central de FreeToken est un cache global d’experts géré par une politique LRU (Least Recently Used). Concrètement, lorsque le modèle doit activer un expert pour un token donné, le moteur vérifie si cet expert est déjà présent en VRAM. Si oui, il est utilisé directement. Sinon, il est transféré depuis la RAM système via le bus PCIe, tandis que l’expert le moins récemment utilisé est éjecté pour libérer de la place. Cette approche contraste radicalement avec le partitionnement statique CPU/GPU utilisé par Ollama, qui répartit les couches selon un ratio fixe (par exemple 30% CPU / 70% GPU) sans tenir compte de la dynamique des activations.

Le dépôt GitHub et l’article arXiv précisent plusieurs briques que la première version de cet article ne faisait qu’effleurer. La co-exécution CPU–GPU n’est pas seulement « dynamique » : elle repose sur une politique adaptative à la bande passante ($q^\star$ policy), qui décide en continu quelle part du calcul confier au CPU et au GPU en fonction des ressources réellement disponibles sur la machine. Le prefill est intégralement streamé en double buffering sur toutes les couches : pendant que le GPU calcule sur la couche courante, les poids de la couche suivante sont transférés depuis la RAM, ce qui masque en grande partie la latence PCIe. Le projet mentionne également un format de poids rapide nommé FTW, optimisé pour des transferts mémoire efficaces, ainsi que le support de formats quantifiés comme MXFP4, NVFP4, FP8 et BF16.

Deux fonctionnalités méritent d’être soulignées car elles n’apparaissaient pas dans les premières descriptions du projet. D’abord, la gestion élastique de la mémoire : FreeToken peut réallouer dynamiquement la VRAM entre le cache d’experts et la mémoire KV, sans redémarrer le moteur ni recharger les poids. Ensuite, le cache sémantique : des « ancres sémantiques » (semantic anchor checkpoints) permettent de conserver l’état récurrent et le KV cache lors des éditions de contexte propres aux agents (appels d’outils, blocs de raisonnement), évitant de recalculer inutilement de longs contextes. C’est une réponse directe à un constat du papier : les charges de travail agentiques changent continuellement leur schéma d’exécution.

Le rejet explicite du partitionnement statique est un choix assumé. Là où Ollama et llama.cpp figent la répartition des couches à l’initialisation, FreeToken adapte en continu la résidence des experts en fonction de l’historique d’utilisation. C’est une différence fondamentale de philosophie : au lieu de considérer le GPU comme un accélérateur partiel, on le traite comme un cache intelligent, la RAM devenant le véritable espace de stockage du modèle.

Chiffres annoncés vs réalité vérifiable : ce que les sources confirment (et ce qu’elles taisent)

Le blog Stork.AI, qui a largement contribué à la popularité du projet, avançait des chiffres spectaculaires. Selon cette source, DeepSeek V4-Flash compterait 284 milliards de paramètres totaux pour 13 milliards actifs par jeton. Le même article affirmait qu’Ollama, avec un partitionnement statique 30% CPU / 70% GPU, atteindrait 58 jetons par seconde sur un modèle Qwen 3.6 35B (38 Go) avec une carte graphique de 32 Go de VRAM. Le titre promettait même une performance « 3x plus rapide » avec FreeToken.

Depuis, des sources plus solides sont venues confirmer — ou nuancer — ces affirmations. BetterStack titre désormais sur un facteur « 2-4x la vitesse d’Ollama », ce qui recoupe l’ordre de grandeur de Stork.AI sans le reprendre mot pour mot. Le dépôt GitHub et l’article arXiv, eux, avancent des cas d’usage concrets et vérifiables dans leur principe : un modèle de 35B sur un GPU de laptop de 8 Go, un modèle de 284B sur un PC de gamer, et le GLM-5.2 de 753B sur un seul GPU de station de travail. Le papier revendique le support de plus de 20 modèles MoE et de véritables agents de code et d’outillage, sur du matériel allant d’un GPU de laptop 8 Go à un GPU de station de travail unique.

Ces chiffres restent toutefois à prendre avec méthode. D’une part, ils proviennent en grande partie des auteurs eux-mêmes ou de sources qui les relaient ; aucune campagne de benchmarks indépendante et contradictoire n’est encore disponible. D’autre part, les mesures précises — tokens par seconde, time-to-first-token (TTFT), évolution en fonction de la taille du contexte — ne sont pas publiées dans les extraits accessibles. Les modèles mentionnés (DeepSeek V4-Flash, Qwen3.6-35B-A3B, GLM-5.2) sont désormais nommés et datés, ce qui est un progrès par rapport aux versions flottantes qui circulaient, mais ils n’ont pas été validés par des benchmarks publics tiers. Et la configuration modeste qui intéresse le grand public — un Ryzen 5, 32 Go de DDR4 et une RTX 3060 12 Go — n’est toujours pas documentée par une mesure publiée.

Les lacunes persistent donc en partie. Aucun test public sur Mixtral 8x7B ou DeepSeek-V2-Lite, pourtant des références de l’inférence locale. Aucune donnée chiffrée sur le TTFT, qui pourrait être pénalisant si le prefill doit transférer massivement des poids. Aucune courbe de performance quand le contexte passe de 4k à 16k tokens. La différence avec la situation d’il y a quelques semaines, c’est que le projet n’est plus un simple dépôt anonyme : il est adossé à un article académique, à des auteurs identifiables et à une licence claire. Cela ne transforme pas les promesses en faits mesurés, mais cela change la nature du doute : on ne suspecte plus un vaporware, on attend des benchmarks indépendants.

Face à l’état de l’art : llama.cpp 0.5.0, GGUF Q4_K_M et speculative decoding

Pour évaluer FreeToken, il faut le confronter aux approches existantes. llama.cpp, avec son option --n-gpu-layers, permet un offloading statique par couches. La quantification GGUF Q4_K_M réduit la précision des poids à 4 bits, divisant par quatre les besoins en mémoire. Ces deux techniques sont matures, éprouvées, et bénéficient d’une large communauté. Le speculative decoding, quant à lui, ne réduit pas les besoins en mémoire mais accélère la génération en prédisant plusieurs tokens à la fois.

Il faut d’ailleurs noter que llama.cpp n’est pas resté immobile : la version 0.5.0, documentée fin septembre 2026, a refondu le backend, le scheduler et le serveur intégré, et reste le socle invisible de l’IA locale. FreeToken ne détrône donc pas un moteur figé, mais un écosystème en mouvement.

Voici un tableau comparatif des approches :

La question cruciale est de savoir si FreeToken est réellement plus rapide ou s’il ne fait que déplacer le goulot d’étranglement. Dans un scénario où le modèle tient entièrement en VRAM, FreeToken n’apporte aucun avantage : le cache LRU ajoute même une surcharge de gestion inutile. En revanche, pour un modèle trop volumineux pour la VRAM, l’approche dynamique pourrait surpasser l’offloading statique, car elle évite de bloquer des couches entières sur CPU. Mais ce gain potentiel dépend entièrement de la capacité à transférer les poids rapidement — et c’est là que les limites physiques entrent en jeu.

Le vrai goulot d’étranglement : la bande passante PCIe et la latence mémoire

La bande passante du bus PCIe est le facteur limitant principal. Une liaison PCIe 4.0 x16 offre environ 32 Go/s de bande passante théorique, tandis que la RAM système en DDR4-3200 plafonne autour de 25,6 Go/s en double canal, et la DDR5-6000 atteint environ 76,8 Go/s. Comparé à la VRAM d’une RTX 3060, qui offre une bande passante de 360 Go/s, l’écart est d’un ordre de grandeur. Chaque transfert d’un expert depuis la RAM vers le GPU prend donc du temps, et si le cache LRU est mal dimensionné, des allers-retours fréquents peuvent rapidement saturer le bus.

Le problème de scalabilité est évident : que se passe-t-il quand plusieurs experts sont éjectés du cache puis redemandés quelques tokens plus tard ? La politique LRU est simple, mais elle ne prédit pas les besoins futurs. Un modèle MoE peut avoir des schémas d’activation cycliques ou dépendants du contexte, rendant le cache inefficace. Le papier arXiv répond en partie à cette objection en invoquant la localité de référence des MoE : pour une séquence de tokens liés, le réseau de gating tend à réutiliser le même ensemble d’experts, ce qui rend le cache LRU efficace en pratique. Reste que le protocole de synchronisation des poids entre RAM et VRAM — verrous, versioning, invalidation des poids obsolètes — n’est pas détaillé dans les sources accessibles.

Pour les configurations 16-32 Go de RAM, la question se pose aussi : un modèle MoE de 284 milliards de paramètres, même quantifié en 4 bits, pèserait environ 142 Go — bien au-delà de la RAM disponible. FreeToken ne peut donc pas faire des miracles : il ne permet d’exécuter que les modèles dont la taille tient dans la RAM système. Pour les modèles plus petits, comme Mixtral 8x7B (26 Go en Q4), la RAM est suffisante, mais la bande passante PCIe devient le facteur dominant. Les tests comparatifs DDR4 vs DDR5, ou PCIe 3.0 vs 4.0, qui permettraient de quantifier précisément cet impact, n’existent toujours pas dans les sources publiques.

Changer de paradigme : la RAM comme nouveau terrain de jeu, la VRAM comme cache

Malgré ces limites, FreeToken incarne un changement de paradigme profond. Pendant des années, la course à l’IA locale s’est concentrée sur l’achat de GPU toujours plus chers, avec des VRAM toujours plus grandes. Le marché des mini-PC IA à mémoire unifiée — AMD Strix Halo et ses 256 Go/s de bande passante sur un bus 256 bits, l’AMD Ryzen AI Halo à 128 Go pour 3 999 $, l’AMD Gorgon Halo visant 192 Go, ou encore les mini-PC Acer à mémoire unifiée de 128 Go capables d’annoncer des modèles jusqu’à 200B — témoigne de cette bascule : ce n’est plus la VRAM qui compte, mais la mémoire totale et sa bande passante.

FreeToken pousse cette logique à son terme en dissociant explicitement le stockage du modèle (RAM) de son accélérateur (VRAM). C’est une réponse directe au constat dressé par les guides matériels de 2026 : la question n’est plus « quel modèle est le meilleur ? » mais « qu’est-ce qui tient dans ma mémoire ? ». En rendant la VRAM élastique et en la traitant comme un cache plutôt que comme un espace de résidence obligatoire, le moteur ouvre la porte à des configurations qui étaient jusqu’ici exclues : un laptop 8 Go, une RTX 3060 12 Go, une station de travail mono-GPU.

Reste que la promesse doit être maniée avec prudence. FreeToken est un projet récent, adossé à un papier solide et à une communauté naissante, mais dont les performances réelles sur les configurations modestes ne sont pas encore documentées de façon indépendante. Pour l’utilisateur qui veut faire tourner un LLM open-weight sans se ruiner en 2026, la recommandation raisonnable est double : suivre FreeToken de près, car il attaque un vrai problème avec une vraie équipe, mais ne pas encore bâtir son budget matériel sur ses seuls chiffres annoncés. Les moteurs éprouvés — llama.cpp 0.5.0, Ollama, les formats GGUF — restent la valeur sûre, le temps que des benchmarks tiers viennent confirmer, ou démentir, le « 2-4x » promis.

Sources

• GitHub — FlashML-org/FreeToken : dépôt officiel, fonctionnalités (runtime edge-native, politique $q^\star$, double buffering full-layer, cache LRU global, format FTW, cache sémantique, gestion mémoire élastique, support RTX 30/40/50), installation via uv ou pip.
• arXiv 2608.16157 — FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution : article académique, auteurs (Shuo Yang, Chenfeng Xu et al.), cas d’usage 35B sur laptop 8 Go, 284B sur PC de gamer, 753B GLM-5.2 sur GPU de station de travail, support de plus de 20 modèles MoE.
• BetterStack — FreeToken: Running Massive MoE Models Locally at 2-4x Ollama’s Speed : publication le 17 août 2026 par UC Berkeley et UT Austin, licence Apache 2.0, auteurs Song Han, Matei Zaharia, Ion Stoica, plus de 2 200 étoiles GitHub la première semaine, facteur 2-4x vs Ollama.
• FlashML — site officiel : téléchargement Windows/Linux, GUI, Slack développeurs, Discord communauté.
• FreeToken Wiki : guide de configuration, considérations matérielles, cache, étapes pratiques pour l’inférence MoE locale.
• Le Fil IA — FreeToken : un moteur MoE natif edge : couverture francophone, GLM-5.2 753B sur un seul GPU de station de travail.
• Stork.AI — FreeToken : Exécutez d’énormes modèles d’IA MoE 3x plus vite qu’avec Ollama (29 août 2026) : source promotionnelle initiale, chiffres DeepSeek V4-Flash (284B/13B actifs), Qwen 3.6 35B, revendication « 3x ».
• llama.cpp v0.5.0 in 2026 (gyanaangan.in) (27 septembre 2026) : refonte backend, scheduler, serveur intégré, GGUF, vérification GPU.
• Modèles GGUF : types de quantification et exécution (convly.ai) (9 septembre 2026) : format GGUF, quantification, tailles de fichiers, exécution Windows/macOS/Linux.
• Comparatif LLM & API IA gratuites en français — Iatrust (28 septembre 2026) : classement indépendant, coût réel, actualités IA.
• Modèles d’IA chinois en 2026 : DeepSeek, Qwen, Kimi, GLM — Iatrust (5 septembre 2026) : cas d’usage par modèle chinois.
• Open-weights ou open-source ? La différence qui compte — QuelLLM.fr (27 août 2026) : grille de lecture sur les licences.
• Strata : l’engine qui fait tourner un modèle 125B sur un seul GPU (ai-stat.ru) (5 octobre 2026) : contexte des « moteurs d’inférence réentraînés », débat r/LocalLLaMA.

Article recherché et rédigé automatiquement · Magazine Electrosens