
Liquid AI a publié de nouveaux checkpoints draft appelés DSpark pour faire fonctionner ses modèles LFM2.5 plus rapidement sur les serveurs et les appareils locaux. Si vous exécutez des modèles d’IA en local ou concevez avec des outils open-source, cette mise à jour peut réduire les temps d’attente sans modifier le résultat textuel final.
Selon un article de Liquid AI / Hugging Face publié le 2026-08-20, DSpark ajoute le décodage spéculatif à trois modèles : LFM2.5-1.2B-Instruct, LFM2.5-2.6B et LFM2.5-8B-A1B. Dans cette configuration, un petit modèle draft prédit rapidement les mots à venir. Ensuite, le modèle principal les vérifie en une seule passe. Sous un décodage glouton standard, tout token draft incorrect est remplacé par le modèle principal. Cela signifie que le résultat final reste identique.
Les chiffres annoncés par Liquid AI
Liquid AI a partagé de solides résultats de benchmark sur plusieurs configurations :
- Jusqu’à 3.18x plus de débit GPU sur un seul Nvidia H100 80GB fonctionnant en précision BF16.
- Vitesse sur l’appareil jusqu’à 2.87x plus rapide sur un MacBook Pro Apple M4 Max utilisant des poids GGUF FP16 sous Metal.
- Latence réduite de 57% en moyenne pour le function calling avec LFM2.5-2.6B.
- Accélération moyenne de 18% sur l’appareil pour le modèle MoE LFM2.5-8B-A1B, où Metal active actuellement des experts supplémentaires pendant la vérification.
L’intégration est disponible dès aujourd’hui. Vous pouvez déjà l’utiliser via la PR #27383 de llama.cpp et la PR #31041 de SGLang.
Ce qu’il ne faut pas croire aveuglément
Tous ces chiffres de performance proviennent directement des benchmarks internes de Liquid AI. Aucun tiers indépendant ne les a encore testés. Liquid AI a réalisé des tests avec une taille de bloc de 9, une taille de lot de 1, une température de 0, jusqu’à 256 tokens de sortie et cinq jeux de données de benchmark. Les résultats ne garantissent pas de gains sur des puces différentes, avec de grands lots ou avec des réglages de température créatifs. Liquid AI a également précisé que les gains de vitesse sur le modèle 1.2B variaient jusqu’à 52% selon le texte.
La vitesse n’est jamais garantie.
Ce que cela signifie pour votre configuration
Le décodage spéculatif n’a rien de magique. Il n’est utile que si le petit modèle devine correctement la plupart du temps. Si le draft échoue, la vérification fait perdre du temps.
Pourtant, le support dès le premier jour dans llama.cpp et SGLang facilite les tests. La vitesse en local est essentielle.
Comment le tester vous-même
Ne vous fiez pas aux moyennes. Faites vos propres tests avant de modifier votre pipeline de production.
Prenez exactement les poids draft et cibles DSpark pour votre modèle LFM2.5. Chargez-les dans votre version actuelle de llama.cpp ou SGLang. Exécutez vos prompts et appels de fonction habituels avec et sans DSpark. Mesurez les tokens par seconde, la mémoire, le taux d’acceptation du draft et la réussite des appels d’outils. Si le gain de vitesse se confirme sur votre matériel et que vos outils renvoient des arguments valides, DSpark est un avantage indéniable.
