FreeToken est un nouveau système de service open source pour les modèles de type Mixture-of-Experts (MoE), publié par des chercheurs de UC Berkeley et UT Austin — dont Matei Zaharia et Ion Stoica, deux noms établis de la recherche en systèmes de service (Zaharia a co-créé Apache Spark ; Stoica a co-créé Ray/Anyscale, et tous deux sont affiliés au laboratoire à l'origine de vLLM et SGLang, sur lesquels FreeToken s'appuie). Le constat de départ de l'article mérite d'être énoncé clairement, car il est juste dans les limites de ce qu'il affirme : les modèles à poids ouverts rattrapent les modèles propriétaires en capacité, mais publier des poids ne détermine que qui peut obtenir un modèle, pas qui peut se permettre de le faire tourner à grande échelle. Les modèles ouverts de pointe supposent encore des clusters GPU de classe datacenter. L'affirmation réelle de FreeToken est qu'une machine personnelle, traitée comme un pool unifié de GPU, de CPU et de mémoire plutôt que « un petit GPU », peut servir bien plus que ce constat ne le suggère.
Le problème que le MoE crée, pas seulement celui qu'il résout
Les architectures Mixture-of-Experts sont habituellement décrites comme l'astuce qui rend les gros modèles bon marché à faire tourner : chaque couche contient des centaines d'experts, mais un token n'en active qu'une poignée. C'est vrai pour le calcul. Cela n'aide pas la mémoire — le pool complet d'experts d'un modèle à 284 ou 753 milliards de paramètres doit tout de même résider quelque part, et la majeure partie ne tiendra pas dans la VRAM d'un GPU grand public. L'article identifie pourquoi les outils de service en périphérie existants (llama.cpp, KTransformers, Ollama) restent en deçà de ce que le matériel pourrait théoriquement offrir : le préremplissage doit toucher presque chaque expert quel que soit le routage, donc il fait transiter la quasi-totalité du pool sur PCIe à chaque fois ; le routage du décodage change à chaque token, donc tout placement fixé au chargement rate l'essentiel du trafic ; et le matériel grand public varie énormément dans la façon dont son GPU, son PCIe et sa bande passante mémoire s'équilibrent réellement entre eux, si bien qu'aucune stratégie fixe ne fonctionne sur toutes les machines.
Le mécanisme : mesurer la machine, puis faire le calcul
L'idée centrale de FreeToken est une politique analytique, calculée en direct, plutôt qu'une règle fixe. Pendant le décodage, quand un expert n'est pas déjà en cache sur le GPU, le système a deux façons de le servir : le tirer par PCIe dans le cache, ou l'exécuter sur place sur le CPU là où il réside déjà. Les deux options puisent dans la même bande passante mémoire hôte, donc l'article dérive la répartition optimale directement à partir de deux chiffres de bande passante mesurés sur la machine réellement déployée — la bande passante de transfert PCIe et la bande passante d'exécution d'experts côté CPU — le ratio de répartition, appelé q*, découlant directement de l'équilibrage des temps de complétion des deux branches l'une contre l'autre. C'est une pièce d'ingénierie véritablement élégante : plutôt que d'ajuster une heuristique par appareil, le système profile le matériel une fois et laisse une formule décider, en direct, quelle part de chaque défaut de cache va où.
Deux mécanismes de soutien complètent cela. Un cache LRU partagé exploite le fait que des étapes de decode consécutives ont tendance à router vers des experts qui se recoupent, si bien que la mémoire GPU rare suit l'ensemble de travail réel actuel du modèle plutôt qu'un placement figé au chargement. Et pour le préremplissage, le système ancre les points de contrôle de l'état récurrent/d'attention aux mêmes limites sémantiques — blocs de réflexion, appels d'outils, sorties d'outils — que les harnais d'agents tels qu'OpenClaw, OpenCode et SWE-agent utilisent déjà comme leurs propres points de modification quand ils tronquent le contexte. C'est un détail bien choisi : plutôt que de deviner où une modification de contexte pourrait tomber, FreeToken place ses points de contrôle exactement là où les harnais d'agents réels sont déjà documentés comme coupant, si bien qu'un contexte modifié peut reprendre depuis l'ancre survivante la plus proche et ne recalculer que le suffixe véritablement nouveau.
Les chiffres phares, et ce à quoi ils sont comparés
En comptant directement les résultats rapportés par l'article lui-même : sur une RTX 5090, FreeToken soutient 77 à 83 tok/s sur Qwen3.6-35B-A3B et 22 à 25 tok/s sur DeepSeek-V4-Flash (284 milliards de paramètres, 13 milliards actifs), soit un débit de décodage rapporté 1,5 à 2,3 fois supérieur au meilleur de quatre systèmes de référence (llama.cpp, Ollama, KTransformers, MoE-Infinity) sur quatre charges de travail agentiques réelles. Deux résultats se distinguent au-delà du simple multiplicateur brut. D'abord, la stabilité en usage agentique : le taux de décodage de FreeToken resterait, selon l'article, à moins de 12 % de son taux à tour unique sur trois charges de travail à tours multiples, tandis que le système de référence le plus sensible au contexte de la comparaison, KTransformers sur DeepSeek-V4-Flash, avait déjà perdu 31 % de son taux à tour unique dès la deuxième charge de travail. C'est un rappel qu'un benchmark exécuté sur un seul prompt isolé peut nettement surestimer la performance d'un système une fois qu'un vrai contexte d'agent s'accumule. Ensuite, la latence de queue : l'article rapporte que le pire temps jusqu'au premier token de FreeToken reste sous 44 secondes sur chaque charge de travail testée, tandis que chaque système de référence dépasse 150 secondes quelque part (llama.cpp à 232 s, Ollama à 179 s, KTransformers à 946 s). Ces chiffres se situent au-delà des seuils de délai d'attente que les vrais clients d'agents appliquent réellement — l'article cite le chien de garde d'inactivité de 120 secondes d'OpenClaw et le délai par défaut d'environ dix minutes de Claude Code —, ce qui fait de la latence de queue une question de disponibilité pour un usage agentique réel, pas seulement une statistique de vitesse.
Sur cinq systèmes grand public, l'article rapporte une amélioration du débit de décodage de 1,3 à 2,1 fois, avec deux résultats qui méritent d'être nommés directement. Sur un portable RTX 4060 à 8 Go, FreeToken servirait, selon l'article, un modèle de 35 milliards de paramètres à 39,3 tok/s — plus vite que les 33 tok/s de vitesse médiane de décodage que l'article attribue à Codex en production. Cette comparaison cite un article de mesure distinct plutôt qu'une exécution sur la même configuration : c'est une référence inter-articles, pas une comparaison directe. Sur un seul GPU de station de travail RTX PRO 6000, FreeToken servirait, selon l'article, GLM-5.2 à 753 milliards de paramètres à 14,9 tok/s contre 7,3 pour llama.cpp (2,0x) avec un temps jusqu'au premier token comparable. KTransformers, selon l'article, n'a aucun chemin fonctionnel pour servir ce modèle sur la même machine, ses noyaux CPU ne prenant pas en charge le format de poids NVFP4 de GLM-5.2.
La méthodologie derrière ces chiffres est inhabituellement divulguée
Il vaut la peine de le créditer directement : trois des six systèmes de test de l'article sont des serveurs bi-socket loués dont les vrais CPU dépasseraient largement toute machine de périphérie réelle, donc les auteurs les plafonnent délibérément à 6 threads CPU et les épinglent au nœud NUMA du GPU pour émuler une bande passante hôte de classe grand public. Plutôt que d'affirmer que l'émulation est valide sans le vérifier, ils montrent qu'elle tombe dans la même plage de bande passante que celle atteinte par leurs deux machines véritablement grand public (un vrai bureau et un vrai portable) à plein nombre de threads. Les systèmes de référence sont tenus à des formats de poids strictement identiques plutôt que comparés entre différentes quantifications. Et les charges de travail agentiques sont de vrais harnais — OpenCode et Claude Code pilotant un vrai ticket de dépôt SWE-bench, OpenClaw exécutant un vrai kit d'agent email/calendrier — plutôt que des prompts synthétiques à tour unique. C'est un dispositif d'évaluation véritablement plus rigoureux que celui de nombreux articles de systèmes de service, et cela mérite d'être nommé comme tel indépendamment du fait que les chiffres finaux tiennent ou non sous un examen extérieur.
Ce qui n'est pas encore vérifié de façon indépendante
C'est un préprint arXiv, soumis le 17 août 2026 — pas encore relu par les pairs, et chaque chiffre de l'article est une mesure propre aux auteurs, pas une mesure reproduite de façon indépendante. Le fait que les auteurs soient des chercheurs en systèmes établis avec de vrais antécédents dans exactement ce domaine est une raison de prendre la méthodologie au sérieux, pas un substitut à ce que quelqu'un en dehors de la liste des auteurs relance la comparaison. Le code est ouvert (Apache 2.0, sur GitHub) et une version téléchargeable existe sur flashml.ai, ce qui est précisément ce qui rend une reproduction indépendante possible ici — contrairement à un benchmark d'API hébergée, quiconque dispose du matériel listé pourrait effectivement relancer ceci.
À surveiller
- Une évaluation indépendante. Parce que FreeToken est installable plutôt que verrouillé derrière une API, des relances tierces sur du matériel identique ou comparable sont réellement faisables ici — un vrai test que ce genre d'article de systèmes n'obtient pas toujours.
- La relecture par les pairs. L'ingénierie est détaillée et la méthodologie d'évaluation est inhabituellement transparente sur ses propres choix d'émulation, mais ni l'une ni l'autre ne remplace le passage de l'article par une relecture indépendante.
- L'adoption sur les deux extrêmes que l'article met en avant. Savoir si un portable à 8 Go faisant tourner un modèle de 35 milliards de paramètres à une vitesse utilisable, et un seul GPU de station de travail faisant tourner un modèle à 753 milliards de paramètres tout court, changent réellement ce que les gens font tourner localement — plutôt que de rester un résultat de benchmark — est le vrai test de l'affirmation « des poids ouverts vers un accès ouvert ».