Liquid AI accélère l’inférence de ses modèles jusqu’à 3,2× sans changer un seul token produit
Le 20 août 2026, Liquid AI publie des modèles draft DSpark pour sa famille LFM2.5, avec un gain de débit allant jusqu’à 3,18× sur GPU et 2,87× sur appareil, sans altérer la sortie. Les équipes qui servent du LLM en production ont une raison concrète de réévaluer leur coût par token.
20 août 2026. Liquid AI publie sur le blog Hugging Face des checkpoints de modèles draft DSpark pour trois modèles de sa famille LFM2.5 : le 1.2B-Instruct, le 2.6B et le 8B-A1B. Jusqu’à 3,18× de débit sur un H100, 2,87× sur un MacBook M4 Max. 57 % de latence en moins en moyenne sur les appels de fonction.
Pour qui sert des modèles ouverts en production, la promesse tient en une phrase : le décodage spéculatif n’est plus une technique de laboratoire, c’est un réglage que vous pouvez brancher aujourd’hui, sans toucher à la qualité de la sortie.
Le goulot n’est pas le calcul, c’est la mémoire
La phase de décodage d’un LLM est, dans la plupart des cas, bornée par la mémoire. La latence vient moins du calcul que du transfert des poids depuis la DRAM vers la SRAM — on « streame » les poids à chaque token, et le matériel passe plus de temps à attendre qu’à calculer.
Le décodage spéculatif contourne ce goulot. Un petit modèle « draft » propose plusieurs tokens candidats à la suite ; le modèle cible les vérifie ensuite tous en une seule passe avant. Le coût de chargement des poids est ainsi partagé entre tous les tokens vérifiés d’un coup, au lieu d’être payé token par token. Le résultat est un débit supérieur pour un résultat final identique.
La technique n’est pas neuve : EAGLE-3, puis DFlash, puis plus récemment DSpark en ont affiné les variantes. Ce qui change avec LFM2.5-DSpark, c’est qu’un éditeur livre des modèles draft prêts à l’emploi, entraînés et ouverts, au lieu de vous demander de les construire vous-même.
Trois briques, un seul mécanisme
DSpark combine trois composants. D’abord, un backbone parallèle de type DFlash, conditionné sur les features de contexte du modèle cible, qui produit les états cachés de tous les tokens draft en une seule passe avant. Ensuite, une tête séquentielle légère, modélisée comme une chaîne de Markov entre tokens voisins, qui ajoute la dépendance inter-token et augmente le taux d’acceptation sur les positions éloignées. Enfin, un vérificateur à confiance programmée qui estime la probabilité de survie de chaque token et élague les suffixes à faible confiance quand la vérification coûterait plus qu’elle ne rapporte.
Les modèles draft restent petits — environ 300 millions de paramètres — face à des cibles qui en comptent plusieurs milliards. Pour le LFM2.5-2.6B, le draft pèse 327,7 millions de paramètres ; pour le 1.2B, 295,7 millions. Leur entraînement a suivi la recette DSpark sur 15 epochs, en sélectionnant l’epoch au meilleur taux d’acceptation plutôt qu’à la plus faible perte — un choix de métrique qui dit tout de l’objectif : la vitesse, pas la vraisemblance du draft.
La qualité ne bouge pas, par construction
Le point qui rassure, et que Liquid AI souligne explicitement, c’est la parité de qualité. En décodage glouton, un token draft n’est accepté que s’il correspond à la distribution du modèle cible. En cas de rejet, c’est le token de la cible qui prend sa place. La séquence émise est donc identique au glouton de base, par construction — le pass@1 et la correspondance exacte sur les benchmarks ne changent pas.
Autrement dit, le gain de vitesse n’est pas payé en précision. C’est ce qui distingue le décodage spéculatif d’une simple quantification agressive : on ne dégrade rien, on organise mieux le calcul.
# Décodage spéculatif avec llama.cpp : le draft LFM2.5-DSpark accélère la cible
./llama-cli -m LFM2.5-2.6B.gguf --model-draft lfm2.5-dspark-draft.gguf \
--draft-max 9 -p "Explique la différence entre un draft et une cible."Les chiffres derrière la promesse
Sur un H100 80 Go en BF16 via SGLang, le LFM2.5-2.6B passe en moyenne de 323 à 864 tokens/s — un facteur 2,67×. Sur un MacBook M4 Max via llama.cpp et Metal, il passe de 61 à 139 tokens/s, soit 2,27×. Le pic atteint 3,06× sur MATH500 côté GPU, et 2,87× sur HumanEval côté appareil pour le 1.2B.
Le détail qui intéresse les intégrateurs d’agents : sur des scénarios multi-outils, DSpark réduit la latence des appels de fonction de 57 % en moyenne pour le 2.6B. C’est précisément là que le décodage spéculatif paie le plus, car les appels d’outils enchaînent de courtes séquences où chaque milliseconde compte.
LFM2.5-2.6B — débit moyen sur 5 datasets
H100 (SGLang, BF16) : 323 → 864 tok/s (×2,67)
M4 Max (llama.cpp) : 61 → 139 tok/s (×2,27)
Latence function-calling : −57 % en moyenneLe 8B-A1B — une architecture MoE à environ 1 milliard de paramètres actifs — reçoit le même traitement, ce qui montre que la technique s’applique aussi aux modèles parcimonieux, pas seulement aux denses.
Ce que ça change pour ceux qui servent du LLM
Le support est annoncé dès le premier jour dans llama.cpp et SGLang, avec l’intégration DSpark ouverte en amont. Traduction opérationnelle : vous n’avez pas à attendre un fork ni à écrire votre propre moteur. Les deux chemins les plus répandus pour servir de l’inférence locale ou sur GPU embarquent déjà la brique.
Pour une équipe qui paie son inférence au token ou qui facture un service, un facteur 2 à 3× de débit sans perte de qualité se traduit directement : soit le même coût pour trois fois plus de trafic, soit un coût divisé par trois à trafic constant. C’est rare qu’une optimisation tienne en une seule ligne de configuration.
Verdict
Si vous servez un modèle de la famille LFM2.5 — ou un modèle pour lequel un draft compatible existe — branchez le décodage spéculatif aujourd’hui. Le surcoût mémoire est minime, la sortie est identique par construction, et le gain de débit est mesuré, pas promis.
Si vous évaluez un modèle ouvert pour un agent, ajoutez le critère « existe-t-il un draft spéculatif prêt à l’emploi » à votre grille. C’est lui qui déterminera si votre latence de bout en bout — et surtout la latence de vos appels d’outils — tient vos objectifs, pas seulement le débit théorique du benchmark.
La règle à retenir : le décodage spéculatif est passé du statut de technique de recherche à celui de réglage de production. Le jour où un modèle open source affiche un débit de cloud propriétaire, ce n’est plus la taille du modèle qui compte, c’est l’organisation du calcul.