LFM2.5-DSpark : jusqu’à 3,2x plus rapide avec le décodage spéculatif

Faire tourner un LLM plus vite ne consiste pas toujours à réduire sa taille ou à changer de matériel. Liquid AI mise ici sur une autre approche : faire proposer plusieurs tokens par un petit modèle auxiliaire, puis les faire vérifier en une passe par le modèle principal. Avec ses checkpoints LFM2.5-DSpark, publiés pour trois modèles de la famille LFM2.5, l’éditeur annonce des gains de débit allant jusqu’à 3,18x sur GPU et 2,87x sur MacBook M4 Max, selon le modèle et le jeu de tests.

Le point intéressant pour les développeurs qui déploient en local ou en self-hosted : cette accélération est proposée dès le départ dans llama.cpp et SGLang. Elle ne modifie pas le résultat en décodage greedy. En revanche, les chiffres restent très dépendants de la nature des requêtes, du matériel et du backend utilisé. Il faut donc les lire comme des mesures de laboratoire reproductibles sous certaines conditions, pas comme une promesse universelle.

DSpark réduit le coût mémoire de la phase de génération

La génération autoregressive d’un LLM avance habituellement token après token. Lors de cette phase de décodage, la latence vient largement des transferts de poids entre la mémoire DRAM et la mémoire rapide utilisée pour le calcul, plutôt que d’un manque de puissance de calcul brute. C’est précisément ce goulot d’étranglement que le décodage spéculatif cherche à contourner.

Le principe est simple : un draft model, plus léger, produit une série de tokens candidats. Le modèle cible vérifie ensuite ces candidats en parallèle lors d’un même passage avant. Quand les propositions sont correctes, le coût du chargement des poids du modèle cible est mutualisé sur plusieurs tokens. Lorsqu’une proposition est rejetée, le modèle cible fournit son propre token et la génération continue.

Selon Liquid AI, DSpark combine trois mécanismes :

• un backbone parallèle inspiré de DFlash, conditionné par les caractéristiques de contexte du modèle cible, pour produire les états cachés des tokens proposés ;
• une tête séquentielle légère, décrite comme une chaîne de Markov entre tokens voisins, qui vise à augmenter l’acceptation aux positions suivantes ;
• un vérificateur piloté par la confiance, capable d’écarter les suffixes dont la vérification coûterait plus qu’elle ne rapporte.

La métrique déterminante est donc le taux d’acceptation. Plus le modèle brouillon anticipe correctement les tokens du modèle cible, plus le gain est élevé. Ce lien explique les écarts notables observés d’un benchmark à l’autre.

Trois modèles brouillons d’environ 300 millions de paramètres

Les nouveaux checkpoints visent LFM2.5-1.2B-Instruct, LFM2.5-2.6B et LFM2.5-8B-A1B. Chaque modèle brouillon repose sur une architecture simplifiée, centrée sur l’attention, avec cinq couches et une taille de bloc de neuf. Ils ont été entraînés durant 15 époques sur un mélange de données SFT, conversationnelles, de code et d’appels de fonctions.

Liquid AI indique avoir retenu l’époque maximisant le taux d’acceptation, plutôt que celle qui minimisait la perte d’entraînement. C’est cohérent avec l’objectif opérationnel : un brouillon utile n’est pas seulement un modèle qui réduit une métrique de loss, mais un modèle qui prédit suffisamment bien les sorties du modèle cible pour accélérer la vérification.

Le modèle brouillon pour LFM2.5-1.2B-Instruct totalise 295,7 millions de paramètres. Ceux destinés aux versions 2.6B et 8B-A1B atteignent 327,7 millions de paramètres, principalement du fait d’une tête de Markov plus large. Il faut donc prévoir un surcoût mémoire : la source le qualifie de minimal, mais ne fournit pas de mesure chiffrée de consommation mémoire dans les configurations testées.

Des gains très nets sur H100, plus contrastés sur Mac

Les tests ont été effectués avec un batch de 1, une température à 0 et jusqu’à 256 tokens générés. Sur GPU, Liquid AI utilise SGLang avec une seule NVIDIA H100 de 80 Go et des poids BF16. En local, l’équipe s’appuie sur llama.cpp, Metal et des poids GGUF FP16 sur un MacBook Pro M4 Max. Les résultats couvrent MATH500, HumanEval, MBPP, GSM8K et MT-Bench.

Pour LFM2.5-2.6B, le débit moyen mesuré passe de 323 à 864 tokens par seconde sur H100, soit 2,67x. Sur le M4 Max, il progresse de 61 à 139 tokens par seconde, soit 2,27x. Les gains varient toutefois entre 1,99x sur MT-Bench et 2,63x sur HumanEval côté Mac.

Le plus petit modèle, LFM2.5-1.2B-Instruct, atteint en moyenne 2,10x sur H100 et 2,54x sur le M4 Max. Son maximum local est de 2,87x sur HumanEval, avec un passage de 136 à 389 tokens par seconde. Mais sur MT-Bench, le gain tombe à 1,72x. La source attribue cette dispersion à la variation des taux d’acceptation selon la distribution textuelle.

Le cas de LFM2.5-8B-A1B est plus nuancé. Sur H100, la moyenne annoncée est de 2,54x, avec un pic à 3,18x sur MATH500. Sur le M4 Max, elle n’est que de 1,18x. Liquid AI relie cette limite à l’implémentation actuelle des modèles MoE dans le backend Metal de llama.cpp : vérifier plusieurs tokens active davantage d’experts et augmente les transferts de poids. Un bon taux d’acceptation ne suffit donc pas à garantir un gain élevé sur toutes les piles logicielles.

Les appels de fonctions sont un cas d’usage à surveiller

Pour les agents locaux, la vitesse de réponse ne se résume pas aux tokens par seconde. Une boucle agentique peut enchaîner raisonnement, sélection d’outil, appel de fonction et traitement du résultat. Dans des scénarios multi-outils, Liquid AI mesure une baisse moyenne de 57 % de la latence avec LFM2.5-2.6B et DSpark.

La source ne détaille ni les outils utilisés ni le protocole exact de ces scénarios. Il serait donc imprudent d’extrapoler ce chiffre à ton propre agent. Mais le signal est concret : sur des flux courts et répétitifs, réduire le temps de décodage peut améliorer la réactivité perçue davantage que sur une longue génération isolée.

Déployer DSpark avec SGLang ou llama.cpp

Les modèles sont disponibles au format Safetensors et GGUF. Avec SGLang, il faut une version intégrant le support DSpark pour les cibles LFM2. Le serveur se lance en attachant le modèle brouillon au modèle principal :

python -m sglang.launch_server 
  --model-path LiquidAI/LFM2.5-2.6B 
  --speculative-algorithm DSPARK 
  --speculative-draft-model-path LiquidAI/LFM2.5-2.6B-DSpark 
  --speculative-draft-attention-backend flashinfer 
  --disable-radix-cache --mem-fraction-static 0.75 --port 30000

L’endpoint exposé est compatible avec l’API OpenAI sur /v1. Avec llama.cpp, la commande associe le GGUF cible et le GGUF brouillon :

llama-server -m LFM2.5-2.6B-F16.gguf 
  -md LFM2.5-2.6B-DSpark-F16.gguf 
  --spec-type draft-dspark --spec-draft-n-max 10 --spec-draft-n-min 0 
  -fa on -ngl 99

Dans les deux cas, la compatibilité dépend de builds intégrant les contributions DSpark citées par Liquid AI. Vérifie donc ta version avant de conclure à une régression ou à une absence de gain.

Pour tester proprement, commence par ton trafic réel en température 0 si tu veux vérifier la parité exacte des sorties. Mesure ensuite le débit, la latence de premier token, la mémoire consommée et le taux d’acceptation. DSpark est particulièrement pertinent lorsque ton modèle est limité par la bande passante mémoire et que tes requêtes obtiennent un bon taux d’acceptation. Si tu exploites un MoE local via Metal, attends-toi à des résultats potentiellement plus modestes que sur H100.