3 min de lecture

FreeToken exécute Qwen3.6-35B-A3B sur une RTX 4060 de 8 Go

FreeTokenMoEлокальный ИИ

FreeToken réunit GPU, CPU et RAM dans un pool adaptatif pour exécuter des modèles MoE en local. Selon FlashML-org, Qwen3.6-35B-A3B atteint 39,3 jetons par seconde sur un portable équipé d’une RTX 4060 mobile de 8 Go. La VRAM devient moins bloquante, mais la RAM, le CPU et la bande passante deviennent déterminants.

Comment FreeToken contourne la limite de VRAM

Le point essentiel, selon moi, est le suivant : FreeToken transforme le GPU, le CPU et la RAM en un pool de calcul partagé afin d’exécuter d’immenses modèles Mixture-of-Experts sans devoir les faire tenir entièrement dans la mémoire vidéo. C’est ainsi que FlashML-org décrit son moteur expérimental dans le dépôt officiel de FreeToken et dans l’article « Efficient Edge-Native MoE Serving with Bandwidth-Adaptive Execution ».

Le mécanisme est plus intéressant qu’un simple déport de couches vers la mémoire système. Au lancement, le moteur évalue la bande passante réelle entre GPU et CPU, ainsi que les capacités de calcul du processeur. À partir de ces données, il décide quels experts conserver sur le GPU, lesquels stocker en RAM et quelles tâches il est moins coûteux d’exécuter sur le CPU plutôt que de les transférer via PCIe.

Les experts les plus sollicités accèdent rapidement au GPU, tandis que les plus rares n’occupent pas durablement une VRAM limitée. Pour les MoE, c’est une approche naturelle : seule une partie des experts est activée à chaque jeton, il n’est donc pas indispensable de placer le modèle entier dans la mémoire vidéo. Cette caractéristique architecturale devient un moyen pratique d’exécuter des modèles bien plus grands que la VRAM disponible.

Lors de la publication, en août 2026, les auteurs ont communiqué les résultats suivants :

  • Qwen3.6-35B-A3B sur un portable doté d’une RTX 4060 mobile de 8 Go : 39,3 jetons/s.
  • DeepSeek-V4-Flash 284B sur une RTX 5090 : 22–25 jetons/s.
  • GLM-5.2 753B sur une seule RTX PRO 6000 : 14,9 jetons/s.

Ce sont les chiffres de l’article, pas mes propres mesures. L’évaluation couvrait trois modèles, six machines et quatre scénarios agentiques, avec une comparaison entre FreeToken, llama.cpp, Ollama, KTransformers et MoE-Infinity. L’ampleur de la vérification est significative, mais ces vitesses ne peuvent pas être transposées automatiquement à chaque prompt, configuration mémoire ou schéma de routage des experts.

L’IA locale ne se heurte plus uniquement à la VRAM

Il s’agit d’un véritable changement d’ingénierie : la capacité de VRAM n’est plus le seul obstacle rigide aux modèles MoE locaux. Le résultat de Qwen3.6-35B-A3B est particulièrement parlant, car un débit interactif est obtenu sur une RTX 4060 de portable avec 8 Go, et non sur un serveur multi-GPU.

La mémoire n’a pas cessé d’être une contrainte ; elle est simplement devenue un système partagé. La capacité de RAM, la bande passante PCIe, la vitesse du CPU et la répartition de l’activité entre les experts deviennent essentielles. Sur une machine mal équilibrée, le planificateur adaptatif peut buter sur les transferts de données bien avant les chiffres séduisants d’un tableau.

Je regarderais d’abord la latence du premier jeton, le débit soutenu durant de longues sessions et le comportement sous charge agentique. La moyenne de jetons par seconde révèle un potentiel, mais pas les pauses lors des changements d’experts ni la pression exercée sur la mémoire système.

FreeToken ne supprime pas les limites matérielles. Il fait quelque chose de plus intéressant : il cesse de considérer le GPU comme le seul endroit où l’inférence locale peut exister.

Nous avons déjà analysé Pony Alpha sur OpenRouter : un accès gratuit à un modèle doté d’un contexte de 200K pour le prototypage et la validation d’architecture. Ce cas complète FreeToken en montrant une autre manière d’expérimenter de grands modèles sans infrastructure coûteuse.