Liquid AI ajoute le décodage spéculatif à LFM2.5-VL-3B pour accélérer l’inférence vision-langage

Liquid AI a publié un modèle expérimental de décodage spéculatif conçu pour accélérer son modèle vision-langage LFM2.5-VL-3B, en visant un goulot d’étranglement central de l’inférence multimodale : générer rapidement des réponses après le traitement d’une image et d’une requête.

Le modèle, nommé LFM2.5-VL-DSpark, ajoute un modèle draft de 280 millions de paramètres au modèle cible de 3 milliards de paramètres. Liquid AI indique que cette combinaison a permis des accélérations de décodage allant jusqu’à 3,13x sur un Apple M5 Max et jusqu’à 2,66x sur un Nvidia H100 dans son évaluation interne. Les gains de latence de bout en bout étaient plus modestes, atteignant 2,62x sur le M5 Max et 2,27x sur le H100.

Cette publication est particulièrement importante pour les équipes qui déploient des modèles vision-langage sur du matériel local, où la latence de réponse et les limites de mémoire peuvent être plus contraignantes que dans de grands clusters d’inférence. Elle étend également l’approche DSpark de Liquid AI des modèles de texte aux charges de travail multimodales sans nécessiter un algorithme de décodage spéculatif différent.

Un modèle draft conçu pour des entrées multimodales

Le décodage spéculatif utilise un modèle plus petit pour proposer plusieurs tokens à la fois. Le grand modèle cible vérifie ensuite ces propositions, accepte les tokens qui correspondent à sa propre distribution du prochain token et génère des remplacements si nécessaire. Cette approche peut réduire le nombre d’étapes coûteuses du modèle cible sans modifier la sortie du modèle cible sous vérification exacte.

Selon la publication Hugging Face de Liquid AI, le modèle draft LFM2.5-VL-DSpark prend des états cachés de certaines couches de LFM2.5-VL-3B et propose des blocs de tokens candidats. Les images et le texte sont d’abord projetés dans une représentation partagée, ce qui permet au modèle draft de recevoir des vecteurs de même dimension quelle que soit la modalité d’entrée.

Liquid AI indique que le modèle draft vision utilise quatre couches uniquement attention et une taille de bloc de neuf pendant l’entraînement. Pour l’inférence, l’entreprise recommande une taille de bloc de huit ou neuf selon le matériel. Le modèle draft ajoute environ 8,9 % au nombre de paramètres du modèle déployé, une augmentation de mémoire relativement faible par rapport à l’exécution d’un grand modèle séparé pour la même tâche.

Le modèle a été entraîné avec un mélange de données de fine-tuning supervisé vision-langage pondéré vers les charges de travail que Liquid AI prévoit de servir. L’entreprise a testé des conceptions à trois, quatre et cinq couches et a entraîné la configuration retenue pendant 10 époques, indiquant que l’acceptation s’améliorait avec des tokens supplémentaires avant d’atteindre des rendements décroissants.

Les gains rapportés varient selon le matériel et la tâche

Liquid AI a évalué le système sur six charges de travail basées sur la vision à l’aide du benchmark MMSpec. Les tâches comprenaient la question-réponse visuelle générale, la question-réponse visuelle axée sur le texte, la génération de légendes d’images, la question-réponse sur graphiques, le raisonnement complexe et la conversation multi-tours.

Les résultats sur appareil ont été mesurés avec MLX sur un M5 Max et avec llama.cpp sur un M3 Ultra. Liquid AI rapporte que le décodage MLX était de 2,30x à 3,13x plus rapide selon la tâche, tandis que la latence de bout en bout s’améliorait de 1,56x à 2,62x. Avec llama.cpp, les gains de décodage allaient de 1,57x à 2,14x, et la latence de bout en bout s’améliorait de 1,30x à 1,77x.

L’évaluation sur H100 a produit des gains de décodage allant jusqu’à 2,66x et des améliorations de bout en bout allant jusqu’à 2,27x, selon l’entreprise. Le matériel source comprend une valeur de borne inférieure incohérente pour l’intervalle de décodage H100, de sorte que le résultat global doit être considéré comme un maximum rapporté par le fournisseur plutôt que comme une attente uniforme de performance.

Il s’agit des mesures de Liquid AI, et non d’un benchmark indépendant. Elles décrivent également du matériel spécifique, des configurations logicielles, des mélanges de tâches et une taille de bloc DSpark de huit. Les gains réels dépendront du taux d’acceptation des tokens proposés, de la longueur de la requête, de la complexité de l’image, de la quantification, de la taille du lot et de la part de la latence totale consacrée au traitement des images et à l’ingestion de la requête.

Liquid AI affirme que le décodage spéculatif est exact parce que le modèle cible vérifie chaque token proposé. Dans son implémentation, la sortie greedy devrait donc correspondre au modèle cible exécuté sans spéculation. Cette propriété répond à l’une des principales préoccupations de déploiement autour des techniques d’accélération : améliorer la vitesse sans modifier silencieusement le comportement du modèle.

Pourquoi la latence de bout en bout reste la métrique la plus difficile

L’écart signalé entre la vitesse de décodage et la latence totale est important pour les équipes produit. Le décodage spéculatif accélère la génération de tokens, mais il n’accélère pas l’encodeur visuel ni la phase de préremplissage qui traite les tokens d’image et la requête textuelle.

Les modèles vision-langage peuvent passer un temps considérable avant de produire le premier token. Une image est traitée par un encodeur visuel, après quoi le modèle de langage traite des centaines de tokens visuels en même temps que l’entrée textuelle. Sur du matériel en périphérie, le budget de calcul plus faible peut faire de ces étapes une part plus importante du temps de réponse total. Par conséquent, une amélioration triple du décodage ne se traduit pas par une réduction triple de la latence visible par l’utilisateur.

Cette limite est un exemple de la loi d’Amdahl : les parties d’une charge de travail qui restent inchangées plafonnent le gain global. Pour une application telle que le chat avec images, l’analyse de documents ou l’interprétation de graphiques, les équipes devront mesurer séparément le temps jusqu’au premier token et le temps de réponse complet. Un chemin de décodage plus rapide peut être particulièrement précieux pour les réponses longues, les tours répétés ou les flux de travail où la génération de sortie domine une fois l’image déjà encodée.

Les résultats suggèrent également que le choix du matériel façonnera la proposition de valeur. La plage de décodage la plus forte rapportée par Liquid AI provenait d’Apple Silicon, tandis que le H100 offrait des gains plus faibles mais toujours significatifs lors des tests de l’entreprise. Cela rend la publication pertinente à la fois pour l’inférence locale et pour les services alimentés par GPU, mais n’établit pas que chaque déploiement verra la même amélioration.

Les intégrations abaissent la barrière d’essai

LFM2.5-VL-DSpark est disponible via des intégrations pour llama.cpp, MLX-VLM et SGLang. Liquid AI indique que le modèle draft est proposé sur Hugging Face aux formats Safetensors et GGUF, offrant aux développeurs des voies pour des workflows de déploiement natifs et quantifiés.

L’intégration SGLang nécessite une compilation avec prise en charge DSpark pour les cibles LFM2, tandis que llama.cpp et MLX-VLM nécessitent également des versions contenant les changements d’implémentation pertinents. Dans SGLang, les opérateurs rattachent le modèle draft au modèle cible et interrogent un point de terminaison compatible OpenAI. La taille de bloc est lue depuis la configuration du modèle, et le timing de réponse peut révéler combien de tokens draft ont été proposés et acceptés.

Pour les développeurs, ce modèle d’intégration est important car la publication ne nécessite ni de remplacer le modèle vision-langage cible ni de redessiner l’interface applicative. Les équipes peuvent comparer un déploiement de base avec décodage spéculatif en utilisant le même modèle cible et mesurer l’acceptation, la latence, l’utilisation mémoire et l’équivalence des sorties. Les 280 millions de paramètres supplémentaires entraînent toutefois un coût mémoire et de chargement, ce qui peut être important sur des appareils en périphérie plus petits.

Ce qu’il faut surveiller ensuite

Le signal de suivi le plus clair sera un test indépendant de LFM2.5-VL-DSpark sur davantage de tailles d’image, de niveaux de quantification, de tailles de lot et de requêtes de type production. Des résultats indépendants aideraient à établir si les gains rapportés persistent en dehors de l’évaluation de six tâches choisie par Liquid AI.

Les développeurs devraient également surveiller les taux d’acceptation et la latence de bout en bout plutôt que de s’en remettre uniquement aux multiplicateurs de décodage mis en avant. La prise en charge dans llama.cpp, MLX-VLM et SGLang sera importante à suivre à mesure que les implémentations mûrissent, en particulier pour les utilisateurs déployant sur Apple Silicon ou sur du matériel local contraint.

De futures publications DSpark pour d’autres modèles vision-langage pourraient indiquer si l’architecture se généralise au-delà de LFM2.5-VL-3B. À l’inverse, si les gains sont très sensibles à l’architecture du modèle ou à la charge de travail, la méthode pourrait rester une optimisation ciblée plutôt qu’une couche d’inférence largement portable.

Point de vue de Creati.ai

La publication de Liquid AI est une mise à jour pratique de l’inférence plutôt qu’un nouveau modèle de capacités. Sa principale contribution est de montrer comment le décodage spéculatif peut être adapté à une cible multimodale tout en conservant la vérification exacte et en gardant le modèle supplémentaire relativement petit.

L’importance commerciale dépendra de la latence totale perçue par l’utilisateur, et non de la valeur maximale de décodage. Pour les équipes qui exécutent localement des charges de travail vision-langage, la combinaison de poids ouverts, d’intégrations runtime existantes et de gains mesurables pourrait justifier des tests. Mais les acheteurs devraient considérer les affirmations de performance actuelles comme rapportées par le fournisseur et les valider avec leurs propres images, requêtes, matériel et objectifs de latence.