LFM2.5-VL-3B-DSpark : le Drafter de 279,5 M de Liquid AI livré six jours avant que quiconque ne l'annonce

Il existe une version de cette histoire où LFM2.5-VL-3B-DSpark est un nouveau modèle. Ce n'est pas le cas. C'est un modèle draft de décodage spéculatif de 279,5 millions de paramètres qui n'existe que dans un seul but — accélérer le décodage du modèle vision-langage LFM2.5-VL-3B de Liquid AI — et il est incapable de générer une réponse exploitable par lui-même. Si cela vaut quand même la peine d'en lire davantage, c'est à cause de la chronologie : les poids sont arrivés sur Hugging Face le 18 septembre 2026, sans la moindre annonce, y sont restés six jours, et n'ont eu droit à un article de blog du fournisseur que le 24 septembre. Radar a repéré le dépôt dans l'intervalle.

Cet écart est aussi la frontière de ce qu’il est possible de savoir pour l’instant. Tout ce qui se trouve dans le dépôt — la décomposition des paramètres, la taille de bloc, les intégrations de frameworks, la licence — est un fichier sur disque que vous ou moi pouvons ouvrir. Chaque chiffre d’accélération est mesuré par le fournisseur, à partir du propre harnais de benchmark de Liquid, et personne en dehors de l’entreprise n’a publié de reproduction. Cet article garde ces deux piles séparées à dessein.

Ce que le dépôt contient réellement

Ouvrez la fiche du modèle et la nature de la chose ne laisse aucune ambiguïté. LFM2.5-VL-3B-DSpark est un modèle brouillon dont la cible est fixée dans ses métadonnées : base_model: LiquidAI/LFM2.5-VL-3B. Vous ne le pointez pas vers un autre modèle et vous ne le servez pas seul.

• Paramètres totaux du brouillon — 279,5 M, BF16, dont 193,0 M pour la pile de décodeurs à 4 couches, 65,5 M pour une tête de Markov, 21,0 M pour une projection d’état caché, et 6,4 k pour les normes plus une tête de confiance

• Backbone — 4 couches d’attention complètes, taille cachée 2 048, taille intermédiaire 6 144 avec SiLU/SwiGLU, attention à requêtes groupées avec 32 têtes d’attention et 8 têtes clé-valeur, dimension de tête 64

• Têtes supplémentaires — une tête de Markov au rang 256 et une tête de confiance, ce qui distingue le drafting DSpark d'un simple drafter parallèle

• Taille de bloc — 9 pendant l’entraînement ; 8 ou 9 à l’inférence selon le matériel, et 8 spécifiquement sur Apple silicon

• Vocabulaire — 128 000, rattaché à la cible plutôt que porté par le brouillon

• Poids dans la pile déployée — Liquid déclare que le drafter augmente le nombre de paramètres déployés de 8,9 %

Le 8,9 % est le chiffre à retenir. L’argument de vente pour cette classe de modèles n’est jamais « une inférence plus rapide est gratuite » ; c’est « une inférence plus rapide vous coûte environ l’équivalent d’un dixième d’un modèle en mémoire ». Avec 279,5 M de paramètres supplémentaires en plus d’une cible de 3,1 B, il s’agit d’une taxe plus faible que ne le suggérerait la taille du seul modèle de draft, car l’embedding et la tête LM sont liés à la cible et ne sont pas dupliqués.

DSpark est une technique DeepSeek avant d'être un modèle Liquid.

L'appellation prête à confusion, il vaut donc mieux être précis. DSpark n'est pas une invention de Liquid AI, ni une famille de modèles. C'est un cadre de décodage spéculatif issu d'une ligne de recherche distincte, décrit dans un article de juillet 2026 comme un décodage spéculatif à planification selon la confiance avec génération semi-autorégressive. Ses trois idées : un backbone parallèle qui produit une ébauche de tout un bloc en une seule passe avant, un module séquentiel léger qui restaure une certaine dépendance entre les jetons de brouillon voisins afin que l'acceptation ne s'effondre pas à la fin du bloc, et un vérificateur qui raccourcit la fenêtre de vérification par requête lorsque la confiance du brouillon lui-même suggère que la fin sera rejetée.

Ce que Liquid a fait, c’est appliquer cette recette aux modèles vision-langage et livrer un checkpoint. La fiche est franche sur le fait que ce transfert est moins spectaculaire qu’il n’y paraît : du point de vue du drafter, la modalité importe peu, car au moment où les tokens atteignent les couches cachées, un patch d’image et un token de texte ne sont plus que des tenseurs. C’est pourquoi une technique mise au point sur des modèles de texte s’adapte à un VLM sans être réinventée — et c’est aussi pourquoi le drafter ne peut pas être vendu comme une nouvelle capacité.

Liquid avait déjà livré des drafters texte DSpark — les compagnons 2,6B, 8B-A1B et 1,2B-Instruct sont sortis en août 2026, avec les exports GGUF qui ont suivi le 19 août. Le drafter vision est la même idée étendue à la branche multimodale, et la quatrième ou cinquième entrée d'une lignée, pas une première.

Les chiffres d'accélération, et qui les a mesurés

Chacun des chiffres ci-dessous est propre à Liquid, recueilli sur l’infrastructure d’évaluation de performance de Liquid, et aucun n’a fait l’objet d’une reproduction indépendante. Considérez-les comme un plafond annoncé par le fournisseur, et non comme un résultat attendu. La fiche distingue l’accélération du décodage de l’accélération de bout en bout, ce qui compte davantage que le chiffre phare.

• Meilleure accélération du décodage — 3,13× sur COCO, mesurée avec MLX-VLM sur un Apple M5 Max avec une taille de bloc de 8, FP16, une taille de lot de 1, température 0

• Meilleure accélération du décodage GPU — 2,66× sur COCO, SGLang sur un seul H100 80GB, BF16, taille de bloc 9

• Meilleure accélération du décodage llama.cpp — 2,14× sur COCO, Apple M3 Ultra, taille de bloc 8

• Plage de décodage H100 sur six tâches de vision — de 2,04× à 2,66×, avec une plage de bout en bout de 1,64× à 2,27×

• Plage de décodage M5 Max — 2,30× à 3,13×, de bout en bout 1,56× à 2,62×

• Plage de décodage du M3 Ultra — 1,57× à 2,14×, de bout en bout 1,30× à 1,77×

• Acceptation des brouillons — environ 3,2 à 4,5 jetons acceptés par passe de vérification de la cible, sur les trois stacks

Le schéma dans ces plages est la partie honnête. Les gains de bout en bout constituent systématiquement la moitié la plus petite de chaque paire, car le drafter n’accélère que le décodage. Notez aussi que le même drafter, à taille de bloc identique, atteint 3,13× sur une stack et 1,57× sur une autre — le taux d’acceptation est une propriété du drafter et de la charge de travail, mais le gain en temps mural est une propriété du matériel et de la surcharge de l’environnement d’exécution. Une affirmation « 2,66× plus rapide » sans stack associée n’est pas une affirmation sur laquelle on peut agir.

Deux points de justesse issus de la fiche méritent d’être énoncés clairement, car ce sont eux qui rendent un drafter acceptable en production tout court. En décodage glouton, le décodage spéculatif est exact : la cible vérifie chaque token proposé, donc le texte est celui que la cible aurait produit seule. Avec des paramètres d’échantillonnage appariés à une température non nulle, il préserve la distribution de sortie de la cible. La formulation de Liquid — vous obtenez l’accélération, pas un modèle différent — est exacte dans la mesure où elle va, et la fiche reconnaît honnêtement qu’augmenter la température réduit le taux d’acceptation et érode donc le gain de débit.

Ce que le propre post de Liquid admet

L'article de blog du 24 septembre est plus utile que la fiche de modèle pour une raison : il nomme la limite. L'inférence vision-langage paie un coût de préremplissage que l'inférence texte ne paie pas — l'image doit passer par un encodeur visuel, puis le backbone linguistique doit traiter les centaines de tokens visuels que produit cet encodeur. Sur un appareil, ce préremplissage domine 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. Liquid invoque la loi d'Amdahl contre son propre produit et souligne que, lorsque le préremplissage représente une part importante du temps d'horloge, une forte accélération du décodage n'apporte qu'une amélioration modeste de bout en bout.

C’est une véritable contrainte pour la décision d’achat, et cela explique pourquoi le temps jusqu’au premier token ne figure pas parmi les éléments que ce modèle de rédaction améliore. Cela implique aussi que les charges de travail qui en bénéficient le plus sont celles qui génèrent de longues sorties à partir d’une image modeste — une légende, une longue transcription OCR, une conversation à plusieurs tours avec une image conservée d’un tour à l’autre — plutôt que celles qui répondent à une question courte sur une grande image.

L’article ajoute deux autres limites de périmètre. Tous les chiffres utilisent un traitement en 16 bits, à la fois pour l’encodeur visuel et pour le backbone linguistique, et l’accélération des modèles quantifiés est hors du périmètre de cette version. Étant donné que tout l’argument de vente d’un VLM edge de 3B est de tourner dans quelques gigaoctets, « les accélérations sont mesurées en FP16 » est une mise en garde importante pour quiconque prévoyait de l’associer à une exportation en 4 bits. Liquid note aussi que le drafter a été entraîné entièrement sur du matériel AMD.

En train de l'exécuter.

La prise en charge dès le premier jour est bien réelle et couvre trois runtimes, ce qui est plus que ce dont bénéficient la plupart des drafters. SGLang sur NVIDIA exige la v0.5.19 ou une version ultérieure et fait passer le drafter par --speculative-algorithm DSPARK avec le chemin de draft et une taille de bloc de 9. MLX-VLM sur Apple silicon exige la v0.7.2 ou une version ultérieure et détecte le drafter lorsqu'il lui est passé avec --draft-model ; il y a un point délicat — le décodage DSpark dans MLX-VLM utilise actuellement un échantillonnage glouton, la température doit donc être réglée sur 0. Pour llama.cpp, il existe un dépôt GGUF distinct, avec un unique export F16 d'environ 567 Mo, et la fiche précise explicitement qu'il faut associer le drafter quantifié à la cible quantifiée plutôt qu'au checkpoint safetensors d'origine.

Si une couche de routage mérite sa place ici, ce n'est pas sur ce modèle — OrcaRouter ne route pas LFM2.5-VL-3B-DSpark ni LFM2.5-VL-3B, et il s'agit d'un appariement de drafter auto-hébergé que vous téléchargez et servez vous-même. C'est sur le reste de la pile qui l'entoure. La même application qui exécute un petit modèle de vision à poids ouverts en local dispose généralement d'un chemin de repli pour les requêtes que le petit modèle ne peut pas traiter, et diriger ce chemin vers un point de terminaison unique couvrant plus de 200 modèles — facturé au prix catalogue de chaque fournisseur, sans marge ajoutée, avec basculement automatique lorsqu'un fournisseur se dégrade — représente une intégration plus légère que la mise en place d'un second contrat fournisseur. Le drafter améliore une branche de cette architecture ; le routeur est ce qui empêche l'autre branche de devenir un second projet.

Ce qui n'est pas encore connu

Le dépôt compte 37 téléchargements et 6 likes au moment de la rédaction. Il n'existe aucune entrée pour ce drafter sur aucun agrégateur public de benchmarks, aucune reproduction par un tiers de l'une des plages d'accélération, et aucune mesure indépendante du taux d'acceptation sur du matériel que Liquid n'a pas testé. Il n'y a pas non plus de benchmarks de qualité sur la fiche pour des raisons évidentes — le drafter préserve la sortie par construction, donc les chiffres de qualité reviennent à LFM2.5-VL-3B, et la fiche renvoie aux benchmarks de ce modèle plutôt que d'inventer les siens.

Un détail dans les métadonnées donne un petit indice sur la nouveauté de la chose : le modèle porte une étiquette de bibliothèque SGLang et un indicateur d’algorithme SGLang qui existe spécifiquement pour l’invoquer. Le support du framework a dû être intégré avant l’annonce, ce qui est cohérent avec l’écart de six jours entre le dépôt et l’article de blog.

Donc : un véritable travail d’ingénierie, utile et au périmètre restreint, annoncé une semaine après sa sortie, dont toute la proposition de valeur réside dans un chiffre mesuré par le fournisseur sur un matériel que vous ne possédez peut-être pas. Si vous servez LFM2.5-VL-3B sur un H100 ou un Mac de la série M et que votre charge de travail est dominée par le décodage, le coût mémoire est de 8,9 % et l’inconvénient est proche de zéro, car la sortie est démontrablement celle de la cible. Si votre latence est dominée par le préremplissage, ou si vous comptiez sur l’export 4 bits, le propre article de Liquid vous indique que cela n’aidera pas. La reproduction, quand elle viendra, est ce qu’il faut attendre.

OrcaRouter place plus de 200 modèles derrière une seule clé, au prix catalogue du fournisseur et avec 0 % de marge, et exprime le chemin de repli comme une couche de routage plutôt que du code applicatif. Le drafteur est auto-hébergé dans un cas comme dans l'autre — c'est le routeur qui empêche le segment auquel votre petit modèle passe le relais de devenir un second projet.