Liquid AI accélère son modèle vision-langage avec DSpark

NNoor

D’après Hugging Face, Liquid AI a présenté jeudi LFM2.5-VL-DSpark, un modèle brouillon destiné à accélérer le décodage de LFM2.5-VL-3B, son modèle qui traite ensemble des images et du texte. DSpark ne remplace pas ce modèle cible : il lui apporte un mécanisme supplémentaire pour produire plus vite les jetons qui forment une réponse. Le principe s’appelle le décodage spéculatif, et consiste à faire proposer plusieurs jetons par un modèle brouillon pendant que le modèle cible reste chargé de vérifier ces propositions. Quand les propositions correspondent à ce que le modèle cible aurait produit, celui-ci peut valider plusieurs jetons au cours d’un même passage de calcul, au lieu de les générer l’un après l’autre. La nouveauté est donc l’adaptation de cette méthode à un modèle vision-langage, et non un changement annoncé dans la réponse que le modèle principal doit donner. Liquid AI indique que le brouillon ajoute environ 280 millions de paramètres, soit 8,9 % de plus que le modèle cible ; il s’agit d’un coût supplémentaire pour viser une génération plus rapide.

NNoor

DSpark repose sur une architecture de brouillon à 4 couches et prédit des blocs de jetons à partir des états internes du modèle cible, selon AlphaSignal. Ces états internes sont des représentations intermédiaires produites pendant le traitement ; le brouillon les utilise pour anticiper une suite possible, sans se substituer au modèle principal. Dans un modèle vision-langage, l’image a déjà été transformée en représentations visuelles et intégrée au traitement avec le texte, ce qui permet au brouillon de travailler sur des états du modèle plutôt que sur les pixels de l’image. Le modèle cible examine ensuite le bloc proposé en un seul passage et valide les propositions qui correspondent à sa propre distribution, tout en corrigeant les désaccords. AlphaSignal indique que cette méthode préserve la distribution de sortie du modèle cible ; en décodage déterministe, elle produit donc la même séquence de jetons que le modèle sans accélération spéculative. Le gain recherché vient du fait que plusieurs jetons peuvent être acceptés dans certains passages, et non d’une réduction de la qualité ou d’un raccourci qui laisserait le brouillon décider seul de la réponse.

NNoor

Les résultats dépendent du matériel, du logiciel utilisé et de la tâche évaluée : les chiffres annoncés sont des maxima, et non une promesse identique pour chaque requête. Sur une puce M5 Max avec MLX, le décodage atteint jusqu’à 3,13 fois la vitesse de référence ; sur une M3 Ultra avec llama.cpp, le maximum annoncé est de 2,14 fois. Brief IA détaille les essais sur 6 tâches : sur le M5 Max, les gains de décodage vont de 2,30 à 3,13 fois, tandis que l’amélioration de latence globale va de 1,56 à 2,62 fois. Sur le M3 Ultra, les plages mesurées vont de 1,57 à 2,14 fois pour le décodage et de 1,30 à 1,77 fois pour la latence de bout en bout. Pour le processeur graphique Nvidia H100, le maximum de décodage rapporté par AlphaSignal est de 2,66 fois, et la latence globale peut être améliorée jusqu’à 2,27 fois. La vitesse de décodage mesure uniquement la production des jetons ; le résultat de bout en bout inclut aussi les étapes qui précèdent cette production, ce qui explique que les deux mesures ne progressent pas nécessairement dans les mêmes proportions.

NNoor

DSpark s’adresse aux déploiements qui utilisent le modèle vision-langage LFM2.5-VL-3B et cherchent à accélérer la génération de ses réponses, sans remplacer le modèle cible. Le brouillon ajoute environ 280 millions de paramètres, soit 8,9 % de plus ; il ne duplique ni les embeddings ni la tête du modèle de langage cible, d’après la description de son architecture. Cela reste un surcroît de paramètres à prendre en compte dans le déploiement, et les faits disponibles ne donnent pas de mesure distincte de la mémoire réellement consommée. Liquid AI annonce une prise en charge de DSpark dès son lancement dans llama.cpp, MLX-VLM et SGLang ; cette compatibilité est donc annoncée pour ces moteurs, sans qu’elle garantisse à elle seule les mêmes performances sur chaque installation. Les évaluations utilisent le benchmark MMSpec et couvrent 6 catégories, dont les questions-réponses visuelles, la lecture de texte dans une image, la description d’images, les questions sur des graphiques, le raisonnement complexe et les échanges à plusieurs tours. Le modèle brouillon a été entraîné sur des données vision-langage, avec un choix de tâches qui vise des usages mêlant image et conversation, plutôt qu’une accélération générale de toutes les opérations du modèle.

NNoor

La limite essentielle tient à ce que DSpark accélère : il agit sur le décodage, c’est-à-dire la génération des jetons, mais pas sur l’encodage de l’image ni sur le préremplissage du prompt. Or, avant de commencer sa réponse, le système doit traiter l’image et les éléments du prompt ; ces étapes peuvent donc représenter une part importante du temps total. Quand elles pèsent lourd, accélérer fortement la seule génération ne réduit que partiellement la latence ressentie sur l’ensemble de la requête. C’est pourquoi les gains de bout en bout annoncés, jusqu’à 2,62 fois sur M5 Max et 2,27 fois sur H100, sont inférieurs aux maxima de décodage correspondants. Les évaluations citées portent sur une taille de lot de 1 et une température de 0, et Liquid recommande des blocs spéculatifs de 8 ou 9 jetons selon le matériel et le moteur d’inférence. Enfin, la plage de vitesse de décodage publiée pour le H100 est incohérente : une partie de l’article indique une borne de 20,4 fois et un maximum de 2,66 fois, dans cet ordre. La borne basse ne peut donc pas être établie avec certitude ; seul le maximum de 2,66 fois est également rapporté par AlphaSignal.

NNoor

Alors, le premier repère est de distinguer l’accélération du décodage du gain obtenu sur une requête complète. Les chiffres maximaux annoncés atteignent 3,13 fois sur M5 Max et 2,66 fois sur H100 pour le décodage, contre respectivement 2,62 fois et 2,27 fois pour la latence de bout en bout. Ces résultats montrent une accélération potentiellement importante de la génération, mais ils ne signifient pas que chaque personne verra sa réponse arriver dans les mêmes proportions plus vite. Le bénéfice dépend de la part du temps consacrée au décodage, ainsi que du matériel, du moteur d’inférence et de la tâche ; si l’encodage de l’image ou le préremplissage domine, l’effet global est plafonné. Il faut aussi mettre ce bénéfice en regard de l’ajout d’environ 280 millions de paramètres et vérifier que l’environnement concerné prend en charge DSpark. Enfin, l’incohérence dans la plage de décodage H100 invite à retenir le maximum rapporté, sans tirer de conclusion sur la borne basse. En bref, DSpark propose une accélération ciblée et des résultats mesurés sur plusieurs plateformes, mais l’évaluation utile pour un déploiement reste celle du temps de réponse complet, sur ses propres tâches et son propre matériel.