LLM auto hébergées · 16 September 2026

FreeToken : la fin du GPU à 3000 € pour faire tourner les MoE de pointe ?

Vous rêvez de faire tourner un modèle à 300 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. Entre promesse marketing et vraie rupture technique, 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 quatre 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, comme le DeepSeek V4-Flash récemment évoqué, atteignent des tailles vertigineuses : 284 milliards de paramètres au total, même si seuls 13 milliards sont actifs par jeton. 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 : du dépôt GitHub FlashML à 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. Une citation arXiv — 2608.16157 — est associée au projet, suggérant une soumission académique en août 2026. Les sources tierces, comme le blog Stork.AI ou l’article d’InfoQ publié en août 2026, corroborent l’existence du projet et décrivent ses mécanismes. Cependant, aucune source indépendante ne confirme l’identité de l’auteur principal ni la date exacte de la première version stable.

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, 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 double buffering constitue le second pilier technique. Pendant la phase de prefill (le traitement initial du prompt), le GPU calcule sur la couche courante pendant que les poids de la couche suivante sont transférés depuis la RAM. Ce chevauchement masque en grande partie la latence des transferts PCIe, qui deviennent transparents pour l’utilisateur. 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.

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 : le grand écart des benchmarks

Le blog Stork.AI, qui a largement contribué à la popularité du projet, avance 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 affirme 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 de l’article promet même une performance « 3x plus rapide » avec FreeToken.

Mais ces chiffres doivent être pris avec des pincettes. D’une part, Stork.AI est une source promotionnelle, potentiellement affiliée au projet, et aucune autre source indépendante ne confirme ces mesures. D’autre part, aucune donnée concrète n’est fournie pour FreeToken lui-même : ni tokens par seconde, ni time-to-first-token (TTFT), ni évolution en fonction de la taille du contexte. Les modèles mentionnés (DeepSeek V4-Flash, Qwen 3.6, GLM-5.2) n’ont pas été vérifiés par des benchmarks publics. Pire, aucune mesure n’existe sur la configuration modeste qui intéresse le grand public : un Ryzen 5, 32 Go de DDR4 et une RTX 3060 12 Go.

Les lacunes sont criantes. Aucun test sur Mixtral 8x7B ou DeepSeek-V2-Lite, pourtant des références de l’inférence locale. Aucune donnée sur le TTFT, qui pourrait être catastrophique si le prefill doit transférer massivement des poids. Aucune information sur l’évolution des performances quand le contexte passe de 4k à 16k tokens. En l’état, les promesses de FreeToken reposent sur des affirmations non vérifiées, et il serait imprudent de les prendre pour argent comptant.

Face à l’état de l’art : llama.cpp, 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.

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. Aucune information n’est fournie sur un éventuel préfetch prédictif, ni sur le protocole de synchronisation des poids entre RAM et VRAM — verrous, versioning, invalidation des poids obsolètes restent des zones d’ombre.

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 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, comme l’AMD Strix Halo avec ses 256 Go/s de bande passante mémoire unifiée, ou l’Apple M4 Ultra avec 546 Go/s et 128 Go de mémoire unifiée, a montré une voie alternative. FreeToken s’inscrit dans cette mouvance : la mémoire unifiée devient le terrain de jeu, et la VRAM n’est plus qu’un accélérateur.

Pour l’utilisateur, les implications sont concrètes. Une configuration avec 64 Go de RAM système et une RTX 3060 12 Go pourrait faire tourner des modèles MoE de 30 à 50 milliards de paramètres, là où il aurait fallu auparavant une RTX 4090 24 Go. Le coût total d’une telle machine est inférieur à 1 500 $, contre plus de 2 900 $ pour une tour équipée d’une RTX 4090. C’est une démocratisation réelle de l’accès aux modèles de grande taille, même si les performances restent à vérifier.

Les projets open source comme Ollama et llama.cpp devront s’adapter. Si FreeToken prouve son efficacité, ces outils devront intégrer des mécanismes de cache dynamique pour rester pertinents. La question de la souveraineté numérique se pose également : l’IA locale devient accessible au grand public, réduisant la dépendance aux API cloud et aux fournisseurs de services. Mais cette promesse ne se concrétisera que si les benchmarks indépendants confirment les performances annoncées.

Vers 2027 : le format FTW, les MoE de nouvelle génération et la démocratisation de l’IA

L’avenir de FreeToken dépend de plusieurs facteurs. La maturation du format FTW est cruciale : il doit être adopté par la communauté et supporté par les outils existants. Le support élargi des modèles, avec une compatibilité spécifique à chaque architecture, est également nécessaire. L’optimisation pour PCIe 5.0, qui double la bande passante par rapport à la 4.0, pourrait réduire significativement le goulot d’étranglement des transferts.

Les tendances des futurs MoE jouent en faveur du projet. Les modèles deviennent plus épars, avec une fraction de paramètres actifs de plus en plus faible. DeepSeek V4-Flash, avec 13 milliards actifs sur 284, illustre cette évolution. Si cette tendance se poursuit, le cache d’experts deviendra de plus en plus efficace, car la probabilité de réutiliser un expert récemment chargé augmentera. Le speculative decoding, qui prédit plusieurs tokens à la fois, pourrait également être combiné avec FreeToken pour améliorer encore les performances.

Le verdict est nuancé. FreeToken ne rend pas les GPU obsolètes, mais il les rend optionnels pour une certaine classe de modèles MoE. Pour les modèles denses, ou pour les modèles dont la taille excède la RAM système, les GPU haut de gamme resteront indispensables. En revanche, pour les utilisateurs qui veulent expérimenter avec des MoE de grande taille sans investir dans du matériel coûteux, FreeToken pourrait bien être la solution. Dans un an, le GPU à 3000 € sera peut-être réservé aux datacenters et aux chercheurs, tandis que l’IA de pointe deviendra un simple logiciel à installer sur son PC — à condition que les benchmarks indépendants confirment les promesses. En attendant, la prudence reste de mise : les chiffres annoncés par Stork.AI ne sont pas vérifiés, et les lacunes sur le TTFT et la scalabilité sont trop importantes pour conclure à une révolution.

Sources

• Dépôt GitHub FlashML-org/FreeToken
• Blog Stork.AI : "This tool runs datacenter AI on your PC"
• Wiki officiel FreeToken
• InfoQ : "FreeToken Unlocks Frontier MoE Inference on Consumer Hardware via Dynamic Co-Execution"
• Guide Intelion Cloud sur les exigences VRAM DeepSeek
• QuelLLM : guide matériel pour LLM local
• Techsy : guide des besoins VRAM pour LLM

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