Liquid AI a publié sur Hugging Face un nouveau lot de checkpoints de la série LFM2.5, au format GGUF Q4_0, entraînés avec une méthode appelée QAD (quantization-aware distillation, distillation consciente de la quantification). Les quatre tailles (230M, 350M, 1.2B-Instruct et 2.6B) ont respectivement retrouvé 97,1 %, 96,5 %, 97,4 % et 96,6 % des scores de leurs bases de référence en BF16 lors des évaluations.
Pour qui ne fait pas d'inférence locale, cette annonce n'a rien de spectaculaire à première vue. Pour en saisir la portée, il faut d'abord comprendre la place qu'occupe Q4_0 dans l'écosystème llama.cpp.
Un format abandonné par la communauté
Q4_0 fait partie des tout premiers schémas de quantification 4 bits, avec une règle simple : tous les 32 poids partagent un facteur d'échelle, le reste est directement compressé en entiers 4 bits. La communauté a ensuite développé la série K-quant (Q4_K_M, Q5_K_M, etc.), qui répartit des largeurs de bits différentes selon l'importance de chaque tenseur, avec une précision nettement meilleure à taille de fichier égale. Q4_0 s'est ainsi presque retiré de la circulation, ne survivant que sur certains appareils et runtimes plus anciens.
Il conserve pourtant un avantage que personne ne peut lui enlever : une structure régulière qui se mappe directement sur les instructions de produit scalaire int8 des CPU Arm. Le découpage en blocs et les tables de correspondance de K-quant demandent quelques détours supplémentaires sur les CPU des smartphones, pas Q4_0. C'est précisément ce que visent les chiffres de vitesse publiés cette fois par Liquid AI : sur les mêmes modèles, les checkpoints Q4_0 sont 4 % à 33 % plus rapides que Q5_K_M, et 3 % à 14 % plus rapides que Q4_K_M.
Ce qui bloquait donc Q4_0 depuis toujours, c'était bien la précision. Et c'est exactement là que QAD intervient.
Faire entrer la quantification dans l'entraînement
L'approche classique est le PTQ (post-training quantization, quantification post-entraînement) : le modèle termine son entraînement, puis on le compresse, on regarde combien de précision a été perdue, et si c'est trop, on change de format et on recommence. L'idée de QAD est de faire savoir au modèle, dès l'entraînement, sous quelle forme il sera compressé plus tard : un modèle enseignant de haute précision distille ses connaissances vers un modèle élève déjà quantifié, la contrainte de quantification participe à l'entraînement, et la distribution des poids se rapproche dès le départ de la grille 4 bits. Sur son blog officiel, Liquid AI décrit cela ainsi : "QAD substantially improves the Q4_0 checkpoint" (QAD améliore substantiellement le checkpoint Q4_0).
Ce n'est pas un concept nouveau : l'entraînement conscient de la quantification est utilisé depuis des années sur les modèles de vision. La difficulté, en le transposant aux modèles de langage, tient au coût : chaque format cible nécessite son propre cycle d'entraînement. Qu'un fournisseur soit prêt à payer ce coût montre qu'il a fait le calcul. Le volume de téléchargements et d'appels des modèles embarqués justifie, semble-t-il, un entraînement dédié par format.
Vérification sur quatre machines
Les tests ont couvert deux catégories de matériel : MacBook Pro et NucBox EVO-X2 pour l'inférence GPU, Samsung Galaxy S26 Ultra et Raspberry Pi 5 pour l'inférence sur CPU Arm. La présence du Raspberry Pi 5 dans cette liste est notable : il représente justement le scénario sans GPU et à mémoire limitée, là où l'avantage de Q4_0 est le plus marqué.
À vue de calcul : un modèle de 2,6 milliards de paramètres stocké en 4 bits pèse un peu plus de 1,4 Go ; en ajoutant le cache KV et la surcharge du runtime, un smartphone doté de 8 Go de mémoire peut encore l'installer tout en gardant de la marge pour d'autres tâches. La version 230M, elle, se situe dans l'ordre de quelques centaines de mégaoctets, tout à fait envisageable à intégrer dans une application comme fonction locale.
Le pari de cette nouvelle génération de checkpoints
La direction de ce compromis est nouvelle. Ces deux dernières années, l'approche dominante de l'inférence embarquée a consisté à réduire le modèle : distiller vers moins de paramètres, ou changer pour un format de quantification plus intelligent. Cette fois, Liquid AI a choisi une troisième voie : sans changer le format, sans changer le nombre de paramètres, en reportant toute la pression d'optimisation sur l'entraînement.
Le prix à payer, c'est que la méthode ne fonctionne que pour ses propres modèles. La communauté ne peut pas s'en servir pour sauver des poids Q4_0 publiés par d'autres, car cela nécessite le pipeline d'entraînement d'origine. C'est quelque chose que seul le fabricant du modèle peut fournir, et c'est l'un des rares points où l'on peut encore creuser un écart dans la course aux petits modèles embarqués : à taille égale de 2,6 milliards de paramètres, tournant tous deux sur llama.cpp, celui dont la version 4 bits perd le moins de précision remporte cette manche.
Pour les développeurs, la barrière d'entrée reste inchangée : GGUF Q4_0 est le format le plus universel, chargé directement par llama.cpp et par tout runtime compatible Q4_0, sans modification de code ni nouvel opérateur. C'est aussi pour cela qu'on le préfère à un format personnalisé : la compatibilité elle-même constitue une capacité de distribution.
Sources : blog officiel de Liquid AI, CocoLoop, page du modèle sur Hugging Face ; les taux de récupération de précision des quatre tailles et les deux fourchettes de vitesse ont été vérifiés d'après les données publiées officiellement.