LFM2.5-VL-3B-DSpark vs UI-Venus 2.9B: En hastighetsmultiplikator mot en GUI-agent

LFM2.5-VL-3B-DSpark och UI-Venus 2.9B hamnar under samma vaga rubrik – små visionsmodeller – och jämförs sedan med varandra, vilket är ett kategorimisstag värt att rätta till innan det kostar någon en veckas integration. LFM2.5-VL-3B-DSpark är en draftmodell med 279,5 miljoner parametrar som accelererar Liquid AI:s LFM2.5-VL-3B. UI-Venus 2.9B, från Ant Groups inclusionAI-labb, är en GUI-agent på 9B som läser skärmdumpar, beslutar om en åtgärd och utför den i mobil-, webb- och skrivbordsmiljöer. Den ena gör en befintlig modell snabbare. Den andra är den som utför arbetet. Om det du behöver är en GUI-agent är draftmodellen inte ett billigare alternativ – den är inte ett alternativ alls.

Den användbara jämförelsen är inte vilken som är bättre, utan vilket problem var och en löser och vad var och en kostar dig i processen. Båda är också nya tillskott som det bredare ekosystemet inte har hunnit ikapp, och gapet mellan vad deras repositorier påstår och vad någon annan har verifierat är större för en av dem än för den andra.

Vad var och en är, exakt

Börja med formerna, för de förklarar det mesta av resten.

• Vad det är — LFM2.5-VL-3B-DSpark är en draftmodell för spekulativ avkodning; UI-Venus 2.9B är en generell GUI-agentpolicy

• Parametrar — 279.5M BF16 för draftmodellen, jämfört med 9B för UI-Venus 2.9B initierad från Qwen3.5-9B

• Fristående kapacitet — utkastaren genererar inget användbart på egen hand och kan inte prestandatestas isolerat; UI-Venus 2.9 körs som en komplett agent

• Indata — utkastaren ser aldrig själva bilden, endast målmodellens dolda tillstånd; UI-Venus 2.9B konsumerar skärmbilder direkt och är helt och hållet uppbyggd kring dem

• Utdata — utkastaren föreslår tokens för verifiering; UI-Venus 2.9B avger grundade åtgärder med avgränsningsrutor mot ett livegränssnitt

• Bas — utkastaren är knuten till LiquidAI/LFM2.5-VL-3B i sin egen metadata; UI-Venus 2.9B bygger på Qwen3.5-9B

• Kontext — draftmodellen ärver vad målmodellen än tillhandahåller; UI-Venus 2.9B serveras med ett maximum på 262 144 tokens i leverantörens eget vLLM-recept

• Licens — båda är olösta på olika sätt; Liquid distribueras under LFM1.0-licensen, och UI-Venus 2.9B:s kort anger rent ut att licensen för dess vikter väntar på slutlig bekräftelse

Den sista punkten är den man bör stanna upp vid. Vår egen bevakning av UI-Venus-2-9B i slutet av augusti beskrev utgåvan som Apache-2.0, eftersom det var vad projektets material innehöll vid den tidpunkten. Modellkortet i dag säger något annat och starkare: att licensen för modellvikterna inväntar slutlig bekräftelse och kommer att läggas till före offentlig utgivning, och att en Apache-2.0-deklaration avsiktligt inte har förts över eftersom de nuvarande uppströmsmaterialen innehåller motstridiga licensuttalanden. Om du planerar en kommersiell driftsättning av UI-Venus 2.9B är licensfrågan öppen enligt leverantörens egen uppgift, och det är en väsentlig risk snarare än en fotnot.

Siffrorna som varje sida faktiskt publicerade

De två repositorierna mäter olika saker, vilket är själva poängen. Liquid publicerar genomströmning; Ant Group publicerar uppgiftsframgång.

För draftmodellen, enligt Liquids egen testbänk: i bästa fall 2,66× snabbare avkodning på en enda H100 80GB i BF16 via SGLang, i bästa fall 3,13× med MLX-VLM på en Apple M5 Max och i bästa fall 2,14× med llama.cpp på en M3 Ultra. End-to-end hamnar samma körningar mellan 1,30× och 2,62× beroende på stack och uppgift. Draft-acceptansen ligger på omkring 3,2 till 4,5 tokens per verifieringspass. Vart och ett av dessa värden är mätt av leverantören utan extern reproduktion.

För UI-Venus 2.9B rapporterar modellkortets egna tabeller 80,2 på AndroidWorld, 65,8 på MobileWorld med en budget på 50 steg, 70,8 på OSWorld-Verified, 48,0 på DeskCraft, 90,8 på WebVoyager över den uppdaterade delningen med 595 uppgifter, 74,0 på Online-Mind2Web, 73,0 på ScreenSpot-Pro och 77,1 på VenusBench-GD. För CAPTCHA rapporterar det 78,1 på VenusBench-CAPTCHA och 75,7 på MCA-Bench. På säkerhetssidan rapporterar det en attackframgångsgrad på 11,3 % på OSHarm mot 25,3 % för dess Qwen3.5-9B-bas. Alla dessa är rapporterade av leverantören, vissa baslinjer har en asterisk som betyder att UI-Venus-författarna utvärderade dem enligt det angivna protokollet, och kortet självt varnar för att OSWorld-Verified-jämförelser använder modellspecifika action-scaffolds och bör läsas som referenser på benchmarknivå snarare än kontrollerade ablationsstudier.

Notera vad som saknas i båda listorna: allt som mätts av en tredje part. För utkastaren beror det på att checkpointen är flera dagar gammal. För UI-Venus 2.9B beror det på att benchmarkar för GUI-agenter är dyra att reproducera och att resultaten från live-miljön varierar med miljöns tillstånd på utvärderingsdagen — ett förbehåll som kortet självmant tar upp.

Där de två faktiskt möts

Det finns en verklig överlappning, och den är snävare än vad kategorietiketten antyder. Båda är relevanta om du bygger en visuell agent på enheten eller i edge-miljö, och båda handlar om kostnaden för att få pixlar genom en modell. De angriper den från motsatta håll.

UI-Venus 2.9B angriper det med träning: en trestegspipeline med multimodal mid-training över simulerade mobil-, webb- och OS-miljöer, domänspecifik offline-RL och sedan multi-teacher on-policy-distillation till en enda policy. Den publicerade kapaciteten är resultatet. Modellen är 9B, vilket är litet för en GUI-agent och stort för en edge-enhet, och kortets avsedda serveringskonfiguration är en vLLM-distribution — samma dokumentation noterar att konfigurationen inte live-canary-validerades som en del av kortuppdateringen och säger åt dig att pinna och verifiera din vLLM-version för Qwen3.5 innan du distribuerar.

LFM2.5-VL-3B-DSpark angriper det med runtime: den lämnar målmodellens vikter orörda och köper hastighet genom att generera utkast och verifiera tokens. På en enhet i telefonklass är avvägningen ensidig till utkastarens fördel, eftersom utdata bevisligen är målmodellens och det extra minnet är under en tiondel av en modell.

Konsekvensen av att välja en agentloop är att den gör många modellanrop per uppgift, och varje anrop betalar för prefill av en ny skärmbild. Visionskodning och prefill är just de steg som spekulativ avkodning inte accelererar — Liquids eget tillkännagivande utgör ett argument mot en obegränsad tolkning av dess rubriksiffror. Så draftmodellens fördel krymper i exakt den arbetsbelastning som UI-Venus 2.9B lever i. Omvänt är UI-Venus 2.9B:s fördel — att faktiskt slutföra uppgiften — inte något som en draftmodell tillhandahåller oavsett hastighet.

Att köra de två

Ingen av dem är en hostad slutpunkt på OrcaRouter. LFM2.5-VL-3B-DSpark och UI-Venus 2.9B kräver båda att du hämtar vikterna och serverar dem själv, och deras serving-upplägg präglas av deras mycket olika roller. Draftmodellen behöver SGLang v0.5.19 eller nyare med en flagga för DSPARK:s speculativa algoritm och en blockstorlek på 9, eller MLX-VLM v0.7.2 eller nyare, där draftmodellen skickas som en draftmodell och temperaturen tvingas till noll, eller llama.cpp med en 567 MB F16 GGUF parad med en kvantiserad målmodell. UI-Venus 2.9B behöver en vLLM-server som är tillräckligt stor för en 9B-modell vid en maximal längd på 262 144 token, plus referensprompterna och action-parsrarna från projektets kodförråd — modellkortet säger uttryckligen att det inte räcker att bara starta servern för att få en fungerande GUI-agent med sluten loop.

Båda lämnar också samma lucka vid gränserna för vad de kan göra. En liten bild- och språkmodell parad med en utkastmodell stöter fortfarande på skärmar och uppgifter som den inte kan hantera, och en GUI-agent misslyckas fortfarande i miljöer utanför dess träningsfördelning. De förfrågningar som faller igenom hamnar någonstans, och i de flesta produktionsdesigner är det en större allmän modell. Att dirigera dessa genom en enda slutpunkt som täcker 200+ modeller till varje leverantörs listpris, med automatisk redundansväxling när en leverantör försämras, håller reservvägen borta från den kritiska integrationslistan i stället för att förvandla den till ett andra driftsättningsprojekt med egna nycklar och avtal.

Hur man bestämmer sig på en minut

Om du behöver programvara som styr ett användargränssnitt – klickar, skriver, navigerar i en app den aldrig har sett – köper du en policy, och det är UI-Venus 2.9B. Budgetera för en 9B vLLM-driftsättning, läs den ännu inte avgjorda licensfrågan innan du binder dig kommersiellt, och behandla leverantörens benchmarktabell som en stark utgångshypotes snarare än ett fastställt resultat, särskilt OSWorld-Verified-jämförelserna som kortet självt flaggar som scaffold-beroende.

Om du redan kör LFM2.5-VL-3B och vill få det snabbare på hårdvara du äger, köper du en runtime-optimering, och det är LFM2.5-VL-3B-DSpark. Kontrollera tre saker först: att dina arbetsbelastningar är decode-tunga snarare än prefill-tunga, att du serverar i 16-bit snarare än en 4-bitsexport, och att din runtime uppfyller versionsgolven. Om alla tre stämmer är minneskostnaden 8,9 % och utdata är oförändrad till sin konstruktion.

Det enda som inte överlever kontakten med något av repona är att behandla dem som substitut. De är en hastighetsmultiplikator och en agent, och det enda scenario där de konkurrerar är det där du redan har bestämt vad du bygger och letar efter en anledning att bygga något billigare i stället.

OrcaRouter når 200+ modeller via en enda nyckel till leverantörens listpris med 0 % påslag, med routningspolicy och automatisk failover för de frågor som en edge-modell eller en agent inte bör ta. ett API för reservvägen Ingen av modellerna på den här sidan finns där – båda körs från dina egna vikter – men reservvägen är den del du inte behöver bygga.