LFM2.5-VL-3B-DSpark vs UI-Venus 2.9B : Un multiplicateur de vitesse face à un agent GUI

LFM2.5-VL-3B-DSpark et UI-Venus 2.9B sont classés sous la même rubrique vague — petits modèles de vision — puis comparés l’un à l’autre, ce qui est une erreur de catégorie qu’il vaut la peine de corriger avant qu’elle ne coûte une semaine d’intégration à quelqu’un. LFM2.5-VL-3B-DSpark est un modèle draft de 279,5 M de paramètres qui accélère LFM2.5-VL-3B de Liquid AI. UI-Venus 2.9B, du laboratoire inclusionAI d’Ant Group, est un agent GUI de 9B qui lit des captures d’écran, décide d’une action et l’exécute sur les environnements mobiles, web et de bureau. L’un rend un modèle existant plus rapide. L’autre est ce qui fait le travail. Si ce dont vous avez besoin est un agent GUI, le modèle draft n’est pas une option moins chère — ce n’est pas une option du tout.

La comparaison utile n’est pas de savoir lequel est meilleur, mais quel problème chacun résout, et ce que chacun vous coûte en cours de route. Tous deux sont aussi des nouveaux venus que l’écosystème au sens large n’a pas encore rattrapés, et l’écart entre ce que leurs dépôts déclarent et ce que quiconque d’autre a vérifié est plus grand pour l’un que pour l’autre.

Ce que chacun est, précisément

Commencez par les formes, car elles expliquent la majeure partie du reste.

• Ce que c'est — LFM2.5-VL-3B-DSpark est un modèle de brouillon pour le décodage spéculatif ; UI-Venus 2.9B est une politique d'agent GUI généraliste.

• Paramètres — 279,5 M en BF16 pour le drafter, contre 9B pour UI-Venus 2.9B initialisé à partir de Qwen3.5-9B

• Capacité autonome — le générateur d'ébauches ne produit rien d'utilisable seul et ne peut pas être évalué de manière isolée ; UI-Venus 2.9B fonctionne comme un agent complet

• Entrées — le rédacteur ne voit jamais l’image elle-même, seulement les états cachés du modèle cible ; UI-Venus 2.9B consomme directement les captures d’écran et est entièrement construit autour d’elles

• Sorties — le rédacteur propose des jetons à vérifier ; UI-Venus 2.9B émet des actions ancrées avec des boîtes englobantes face à une interface en direct

• Base — le générateur de brouillons est associé à LiquidAI/LFM2.5-VL-3B dans ses propres métadonnées ; UI-Venus 2.9B s’appuie sur Qwen3.5-9B

• Contexte — le modèle de draft hérite de tout ce que la cible fournit ; UI-Venus 2.9B est servi avec un maximum de 262 144 jetons dans la recette vLLM propre au fournisseur

• Licence — les deux restent en suspens, chacune à sa manière ; Liquid est distribué sous licence LFM1.0, et la fiche de UI-Venus 2.9B indique sans ambiguïté que la licence de ses poids est en attente de confirmation finale

C'est sur cette dernière puce qu'il faut s'attarder. Notre propre couverture d'UI-Venus-2-9B fin août décrivait la publication comme étant sous Apache-2.0, car c'est ce que les documents du projet indiquaient à l'époque. La fiche modèle d'aujourd'hui dit quelque chose de différent et de plus fort : que la licence des poids du modèle est en attente de confirmation finale et sera ajoutée avant la publication publique, et qu'une déclaration Apache-2.0 n'a intentionnellement pas été reprise parce que les documents amont actuels contiennent des déclarations de licence contradictoires. Si vous envisagez un déploiement commercial d'UI-Venus 2.9B, la question de la licence reste ouverte de l'aveu même du fournisseur, et il s'agit d'un risque important, et non d'une simple note de bas de page.

Les chiffres que chaque camp a réellement publiés

Les deux dépôts mesurent des choses différentes, et c'est précisément là l'intérêt. Liquid publie le débit ; Ant Group publie la réussite des tâches.

Pour le drafter, selon le propre harnais de test de Liquid : une accélération de décodage allant jusqu'à 2,66× sur un seul H100 80GB en BF16 via SGLang, jusqu'à 3,13× avec MLX-VLM sur un Apple M5 Max, et jusqu'à 2,14× avec llama.cpp sur un M3 Ultra. De bout en bout, ces mêmes exécutions se situent entre 1,30× et 2,62× selon la pile et la tâche. L'acceptation des drafts se situe autour de 3,2 à 4,5 tokens par passe de vérification. Chacun de ces chiffres est mesuré par le fournisseur, sans reproduction externe.

Pour UI-Venus 2.9B, les tableaux de la fiche elle-même rapportent 80,2 sur AndroidWorld, 65,8 sur MobileWorld avec un budget de 50 étapes, 70,8 sur OSWorld-Verified, 48,0 sur DeskCraft, 90,8 sur WebVoyager sur le découpage actualisé de 595 tâches, 74,0 sur Online-Mind2Web, 73,0 sur ScreenSpot-Pro et 77,1 sur VenusBench-GD. Sur CAPTCHA, elle rapporte 78,1 sur VenusBench-CAPTCHA et 75,7 sur MCA-Bench. Côté sécurité, elle rapporte un taux de réussite d’attaque de 11,3 % sur OSHarm contre 25,3 % pour sa base Qwen3.5-9B. Tous ces chiffres sont déclarés par le fournisseur, certaines bases de référence portent un astérisque, ce qui signifie que les auteurs d’UI-Venus les ont évaluées selon le protocole indiqué, et la fiche elle-même avertit que les comparaisons OSWorld-Verified utilisent des échafaudages d’action propres au modèle et doivent être considérées comme des références au niveau du benchmark plutôt que comme des ablations contrôlées.

Notez ce qui est absent des deux listes : tout ce qui est mesuré par un tiers. Pour le drafter, c’est parce que le checkpoint date de plusieurs jours. Pour UI-Venus 2.9B, c’est parce que les benchmarks d’agents GUI sont coûteux à reproduire et que les résultats en environnement réel évoluent avec l’état de l’environnement à la date de l’évaluation — une réserve que la fiche formule spontanément.

Là où les deux se rencontrent réellement

Il y a un véritable chevauchement, et il est plus étroit que ne le suggère l'étiquette de catégorie. Les deux sont pertinents si vous construisez un agent visuel embarqué ou en périphérie, et tous deux s'intéressent au coût de faire passer des pixels dans un modèle. Ils l'attaquent par des extrémités opposées.

UI-Venus 2.9B s'y attaque par l'entraînement : un pipeline en trois étapes composé d'un mid-training multimodal sur des environnements simulés mobiles, web et OS, d'un RL hors ligne par domaine, puis d'une distillation on-policy multi-enseignants vers une politique unique. La capacité publiée en est le résultat. Le modèle fait 9B, ce qui est petit pour un agent GUI et grand pour un appareil en périphérie, et la configuration de service prévue par la fiche est un déploiement vLLM — la même documentation indique que cette configuration n'a pas été validée par canari en production dans le cadre de la mise à jour de la fiche et vous recommande d'épingler et de vérifier votre version de vLLM pour Qwen3.5 avant de déployer.

LFM2.5-VL-3B-DSpark s'y attaque via le runtime : il laisse les poids du modèle cible intacts et gagne en vitesse en générant et en vérifiant des jetons. Sur un appareil de classe téléphone, le compromis penche à sens unique en faveur du générateur de brouillons, car la sortie est prouvablement celle de la cible et la mémoire supplémentaire représente moins d'un dixième d'un modèle.

La conséquence pour quiconque choisit : une boucle d'agent effectue de nombreux appels au modèle par tâche, et chaque appel paie le pré-remplissage pour une nouvelle capture d'écran. L'encodage visuel et le pré-remplissage sont précisément les étapes que le décodage spéculatif n'accélère pas — l'annonce de Liquid elle-même avance cet argument contre une lecture illimitée de ses chiffres phares. Ainsi, l'avantage du drafteur se réduit exactement dans la charge de travail dans laquelle évolue UI-Venus 2.9B. À l'inverse, l'avantage d'UI-Venus 2.9B — accomplir réellement la tâche — n'est pas quelque chose qu'un drafteur apporte, quelle que soit la vitesse.

Exécution des deux

Aucun des deux n’est un point de terminaison hébergé sur OrcaRouter. LFM2.5-VL-3B-DSpark et UI-Venus 2.9B exigent tous deux que vous récupériez les poids et que vous les serviez vous-même, et leurs modalités de mise en service sont dictées par leurs rôles très différents. Le drafter nécessite SGLang v0.5.19 ou une version plus récente avec une option d’algorithme spéculatif DSPARK et une taille de bloc de 9, ou MLX-VLM v0.7.2 ou une version plus récente avec le drafter transmis comme modèle de draft et la température forcée à zéro, ou llama.cpp avec un GGUF F16 de 567 Mo associé à une cible quantifiée. UI-Venus 2.9B nécessite un serveur vLLM suffisamment grand pour un modèle 9B avec une longueur maximale de 262 144 jetons, ainsi que les prompts de référence et les parseurs d’actions du dépôt de code du projet — la fiche est explicite : le simple fait de démarrer le serveur ne vous donne pas un agent GUI en boucle fermée fonctionnel.

Tous deux laissent également la même lacune aux limites de ce qu'ils savent faire. Un petit modèle vision-langage associé à un modèle de brouillon se heurte encore à des écrans et à des tâches qu'il ne peut pas gérer, et un agent GUI échoue encore sur des environnements en dehors de sa distribution d'entraînement. Les requêtes qui passent à travers retombent quelque part, et dans la plupart des architectures de production, c'est sur un modèle généraliste plus grand. Les acheminer via un point de terminaison unique couvrant plus de 200 modèles au prix catalogue de chaque fournisseur, avec bascule automatique en cas de dégradation d'un fournisseur, garde le chemin de repli hors de la liste des intégrations critiques plutôt que d'en faire un second projet de déploiement avec ses propres clés et contrats.

Comment décider en une minute

Si vous avez besoin d’un logiciel qui pilote une interface utilisateur — cliquer, taper, naviguer dans une application qu’il n’a jamais vue —, vous achetez une politique, et c’est UI-Venus 2.9B. Prévoyez un budget pour un déploiement vLLM de 9B, lisez la question de licence en suspens avant de vous engager commercialement, et considérez le tableau de référence du fournisseur comme une solide hypothèse de départ plutôt qu’un résultat établi, en particulier les comparaisons OSWorld-Verified que la fiche elle-même signale comme dépendantes du scaffold.

Si vous exécutez déjà LFM2.5-VL-3B et que vous voulez qu’il soit plus rapide sur le matériel que vous possédez, vous achetez une optimisation de runtime, et c’est LFM2.5-VL-3B-DSpark. Vérifiez d’abord trois choses : que vos charges de travail sont lourdes en décodage plutôt qu’en préremplissage, que vous servez en 16 bits plutôt qu’avec un export 4 bits, et que votre runtime respecte les versions minimales requises. Si ces trois conditions sont réunies, le coût mémoire est de 8,9 % et la sortie est inchangée par construction.

La seule chose qui ne survit pas au contact de l’un ou l’autre des dépôts, c’est de les traiter comme des substituts. Ils sont un multiplicateur de vitesse et un agent, et le seul scénario dans lequel ils entrent en concurrence est celui où vous avez déjà décidé ce que vous construisez et cherchez une raison de construire quelque chose de moins cher à la place.

OrcaRouter donne accès à plus de 200 modèles via une seule clé, au prix catalogue du fournisseur, avec 0 % de marge, avec une politique de routage et un basculement automatique pour les requêtes qu'un modèle en périphérie ou un agent ne devrait pas prendre. une API pour le chemin de repli Aucun des deux modèles de cette page n'est hébergé là-bas — les deux sont servis depuis vos propres poids — mais le chemin de repli est la partie que vous n'avez pas à construire.