LFM2.5-VL-3B-DSpark vs UI-Venus 2.9B: Een snelheidsvermenigvuldiger tegenover een GUI-agent

LFM2.5-VL-3B-DSpark en UI-Venus 2.9B worden onder dezelfde vage noemer geschaard — kleine visiemodellen — en dan met elkaar vergeleken, wat een categoriefout is die het waard is om te verhelpen voordat het iemand een week integratie kost. LFM2.5-VL-3B-DSpark is een draftmodel met 279,5 miljoen parameters dat het LFM2.5-VL-3B van Liquid AI versnelt. UI-Venus 2.9B, van het inclusionAI-lab van Ant Group, is een 9B GUI-agent die screenshots leest, een actie bepaalt en deze uitvoert in mobiele, web- en desktopomgevingen. De ene maakt een bestaand model sneller. De andere is het ding dat het werk doet. Als je een GUI-agent nodig hebt, is het draftmodel geen goedkopere optie — het is helemaal geen optie.

De nuttige vergelijking is niet welke beter is, maar welk probleem elk ervan oplost, en wat elk je daarbij kost. Beide zijn ook recente nieuwkomers die het bredere ecosysteem nog niet heeft ingehaald, en de kloof tussen wat hun repositories beweren en wat iemand anders heeft geverifieerd, is bij de ene groter dan bij de andere.

Wat elk ervan precies is

Begin met de vormen, want ze verklaren het grootste deel van de rest.

• Wat het is — LFM2.5-VL-3B-DSpark is een draftmodel voor speculatieve decoding; UI-Venus 2.9B is een algemeen inzetbaar GUI-agentbeleid.

• Parameters — 279,5M BF16 voor de drafter, tegenover 9B voor UI-Venus 2.9B, geïnitialiseerd vanuit Qwen3.5-9B

• Losstaande capaciteit — de opsteller genereert op zichzelf niets bruikbaars en kan niet geïsoleerd worden gebenchmarkt; UI-Venus 2.9B draait als een volledige agent

• Invoer — het conceptmodel ziet de afbeelding zelf nooit, alleen de verborgen toestanden van het doelmodel; UI-Venus 2.9B verwerkt schermafbeeldingen rechtstreeks en is er volledig omheen gebouwd

• Uitvoer — de opsteller stelt tokens voor ter verificatie; UI-Venus 2.9B genereert gegronde acties met bounding boxes op een live interface

• Base — de opsteller is in zijn eigen metadata gekoppeld aan LiquidAI/LFM2.5-VL-3B; UI-Venus 2.9B bouwt voort op Qwen3.5-9B

• Context — de drafter erft wat het doel ook levert; UI-Venus 2.9B wordt geserveerd met een maximum van 262.144 tokens in het eigen vLLM-recept van de leverancier.

• Licentie — beide zijn op verschillende manieren onopgelost; Liquid wordt uitgebracht onder de LFM1.0-licentie, en de kaart van UI-Venus 2.9B vermeldt ronduit dat de licentie voor de gewichten nog op definitieve bevestiging wacht

Bij die laatste bullet moet je even stilstaan. Onze eigen berichtgeving over UI-Venus-2-9B eind augustus omschreef de release als Apache-2.0, omdat dat destijds in de materialen van het project stond. De model card van vandaag zegt iets anders en stelligers: dat de licentie voor de modelgewichten in afwachting is van definitieve bevestiging en vóór publieke release wordt toegevoegd, en dat een Apache-2.0-verklaring bewust niet is overgenomen omdat de huidige upstream-materialen tegenstrijdige licentieverklaringen bevatten. Als u een commerciële implementatie van UI-Venus 2.9B overweegt, staat de licentiekwestie volgens de leverancier zelf nog open, en dat is een materieel risico, niet slechts een voetnoot.

De cijfers die elke partij daadwerkelijk heeft gepubliceerd

De twee repositories meten verschillende dingen, en dat is juist het punt. Liquid publiceert doorvoer; Ant Group publiceert taaksucces.

Voor de drafter, volgens Liquid's eigen harness: een decode-versnelling van maximaal 2,66× op een enkele H100 80GB in BF16 via SGLang, maximaal 3,13× met MLX-VLM op een Apple M5 Max, en maximaal 2,14× met llama.cpp op een M3 Ultra. End-to-end komen diezelfde runs uit tussen 1,30× en 2,62×, afhankelijk van de stack en de taak. De draft-acceptatie ligt rond 3,2 tot 4,5 tokens per verificatieronde. Allemaal zijn ze door de leverancier gemeten, zonder externe reproductie.

Voor UI-Venus 2.9B rapporteren de eigen tabellen van de modelkaart 80,2 op AndroidWorld, 65,8 op MobileWorld bij een budget van 50 stappen, 70,8 op OSWorld-Verified, 48,0 op DeskCraft, 90,8 op WebVoyager over de vernieuwde split van 595 taken, 74,0 op Online-Mind2Web, 73,0 op ScreenSpot-Pro en 77,1 op VenusBench-GD. Op CAPTCHA rapporteert het 78,1 op VenusBench-CAPTCHA en 75,7 op MCA-Bench. Aan de veiligheidskant rapporteert het een aanvalssuccespercentage van 11,3% op OSHarm tegenover 25,3% voor zijn Qwen3.5-9B-basis. Al deze cijfers zijn door de leverancier gerapporteerd; sommige baselines hebben een asterisk, wat betekent dat de auteurs van UI-Venus ze onder het vermelde protocol hebben geëvalueerd, en de modelkaart zelf waarschuwt dat vergelijkingen met OSWorld-Verified gebruikmaken van modelspecifieke action scaffolds en moeten worden gelezen als referenties op benchmarkniveau in plaats van gecontroleerde ablaties.

Merk op wat in beide lijsten ontbreekt: alles wat door een derde partij is gemeten. Voor de drafter komt dat doordat het checkpoint dagen oud is. Voor UI-Venus 2.9B komt dat doordat GUI-agent-benchmarks duur zijn om te reproduceren en de resultaten in de live-omgeving meebewegen met de status van de omgeving op de evaluatiedatum — een kanttekening die de kaart uit eigen beweging plaatst.

Waar de twee elkaar daadwerkelijk ontmoeten

Er is een echte overlap, en die is smaller dan het categorielabel doet vermoeden. Beide zijn relevant als je een on-device- of edge-visuele agent bouwt, en beide gaan over de kosten om pixels door een model te krijgen. Ze vallen het van tegenovergestelde kanten aan.

UI-Venus 2.9B pakt het aan met training: een drietrapspijplijn van multimodale mid-training over gesimuleerde mobiele, web- en OS-omgevingen, per-domein offline RL, en daarna multi-teacher on-policy distillatie in één policy. De gepubliceerde capaciteit is het resultaat. Het model is 9B, wat klein is voor een GUI-agent en groot voor een edge-apparaat, en de beoogde serveerconfiguratie van de kaart is een vLLM-implementatie — dezelfde documentatie merkt op dat die configuratie niet live-canary-gevalideerd was als onderdeel van de kaartupdate en zegt dat je je vLLM-versie voor Qwen3.5 moet vastpinnen en verifiëren voordat je uitrolt.

LFM2.5-VL-3B-DSpark pakt het aan met runtime: het laat de gewichten van het doelmodel ongemoeid en wint snelheid door tokens te draften en te verifiëren. Op een apparaat van telefoonklasse is de ruil eenzijdig in het voordeel van de drafter, omdat de output aantoonbaar die van het doelmodel is en het extra geheugen minder dan een tiende van een model bedraagt.

De consequentie voor wie kiest: een agent-loop doet veel modelaanroepen per taak, en elke aanroep betaalt prefill voor een nieuwe schermafbeelding. Beeldcodering en prefill zijn precies de fasen die speculatieve decoding niet versnelt — Liquid's eigen aankondiging maakt dit argument tegen een onbeperkte lezing van zijn kopcijfers. Dus de voorsprong van de drafter krimpt precies in de workload waarin UI-Venus 2.9B leeft. Omgekeerd is de voorsprong van UI-Venus 2.9B — de taak daadwerkelijk voltooien — niet iets wat een drafter bij welke snelheid dan ook levert.

De twee runnen

Geen van beide is een gehost endpoint op OrcaRouter. LFM2.5-VL-3B-DSpark en UI-Venus 2.9B vereisen beide dat je zelf gewichten ophaalt en serveert, en hun serveerverhalen worden bepaald door hun heel verschillende rollen. De drafter heeft SGLang v0.5.19 of nieuwer nodig met een DSPARK-vlag voor het speculatieve algoritme en een blokgrootte van 9, of MLX-VLM v0.7.2 of nieuwer waarbij de drafter als draftmodel wordt doorgegeven en de temperatuur op nul wordt geforceerd, of llama.cpp met een F16 GGUF van 567 MB gekoppeld aan een gequantiseerd doel. UI-Venus 2.9B heeft een vLLM-server nodig die groot genoeg is voor een 9B-model met een maximale lengte van 262.144 tokens, plus de referentieprompts en actieparsers uit de coderepository van het project — de modelkaart zegt expliciet dat het alleen starten van de server je geen werkende closed-loop GUI-agent oplevert.

Beide laten ook dezelfde leemte achter aan de randen van hun kunnen. Een klein visie-taalmodel in combinatie met een drafter stuit nog steeds op schermen en taken die het niet aankan, en een GUI-agent faalt nog steeds in omgevingen buiten zijn trainingsdistributie. De queries die doorvallen, belanden ergens, en in de meeste productieontwerpen is dat een groter model voor algemene doeleinden. Het routeren daarvan via één enkel eindpunt dat 200+ modellen dekt tegen de lijstprijs van elke aanbieder, met automatische failover wanneer een aanbieder verslechtert houdt het fallbackpad buiten de lijst van kritieke integraties in plaats van er een tweede deploymentproject met eigen sleutels en contracten van te maken.

Hoe je in één minuut beslist

Als u software nodig hebt die een gebruikersinterface bedient — klikken, typen, navigeren door een app die hij nog nooit heeft gezien — dan koopt u een beleid, en dat is UI-Venus 2.9B. Reken op een 9B vLLM-implementatie, lees de openstaande licentiequestie voordat u zich commercieel vastlegt, en beschouw de benchmarktabel van de leverancier als een sterke beginhypothese in plaats van een vaststaand resultaat, vooral de OSWorld-Verified-vergelijkingen die de kaart zelf markeert als scaffold-afhankelijk.

Als je al LFM2.5-VL-3B draait en het sneller wilt op hardware die je bezit, koop je een runtime-optimalisatie, en dat is LFM2.5-VL-3B-DSpark. Controleer eerst drie dingen: dat je workloads decode-heavy zijn in plaats van prefill-heavy, dat je op 16-bit serveert in plaats van een 4-bit export, en dat je runtime aan de minimale versievereisten voldoet. Als alle drie kloppen, zijn de geheugenkosten 8,9% en is de uitvoer door de constructie ongewijzigd.

Het enige dat het contact met geen van beide repositories overleeft, is ze als substituut voor elkaar te behandelen. Ze zijn een snelheidsvermenigvuldiger en een agent, en het enige scenario waarin ze met elkaar concurreren, is dat waarin je al hebt besloten wat je aan het bouwen bent en een reden zoekt om in plaats daarvan iets goedkopers te bouwen.

OrcaRouter bereikt 200+ modellen via één sleutel tegen de listprijs van de provider met 0% markup, met routeringsbeleid en automatische failover voor de queries die een edge-model of een agent niet zou moeten afhandelen. één API voor het fallbackpadGeen van beide modellen op deze pagina wordt daar gehost - beide worden vanaf je eigen weights geserveerd - maar het fallbackpad is het deel dat je niet zelf hoeft te bouwen.