Liquid AI publie LFM2.5-VL-DSpark : un modèle visuel 3B avec modèle de draft, décodage jusqu'à 3,13 fois plus rapide
Selon un billet de blog de Liquid AI publié en septembre 2026, Liquid AI propose un modèle de draft expérimental DSpark pour son modèle vision-langage à poids ouverts LFM2.5-VL-3B, ajoutant environ 280 millions de paramètres (soit 8,9 % de plus que le modèle cible de 3B), avec une accélération annoncée du décodage allant jusqu'à 3,13 fois sur appareil et 2,66 fois sur H100, et un support dès le premier jour de llama.cpp, MLX-VLM et SGLang.
Ce qui change
Liquid AI a publié en septembre 2026 un modèle de draft expérimental DSpark, associé à son modèle vision-langage LFM2.5-VL-3B. Selon le blog du fournisseur, ce modèle de draft reprend l'approche architecturale de la version texte LFM2.5-DSpark : il capture les états cachés du modèle cible au niveau de couches d'accès fixes et s'en sert pour proposer un lot de tokens candidats ; les patches d'image et les tokens texte sont projetés dans un espace de représentation partagé avant d'entrer dans ces couches, de sorte que le modèle de draft traite des états cachés de dimension uniforme, avec un algorithme d'inférence identique à celui du modèle texte. Le modèle de draft adopte une structure à 4 couches composée uniquement d'attention, avec une taille de bloc de 9, et compte environ 279,5 millions de paramètres, répartis en 193 millions pour la pile de décodeur, 21 millions pour la projection des états cachés, 65,5 millions pour la tête de Markov, et 64 millions pour les normes et la tête de confiance. Le fournisseur annonce des accélérations de décodage de 2,30 à 3,13 fois selon les tâches et de 1,56 à 2,62 fois en bout en bout avec MLX sur M5 Max ; de 1,57 à 2,14 fois en décodage avec llama.cpp sur M3 Ultra ; et sur H100, les données d'accélération de décodage et de bout en bout semblent présenter une anomalie de mise en page dans le texte original. Le fournisseur souligne que le décodage spéculatif est exact, le modèle cible validant chaque token proposé, la sortie gloutonne étant identique à celle du modèle cible seul ; le modèle de draft est proposé sur Hugging Face aux formats Safetensors et GGUF.
Conséquences pour les développeurs
Pour les développeurs qui déploient des modèles multimodaux en local ou sur des appareils en périphérie, l'intérêt de cette publication ne réside pas dans les chiffres de vitesse absolus, mais dans le rapport de taille entre le modèle de draft et le modèle cible — environ 8,9 % — ce qui signifie que l'augmentation de l'occupation mémoire GPU et RAM reste contrôlable. Toutefois, la plupart des accélérations sont des indicateurs de la phase de décodage ; le gain de bout en bout dépend de la part de l'encodage visuel et du prefill dans la charge de travail, ce que le fournisseur lui-même explique en citant la loi d'Amdahl. Cela crée une bifurcation : les scénarios dominés par de longues sorties, des dialogues multi-tours ou la description d'images pourraient s'approcher des chiffres de bout en bout annoncés ; ceux dominés par une question-réponse sur une seule grande image, nécessitant de traiter d'abord de nombreux tokens visuels et se terminant rapidement, verront un gain nettement moindre. En outre, l'exécution du modèle de draft dépend de branches llama.cpp, MLX-VLM ou SGLang non encore fusionnées dans la branche principale ou nécessitant des builds spécifiques, et le coût d'intégration ne doit pas être négligé. À noter qu'au moment de cette vérification, le catalogue actuel de KimiSeek ne contient aucune entrée pour LFM2.5-VL-3B ou LFM2.5-VL-DSpark, et les disponibilités d'API et de poids mentionnées dans la source relèvent du discours du fournisseur.
Intégration et évaluation
Recommandation 1 : mesurez d'abord la part du décodage dans la latence totale de votre charge avant de décider d'introduire le modèle de draft. La source indique que le décodage spéculatif n'accélère que le décodage, pas l'encodage visuel ni le prefill, et que sur les appareils en périphérie, le prefill représente une part plus élevée de la latence de bout en bout. Cela suppose que vous disposez déjà de données détaillées sur la latence du premier token et le temps de décodage ; il est recommandé de faire tourner deux configurations, baseline et modèle de draft, sur le même ensemble de six types de tâches visuelles (VQA général, VQA texte, description d'image, VQA sur graphiques, raisonnement complexe, dialogue multi-tours), et d'évaluer les percentiles de latence de bout en bout plutôt que le seul débit de décodage. Si votre charge est dominée par des sorties longues sur des images courtes, le modèle de draft peut être rentable ; si elle est dominée par des questions-réponses sur une seule grande image, le gain maximal est limité par le prefill. Recommandation 2 : choisissez entre llama.cpp et SGLang selon votre forme de déploiement, et non selon l'accélération de pointe annoncée. La source donne des modes de lancement différents : SGLang monte le modèle de draft via des paramètres tels que --speculative-dspark-block-size et exige explicitement la désactivation du radix cache ; côté llama.cpp, il faut --spec-type draft-dspark avec --spec-draft-n-max 8. Cela suppose que votre build inclut la PR correspondante, sinon ces paramètres sont indisponibles. Lors de l'évaluation, il est conseillé d'enregistrer les draft_n et draft_n_accepted de chaque réponse, et de juger d'après le taux d'acceptation si une taille de bloc de 8 ou de 9 est plus appropriée ; si le taux d'acceptation est faible, vérifiez si la distribution des tâches s'écarte du mélange de données d'entraînement. Ces éléments sont des pratiques recommandées, et non des engagements du fournisseur.
Limites et points à confirmer
Premièrement, au moment de cette vérification, le catalogue actuel de KimiSeek ne contient aucune entrée exacte pour LFM2.5-VL-3B ou LFM2.5-VL-DSpark ; cette version n'est donc pas disponible sur KimiSeek. Le téléchargement des poids, les formats et les modes d'intégration mentionnés dans la source relèvent du discours du fournisseur et ne représentent pas la disponibilité sur notre site. Deuxièmement, dans le texte original du fournisseur, une plage d'accélération de décodage sur H100 est écrite comme « 20,4 fois à 2,66 fois », ce qui constitue une anomalie évidente de mise en page ou de transcription et ne doit pas être cité comme limite fiable. Troisièmement, le fournisseur décrit lui-même le modèle de draft comme expérimental ; sa structure à 4 couches et sa taille de bloc de 9 proviennent d'ablations sur 3, 4 et 5 couches, et le mélange de données d'entraînement est pondéré selon la charge attendue, de sorte que le taux d'acceptation et l'accélération varieront avec la distribution réelle des tâches. Quatrièmement, les chiffres d'accélération proviennent de tests internes du fournisseur sur M5 Max, M3 Ultra et H100, évalués selon les six types de tâches du benchmark MMSpec ; les performances sur d'autres matériels, formats de quantification, longueurs de contexte et configurations de traitement par lots n'ont pas été validées indépendamment. Cinquièmement, la source décrit le modèle comme à poids ouverts et librement téléchargeable, affinable et déployable, mais le blog ne fournit pas les termes de licence précis ; la disponibilité des poids n'équivaut pas à une licence open source, et les droits d'usage commercial et de redistribution dépendent de la licence réelle indiquée sur la page Hugging Face du modèle.
Illustrations de l’article original
