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 cadrage de l'article mérite d'être énoncé clairement car il est juste dans la mesure où il va : 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 cadrage 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 prefill 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 decode 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 à forme close, calculée en direct, plutôt qu'une règle fixe. Pendant le decode, 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 prefill, 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 comme 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 vrais cadres d'agents sont déjà documentés pour couper, si bien qu'un contexte modifié peut reprendre depuis l'ancre survivante la plus proche et ne re-prefiller 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 decode 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 decode de FreeToken resterait, d'après les rapports, à 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 — un rappel qu'un benchmark exécuté sur un seul prompt isolé peut surestimer de façon significative 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) — 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 decode 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, d'après les rapports, 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 decode que l'article attribue à Codex en production, en citant un article de mesure distinct plutôt qu'une comparaison sur la même configuration, ce qui mérite d'être signalé comme une référence inter-articles plutôt que comme une comparaison directe. Sur un seul GPU de station de travail RTX PRO 6000, FreeToken servirait, d'après les rapports, 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 — tandis que 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 — et ils montrent que cette émulation tombe dans la même plage de bande passante que leurs deux machines véritablement grand public (un vrai bureau et un vrai portable) atteignent à plein nombre de threads, plutôt que d'affirmer que l'émulation est valide sans le vérifier. 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
- Un benchmarking indépendant. 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 ».
Références : arXiv — FreeToken: Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution (2608.16157) · GitHub — FlashML-org/FreeToken · couverture liée : Ces poids ouverts que vous ne pouvez pas faire tourner · Frontier Arcade : tendances et prédictions