C’est quoi, LFM2.5-DSpark ?
Liquid AI, l’éditeur américain derrière la famille LFM2.5, vient de publier des variantes DSpark de ses modèles. La famille LFM2.5, lancée en janvier 2026, est conçue pour l’IA locale : assistants, agents, applications embarquées, avec un accent sur la vitesse et la faible consommation de mémoire. DSpark concerne trois modèles :
- LFM2.5-1.2B-Instruct, le plus léger, pensé pour l’embarqué ;
- LFM2.5-2.6B, le modèle intermédiaire récent ;
- LFM2.5-8B-A1B, le plus puissant, en architecture mixture of experts (MoE).
Le principe : chaque modèle conserve son comportement, on lui ajoute un compagnon qui accélère la génération.
Comment le décodage spéculatif accélère les réponses ?
En générant par blocs au lieu de token par token. Normalement, un modèle produit un mot (un token) à la fois : pour chaque token, une passe complète de calcul. Le décodage spéculatif change la donne. Un petit modèle draft d’environ 300 millions de paramètres propose un bloc de 9 tokens plausibles. Le modèle principal vérifie ce bloc en une seule passe et ne conserve que les tokens qu’il valide. Résultat : beaucoup moins de passes de calcul pour le même texte, donc des réponses nettement plus rapides. La contrepartie : une petite augmentation de mémoire pour charger le draft à côté du modèle principal, largement compensée par le gain de vitesse.
Quels gains réels, sur quel matériel ?
D’après les mesures de Liquid AI : jusqu’à 3,18 fois plus de débit sur un GPU NVIDIA H100 et jusqu’à 2,87 fois sur un MacBook Apple Silicon. Ces chiffres sont des maximums, atteints dans des conditions précises. Le gain réel dépend du modèle, du matériel et de la tâche. Sur MacBook, les modèles denses profitent pleinement de l’accélération ; le modèle MoE progresse moins (18 % en moyenne) tant que l’implémentation Metal de llama.cpp n’est pas optimisée. En clair : plus le matériel est puissant, plus le gain est net, mais même en local l’accélération est bien réelle.
La qualité des réponses change-t-elle ?
Non. Les sorties restent identiques à celles du modèle d’origine. Le draft propose, le modèle principal décide. Sous décodage greedy, le mode de génération standard, les réponses sont strictement identiques à celles de LFM2.5 sans DSpark. Un assistant déjà calibré garde donc exactement le même comportement, il répond simplement plus vite.
Comment tester LFM2.5-DSpark ?
Les checkpoints sont en accès libre sur Hugging Face, aux formats Safetensors et GGUF, avec un support intégré dans llama.cpp et SGLang dès la sortie. Aucun ré-entraînement nécessaire : on charge le draft correspondant à son modèle à côté du modèle principal, puis on mesure le débit avant et après. L’opération s’adresse aux équipes techniques qui déploient déjà LFM2.5, que ce soit sur un serveur, un poste de travail ou un appareil local. Pour les autres, l’intérêt est surtout de savoir que l’IA locale continue de gagner en vitesse.
Pourquoi c’est important pour votre activité ?
Chaque seconde gagnée sur une réponse change l’expérience des utilisateurs : un support client qui répond sans temps mort, un agent qui enchaîne ses étapes sans latence, un traitement de documents qui boucle plus vite. À vitesse égale, l’accélération se transforme en économie : moins de GPU requis, donc une facture d’inférence allégée. Et comme LFM2.5 tourne en local, les données sensibles restent chez vous. Le décodage spéculatif n’est pas réservé aux grands data centers, il profite aussi aux machines de bureau. C’est un bon moment pour regarder de près ce que vos outils IA coûtent et ce qu’ils pourraient coûter demain.
Vous déployez des assistants ou des agents IA et vous voulez mesurer ce que ces évolutions changent pour vous ? Nous faisons le point sur votre configuration actuelle et les pistes d’optimisation. Demandez votre maquette gratuite et repartez avec un plan clair.