LFM2.5-2.6B-DSpark : le drafter de 328M qui rend l'agent embarqué de Liquid 2,3× plus rapide

Personne en dehors de Liquid AI n'a exécuté LFM2.5-2.6B-DSpark sur son propre matériel et publié un résultat chiffré. C'est le point de départ honnête pour ce modèle, car tout repose sur une promesse de performance : ce n'est pas un meilleur modèle 2.6B, c'est un modèle draft de 328M de paramètres placé devant le modèle agentique 2.6B LFM2.5-2.6B, qui lui propose des tokens à vérifier, de sorte que l'agent tourne environ deux fois plus vite sans que sa sortie change.

Publié le 20 août 2026 avec une note technique sur Hugging Face et un article complémentaire sur le blog de Liquid lui-même, LFM2.5-2.6B-DSpark est le modèle phare d'une petite famille de checkpoints de drafters pour décodage spéculatif publiés par Liquid ce jour-là. Tout ce qui figure ci-dessous dans la colonne des vitesses provient de mesures du fournisseur et n'a pas encore été confirmé de manière indépendante ; tout ce qui se trouve dans le dépôt, les formats et la prise en charge par les frameworks est simplement là pour être vérifié.

Ce qu'est DSpark, en un mot.

La décodage spéculatif consiste à faire tourner un petit modèle draft en amont du vrai modèle : le drafter prédit la prochaine série de tokens, la cible vérifie tout le lot en une seule passe avant, et elle conserve les tokens qu’elle valide. Quand les prédictions sont bonnes, vous avancez de plusieurs tokens pour le prix d’un seul, donc le débit augmente sans toucher aux poids de la cible. DSpark — la technique, proposée à l’origine par les chercheurs de DeepSeek en juillet 2026 et déjà déployée dans DeepSeek-V4 — est une version de cette astuce adaptée aux petits modèles sur appareil. Liquid l’appelle le décodage spéculatif à planification de confiance, et elle repose sur trois éléments : un backbone parallèle qui produit les états cachés de tous les tokens draft en une seule passe, une tête séquentielle légère qui modélise la dépendance entre tokens voisins afin que le taux d’acceptation ne s’effondre pas en fin de bloc, et un vérificateur qui élimine les suffixes à faible confiance lorsque les vérifier coûterait plus que ce que cela rapporte.

Ce dernier élément est ce qui distingue DSpark d’un simple générateur de brouillon : il ne fait pas toujours passer un bloc complet par la vérification. Lorsque la confiance du brouillon indique qu’un suffixe a peu de chances d’être accepté, il écourte le bloc et économise le calcul gaspillé. Le bloc de brouillon compte neuf jetons, donc la cible en vérifie jusqu’à dix à la fois.

Le rédacteur, en chiffres

Le checkpoint LFM2.5-2.6B-DSpark est un modèle de draft de 0,3 milliard de paramètres, composé uniquement d'attention : cinq couches d'attention complètes (taille cachée de 2 048, attention à requêtes groupées avec 32 têtes et 8 têtes clé-valeur), un vocabulaire de 128 000 jetons, une tête de Markov de rang 256 et une tête de confiance. Liquid l'a entraîné pendant 15 époques sur un mélange de données d'instructions, de conversations, de code et d'appels de fonctions — sur du matériel AMD — et a choisi l'époque en fonction du taux d'acceptation le plus élevé plutôt que de la perte la plus faible.

Ce taux d’acceptation est le nombre qui détermine la valeur du drafter. Sur cinq benchmarks, avec une taille de lot de 1 et une température de 0, LFM2.5-2.6B-DSpark a en moyenne accepté 4,83 jetons par étape de décodage sur un H100 et 4,42 sur un M4 Max — soit environ la moitié du bloc acceptée, d’où proviennent les accélérations d’un facteur deux.

Les accélérations, étiquetées

Tous les chiffres suivants proviennent des propres mesures de Liquid AI — SGLang sur un seul H100 80 Go en BF16, et llama.cpp avec le backend Metal sur un MacBook Pro M4 Max en FP16 GGUF, taille de lot 1, température 0 — et aucun n'a été reproduit par une partie indépendante au moment où nous écrivons ces lignes :

• Moyenne H100 — 2,67×, de 323 à 864 tokens/s. Par benchmark : MATH500 3,06×, HumanEval 2,56×, MBPP 2,64×, GSM8K 2,22×, MT-Bench 2,87×.

• Moyenne M4 Max — 2,27×, de 61 à 139 tokens/s. Par benchmark : MATH500 2,25×, HumanEval 2,63×, MBPP 2,11×, GSM8K 2,36×, MT-Bench 1,99×.

• Appel d'outils — dans des scénarios d'appel de fonctions multi-outils, la latence moyenne a chuté de 57 %.

• Contexte familial — le plus grand draft du groupe, LFM2.5-8B-A1B-DSpark, a atteint jusqu'à 3,18× sur H100, et le draft 1.2B jusqu'à 2,87× sur M4 Max ; les chiffres 2.6B ci-dessus se situent en milieu de peloton.

Deux éléments comptent dans ces chiffres, au-delà des moyennes. Premièrement, ils sont mesurés à température 0 et avec une taille de lot de 1 — la configuration qui favorise la spéculation et celle qui correspond le plus au travail des agents interactifs sur appareil. La garantie d’identité tient aussi dans ce cas : le décodage spéculatif vérifie chaque jeton proposé, donc en décodage glouton le texte émis est exactement ce que le modèle cible aurait produit seul. Deuxièmement, l’écart se réduit à mesure que le nombre de requêtes simultanées augmente : sur un seul H100, Liquid rapporte que l’avantage de DSpark converge autour d’une taille de lot de 128. Le modèle draft constitue donc un gain de latence pour les charges de travail interactives et fortement outillées, et non une solution miracle en termes de débit brut pour un serveur saturé.

Ce qui est confirmé, et ce qui ne l'est pas

{{1}}Confirmé, en ce sens que le dépôt est public et vérifiable :{{/1}} {{2}}le drafter est distribué en Safetensors (BF16) et GGUF ;{{/2}} {{3}}il s'associe au LFM2.5-2.6B post-entraîné, pas à la version de base ;{{/3}} {{4}}le support dès le premier jour a été intégré en amont dans llama.cpp (avec des kernels Metal expérimentaux) et dans SGLang ;{{/4}} {{5}}il est sous licence Liquid LFM Open License v1.0 ;{{/5}} {{6}}et — important pour quiconque planifie autour — la fiche du modèle indique qu'aucun fournisseur d'inférence ne le sert,{{/6}} {{7}}c'est donc un composant à exécuter soi-même.{{/7}}

Pas encore confirmé : que les accélérations se reproduisent sur d'autres matériels et configurations (personne en dehors de Liquid n'a publié de mesure), comment le drafter se comporte en échantillonnage plutôt qu'en décodage glouton, et si le chiffre de latence d'appel d'outil de 57 % tient dans de véritables harnais d'agents au-delà du harnais de référence utilisé par Liquid. Aucune de ces remarques n'est une accusation — la publication date d'un jour — mais elles font la différence entre un chiffre prometteur et un chiffre vérifié.

En train de l'exécuter.

Dans SGLang, vous utilisez une build compatible DSpark, lancez le serveur sur le modèle cible et nommez le drafter : l'algorithme spéculatif est DSPARK, le chemin du modèle draft pointe vers LiquidAI/LFM2.5-2.6B-DSpark, et la taille de bloc est lue dans le config.json du draft. Dans llama.cpp, vous chargez le GGUF cible avec le GGUF draft comme modèle draft et réglez le type de spec sur draft-dspark, la taille de bloc étant lue dans les métadonnées sidecar. Les deux intégrations sont intégrées en amont, donc aucun fork n'est requis — juste une build assez récente pour les inclure.

Quand il vaut la peine d'ajouter

LFM2.5-2.6B-DSpark mérite ses quelque 0.3GB de mémoire supplémentaire lorsque vous déployez réellement l'agent 2.6B là où Liquid l'a conçu pour vivre — sur un téléphone, un ordinateur portable ou une box edge — pour des charges de travail interactives ou d'appel d'outils qui sont contraintes par la latence et fonctionnent en mode glouton. C'est précisément le profil où le chiffre 2.27× sur l'appareil et la réduction de 57 % de la latence des appels d'outils font toute la différence. C'est moins intéressant si vous servez des requêtes en batch élevé sur un serveur (l'accélération converge vers 1×), ou si votre charge de travail fonctionne à une température supérieure à zéro, où les chiffres rapportés ne s'appliquent plus. Et si vous utilisez la variante 8B-A1B de la famille, notez le cas limite : son accélération sur l'appareil n'est aujourd'hui que d'environ 1.18×, car la vérification des jetons candidats active davantage d'experts dans le backend Metal de llama.cpp — Liquid le signale comme un problème connu.

Rien dans DSpark ne change l'endroit où s'exécute l'agent 2.6B — c'est une solution auto-hébergée par conception, et il se placera aux côtés des modèles hébergés que vous appelez déjà. Ce mélange d'un rédacteur local et d'une douzaine de points de terminaison API est exactement le type de plomberie qu'une couche de routage existe pour aplatir : une clé API unique sur plus de 200 modèles, un basculement automatique quand un fournisseur se dégrade, et les prix catalogue des fournisseurs transmis avec une marge de 0 %, de sorte que la comparaison des coûts local versus hébergé pour un agent de classe 2.6B reste claire au lieu de vivre dans un tableur.

La bonne façon de lire LFM2.5-2.6B-DSpark aujourd'hui est d'y voir une promesse de vitesse mesurée par le fournisseur, pas encore vérifiée de manière indépendante, attachée à un checkpoint réel, téléchargeable et exécutable. Si vous déployez l'agent 2.6B sur l'appareil, le drafter est peu coûteux à essayer et facile à retirer — ajoutez les deux flags spéculatifs à la commande SGLang, conservez le décodage glouton et mesurez par rapport à votre propre charge de travail avant de vous fier au 2,3×. Le repo est là ; la vérification indépendante est le point ouvert.