Mises à Jour des Modèles & Plateformes IAAccélération de l’inférence

DSpark de Liquid AI booste LFM2.5 avec un débit jusqu’à 3,2×—sans modifier les sorties gourmandes

Liquid AI a publié des checkpoints préliminaires DSpark pour LFM2.5-1.2B-Instruct, 2.6B et 8B-A1B qui ajoutent un décodage spéculatif pour des accélérations majeures : jusqu’à 3,18× sur GPU et 2,87× en local, avec un impact mémoire minimal et une parité des sorties gourmandes. Le support dès le premier jour dans llama.cpp et SGLang en fait une mise à jour pratique pour les charges de travail en périphérie et agentiques.

Équipe de recherche NexusAi25 août 20262.1K vues8 min de lecture

DSpark de Liquid AI booste LFM2.5 avec un débit jusqu’à 3,2×—sans modifier les sorties gourmandes

Brief IA

DSpark de Liquid AI arrive sous forme de checkpoints préliminaires pour trois modèles LFM2.5, ajoutant un chemin de décodage spéculatif qui préserve la sortie gourmande tout en augmentant le débit de décodage—jusqu’à 3,18× sur un H100 et 2,87× sur un MacBook avec un impact mémoire minimal. DSpark combine un backbone parallèle, une tête séquentielle légère et un vérificateur programmé par confiance pour augmenter les taux d’acceptation et amortir les charges de poids sur plusieurs jetons. Avec un support dès le premier jour dans llama.cpp et SGLang, les équipes peuvent rapidement évaluer DSpark en contexte GPU et local. La conclusion : les petits modèles ajustés par instruction peuvent désormais atteindre des vitesses « interactives » pour le chat, le codage et les boucles agentiques—notamment les appels de fonctions—sans réentraînement ni perte de déterminisme sous greedy.

Liquid AI déploie des checkpoints préliminaires DSpark pour LFM2.5-1.2B-Instruct, 2.6B et 8B-A1B qui ajoutent un décodage spéculatif au chemin de décodage. La promesse est claire : jusqu’à 3,18× de débit sur un seul H100 et jusqu’à 2,87× en local, tout en conservant des sorties gourmandes identiques à la référence. Cette parité est cruciale—DSpark vérifie chaque jeton proposé—permettant aux équipes d’adopter cette accélération sans compromettre les bases d’évaluation établies. Avec un support dès le premier jour dans SGLang et llama.cpp, ce déploiement n’est pas un simple prototype de laboratoire ; il est immédiatement opérationnel dans les piles d’inférence courantes. L’impact est le plus visible là où les petits modèles doivent être instantanés : chat local, assistants de codage et appels de fonctions agentiques, où DSpark réduit aussi significativement la latence.

Pourquoi cela fonctionne-t-il maintenant ? Le décodage LLM est souvent limité par la mémoire : le chargement répété de poids volumineux depuis la DRAM domine la latence. DSpark résout cela en utilisant un rédacteur compact qui propose plusieurs jetons, puis en faisant vérifier ces propositions par le modèle cible en une seule passe—amortissant ainsi le trafic mémoire. Sa recette combine un backbone parallèle de type DFlash avec une tête Markov légère pour ajouter une dépendance inter-jetons, ainsi qu’un vérificateur programmé par confiance qui élagage les suffixes à faible confiance. Les rédacteurs de Liquid AI comptent environ 300 millions de paramètres et sont entraînés pour maximiser l’acceptation plutôt que la simple perte, poussant plus de jetons vérifiés par passe. Résultat : moins d’allers-retours en mémoire par jeton émis, ce qui se traduit par un débit plus élevé sans modifier les sorties gourmandes.

Les performances varient selon les contextes. Pour les petits modèles denses (1,2B–2,6B), DSpark offre des gains constants de 2 à 3× sur GPU et de fortes accélérations en local qui franchissent le seuil du « ressenti instantané » pour un usage interactif. Le modèle MoE 8B-A1B montre des gains robustes sur GPU mais des améliorations plus modestes en local, en raison de l’efficacité actuelle de Metal MoE et du coût de la vérification de plusieurs jetons sur plusieurs experts. Néanmoins, la capacité de DSpark à augmenter les jetons par seconde sur ordinateurs portables rend les assistants et agents locaux nettement plus efficaces, et dans les flux agentiques, Liquid AI rapporte une réduction moyenne de plus de moitié de la latence des appels de fonctions—un avantage considérable pour les scénarios à forte utilisation d’outils où le temps de réponse est critique.

Opérationnellement, DSpark est une mise à jour simple : associez le brouillon au modèle cible dans SGLang ou utilisez une version de llama.cpp compatible DSpark, puis surveillez le taux d’acceptation et draft_n/draft_n_accepted pour valider les bénéfices. Commencez avec le rédacteur correspondant à votre cible LFM2.5 et une taille de bloc modérée ; ajustez selon votre domaine pour stabiliser l’acceptation. Comme le décodage spéculatif est exact sous greedy, vos outils d’évaluation et benchmarks restent comparables. En production, validez la performance agentique de bout en bout—en particulier la latence des outils et la cadence des appels de fonctions—car le ROI pratique de DSpark semble maximal là où les appels multi-étapes dominent le temps de réponse.

Points clés à retenir

Parité gourmande avec une vraie vitesse

DSpark vérifie chaque jeton proposé, garantissant que le décodage gourmand correspond aux sorties de référence tout en offrant jusqu’à 3,2× de débit sur GPU et de solides gains en local—idéal là où exactitude et réactivité comptent.

Les charges en périphérie et agentiques bénéficient en premier

Les petits modèles denses LFM2.5 atteignent des vitesses interactives localement, et les flux multi-outils agentiques voient une réduction notable du temps de réponse grâce à DSpark qui réduit la latence des appels de fonctions de plus de moitié en moyenne.

Adoptez vite, mesurez intelligemment

Associez le brouillon DSpark, suivez le taux d’acceptation et draft_n_accepted, et évaluez les jetons par dollar et la latence de bout en bout. Attendez-vous à des gains plus modestes en local pour MoE jusqu’à maturation des kernels et de la planification Metal.

Ce que Liquid AI vient de livrer—et pourquoi c’est important

Les checkpoints préliminaires DSpark pour trois modèles LFM2.5 permettent un décodage spéculatif qui augmente le débit sans modifier les sorties gourmandes. Les gains sont significatifs tant pour le cloud que pour la périphérie : jusqu’à 3,18× sur un H100 et 2,87× sur un appareil de type MacBook avec une mémoire supplémentaire minimale. Avec un support dès le premier jour dans SGLang et llama.cpp, DSpark n’est pas une simple branche de recherche ; c’est une solution proche de la production. Pour les fondateurs et équipes plateformes qui priorisent la réactivité et le coût, cela permet aux petits modèles d’atteindre des vitesses interactives en codage, chat et boucles agentiques—réduisant la nécessité de passer à des modèles plus grands uniquement pour la latence.

Comment DSpark augmente le débit tout en préservant la parité gourmande

Le décodage spéculatif résout le goulot d’étranglement mémoire du décodage en proposant plusieurs jetons via un rédacteur léger et en les vérifiant en une seule passe sur le modèle cible. Le mélange DSpark—backbone parallèle pour tous les jetons du brouillon, tête Markov séquentielle pour augmenter l’acceptation en positions ultérieures, et vérificateur programmé par confiance pour élaguer les suffixes à faible confiance—pousse plus de jetons acceptés par vérification. Liquid AI a entraîné des rédacteurs d’environ 300 millions de paramètres optimisés pour l’acceptation, pas seulement la perte. Sous décodage gourmand, les propositions rejetées sont remplacées par le choix du modèle cible, donc les jetons émis sont identiques à la référence. Le résultat net : moins d’allers-retours en mémoire par jeton émis et un débit plus élevé sans changer les sorties.

Où cela aide le plus : GPU vs. local et la mise en garde MoE

Pour les modèles denses de 1 à 3 milliards de paramètres, DSpark offre régulièrement un débit multiplié par 2 à 3 sur GPU et plus de 2× sur les ordinateurs portables modernes—suffisant pour transformer les expériences de chat et de codage et accélérer les boucles agentiques. Les accélérations locales pour la variante MoE 8B-A1B sont plus modestes en raison de l’efficacité actuelle du backend Metal et du coût de validation de k jetons sur plusieurs experts. Si votre charge est fortement orientée outils, la réduction moyenne de 57 % de la latence des appels de fonctions est particulièrement précieuse. En résumé : choisissez DSpark pour les petits et moyens modèles ciblant une UX interactive ou un service économique ; pour MoE en local, attendez-vous à des bénéfices mais restez prudent jusqu’à maturation des kernels et du backend.

Guide d’intégration : du laboratoire à la confiance en production

Adoptez DSpark en associant le modèle LFM2.5 cible avec son brouillon correspondant dans SGLang ou une version de llama.cpp compatible DSpark. Commencez avec la taille de bloc par défaut du brouillon et vérifiez les gains à l’aide des télémetries de taux d’acceptation et des compteurs draft_n vs. draft_n_accepted. Évaluez sur votre trafic réel—chat, code, mathématiques et usage d’outils—pour éviter le surapprentissage sur un seul corpus. Pour les déploiements locaux, profilez la mémoire disponible avec la quantification et la longueur de contexte choisies. En production, suivez la latence agentique de bout en bout et les jetons par dollar, pas seulement les tok/s bruts, pour capturer l’effet de DSpark sur le temps de réponse des appels de fonctions et la réactivité perçue par l’utilisateur.

Limites, risques et points de vigilance

La parité des sorties gourmandes de DSpark ne s’étend pas aux réglages non gourmands ; l’échantillonnage avec température ou nucleus modifie la dynamique d’acceptation et peut réintroduire une dérive, donc utilisez un décodage déterministe lorsque la parité est essentielle. Sur les modèles MoE, la vérification de plusieurs jetons peut activer plus d’experts et saturer la bande passante mémoire, réduisant les accélérations locales jusqu’à amélioration des kernels. Il y a une petite surcharge mémoire due au brouillon ; prévoyez-la avec la longueur de contexte et le cache KV. Enfin, surveillez le support en amont dans SGLang et llama.cpp ; à mesure que les kernels et la planification s’améliorent—surtout sur Metal—l’écart local pour MoE devrait se réduire.

Questions fréquentes

DSpark va-t-il modifier les réponses de mon modèle ?

Sous décodage gourmand, non—le vérificateur de DSpark garantit que la séquence émise correspond au modèle cible. Si vous activez l’échantillonnage (température, nucleus), la dynamique d’acceptation change et les sorties peuvent diverger ; conservez les réglages déterministes lorsque la parité est requise.

Quelle mémoire supplémentaire le brouillon ajoute-t-il, et la quantification aide-t-elle ?

Le rédacteur compte environ quelques centaines de millions de paramètres, ajoutant une surcharge modeste par rapport au modèle cible. Les builds GGUF quantifiés réduisent encore l’empreinte, ce qui est particulièrement utile sur les ordinateurs portables et appareils périphériques avec des budgets mémoire serrés.

Que dois-je mesurer pour valider DSpark en production ?

Suivez le taux d’acceptation, les jetons par seconde, et draft_n vs. draft_n_accepted. Pour un ROI réel, mesurez la latence de bout en bout (notamment les appels de fonctions), les jetons par dollar, et la réactivité perçue par l’utilisateur sur votre mix de charge réel.