LFM2.5 QAD Q4_0 : des modèles IA locaux plus précis en 4 bits

Faire tourner un modèle de langage localement oblige presque toujours à arbitrer entre trois contraintes : la mémoire, la vitesse et la qualité des réponses. La quantification en 4 bits est souvent le compromis retenu sur un laptop, un smartphone ou un mini-PC. Mais ce compromis a un coût : réduire la précision numérique d’un modèle après son entraînement peut dégrader ses performances, parfois de façon sensible sur le raisonnement, le suivi d’instructions ou l’usage d’outils.

Liquid AI annonce des versions QAD Q4_0 de quatre modèles LFM2.5 au format GGUF. Leur particularité n’est pas seulement d’être quantifiées en 4 bits : elles ont été produites via une méthode de Quantization-Aware Distillation, ou QAD. Selon les résultats communiqués par l’éditeur, ces checkpoints conservent l’empreinte mémoire et le débit d’un Q4_0 classique tout en récupérant une grande partie de la qualité habituellement perdue lors de la quantification.

La distillation QAD traite la quantification pendant l’entraînement

Dans une approche de quantification post-entraînement (Post-Training Quantization, PTQ), on entraîne d’abord le modèle en haute précision, puis on convertit ses poids vers une représentation plus compacte. Cette opération est pratique et très répandue, notamment dans l’écosystème GGUF, mais elle introduit des approximations numériques. Elles peuvent modifier le comportement du modèle.

Liquid AI décrit ici une autre voie. Un modèle étudiant, directement destiné à être quantifié, est entraîné par distillation à partir d’un modèle enseignant de haute précision. Autrement dit, l’entraînement cherche à ce que la version basse précision reproduise plus fidèlement les sorties ou comportements du modèle de référence. La promesse de cette approche est claire : ne pas considérer la quantification comme une conversion finale, mais comme une contrainte intégrée au processus de formation.

Les fichiers annoncés couvrent quatre tailles de la famille LFM2.5 :

• LFM2.5-230M ;
• LFM2.5-350M ;
• LFM2.5-1.2B-Instruct ;
• LFM2.5-2.6B.

Ils sont distribués au format GGUF Q4_0. Cela les rend utilisables avec llama.cpp et, plus largement, avec les runtimes compatibles avec des artefacts GGUF Q4_0. Pour un développeur, l’intérêt est opérationnel : il ne s’agit pas d’adopter un nouveau format ni de changer de pile d’inférence, mais de sélectionner un checkpoint différent.

Les benchmarks publiés indiquent une récupération d’environ 97 % de la référence BF16

Liquid AI compare ses nouveaux checkpoints QAD à des versions GGUF obtenues par quantification post-entraînement, avec les GGUF BF16 comme plafond de référence « dans le format ». Le protocole couvre plusieurs dimensions : raisonnement avec GPQA Diamond et MMLU-Pro, suivi d’instructions avec IFEval, IFBench et Multi-IF, ainsi qu’usage d’outils et capacités agentiques avec BFCLv4.

Une évaluation mathématique adaptée à la taille des modèles est aussi ajoutée : GSM8K pour les modèles 230M et 350M, AIME25 pour les modèles 1,2B-Instruct et 2,6B. Les scores sont calculés comme une moyenne sur cinq répétitions.

D’après l’éditeur, les versions QAD récupèrent respectivement 97,1 %, 96,5 %, 97,4 % et 96,6 % de la performance de base BF16 pour les quatre modèles. La formulation mérite d’être lue avec précision : ces pourcentages correspondent à une performance moyenne relative sur la suite d’évaluations retenue par Liquid AI. Ils ne signifient pas que chaque tâche, chaque prompt ou chaque langue atteindra le même niveau que BF16.

La publication affirme également que la méthode améliore substantiellement les checkpoints Q4_0 issus de PTQ. C’est le résultat central de l’annonce, mais les données restent celles fournies par le concepteur des modèles. La source ne détaille pas, dans le contenu disponible, les écarts score par score, les prompts exacts, les paramètres d’inférence ni une reproduction indépendante complète. Tu as donc intérêt à valider le comportement sur tes propres jeux de tests avant un passage en production.

Des gains annoncés sur Mac, mini-PC, Galaxy S26 Ultra et Raspberry Pi 5

Le bénéfice recherché ne se limite pas aux scores. Liquid AI a mesuré le débit de génération des quatre modèles sur quatre cibles : un MacBook Pro, un NucBox EVO-X2, un Samsung Galaxy S26 Ultra et un Raspberry Pi 5. Les deux premières plateformes utilisent l’inférence GPU dans ces tests, tandis que le smartphone Samsung et le Raspberry Pi reposent sur des CPU Arm.

Pour les modèles de 230M et 350M, l’éditeur indique que QAD Q4_0 atteint une qualité équivalente à Q5_K_M, dans la variance des évaluations, avec un débit de décodage supérieur de 4 à 33 %. Pour les modèles 1,2B et 2,6B, QAD Q4_0 atteindrait le niveau de Q4_K_M avec 3 à 14 % de débit supplémentaire.

La comparaison avec les quantifications UD-Q4_K_XL d’Unsloth est aussi mentionnée pour les modèles 230M et 1,2B : Liquid AI affirme des résultats comparables là où cette référence est applicable. En pratique, ces comparaisons suggèrent qu’un checkpoint Q4_0 mieux entraîné peut se rapprocher de formats traditionnellement choisis pour préserver davantage de qualité, sans leur coût potentiel en débit ou en mémoire.

Il faut toutefois éviter de généraliser les chiffres de vitesse. Le débit dépend fortement du runtime, de ses options de compilation, du contexte utilisé, du nombre de threads, du backend GPU, de la température de l’appareil et du scénario de génération. La source donne les plateformes ciblées, mais ne fournit pas ici le détail exhaustif des conditions nécessaires pour transposer ces mesures à ton matériel.

Tester les nouveaux GGUF sans modifier ton workflow llama.cpp

Le chemin d’essai est volontairement direct. Les fichiers sont disponibles sur Hugging Face et peuvent être appelés avec llama-cli. Liquid AI fournit notamment cet exemple pour le modèle 350M :

llama-cli -hf LiquidAI/LFM2.5-350M 
  --hf-file LFM2.5-350M-QAD-Q4_0.gguf 
  -p "What is C. elegans?"

Avant de remplacer un modèle existant dans un produit, mets surtout en place une comparaison utile pour ton cas réel :

1. conserve tes prompts de production, y compris les entrées longues et ambiguës ;
2. mesure la qualité attendue : exactitude, format JSON, respect des consignes, appels d’outils ou ton rédactionnel ;
3. compare QAD Q4_0 à ton checkpoint actuel avec les mêmes paramètres de température, de contexte et de sampling ;
4. mesure le temps au premier token, le débit de génération et la mémoire réellement consommée sur l’appareil visé ;
5. teste les échecs : données incomplètes, consignes contradictoires et requêtes hors périmètre.

Pour un assistant embarqué, un outil de support hors ligne ou un agent local simple, les tailles 230M et 350M peuvent être pertinentes si la latence et la sobriété priment. Les modèles 1,2B-Instruct et 2,6B offrent une autre enveloppe de capacité, mais le choix ne peut pas reposer sur le nombre de paramètres seul : tes contraintes de matériel et tes tâches doivent guider la décision.

Le bon usage : considérer QAD Q4_0 comme un candidat de déploiement, pas comme une garantie universelle

Cette publication apporte un signal intéressant pour l’IA locale : la qualité d’un modèle compact dépend aussi de la manière dont il a été préparé pour la quantification. Si les résultats se confirment dans des usages indépendants, QAD peut réduire le besoin de monter vers des formats plus lourds simplement pour compenser une conversion 4 bits trop agressive.

La démarche la plus rationnelle est de télécharger le checkpoint correspondant à ton budget matériel, de l’intégrer à ton banc d’essai llama.cpp, puis de le confronter à la fois à ton Q4_0 actuel et à la référence plus qualitative que tu envisages habituellement. Les chiffres de benchmark donnent une hypothèse crédible ; seul un test sur tes données permet de décider si cette hypothèse se traduit en valeur produit.