Liquid AI a annoncé le 20 août 2026 la disponibilité de checkpoints de brouillon DSpark pour trois modèles de sa famille LFM2.5 : LFM2.5-1.2B-Instruct, LFM2.5-2.6B et LFM2.5-8B-A1B. L’objectif est précis : réduire le temps nécessaire à l’inférence, notamment lorsque les modèles génèrent des réponses ou enchaînent plusieurs appels d’outils.
Selon l’annonce de Liquid AI, DSpark ajoute une voie de décodage spéculatif au fonctionnement habituel. Un modèle de brouillon plus petit propose plusieurs tokens, puis le modèle cible les vérifie. Liquid AI affirme qu’avec un décodage glouton, la sortie obtenue reste identique à celle du modèle cible exécuté seul. Le changement annoncé porte donc sur le rythme de génération et non sur la réponse produite.
Des gains importants, mais liés au matériel et au scénario
Liquid AI rapporte une amélioration maximale du débit de 3,18 fois sur GPU et de 2,87 fois sur appareil pour les modèles concernés. Pour LFM2.5-2.6B, les gains moyens publiés atteignent 2,67 fois sur un H100 et 2,27 fois sur un MacBook Pro équipé d’une puce M4 Max.
L’entreprise annonce également une réduction moyenne de 57 % de la latence des appels de fonctions pour LFM2.5-2.6B, dans plusieurs scénarios impliquant plusieurs outils. C’est l’impact le plus concret pour les développeurs d’applications capables de planifier une séquence d’actions : chaque appel peut être traité plus rapidement, ce qui réduit le temps d’attente cumulé lorsque le modèle doit utiliser plusieurs outils.
Ces résultats ne constituent toutefois pas une garantie de vitesse pour toutes les configurations. Ils proviennent de matériels, de moteurs d’inférence et de scénarios de test déterminés. Le bénéfice réel dépendra donc de l’environnement dans lequel le modèle est exécuté, ainsi que de la charge de travail concernée.
Un modèle de brouillon conçu pour vérifier rapidement les tokens
L’approche DSpark combine une architecture dorsale parallèle de type DFlash, une tête séquentielle légère modélisée comme une chaîne de Markov et un vérificateur de planification de confiance. Les premiers modèles de brouillon sont des réseaux simplifiés composés uniquement d’attention, avec cinq couches et un bloc de neuf.
Chacun contient environ 300 millions de paramètres : 295,7 millions pour LFM2.5-1.2B-Instruct-DSpark et 327,7 millions pour chacun des deux autres modèles de brouillon. Leur rôle n’est pas de remplacer le modèle cible, mais de lui soumettre des propositions afin qu’il puisse les accepter ou les vérifier pendant la génération.
Liquid AI a évalué le système sur MATH500, HumanEval, MBPP, GSM8K et MT-Bench, avec une taille de bloc DSpark de neuf, une taille de lot de un et une température nulle. Ces paramètres définissent le cadre des mesures publiées : ils décrivent une configuration d’évaluation précise, et non un mode de fonctionnement dont la vitesse serait identique dans tous les usages.
llama.cpp et SGLang pris en charge dès le lancement
Les checkpoints DSpark sont disponibles sur Hugging Face aux formats Safetensors et GGUF pour les trois modèles. Liquid AI indique que l’intégration est incluse dès le lancement dans llama.cpp et SGLang. Dans SGLang, ses exemples utilisent l’algorithme spéculatif DSPARK. Dans llama.cpp, ils s’appuient sur le type spéculatif draft-dspark, avec des fichiers distincts pour le modèle cible et le modèle de brouillon.
Pour LFM2.5-2.6B, les mesures ont été réalisées avec llama.cpp et Metal sur le MacBook Pro équipé d’une puce M4 Max, en utilisant des poids GGUF FP16. Sur H100 de 80 Go, Liquid AI a utilisé SGLang avec des poids BF16. Pour LFM2.5-8B-A1B, l’entreprise attribue une partie de l’écart entre les résultats sur GPU et sur appareil à l’implémentation actuelle de Metal dans llama.cpp et au trafic supplémentaire de poids généré par ses experts.
DSpark propose ainsi une voie d’inférence plus rapide pour les utilisateurs de LFM2.5, au prix d’un besoin de mémoire légèrement supérieur. Les chiffres publiés donnent des repères sur H100 et sur MacBook Pro équipé d’une puce M4 Max, mais ils ne remplacent pas une mesure dans l’environnement visé. Le modèle cible reste responsable de la vérification finale ; DSpark cherche à maintenir la génération en mouvement avec un modèle de brouillon plus léger.