LFM2.5-VL-3B-DSpark vs LFM2.5-VL-3B : On ne choisit pas l'un, on en attache un

La recherche qui amène les gens ici est une comparaison, mais la réponse honnête est que LFM2.5-VL-3B-DSpark et LFM2.5-VL-3B ne sont pas deux choses entre lesquelles choisir. Le second est un modèle vision-langage de 3,1 milliards de paramètres que vous pouvez télécharger et servir. Le premier est un modèle draft de 279,5 millions de paramètres qui n’existe que pour se placer devant le second et accélérer son décodage. Retirez le modèle draft de la pile et il ne produit rien ; vous ne pouvez pas l’évaluer seul, car « seul » n’est pas une configuration qu’il prend en charge. La vraie comparaison est LFM2.5-VL-3B exécuté seul contre le même modèle exécuté avec le modèle draft attaché.

Lu de cette façon, la décision se réduit à une seule question : la mémoire supplémentaire et la complexité d’exécution supplémentaire vous font-elles gagner suffisamment en latence pour que cela compte dans votre charge de travail ? Les propres chiffres de Liquid AI disent oui pour les travaux à forte intensité de décodage et disent explicitement non lorsque le préremplissage domine. Aucun de ces deux constats n’a été reproduit en dehors de l’entreprise.

Les deux points de contrôle, côte à côte

Ce qui les distingue, c’est toute l’histoire, il vaut donc la peine de mettre les deux dépôts côte à côte avant que le débat sur la vitesse ne commence.

• Rôle — LFM2.5-VL-3B génère du texte et répond à propos d'images ; LFM2.5-VL-3B-DSpark lui propose des tokens à vérifier et ne génère rien d'utilisable par lui-même

• Paramètres — 3,1 B pour le modèle cible, 279,5 M en BF16 pour le modèle de draft, ce que Liquid estime représenter une augmentation de 8,9 % du nombre de paramètres déployés

Architecture — la cible est un modèle hybride construit sur un backbone LFM2.5-2.6B avec un encodeur visuel SigLIP2 NaFlex ; le modèle brouillon est constitué de 4 couches d’attention complètes d’une dimension cachée de 2 048 avec attention à requêtes groupées, plus une tête de Markov et une tête de confiance.

• Fenêtre de contexte — 32 768 jetons pour la cible ; le rédacteur ne dispose d’aucun contexte propre et hérite de celui de la cible

• Encodeur de vision — SigLIP2 NaFlex 400M sur la cible ; le drafter n'en possède aucun et ne voit jamais l'image directement

• Vocabulaire — 128 000, et l'embedding du drafter et la tête LM sont liés à la cible plutôt que dupliqués, c'est pourquoi le coût mémoire est plus faible que ne le laisseraient supposer 279,5 M de paramètres

• Licence — les deux sont distribués sous la licence LFM1.0 de Liquid, laquelle est répertoriée comme « other » sur Hugging Face plutôt que comme une licence OSI, donc lisez les conditions avant tout déploiement commercial.

• Formats — le modèle cible est fourni en quantifications safetensors, GGUF, ONNX et MLX ; le modèle de draft est fourni en safetensors et un seul GGUF F16 d'environ 567 Mo

Une ligne de cette liste mérite d’être soulignée, car c’est la raison mécanique pour laquelle ce couplage fonctionne tout court : le générateur de brouillons n’est pas un petit modèle de vision. Il n’a pas d’encodeur visuel et ne touche jamais à l’image. Au moment où les tokens atteignent les couches cachées à partir desquelles il génère ses brouillons, un patch d’image et un token de texte ne sont plus que des tenseurs, si bien que la modalité est invisible pour le calcul de génération des brouillons. C’est ce qui a permis à Liquid de transposer sur un VLM une technique développée pour des modèles de texte sans la reconcevoir.

Ce que le rédacteur modifie, et ce qu’il laisse inchangé

Le modèle cible ne change pas. Ce n'est pas du marketing — c'est la propriété de correction du décodage spéculatif. En décodage glouton, chaque token de brouillon est vérifié par la cible, donc la sortie est exactement ce que la cible aurait produit seule. Avec des paramètres d'échantillonnage appariés à une température non nulle, la distribution de sortie correspond à celle de la cible. Le modèle de draft échange de la mémoire contre du temps et ne touche à rien d'autre.

Ce qui signifie que chaque chiffre de qualité que vous pouvez trouver pour LFM2.5-VL-3B s'applique sans modification à la configuration appariée. Selon l'évaluation propre à Liquid, le modèle cible obtient 80,7 sur ScreenSpot-v2, 61,5 sur BLINK, 58,3 sur MuirBench, 73,1 sur MME, 63,3 sur MMStar, 81,3 sur ChartQA et 88,7 sur POPE — tous rapportés par le fournisseur, aucun reproduit indépendamment, et tous tout aussi vrais, que le modèle de brouillon soit attaché ou non. Il n'y a ici aucun compromis qualité-vitesse à mettre en balance, et toute page de comparaison qui en présente un a mal interprété le modèle.

Ce qui change, en revanche, c’est le coût d’un token en temps réel écoulé. Liquid mesure des accélérations de décodage de 2,04× à 2,66× sur un seul H100 en BF16 via SGLang avec une taille de bloc de 9, de 2,30× à 3,13× sur un Apple M5 Max via MLX-VLM avec une taille de bloc de 8, et de 1,57× à 2,14× sur un M3 Ultra via llama.cpp. De bout en bout, les mêmes exécutions se situent respectivement à 1,64×–2,27×, 1,56×–2,62× et 1,30×–1,77×. Ces paires constituent tout l’argument : l’amélioration du décodage est environ deux fois plus importante que celle obtenue de bout en bout, et l’écart correspond à la partie de la charge de travail sur laquelle le drafter ne peut pas intervenir.

Le problème de préremplissage, tel qu’énoncé par le fournisseur

La phrase la plus utile dans l’annonce de Liquid elle-même est celle qui argumente contre une lecture illimitée de son titre. L’inférence vision-langage paie un coût de préremplissage que l’inférence textuelle ne paie pas : l’image passe par un encodeur visuel, puis le réseau linguistique principal traite les centaines de jetons visuels que cet encodeur émet. Sur un appareil en périphérie, ce préremplissage représente une grande part de la latence de bout en bout. Le décodage spéculatif n’accélère que le décodage — l’encodage visuel et le préremplissage restent inchangés. Lorsque le préremplissage domine, une accélération du décodage de 3× se traduit par un gain de bout en bout bien plus faible.

C'est la loi d'Amdahl appliquée par le fournisseur à son propre produit, et cela devrait déterminer qui lit cette page. Une longue transcription d'une seule page numérisée, une légende, une conversation à plusieurs tours qui transporte une image d'un tour à l'autre — à forte intensité de décodage — et le drafter justifie ses 279,5 M paramètres. Une question courte sur une grande image haute résolution — à forte intensité de préremplissage — et il ne les justifie pas. Placez la même cible sur un serveur à forte concurrence et la donne change encore : Liquid mesure une frontière débit-interactivité plutôt qu'un chiffre unique, et rapporte que DSpark conserve son avantage à chaque niveau de concurrence testé, tandis que l'écart se réduit à mesure que la concurrence augmente.

Deux notes de cadrage plus brèves issues de la même source. Toutes les mesures utilisent un traitement en 16 bits pour l’encodeur visuel comme pour le backbone linguistique, et l’accélération des modèles quantifiés ne fait pas partie du périmètre de la version. Si votre plan était d’associer un export cible en 4 bits au modèle de draft parce que tout l’intérêt d’un VLM 3B est de tenir dans quelques gigaoctets, cette combinaison n’est pas ce qui a été mesuré.

Ce que cela vous coûte réellement de l'attacher

La mémoire est le coût visible et la fiche le quantifie : 8,9 % de paramètres en plus dans la pile déployée. La complexité d'exécution est le coût invisible. SGLang nécessite la v0.5.19 ou une version plus récente et une ligne de lancement comportant --speculative-algorithm DSPARK, le chemin du modèle draft et une taille de bloc ; l'exemple de la fiche désactive aussi le cache radix et fixe une fraction de mémoire statique, qui sont des décisions de service que vous devez désormais prendre en compte. MLX-VLM nécessite la v0.7.2 ou une version plus récente et fait passer le drafter par --draft-model, mais le décodage DSpark y utilise actuellement un échantillonnage glouton, donc la température doit être forcée à 0 — une contrainte réelle si votre application repose sur la diversité d'échantillonnage. llama.cpp fonctionne via le drafter GGUF associé à la cible GGUF, et non avec le checkpoint safetensors d'origine.

Il y a un coût supplémentaire qui apparaît en production plutôt que dans un benchmark : le modèle de brouillon et le modèle cible doivent voyager ensemble. Un décalage de version entre eux est un mode de défaillance qui n'existe pas dans un déploiement à modèle unique, et déployer progressivement l'un ou l'autre indépendamment est désormais un problème à deux artefacts.

Il s'agit d'un appairage auto-hébergé. OrcaRouter ne route pas LFM2.5-VL-3B ni son drafter — vous téléchargez les deux et les servez vous-même —, la question du routage porte donc sur tout ce à quoi le petit modèle délègue. La plupart des déploiements qui associent un VLM edge 3B au drafter ont encore des requêtes auxquelles le petit modèle ne devrait pas répondre, et les envoyer vers un point de terminaison unique couvrant plus de 200 modèles au prix catalogue de chaque fournisseur, avec basculement automatique en cas de dégradation d'un fournisseur, c'est une seule intégration au lieu d'une par fournisseur. Cela signifie aussi qu'au moment où un fournisseur baisse un prix, votre tarif le reflète le jour même plutôt qu'à la prochaine renégociation de contrat.

Lequel télécharger ?

Si votre charge de travail est dominée par le décodage et que votre matériel fait partie des trois testés par Liquid, associez le modèle de brouillon — l'inconvénient est limité, car la sortie est, de façon prouvable, celle du modèle cible et le coût mémoire est inférieur à un dixième de celui d'un modèle. Si votre latence est dominée par le préremplissage, ou si vous exécutez un modèle cible quantifié, ou si vous dépendez d'un échantillonnage non glouton dans un environnement d'exécution qui n'a pas levé cette restriction, exécutez LFM2.5-VL-3B seul. Il est rapide en soi : 228 jetons par seconde sur un M5 Max, 116 sur un AMD Ryzen AI Max+ 395, et 20 sur un Galaxy S26 Ultra, tous des chiffres fournis par les constructeurs, pour environ 3 Go de mémoire.

Ce que personne ne peut encore vous dire, c'est si les chiffres de Liquid tiennent sur votre matériel. Le drafter comptait 37 téléchargements sur Hugging Face au moment de la rédaction, et aucune reproduction indépendante d'un quelconque chiffre de ses tableaux. L'ingénierie est solide et l'argument de correction est une preuve plutôt qu'une affirmation, mais l'ordre de grandeur est une mesure — et des mesures issues d'un seul labo sur un seul ensemble de machines sont exactement le genre de chiffre qu'il faut vérifier soi-même avant de les intégrer à un plan de capacité.

OrcaRouter donne accès à plus de 200 modèles via une seule clé, avec le prix catalogue de chaque fournisseur répercuté directement à 0 % de marge et un basculement automatique entre fournisseurs. prix catalogue du fournisseur répercuté à 0 % de marge L'association présentée sur cette page est auto-hébergée dans les deux cas - le routeur sert à tout ce que le petit modèle délègue, et cela signifie qu'une baisse de prix d'un fournisseur apparaît dans votre tarif le jour même.