Le 20 août, Liquid AI a publié sur Hugging Face une série de modèles brouillons LFM2.5-DSpark, dotant trois de ses modèles du décodage spéculatif : LFM2.5-1.2B-Instruct, 2.6B et 8B-A1B. Selon l'entreprise, le gain de vitesse atteint jusqu'à 3,18 fois, avec des résultats en sortie strictement identiques à ceux du modèle d'origine.
Le principe du décodage spéculatif n'a rien de compliqué : un petit modèle devine d'abord les prochains mots, et le grand modèle ne calcule plus mot par mot, mais vérifie en une seule passe avant l'ensemble de cette série de candidats. Si la supposition est juste, elle est utilisée directement ; sinon, il faut recalculer. Tout le temps gagné vient du fait qu'on évite d'aller et venir sans cesse dans le chargement des poids.
655 Mo contre une vitesse doublée voire triplée
Les modèles brouillons que Liquid AI associe cette fois sont tous très petits. La version pour le 1.2B compte 295,7 millions de paramètres ; les versions 2.6B et 8B-A1B partagent un modèle de 327,7 millions de paramètres. La structure comprend 5 couches d'attention complète, une dimension cachée de 2048, une couche intermédiaire de 6144, 32 têtes de requête partageant 8 groupes KV, avec 9 mots candidats proposés à chaque étape. En précision BF16, l'occupation mémoire GPU est de 655 Mo.
Un calcul rapide sur un Mac doté de 16 Go de mémoire : 655 Mo représentent environ 4 % de la mémoire totale, en échange d'un temps de réponse en dialogue local plus de deux fois plus rapide. Ce rapport coût-bénéfice est plutôt avantageux dans les scénarios embarqués. Ce qui manque le plus sur l'appareil n'a jamais été la puissance de calcul de pointe, mais ces quelques secondes de blanc pendant l'attente.
Les chiffres dépendent du matériel utilisé
Le benchmark officiel a été mené sur deux environnements distincts, et les résultats diffèrent nettement.
| Modèle cible | Moyenne H100 | Pic H100 | Moyenne M4 Max | Pic M4 Max |
|---|---|---|---|---|
| 1.2B-Instruct | 2,10x | 2,56x | 2,54x | 2,87x |
| 2.6B | 2,67x | 3,06x | 2,27x | 2,63x |
| 8B-A1B | 2,54x | 3,18x | 1,18x | 1,44x |
Le facteur 3,18 mis en avant dans le titre provient du meilleur résultat du 8B-A1B sur H100. Sur un portable M4 Max, ce même modèle ne dépasse plus 1,18 fois. Liquid AI en explique elle-même la raison : le backend Metal de llama.cpp n'implémente pas encore correctement les architectures de mélange d'experts (MoE), et le MoE embarqué reste le point faible de cette solution.
Les données de taux d'acceptation ont également été publiées. Sur MATH500, le 8B-A1B voit en moyenne 8,27 mots candidats sur 10 acceptés ; sur GSM8K, ce chiffre tombe à 4,02. Les textes de démonstrations mathématiques ont une structure régulière et une forte prévisibilité, ce qui permet au modèle brouillon de mieux deviner ; face à des énoncés de problèmes de primaire formulés plus librement, le taux de réussite chute aussitôt de moitié.
Une autre donnée se rapproche davantage d'un usage réel : dans les scénarios d'appels de fonctions multi-outils, la latence de la version 2.6B a baissé de 57 % en moyenne. Chaque étape d'un agent doit attendre que le modèle produise un appel structuré, et ce type d'aller-retour redoute par-dessus tout l'accumulation de latence.
D'où vient cette méthode
Le nom DSpark n'a pas été inventé par Liquid AI. Il provient d'un travail publié en open source fin juin de cette année par DeepSeek en collaboration avec l'université de Pékin, utilisant une ossature de brouillon parallèle associée à une tête de Markov légère, ainsi qu'un mécanisme ajustant la longueur de vérification en fonction de la charge GPU en temps réel. Les chiffres communiqués à l'époque faisaient état d'une hausse de 60 à 85 % de la vitesse de génération pour un utilisateur unique, et d'un débit par carte jusqu'à 6,6 fois supérieur sous des objectifs de latence stricts.
Deux mois plus tard, cette méthode réapparaît dans l'annonce d'une entreprise américaine de modèles embarqués. Sur SGLang, l'activation se fait en ajoutant le paramètre --speculative-algorithm DSPARK ; llama.cpp a pris en charge dès le premier jour le format FP16 GGUF sur le backend Metal. Le fait que des frameworks en amont transforment directement le nom de l'algorithme en valeur de commutateur en ligne de commande montre à lui seul que la méthode est déjà traitée comme une norme de fait.
Ces deux dernières années, les laboratoires chinois ont publié en open source pas mal de résultats d'ingénierie côté inférence, les discussions portant surtout sur les économies de cartes. Cette diffusion de DSpark apporte un autre type de retour : la méthode s'est glissée dans le chemin par défaut d'un tiers, et tous les déploiements ultérieurs bâtis sur ce framework font désormais tourner cette logique.
La licence trace une ligne claire
Les poids sont publiés dans les formats Safetensors et GGUF, sous la licence LFM Open License 1.0 : les entités dont le chiffre d'affaires annuel est inférieur à 10 millions de dollars peuvent les utiliser commercialement gratuitement ; au-delà de ce seuil, un accord commercial séparé doit être négocié. Le seul mode de déploiement possible est l'auto-hébergement, Liquid AI ne proposant pas d'API hébergée.
Cette ligne se situe précisément entre les start-up et les entreprises de taille moyenne ou grande, avec une intention assez claire : utiliser le quota gratuit pour devenir le choix par défaut des développeurs, tout en réservant les revenus à ceux qui peuvent payer.
Sources : blog officiel Hugging Face, fiche modèle de Liquid AI, CocoLoop, MarkTechPost ; les données de gain de vitesse, de nombre de paramètres et de taux d'acceptation suivent le tableau de benchmark officiel, les conditions de licence suivent la page du modèle.