FreeToken accélère les LLM locales face à Ollama

Ce que FreeToken accélère réellement

Ce qui m'a marqué ici, ce sont les gains annoncés de 3–4× en vitesse de decode et de 6–30× en prefill face à Ollama. L'équipe FlashML présente ces résultats dans l'article FreeToken, arXiv 2608.16157, ainsi que dans la documentation du projet. Il s'agit de benchmarks publiés par le projet au moment de leur publication, et non de mon test indépendant : le gain réel dépend du modèle, du matériel et de la forme de charge.

L'idée centrale de FreeToken n'est pas simplement un nouveau kernel rapide. Le système considère le CPU, le GPU et la mémoire vive comme une plateforme élastique unique pour l'inférence de grands modèles MoE qui ne tiennent pas entièrement en VRAM. Pendant l'exécution, il mesure la bande passante de liaison CPU–GPU via PCIe, ainsi que la vitesse de traitement du CPU.

Le runtime décide ensuite ce qui est le plus rentable pour chaque expert : le conserver dans le cache GPU ou l'exécuter directement sur le CPU. Un partitionnement statique est moins efficace, car les coûts de transfert des données et de calcul varient fortement entre un portable, un ordinateur de bureau et une station de travail. Cela ressemble déjà à une optimisation système, plutôt qu'à un chiffre séduisant issu d'une seule exécution favorable.

Le second levier est un cache sensible à la sémantique entre les tours de l'agent. Lorsque les requêtes sont liées et évoluent progressivement, FreeToken réutilise l'état utile, maintient les experts demandés à chaud et réduit le traitement répété du prompt. C'est pourquoi le gain en prefill est nettement supérieur à celui de la génération séquentielle de tokens.

Le résumé du projet annonce également un decode 1,5–2,3× plus rapide que les meilleurs systèmes edge comparés sur une RTX 5090. Un scénario parlant exécute un modèle de 35B paramètres avec un GPU de portable doté de 8 Go de mémoire.

Pourquoi cela change l'inférence locale

FreeToken ressemble moins à une accélération cosmétique qu'à une tentative de corriger l'architecture fondamentale de la pile de serving locale. Les machines disposant d'une VRAM limitée mais de suffisamment de RAM, ainsi que les scénarios d'agents comportant de longues séquences de requêtes liées, devraient en profiter le plus.

Je regarderais d'abord le démarrage à froid, la latence de queue, la pression sur la RAM et le comportement du cache lors d'un changement brutal de sujet. La réutilisation sémantique fonctionne très bien lorsqu'il existe réellement une répétition ; pour des requêtes sans lien, son apport sera inévitablement plus faible. De même, l'équilibre CPU–GPU peut être limité par une liaison PCIe donnée ou un processeur peu puissant.

Sur le plan de l'ingénierie, l'idée est solide : mesurer d'abord la machine réelle, puis planifier l'exécution, plutôt que d'imposer la même répartition partout. La question ouverte n'est donc plus de savoir si FreeToken est plus rapide dans les tests publiés, mais si cet avantage résiste aux différents modèles, matériels et véritables sessions d'agents.

Nous avons déjà analysé comment une infrastructure de calcul confidentiel peut transformer les coûts d’inférence des LLM et les arbitrages liés à la confidentialité. FreeToken ajoute le volet performance en améliorant le débit de décodage grâce à l’adaptation à la bande passante entre CPU et GPU.