LFM2.5-VL-DSpark : comment traiter le drafter vision de Liquid AI comme un sidecar vérifié, et non comme un second modèle

Ce que Liquid AI a réellement publié : un sidecar drafter vision pour LFM2.5-VL-3B

Liquid AI a publié son drafter vision expérimental LFM2.5-VL-DSpark le 24 septembre 2026. Il est facile à mal interpréter. Le petit artefact DSpark ressemble à quelque chose qu’une équipe pourrait déployer à côté, ou peut-être à la place, d’un plus grand modèle vision-langage. Cette lecture est mauvaise. La question utile n’est pas : quelle est la vitesse du petit modèle ? La question utile est de savoir si la cible, le sidecar, le projecteur, le runtime, le point de lecture, la logique de vérification et le chemin de retour arrière sont assez étroitement appariés pour que la cible ait produit la même réponse.

Liquid AI décrit LFM2.5-VL-DSpark comme un drafter expérimental pour LiquidAI/LFM2.5-VL-3B. Le drafter compte environ 279,5 M de paramètres BF16, possède quatre couches d’attention et utilise des têtes Markov et de confiance. Il lit les états cachés de la cible à des couches de lecture fixes après l’entrée des images et du texte dans la représentation partagée. En termes simples, ce n’est pas un modèle vision-langage autonome. Ce n’est pas un remplacement compressé de LFM2.5-VL-3B. Ce n’est pas un raccourci qui contourne l’encodeur de vision. C’est un sidecar de décodage spéculatif, utile seulement lorsque la cible inchangée vérifie les jetons proposés.

Cette distinction semble tatillonne jusqu’à ce qu’elle casse un déploiement. Une équipe peut associer le mauvais sidecar, copier un exemple de modèle texte, servir le drafter seul ou mesurer la latence avant de vérifier si les sorties greedy correspondent encore au chemin cible. Aucun de ces échecs ne serait exotique. Ce sont exactement les erreurs qui se produisent lorsqu’une sortie est traitée comme un bouton de vitesse plutôt que comme un contrat.

Si vous évaluez encore le modèle de base, le précédent test d’acceptation de vision locale LFM2.5-VL-3B d’Optijara est le contexte parent. Cet article est plus étroit. Il traite de DSpark comme sidecar vérifié. Pour les équipes qui travaillent déjà avec des artefacts locaux quantifiés, le guide Optijara du chemin packed Transformers GGUF llama.cpp explique aussi pourquoi un nom de fichier plausible ne suffit pas.

Le contrat d’exécution DSpark : rédiger, vérifier, revenir en arrière, puis accepter les jetons

Dans une configuration DSpark vision correcte, l’image et le prompt entrent toujours dans le chemin vision-langage cible. La cible reste responsable du processeur, du tokenizer, du modèle de prompt, du projecteur de vision, du backbone de langage et de la vérification finale. DSpark lit les informations d’état caché aux points de lecture pris en charge et propose des jetons candidats. La cible vérifie ces propositions. Les jetons acceptés avancent. Les propositions rejetées nécessitent un retour arrière du cache afin que le système revienne à un état cohérent avec la cible.

Le point de lecture est la frontière qui compte. Un drafter entraîné à lire un état interne ne peut pas être inséré dans un chemin de modèle arbitraire avec l’attente qu’il préserve le comportement. Le checkpoint cible, le projecteur, la couche de lecture, les hypothèses d’embedding partagé ou de tête LM, et l’implémentation du runtime déterminent tous si les jetons rédigés ont du sens.

La vérification est la protection. Pour le décodage greedy dans des conditions appariées, le décodage spéculatif est conçu pour préserver la sortie cible tout en réduisant les étapes coûteuses de la cible. Cette idée algorithmique est utile. Elle n’est pas non plus une garantie sur tous les backends. Les différences de noyaux, la précision, le prétraitement des images, les modèles de prompt, les révisions de runtime et les implémentations d’échantillonnage peuvent encore créer des divergences. La discussion de la PR vision SGLang signale des différences de jetons de sortie dans un contexte de test en raison de différences numériques liées à la forme de vérification. Traitez cela comme une invitation à tester soigneusement, pas comme une raison de rejeter la sortie.

Les gains ont aussi une forme. DSpark ne supprime pas le prétraitement des images ni le prefill de vision. Il peut aider lorsque suffisamment de jetons de décodage sont acceptés pour compenser le coût de la rédaction, du batching de vérification, des propositions rejetées et du trafic de cache. C’est lié au minutage des étapes, mais ce n’est pas le même problème que la cartographie des temps d’encodage et de décodage avec OpenVINO GenAI.

Cadre original : la carte de compatibilité draft-cible

Le cadre recommandé par Optijara pour cette sortie est la carte de compatibilité draft-cible. Remplissez-la avant de chronométrer DSpark. Si une ligne est inconnue, le benchmark n’est pas encore fiable.

Pour GGUF, préférez la paire VL officielle actuelle : LiquidAI/LFM2.5-VL-3B-GGUF:F16 avec LiquidAI/LFM2.5-VL-3B-DSpark-GGUF:F16, en utilisant les flags de draft DSpark décrits sur la fiche du modèle. Évitez les commandes génériques du Hub qui impliquent que le drafter peut être servi seul. Évitez aussi de copier un exemple de drafter texte dans une sortie vision. Un sidecar DSpark texte et une cible VL ne sont pas interchangeables simplement parce que les noms se ressemblent.

La prise en charge du runtime mérite le même scepticisme. La fiche du modèle DSpark mentionne la prise en charge de versions SGLang et la prise en charge MLX-VLM, mais les équipes doivent vérifier que le build installé contient la capacité vision pertinente, et pas seulement la chaîne de version. La PR vision SGLang expose l’accès à la tête LM du modèle de langage imbriqué et la prise en charge de la couche de capture. La PR MLX-VLM connecte les lectures d’état caché de style DSpark, la vérification spéculative et le retour arrière du cache d’état convolutionnel. La PR llama.cpp traite de l’architecture du vocabulaire cible et du double réordonnancement RoPE lors de la conversion. Ce sont des capacités à vérifier, pas des étiquettes à citer dans une présentation.

Ce qu’il faut tester avant de faire confiance au tableau d’accélération

Optijara a inspecté les fiches de modèles publiques et le code d’intégration pour cet article. Nous n’avons pas exécuté ces modèles ni reproduit les benchmarks ; le plan de test ci-dessous est un travail proposé.

Commencez par la parité. Mesurez ensuite la latence. Un smoke test utile fixe le modèle, le tokenizer, le processeur, le projecteur, le modèle de chat, le commit ou la version de package du runtime, la précision, le prétraitement des images, les paramètres de génération et le réglage de bloc. Exécutez d’abord la sortie greedy cible seule. Exécutez ensuite la sortie greedy DSpark. Comparez le texte exact. S’il diverge, journalisez le prompt, le hash de l’image, les paramètres, la révision du runtime et le diff de sortie avant toute affirmation de vitesse.

Les chiffres de performance rapportés par Liquid AI sont utiles, mais ce sont des résultats fournisseur propres à certaines conditions. La fiche du modèle cadre les résultats autour du batch 1, de la température 0, de paramètres d’encodeur et de backbone en 16 bits, de H100 BF16 avec bloc 9, d’Apple FP16 avec bloc 8 ; les mesures Apple utilisent jusqu’à 2 048 jetons de sortie. Elle rapporte des exemples comme les ratios de décodage et bout en bout COCO sur H100, ainsi que des résultats Apple incluant des lignes M5 Max et M3 Ultra. Traitez-les comme des indices directionnels pour la sortie, pas comme une promesse pour votre charge de travail. Si les preuves de benchmark doivent être comparées entre systèmes, utilisez une discipline de protocole comme dans le guide Optijara des cartes d’évaluation et des protocoles de benchmark : le score, l’ensemble de prompts, le runtime, la précision et les règles de mesure doivent voyager ensemble.

La moyenne de jetons acceptés par passe de vérification n’est pas en soi un pourcentage d’acceptation. La longueur acceptée, le travail rejeté, le coût du drafter, le comportement du batch de vérification, le trafic de cache et la longueur de sortie déterminent tous la vitesse réalisée. Une réponse courte peut passer la majeure partie de son temps dans le prétraitement de vision et le prefill. Une réponse plus longue, dominée par le décodage, donne aux jetons draft acceptés plus de marge pour compter.

Voici la règle pratique : si votre évaluation DSpark commence par le tableau d’accélération, elle est orientée dans la mauvaise direction. Commencez par la parité de sortie et l’association des artefacts. La vitesse vient ensuite, et seulement si les contrôles de compatibilité réussissent.

Erreurs courantes lors de l’adoption de LFM2.5-VL-DSpark

La première erreur consiste à traiter le sidecar comme un second modèle de vision déployable. C’est un drafter pour un chemin cible apparié. Si votre plan de déploiement dit de servir le fichier DSpark comme modèle, le plan est faux.

La deuxième erreur consiste à associer un sidecar DSpark texte à la cible VL. Le matériel de lancement de Liquid AI inclut des exemples qui peuvent être faciles à copier hors contexte. Pour la sortie vision, utilisez les artefacts actuels de cible vision et de DSpark vision, puis vérifiez le projecteur et le chemin de runtime.

La troisième erreur consiste à chronométrer avant de prouver la parité. Un chemin rapide qui modifie la sortie greedy n’est pas un chemin d’accélération valide pour un décodeur spéculatif qui préserve la cible. Il peut encore être intéressant pour la recherche, mais ce n’est pas une preuve que DSpark accélère votre modèle cible en toute sécurité.

La quatrième erreur consiste à lire un ratio de vitesse de décodage comme un débit, une qualité, des économies de mémoire ou une latence produit. La vitesse de décodage n’est pas le débit de concurrence. Ce n’est pas une amélioration de qualité. Elle ne réduit pas automatiquement la mémoire maximale. Elle ne supprime pas le prefill. Mesurez chaque élément séparément.

La cinquième erreur consiste à ignorer la licence et la provenance des artefacts. La LFM Open License v1.0 inclut des conditions commerciales dépendantes du chiffre d’affaires et un seuil décrit dans le texte de la licence. Ce n’est pas de l’open source sans restriction. Passez en revue la licence actuelle et obtenez un avis juridique pour les limites de déploiement commercial.

Réserves et limites : là où DSpark peut ne pas aider

DSpark peut aider le moins sur les sorties courtes et les prompts très axés sur la vision, où le prétraitement et le prefill dominent. Si un cas d’utilisation demande une légende d’une ligne, le sidecar peut ne pas avoir assez de longueur de décodage pour compenser le surcoût. Si un cas d’utilisation produit des explications plus longues de graphiques, du raisonnement sur documents ou des réponses ancrées dans l’image en plusieurs étapes, l’évaluation est plus prometteuse, mais reste dépendante de la charge de travail.

La dérive backend est une autre limite. H100, Apple MLX, SGLang, llama.cpp, BF16, FP16, FlashAttention, les modèles d’image et la gestion du tokenizer peuvent tous affecter la parité et les performances. Un runtime qui fonctionne pour un chemin ne prouve pas que chaque conversion ou backend est sûr.

L’échantillonnage exige une prudence supplémentaire. En principe, le décodage spéculatif peut préserver la distribution cible lorsque l’échantillonnage apparié est correctement implémenté. C’est différent de produire un texte identique pour chaque seed sur chaque backend. Pour DSpark aujourd’hui, faites de la parité greedy à température 0 la première porte de confiance, puis évaluez l’échantillonnage seulement si votre runtime documente et prend en charge l’algorithme apparié.

Matrice de décision : quand une équipe devrait évaluer DSpark maintenant

La décision n’est pas : DSpark est-il bon ? Elle est : le contrat de sidecar de cette sortie convient-il à votre cible, votre backend, votre charge de travail et votre discipline opérationnelle ? Ce cadrage empêche une technique d’accélération prometteuse de devenir un raccourci de déploiement non vérifié.

Checklist d’implémentation

Utilisez cette checklist pour le premier sprint d’évaluation. Choisissez des prompts d’image représentatifs. Fixez la cible, le projecteur, le sidecar DSpark, le tokenizer, le processeur, le modèle, la révision du runtime, la précision, le réglage de bloc et le prétraitement des images. Exécutez une baseline greedy cible seule. Exécutez la sortie greedy DSpark et comparez le texte exact. Mesurez TTFT, la latence bout en bout p50 et p95, la mémoire maximale, la longueur de jetons acceptés, les propositions rejetées, la politique de warmup, les paramètres de cache et le comportement de fallback cible seule. Passez en revue la licence. Décidez du périmètre de déploiement seulement après que les preuves de parité et de mesure figurent dans le même rapport.

{
  "target": "LiquidAI/LFM2.5-VL-3B",
  "sidecar": "LiquidAI/LFM2.5-VL-3B-DSpark",
  "runtime": "pinned revision with VL DSpark taps, verification, and rollback",
  "parity_status": "greedy target-only versus DSpark comparison required",
  "latency_status": "measure TTFT and p50/p95 end-to-end after parity",
  "memory_status": "measure peak runtime memory, not parameter count only",
  "license_review": "required before commercial rollout",
  "fallback_ready": "target-only path documented"
}

Si votre équipe a besoin d’aide pour transformer cela en banc d’évaluation d’inférence reproductible, Optijara peut aider à définir la carte de compatibilité, le plan de fixation des artefacts et le dossier de décision de déploiement. Le travail de validation doit tout de même avoir lieu sur votre charge de travail, avec vos images, vos prompts, votre runtime et vos contraintes.