TurboQuant : faire de la place à l’IA, sans agrandir la mémoire

Faire tourner une intelligence artificielle plus ambitieuse sur un ordinateur ordinaire : la promesse attire forcément mon attention. Le récit relayé par Frandroid le 31 mars 2026 ajoute un personnage séduisant, un développeur qui reprend une recherche de Google avec l’aide de Claude en une semaine. On a presque déjà le scénario. Il manque seulement une question : qu’est-ce qui a réellement été rendu plus petit ?

J’ai envie de comprendre le gain sans transformer une optimisation en tour de magie. Entre un cache comprimé, un modèle qui tient en mémoire et une réponse qui arrive plus vite, il y a plusieurs étapes. Les confondre permet un titre très court. Les distinguer permet de savoir ce qu’on peut attendre de son ordinateur.

Le modèle et son carnet de travail

Un modèle de langage utilise des paramètres appris pendant son entraînement, souvent appelés ses poids. Lorsqu’il produit une réponse, il manipule aussi des données temporaires. La documentation de Hugging Face explique notamment le cache KV : il conserve des résultats de calcul liés aux éléments de texte déjà traités, afin de ne pas les recalculer à chaque étape.

Ce n’est donc pas le fichier brut de toute la conversation rangé dans une petite boîte. C’est une mémoire de travail numérique, utilisée par le mécanisme d’attention. Dans une architecture classique à attention complète, sa taille augmente avec la longueur du contexte. La taille des poids, elle, ne grossit pas parce que la discussion s’allonge.

Cette distinction change beaucoup de choses. Réduire le carnet de travail peut rendre un long échange plus facile à traiter. Cela ne réduit pas automatiquement les poids du modèle, ni la mémoire du système, ni toutes les autres allocations nécessaires pour le faire fonctionner.

Si le bureau est déjà occupé par une énorme machine, ranger ses notes aide. Cela ne fait pas disparaître la machine. L’analogie s’arrête là, mais elle suffit à éviter de lire « cache divisé » comme « ordinateur soudain six fois plus puissant ».

Ce que Google publie vraiment

Dans son billet du 24 mars, Google Research présente TurboQuant comme une méthode de quantification de vecteurs : représenter des ensembles de nombres avec moins de bits en cherchant à préserver les relations utiles au calcul. Une rotation des données et un traitement de l’erreur résiduelle font partie du principe décrit.

Google annonce une réduction d’au moins un facteur six de la mémoire du cache KV dans les essais mis en avant. Il rapporte aussi une accélération pouvant atteindre huit fois pour un calcul d’attention particulier sur des accélérateurs H100. Ni l’un ni l’autre de ces résultats ne décrit le temps complet d’une conversation sur n’importe quel ordinateur.

Il faut aussi remettre la découverte sur son calendrier. Le préarticle scientifique a été déposé sur arXiv le 28 avril 2025. Le billet de mars 2026 le met en lumière avant une présentation à ICLR, dont la conférence est prévue en avril. Ce n’est pas une invention dévoilée pour la première fois sur scène à la fin de mars.

La méthode n’est donc pas secrète au sens où ses principes seraient cachés. Les équations sont publiques. Avoir un article décrivant une méthode et disposer d’un logiciel utilisable restent toutefois deux situations différentes. C’est dans cet espace que le travail d’implémentation prend son intérêt.

Sept jours racontés, beaucoup d’ingénierie visible

Le projet de Tom Turney s’appelle TurboQuant+. Pour regarder ce qu’il documente à cette époque, je m’appuie sur une version conservée du dépôt au 31 mars, pas sur un fichier principal qui pourra changer ensuite. Il propose notamment une intégration dans un dérivé de llama.cpp et des calculs adaptés aux puces graphiques Apple.

Frandroid raconte un travail mené avec Claude en sept jours. Je garde ce délai comme un récit de production, pas comme une mesure qui prouverait à elle seule une supériorité scientifique. Le dépôt permet d’examiner des choix, des tests et des corrections ; il ne réduit pas tout ce travail à « l’IA a écrit le programme ».

Le journal des optimisations est particulièrement éclairant. La progression de 739 à 2 747 tokens par seconde concerne le prefill, le traitement initial du texte fourni au modèle. Ce ne sont pas 2 747 morceaux de réponse produits chaque seconde. Le journal distingue cette mesure de la génération progressive, ou décodage.

Dans ce même essai, la référence q8_0 atteint 2 694 tokens par seconde. L’intérêt est donc de rapprocher la vitesse d’un cache comprimé d’une référence donnée, pas d’établir que toutes les autres méthodes seraient dépassées. Le bond impressionnant part aussi d’une première version encore peu optimisée.

Le zéro qui n’efface pas les limites

Turney ajoute une technique baptisée Sparse V, qui évite certaines opérations quand leur contribution à l’attention est très faible. Son document rapporte notamment un gain de 22,8 % en décodage à un contexte de 32 000 tokens, avec un modèle Qwen de 35 milliards de paramètres sur un M5 Max équipé de 128 Go de mémoire.

Le « zéro » mérite surtout d’être lu avec sa colonne. Dans ses tableaux, la différence affichée à 0,0000 compare la perplexité avec et sans cette optimisation, dans les essais décrits. La perplexité mesure la capacité du modèle à prédire un texte de test. Elle ne certifie ni l’exactitude de toutes ses réponses, ni l’absence de différence dans n’importe quelle tâche.

Le document distingue d’ailleurs cet effet supplémentaire de celui de la compression elle-même. Une optimisation peut ne pas dégrader davantage un résultat déjà légèrement différent de sa référence. Ce n’est pas contradictoire ; c’est simplement une autre comparaison.

Ces nombres restent ceux du développeur et de ses contributeurs, pas mes propres mesures. Je n’ai pas installé le projet ni reproduit ses bancs d’essai. Leur publication rend la vérification possible ; elle ne m’autorise pas à présenter un test effectué par quelqu’un d’autre comme une validation universelle.

Mon ordinateur n’a pas changé de catégorie

Le guide associé à cette version décrit une compilation et des réglages selon le matériel et le modèle. Il signale aussi des configurations à éviter. C’est un projet concret, mais ce n’est pas la preuve que chaque application déjà installée exploite cette méthode, ni que tout MacBook bénéficiera des chiffres d’une machine à 128 Go.

Pour un usage local, je regarderais séparément la place occupée par les poids, celle du cache à la longueur souhaitée, la vitesse de lecture et celle de génération. Puis la qualité sur la tâche qui m’intéresse. Un chiffre de compression, pris seul, ne répond pas à ces cinq questions.

Il est possible que ce type de progrès rende certains usages plus accessibles. Il est également possible qu’on profite de la marge gagnée pour demander davantage de contexte ou lancer davantage de traitements. L’économie par opération ne suffit pas à prédire la consommation totale, encore moins le prix futur des barrettes de mémoire.

C’est finalement ce qui me plaît dans cette histoire, une fois les superlatifs retirés : une idée publiée peut devenir un outil que d’autres examinent et transforment. Le gain n’a pas besoin de mettre fin à une crise mondiale pour être intéressant.

Je garderais volontiers la promesse d’une IA locale moins à l’étroit. Mais avant de demander si elle tient sur mon ordinateur, j’ai maintenant une autre question : dans quelles conditions, pour quel travail et avec quelle preuve du résultat ?