Liquid AI LFM2.5-VL-3B-DSpark accélère le décodage visuel, mais le chiffre de 3,13x ne raconte que la moitié de l’histoire
Liquid AI a lancé LFM2.5-VL-3B-DSpark en annonçant un décodage jusqu’à 3,13x plus rapide pour son modèle compact vision-langage. Cette amélioration concerne la génération de tokens, et non l’ensemble du processus de compréhension d’une image et de production d’une réponse.
Cette distinction définit l’importance de Liquid AI LFM2.5-VL-3B-DSpark. Le modèle de brouillon expérimental montre que le décodage spéculatif peut fonctionner sur des tâches visuelles et textuelles, aussi bien sur du matériel de datacenter que grand public. Toutefois, les propres résultats de Liquid AI situent le meilleur gain de bout en bout à 2,62x, sous le pic annoncé pour le décodage.
Cette sortie pousse les développeurs à reconsidérer leur façon d’optimiser les applications vision-langage locales. La compression des modèles et les architectures plus petites ne sont plus les seuls moyens de réduire la latence. Un modèle de brouillon distinct peut accélérer un modèle cible existant tout en préservant son comportement de sortie avec des paramètres de décodage identiques.
La comparaison ne porte donc pas sur Liquid AI face à un modèle concurrent. Elle oppose le décodage spéculatif à la pratique classique consistant à rendre le modèle vision-langage principal plus petit, plus simple ou moins précis pour gagner en vitesse.
Liquid AI LFM2.5-VL-3B-DSpark ajoute un modèle de brouillon dédié
Cette sortie dissocie la qualité des réponses d’une part importante du problème de latence.
Liquid AI LFM2.5-VL-3B-DSpark est un modèle de brouillon de 279,5 millions de paramètres conçu spécifiquement pour LFM2.5-VL-3B. Il ne remplace pas le modèle cible de 3 milliards de paramètres et ne répond pas aux requêtes de façon autonome. Il propose plutôt plusieurs tokens probables avant que le modèle plus grand ne les vérifie simultanément.
Ce processus s’appelle le décodage spéculatif, une méthode qui utilise un prédicteur plus petit pour préparer des tokens que le modèle cible vérifie en parallèle. Les tokens acceptés réduisent le nombre de passages coûteux du modèle cible nécessaires pour générer une réponse. Les propositions rejetées sont corrigées par la cible.
Liquid AI indique que le modèle de brouillon comprend quatre couches d’attention complète, une tête de Markov et une tête de confiance. Son bloc d’entraînement contient neuf tokens proposés. Le déploiement utilise des blocs de huit ou neuf tokens, selon le matériel et le framework d’inférence.
L’entreprise a publié le modèle aux formats Safetensors et GGUF via son dépôt de modèles. Il prend en charge SGLang sur les GPU Nvidia, MLX-VLM sur Apple silicon et llama.cpp via le checkpoint GGUF.
Cette couverture des frameworks compte, car l’accélération de l’inférence reste souvent limitée à un article de recherche ou à une implémentation personnalisée. Ici, Liquid AI a relié son modèle de brouillon à trois voies de déploiement déjà utilisées pour les serveurs, les Mac et les modèles quantifiés locaux.
SGLang requiert la version 0.5.19 ou une version ultérieure pour la configuration publiée. MLX-VLM requiert la version 0.7.2 ou une version ultérieure et exécute actuellement cette implémentation DSpark avec un échantillonnage glouton. Liquid AI demande aux utilisateurs de MLX de régler la température sur zéro.
Le modèle cible est arrivé avant le modèle de brouillon. Liquid AI a présenté LFM2.5-VL-3B en août 2026 comme un modèle vision-langage à poids ouverts destiné au déploiement en périphérie. Le modèle combine une base linguistique et un encodeur visuel pour les images, les documents, l’ancrage spatial, la reconnaissance optique de caractères et l’utilisation d’outils visuels.
Liquid AI avait auparavant affirmé que la cible pouvait décoder 228 tokens par seconde sur un M5 Max. L’entreprise avait également signalé 116 tokens par seconde sur un Ryzen AI Max+ 395 et 20 sur un Galaxy S26 Ultra. Ces chiffres provenaient des propres tests de l’entreprise.
La sortie de DSpark modifie le package de déploiement plutôt que les capacités apprises du modèle sous-jacent. Les développeurs attachent le modèle de brouillon pendant l’inférence, tandis que LFM2.5-VL-3B reste responsable de l’approbation de chaque token généré.
Avec un décodage glouton, la cible n’accepte un token de brouillon que s’il correspond au token qu’elle aurait elle-même sélectionné. La réponse qui en résulte devrait donc correspondre à une génération gloutonne ordinaire. À des températures non nulles, l’échantillonnage apparié peut préserver la distribution de sortie du modèle cible plutôt qu’une unique séquence déterministe.
Cette propriété confère au décodage spéculatif une proposition de valeur différente de la quantification ou de la distillation. Ces techniques peuvent modifier la précision numérique, la taille du modèle ou son comportement appris. DSpark cherche plutôt à réduire le temps nécessaire pour parvenir aux décisions initiales du modèle cible.
C’est pourquoi cette sortie crée une concurrence significative entre deux voies d’optimisation. Les développeurs peuvent réduire le travail réalisé par le modèle principal, ou prédire une plus grande part de ce travail et vérifier ces prédictions efficacement.
Le résultat de 3,13x dépend du matériel, de la charge de travail et de la mesure
Le chiffre le plus élevé de Liquid AI décrit un résultat de décodage, pas une accélération universelle des applications.
Liquid AI a évalué le modèle de brouillon dans six catégories de MMSpec : questions-réponses visuelles générales, reconnaissance de texte, légendage d’images, analyse de graphiques, raisonnement complexe et conversation à plusieurs tours. L’entreprise a testé une taille de lot de un sur du matériel Apple et un GPU H100.
Sur un M5 Max utilisant MLX-VLM, Liquid AI a rapporté des gains de décodage allant de 2,30x à 3,13x. Les améliorations de bout en bout se situaient entre 1,56x et 2,62x. Le pic de 3,13x a été atteint sur la charge de travail de légendage d’images COCO.
L’entreprise a également testé un M3 Ultra avec llama.cpp. Le décodage a progressé de 1,57x à 2,14x selon les chiffres rapportés, tandis que les performances de bout en bout se sont améliorées de 1,30x à 1,77x.
Sur un unique GPU H100 80GB avec SGLang, Liquid AI a mesuré des gains de décodage compris entre 2,04x et 2,66x. Les améliorations de bout en bout allaient de 1,64x à 2,27x. La publication détaillée des benchmarks de l’entreprise fournit les configurations et les résultats par tâche.
Ces tests utilisaient un traitement 16 bits pour l’encodeur visuel et la base linguistique. La configuration H100 utilisait BF16, un bloc de brouillon de neuf, une taille de lot de un et une température nulle. Les tests Apple utilisaient FP16, un bloc de huit et jusqu’à 2 048 tokens générés.
La longueur médiane des réponses dans l’évaluation Apple était de 90 tokens. Ce détail est important, car la longueur de sortie modifie la part d’une requête consacrée au décodage. Un système produisant une longue description donne au modèle de brouillon davantage de temps pour amortir son surcoût initial.
Les réponses courtes créent un équilibre moins favorable. Si une application renvoie une étiquette, une coordonnée ou une phrase, l’encodage de l’image et le traitement du prompt peuvent dominer. Une génération plus rapide n’affecte alors qu’une plus petite part de l’attente totale.
L’acceptation des brouillons aide à expliquer l’accélération rapportée. Liquid AI a mesuré environ 3,2 à 4,5 tokens acceptés par passage de vérification sur les piles Apple. Ses résultats H100 allaient de 3,46 à 4,57 tokens acceptés.
Une longueur d’acceptation plus élevée signifie que la cible valide davantage de sortie utile lors de chaque passage. Pourtant, l’acceptation ne se traduit pas directement par des gains de vitesse équivalents. L’exécution du modèle de brouillon, la synchronisation, les accès mémoire et les surcoûts du framework consomment encore du temps.
Les résultats varient également selon la tâche. Le légendage d’images a produit le meilleur gain de décodage MLX, tandis que la conversation à plusieurs tours a enregistré 2,30x. Les gains de bout en bout étaient respectivement de 2,59x et 1,91x.
Cette variation empêche d’interpréter de manière responsable « jusqu’à 3,13x » comme un résultat attendu pour chaque assistant visuel. Il s’agit d’un plafond observé dans une configuration publiée. Le résultat d’une application dépendra de son matériel, de la longueur du prompt, de la longueur de sortie, des paramètres d’échantillonnage et de la charge de travail visuelle.
Liquid AI affirme que DSpark a conservé un avantage à plus forte concurrence dans ses tests H100. Toutefois, l’écart s’est réduit à mesure que la concurrence augmentait. Cela suggère que le bénéfice relatif du modèle de brouillon évolue lorsque le GPU passe d’un décodage limité par la mémoire à une exécution limitée par le calcul.
Pour les équipes produit, la question pratique n’est pas de savoir si le chiffre maximal est réel dans le test de Liquid AI. La question est de savoir si leur profil de latence ressemble au test qui l’a produit. Cela exige de mesurer chaque phase d’inférence plutôt que de recopier un multiplicateur accrocheur dans les plans de capacité.
Comment le décodage spéculatif de Liquid AI préserve le modèle cible
DSpark cherche à anticiper davantage sans transformer les erreurs de prédiction en sortie finale.
La génération autorégressive standard produit un token après l’autre. Chaque nouveau token nécessite un nouveau passage du modèle cible, même lorsque la suite est très prévisible. Cette structure sérielle peut laisser le matériel sous-utilisé lors d’un décodage limité par la mémoire.
Le décodage spéculatif insère un modèle plus petit dans cette boucle. Le modèle de brouillon propose un bloc de tokens futurs, puis la cible évalue ces positions simultanément. Du travail est économisé lorsque plusieurs propositions passent la vérification.
Le défi consiste à produire des propositions assez rapidement et assez précisément pour justifier ce modèle supplémentaire. Un modèle de brouillon faible génère des tokens rejetés. Un modèle de brouillon lourd prédit bien, mais consomme trop de temps pour produire son bloc.
DSpark combine une génération parallèle avec une composante séquentielle légère. Sa tête de Markov introduit une dépendance limitée entre les positions proposées, tandis que la tête de confiance estime si les propositions ultérieures doivent être vérifiées. Cette conception vise à préserver la cohérence du bloc sans rendre la préparation entièrement autorégressive.
La recherche DSpark sous-jacente décrit l’approche comme un décodage spéculatif planifié par confiance avec génération semi-autorégressive. Son compromis central concerne la qualité des propositions, la latence de préparation et le nombre de tokens envoyés pour vérification.
La préparation purement parallèle peut générer rapidement un bloc, mais la précision baisse souvent pour les tokens situés plus loin dans ce bloc. Chaque position dépend d’un contexte qui inclut les suppositions précédentes. Les erreurs peuvent donc se cumuler au fil de la proposition.
Un modèle de brouillon entièrement autorégressif maintient des dépendances plus fortes, mais recrée une partie du goulot d’étranglement sériel. La structure hybride de DSpark cherche à occuper un terrain intermédiaire. Elle ajoute une petite tête séquentielle après l’opération de brouillon parallèle.
Le mécanisme de confiance traite une autre source de gaspillage. Vérifier un bloc fixe entier n’a guère de sens lorsque le modèle de brouillon prévoit que ses tokens ultérieurs échoueront. Un ordonnanceur peut raccourcir le préfixe soumis avant que les positions à faible confiance ne consomment la capacité de la cible.
La configuration publiée de LFM2.5-VL-3B-DSpark utilise une tête de Markov de rang 256 et une tête de confiance distincte. Son vocabulaire contient 128 000 tokens. L’architecture reste liée à son modèle cible désigné et ne peut pas servir de modèle de brouillon générique prêt à l’emploi pour chaque VLM.
Cette relation spécifique au modèle est à la fois une force et une limitation. S’entraîner contre une cible donnée peut améliorer l’alignement des propositions. Toutefois, une équipe qui passe à un autre modèle cible a besoin d’un checkpoint compatible, d’un processus d’entraînement et d’une intégration d’exécution adaptés.
La description « sans perte » exige également une interprétation précise. Avec un décodage glouton à température zéro, la vérification préserve les choix exacts de tokens que la cible effectuerait seule. Le modèle de brouillon n’est pas autorisé à substituer une alternative simplement plausible.
À des températures non nulles, l’objectif passe de la reproduction d’une séquence à la préservation de la distribution de la cible. Un échantillonnage spéculatif correct peut y parvenir avec des paramètres appariés, selon la recherche fondatrice sur l’échantillonnage. La vitesse dépend toujours de la fréquence à laquelle les distributions du brouillon et de la cible s’alignent.
Liquid AI indique qu’une hausse de la température a réduit l’acceptation dans ses expériences. La probabilité se répartit davantage vers des tokens moins bien classés, créant plus d’occasions de désaccord entre le modèle de brouillon et la cible. Par conséquent, l’échantillonnage créatif peut offrir des gains plus faibles que la génération déterministe.
Cela a des implications pour la conception des applications. L’extraction de documents, l’ancrage visuel, la lecture de graphiques et les réponses contraintes utilisent souvent de faibles températures. Les conversations ouvertes sur les images peuvent recourir davantage à l’échantillonnage, rendant les résultats gloutons publiés moins représentatifs.
Le décodage spéculatif de Liquid AI convient donc particulièrement aux sorties prévisibles. Le sous-titrage d’images de produits standardisées, la lecture de reçus, la description de captures d’écran d’interfaces et l’extraction de faits structurés constituent des charges de travail plausibles. Les gains réels exigent toutefois des mesures locales.
Un décodage plus rapide ne supprime pas le goulot d’étranglement vision-langage
La principale incertitude concerne la part d’une requête réelle qui reste en dehors de la phase de décodage accélérée.
Une requête vision-langage implique davantage de travail que la génération de texte. Le système doit encoder l’image, la transformer en représentations visuelles, traiter ces jetons visuels avec le prompt, puis décoder la réponse.
DSpark n’accélère que l’étape finale. Il ne rend pas l’encodage des images plus rapide. Il laisse également le préremplissage inchangé, ce qui signifie que le modèle cible traite toujours le prompt et le contexte des jetons visuels avant de produire son premier jeton de réponse.
Cette limite explique l’écart entre les résultats de décodage et les résultats de bout en bout. Liquid AI a signalé un décodage jusqu’à 3,13 fois plus rapide sur le M5 Max, mais son amélioration totale maximale était de 2,62 fois. D’autres tâches ont affiché des écarts plus importants.
Sur TextVQA, l’entreprise a mesuré une amélioration du décodage de 2,69 fois et un gain de bout en bout de 1,56 fois sur le M5 Max. Ce résultat implique que le traitement de l’image et le préremplissage représentaient une part substantielle du temps initial de la requête.
Cette limite découle de la loi d’Amdahl, qui plafonne l’accélération globale lorsqu’une partie de la charge de travail reste inchangée. Si le décodage représente la moitié de la latence de référence, même un décodeur infiniment rapide ne peut pas améliorer l’ensemble de la requête au-delà de 2 fois.
Le matériel edge rend cette contrainte particulièrement pertinente. Les appareils grand public offrent moins de puissance de calcul que les GPU de datacenter pour l’encodage visuel et le préremplissage à long contexte. Une image volumineuse ou un prompt comportant plusieurs images peut retarder le premier jeton avant que le décodage spéculatif ne commence à aider.
Le benchmark indépendant MMSpec renforce la nécessité d’une interprétation prudente. Ses auteurs ont évalué 600 échantillons dans six catégories de tâches et dix méthodes de décodage spéculatif. Ils ont constaté que l’accélération du débit à elle seule ne représentait pas de manière fiable les performances de latence.
MMSpec a également constaté que les techniques conçues pour les modèles de langage textuels peuvent se dégrader dans des contextes multimodaux. Les dépendances intermodales modifient les propositions susceptibles d’être retenues. La prise en compte de la vision devient plus importante à mesure que la taille des lots augmente.
Liquid AI a suivi les catégories de tâches de MMSpec, ce qui améliore l’étendue de son évaluation interne. Toutefois, Liquid AI a elle-même mené et publié les tests de performances de DSpark. Les réplications indépendantes sur des appareils courants et avec des prompts de production restent limitées.
La référence de comparaison mérite une attention égale. Les multiplicateurs publiés comparent le même modèle cible LFM2.5-VL-3B avec et sans son drafter, dans des frameworks spécifiés. Ils n’établissent pas que le système combiné surpasse tous les VLM concurrents.
Ils ne comparent pas non plus le système à d’autres stratégies de latence. Les développeurs peuvent quantifier le modèle cible, réduire la résolution des images, mettre en cache les embeddings visuels, raccourcir les prompts, traiter les requêtes par lots ou sélectionner un modèle plus petit. Ces changements influencent différentes parties du budget de latence.
La mémoire constitue une autre considération opérationnelle. Le drafter est petit face au modèle cible de 3 milliards de paramètres, mais il n’est pas gratuit. Ses poids, son cache, son état d’exécution et son intégration consomment une capacité importante sur les appareils contraints.
La compatibilité crée des frictions supplémentaires. SGLang, MLX-VLM et llama.cpp proposent désormais des voies publiées, mais les équipes utilisant d’autres systèmes de serving ne peuvent pas présumer d’une prise en charge immédiate. L’adoption en production exige un chargement stable, de l’observabilité, un comportement prévisible en traitement par lots et une gestion des défaillances.
Le chemin DSpark actuel de MLX-VLM, limité à la génération gloutonne, réduit ses cas d’usage immédiats. Les applications dépendant de la génération échantillonnée nécessitent une autre stack prise en charge ou doivent attendre une prise en charge plus large de l’échantillonnage. Même dans ce cas, des températures plus élevées peuvent réduire l’acceptation des brouillons.
La publication doit donc être considérée comme une optimisation système crédible, aux limites clairement énoncées. Elle ne prouve pas que l’inférence visuelle est devenue 3,13 fois plus rapide dans tous les sens pertinents.
Le vrai enjeu oppose une meilleure prédiction à moins de travail pour le modèle
DSpark renforce une voie où les développeurs conservent le modèle cible intact et optimisent la fréquence à laquelle il doit s’exécuter.
La réponse classique de l’IA edge à la latence consiste à réduire la charge de travail du modèle cible. Les équipes utilisent moins de paramètres, une précision inférieure, des prompts plus courts, des images plus petites ou une distillation spécifique à la tâche. Chaque technique peut améliorer la réactivité, mais chacune peut introduire des compromis en matière de qualité ou de flexibilité.
Liquid AI LFM2.5-VL-3B-DSpark propose une autre voie. Conserver le modèle cible existant et prédire plusieurs étapes futures avec un compagnon spécialisé. Laisser le modèle cible vérifier ces hypothèses sans renoncer au contrôle de la sortie finale.
Cette voie devient attrayante lorsqu’une équipe accepte déjà les capacités du modèle cible. Le remplacer exigerait de nouvelles évaluations, des modifications de prompts, des vérifications de sécurité et des ajustements produit. Ajouter un drafter peut préserver une plus grande part de cet investissement.
L’approche convient également au déploiement local, où la bande passante mémoire contraint fréquemment la génération de jetons. Vérifier un bloc peut exploiter le matériel plus efficacement que recharger à répétition l’état du modèle pour un seul jeton. Les résultats de Liquid AI sur Apple rendent cette possibilité concrète.
Les modèles plus petits conservent toutefois des avantages. Ils simplifient le packaging, réduisent l’utilisation totale de mémoire et accélèrent des étapes qu’une optimisation limitée au décodeur ne peut pas toucher. Un encodeur visuel compact peut améliorer le délai avant le premier jeton, ce que DSpark ne peut pas faire.
La quantification peut également se combiner au décodage spéculatif plutôt que de lui être exclusivement concurrente. Liquid AI fournit un drafter GGUF associé à sa cible GGUF. Une stack locale peut donc réduire la précision et ajouter le drafting, à condition que le runtime prenne correctement en charge la paire.
Cette combinaison déplace la question d’ingénierie : il ne s’agit plus de choisir une technique, mais d’affecter chaque technique au bon goulot d’étranglement. La quantification réduit la taille des poids et le coût arithmétique. Le prétraitement des images modifie le coût de la vision. La spéculation cible la génération autorégressive.
C’est pourquoi le profilage au niveau des phases devient essentiel. Un assistant documentaire qui analyse des pages haute résolution peut passer l’essentiel de son temps avant le décodage. Un outil de chat visuel produisant des descriptions détaillées peut consacrer bien plus de temps à générer la sortie.
La même distinction s’applique à l’expérience utilisateur. Le délai avant le premier jeton détermine si une application semble réactive au démarrage. Le nombre de jetons par seconde détermine si une longue réponse paraît fluide une fois la génération commencée.
DSpark améliore directement la seconde mesure. Il améliore la latence totale lorsque le décodage occupe une part suffisante de la requête. Il ne garantit pas une amélioration proportionnelle de la première.
Les développeurs doivent également distinguer la vitesse pour un utilisateur unique du débit à l’échelle d’une flotte. Liquid AI a observé un avantage à tous les niveaux de concurrence H100 mesurés, mais l’écart s’est réduit sous une charge plus élevée. L’économie de production dépend des mélanges de requêtes, du traitement par lots et des objectifs de niveau de service.
L’aspect le plus conséquent de cette publication est donc architectural. Liquid AI a intégré le décodage spéculatif dans une famille de modèles vision plutôt que de le présenter uniquement comme une recherche.
Si cette tendance se propage, les publications de modèles pourraient de plus en plus inclure une cible, plusieurs quantifications et des drafters spécifiques au matériel. L’optimisation de l’inférence deviendrait une partie de l’artefact du modèle plutôt qu’une décision de serving prise après coup.
Cette orientation met la pression sur les autres développeurs de modèles à poids ouverts. Publier uniquement un checkpoint laisse aux équipes en aval la responsabilité de l’accélération. Fournir un drafter associé offre une histoire de latence plus complète, même lorsque les gains mesurés restent dépendants de la charge de travail.
Trois signaux montreront si l’accélération compte en pratique
Les tests indépendants, une prise en charge plus large de l’échantillonnage et les profils d’applications réelles détermineront si DSpark devient un modèle de déploiement reproductible.
Le premier signal est la réplication indépendante sur du matériel accessible. Les développeurs devraient surveiller les tests sur les Mac M-series, les GPU grand public et les systèmes edge utilisant des prompts identiques avec et sans le drafter.
Les rapports utiles doivent indiquer les dimensions des images, la longueur du prompt, la longueur de sortie, la température, la quantification et la version du runtime. Un seul chiffre de jetons par seconde ne peut pas expliquer si la réponse complète de l’application est devenue sensiblement plus rapide.
Une réplication proche des plages rapportées par Liquid AI renforcerait le dossier de l’entreprise. Des gains plus faibles ou incohérents suggéreraient que les charges de travail publiées favorisent davantage le drafter que les applications quotidiennes.
Le deuxième signal est une prise en charge plus large des runtimes et de l’échantillonnage. MLX-VLM limite actuellement le chemin DSpark publié à la génération gloutonne, tandis que SGLang cible le déploiement Nvidia et llama.cpp couvre les cas d’usage GGUF.
La prise en charge dans d’autres moteurs d’inférence réduirait le coût d’intégration. Un échantillonnage stable à température non nulle rendrait également la méthode plus pertinente pour le chat visuel et les outils de description créative.
Les développeurs devraient examiner les taux d’acceptation à mesure que l’échantillonnage évolue. Liquid AI indique que des températures plus élevées ont réduit l’acceptation et le débit dans ses expériences. Les tests de production devraient révéler si ces baisses restent acceptables pour les produits conversationnels.
Le troisième signal est de savoir si les équipes rapportent des gains par phase issus d’applications réelles. Les métriques décisives sont le délai avant le premier jeton, le taux de décodage, la latence de bout en bout, le pic de mémoire et le débit sous la concurrence attendue.
Un assistant visuel de longue durée peut bénéficier de manière substantielle, car la génération domine sa session. Un flux OCR renvoyant quelques champs peut gagner bien moins, car l’encodage visuel et le préremplissage occupent la majeure partie de la requête.
Les équipes évaluant Liquid AI LFM2.5-VL-3B-DSpark devraient commencer par des traces, et non par des multiplicateurs de titres. Mesurez la part de référence consommée par l’encodage des images, le préremplissage et le décodage. Ajoutez ensuite le drafter et répétez la même charge de travail.
Vérifiez l’équivalence des sorties sous décodage glouton et le comportement distributionnel sous échantillonnage pris en charge. Mesurez séparément les démarrages à chaud et à froid. Incluez la pression mémoire et les performances thermiques soutenues lors des tests sur des ordinateurs portables ou des systèmes de classe mobile.
La publication fournit suffisamment de détails d’implémentation pour rendre ces évaluations possibles. Elle rappelle également utilement aux développeurs que la capacité du modèle et le comportement de l’inférence sont deux problèmes d’ingénierie distincts.
Le chiffre de 3,13 fois de Liquid AI se comprend le mieux comme la preuve qu’un drafter associé peut accélérer sensiblement une phase de l’inférence multimodale locale. Les chiffres de bout en bout montrent à la fois la valeur et la limite de cette affirmation.
Les modèles de brouillon associés deviendront-ils des compagnons standard pour les VLM à poids ouverts, ou resteront-ils des optimisations spécialisées pour les charges de travail à sortie longue ? La réponse viendra de traces d’applications reproductibles, et non d’un seul benchmark de pointe.
