WeVisOne-VL-2B vs LFM2.5-VL-3B: un creatore di maschere contro un lettore di schermo

Date a entrambi i modelli la stessa fotografia e la stessa frase — «il cane a sinistra» — e ottenete due cose diverse. LFM2.5-VL-3B risponde con una posizione e, se gliela chiedete, con una descrizione: un riquadro, un punto o una breve frase su ciò che ha trovato. Anche WeVisOne-VL-2B risponde con un riquadro, e poi un piccolo decoder trasforma quel riquadro in una alpha matte dai bordi morbidi che potresti comporre su uno sfondo nuovo senza un alone attorno al pelo. Un modello è stato progettato per leggere un'interfaccia e rispondere. L'altro è stato progettato per consegnarti i pixel.

Quella differenza è l’intero confronto, e resiste a ogni tabella di benchmark pubblicata da uno qualunque dei due fornitori. Spiega anche perché i due modelli siano raramente valutati l’uno contro l’altro: la scheda di Liquid AI non menziona WeVisOne, il paper di Tencent non menziona Liquid, e nessuna terza parte li ha messi a confronto fianco a fianco. Quanto segue è ciò che ciascun rilascio ha effettivamente messo nero su bianco, quali dei loro numeri possono essere accostati tra loro e quali no.

Due release, due quantità di prove molto diverse

LFM2.5-VL-3B è stato pubblicato da Liquid AI l'11 agosto 2026 — prima i pesi, l'annuncio il giorno successivo — ed è arrivato con una tabella numerica di benchmark, una baseline nominata per ogni riga e una sezione sulla velocità misurata su hardware specificato. È un modello denso da 3,12 miliardi di parametri: un backbone linguistico LFM2.5-2.6B abbinato a un encoder visivo SigLIP2 NaFlex 400M, una finestra di contesto di 32.768 token, un vocabolario di 128.000 token e sedici lingue dichiarate. La sua licenza è la LFM Open License v1.0 di Liquid, gratuita per uso commerciale al di sotto di una soglia di ricavi anziché gratuita senza condizioni.

WeVisOne-VL-2B è stato pubblicato dal team WeChat Vision di Tencent il 22 ottobre 2026, e la sua scheda modello non contiene alcuna tabella di benchmark — nessun punteggio, nessuna lunghezza del contesto, nessun dato di throughput, nessun requisito hardware. I numeri esistono, ma sono nell'articolo di accompagnamento, che riporta sette tabelle di task relative a quelli che gli autori descrivono come più di trenta benchmark. Quindi le due release non sono solo modelli diversi; sono tipi diversi di documento. Liquid ha pubblicato una specifica di prodotto. Tencent ha pubblicato un risultato di ricerca e ha lasciato la scheda tecnica in gran parte vuota.

Quell'asimmetria conta quando si legge un confronto come questo. I dati di Liquid sono stati messi insieme per essere letti rispetto ai suoi stessi valori di riferimento. Quelli di Tencent sono stati messi insieme per vincere una tabella accademica. Nessuno dei due fornitori ha scelto i propri numeri pensando all'altro modello, ed è proprio per questo che i numeri non coincidono.

Il numero che sembra comparabile e non lo è

Entrambi i modelli pubblicano un punteggio RefCOCO e, mettendoli fianco a fianco, si ottiene un titolo dall'aria pulita: LFM2.5-VL-3B a 87,9 contro WeVisOne-VL-2B a 79,7. Quel confronto è privo di significato, e vale la pena spiegare perché, dato che lo stesso errore viene commesso proprio ora nei fogli di calcolo.

• Liquid riporta RefCOCO precision@1 mediata tra gli split. Si tratta di una statistica di rilevamento: il box previsto con il punteggio più alto si sovrapponeva sufficientemente al box di verità di riferimento da essere considerato corretto.

• Il 79,7 di Tencent è riportato in una tabella di segmentazione, e l'articolo afferma chiaramente che le cifre della famiglia RefCOCO ivi riportate sono IoU cumulativa — intersezione totale sull'unione totale su tutto il set di valutazione.

• La tabella di rilevamento referenziale di Tencent non riporta affatto RefCOCO. Riporta RefCOCOg, dove il 2B ottiene un F1 medio di 77,1.

Quindi l'87,9 e il 79,7 misurano tre cose diverse in due compiti diversi. Un box che si sovrappone appena a un target può ottenere un buon punteggio su precision@1 e uno scarso su cIoU; una maschera che copre bene un oggetto grande può ottenere un punteggio elevato su cIoU mentre il suo bounding box è approssimativo. Non esiste un'aritmetica che li riconcili.

La stessa trappola si annida nell'OCR. Liquid pubblica OCRBench v1 a 84,2 e OCRBench v2 English a 47,5 — benchmark di trascrizione. Tencent pubblica l'OCR come F1 di localizzazione con una soglia IoU di 0,5: 62,1 su SROIE, 42,6 su ICDAR2015, 42,5 su TotalText, 30,5 su HierText. Questi misurano se il modello ha trovato e racchiuso il testo in un riquadro, non se lo ha letto correttamente. Citare "84,2 contro 62,1" significherebbe confrontare un test di lettura con un test di indicazione.

Che cos’è in realtà un confronto equo?

Togli i punteggi e i due modelli si allineano lungo dimensioni che non richiedono un harness:

• Dimensioni — circa 3,12B parametri densi per LFM2.5-VL-3B rispetto a circa 2B per WeVisOne-VL-2B, più un decoder da 9,5M di parametri che deve essere scaricato separatamente ed è necessario per gli output densi.

• Base — la backbone ibrida LFM2.5-2.6B proprietaria di Liquid rispetto a Qwen3-VL.

• Contesto — 32.768 token pubblicati sulla scheda rispetto a nessuna lunghezza di contesto pubblicata. Le fasi di addestramento del paper WeVisOne sono state eseguite a 4.096 e 8.192 token, e l'inferenza limita ciascuna immagine a 1.960 token visivi, ma nulla di tutto ciò costituisce una finestra di deployment.

• Tipi di output — box, punti e testo rispetto a box, punti, maschere binarie e alpha matte continui.

• Ragionamento — LFM2.5-VL-3B è deliberatamente non-reasoning e risponde direttamente per mantenere bassa la latenza; anche WeVisOne è non-reasoning, ma per un motivo diverso: genera output strutturato senza catena di pensiero per garantire efficienza inferenziale. Nessuno dei due modelli "pensa" prima di rispondere, e nessuno dei due vendor finge il contrario.

• Chiamata di strumenti — supportata e sottoposta a benchmark su LFM (ToolSandbox 59,5, BFCL v4 32,5) contro una capacità non dichiarata su WeVisOne.

• Lingue — sedici indicate sulla scheda LFM rispetto a non specificate sulla scheda WeVisOne.

• Licenza — LFM Open License v1.0, con una soglia di ricavi, rispetto ad Apache 2.0 per il codice scritto da Tencent.

• Build quantizzate — esportazioni GGUF, ONNX e MLX offerte da Liquid vs nessuna annunciata da Tencent.

• Valutazione indipendente — al momento della stesura, nessuno dei due modelli ha una voce su Artificial Analysis. Ogni numero in questo articolo, da entrambi i fornitori, è dichiarato dai fornitori.

Il divario di implementazione è più ampio del divario nei parametri

LFM2.5-VL-3B è stato progettato per funzionare su un telefono e la scheda lo dimostra con i numeri: meno di 3,3 GB di memoria, 20 token al secondo su un Galaxy S26 Ultra, 228 token al secondo su un Apple M5 Max, 116 su un AMD Ryzen AI Max+ 395 e circa 11.000 token di output al secondo con elevata concorrenza su una singola H100. Viene distribuito in formati che i runtime consumer possono effettivamente caricare.

WeVisOne-VL-2B non pubblica nulla di tutto ciò. Ciò che pubblica implica un conto diverso. Lo stadio finale del decoder produce una alpha matte a risoluzione piena con stride 1, il che significa che l'output denso ha le dimensioni dell'immagine di input anziché essere un vettore di dimensione fissa — un costo che scala con la risoluzione, non con il numero di parametri. Per un modello 2B su una GPU moderna è gestibile. Per un telefono, non è affatto detto che sia gestibile, e Tencent non ha affermato che lo sia.

La conseguenza pratica è che questi due modelli non competono per lo stesso slot di deployment. Uno è un componente che potresti distribuire all'interno di un'app. L'altro è un componente che eseguiresti su un server, o su una workstation, accanto a qualunque altra cosa debba essere mascherata.

Scegli in base al tipo di output, non al punteggio

Se il compito è leggere uno schermo — analizzare un flusso di pagamento, trovare il pulsante etichettato "Continue", estrarre una tabella da un documento fotografato — LFM2.5-VL-3B è il candidato ovvio. Ha ScreenSpot-v2 a 80,7, DocVQA a 91,1, ChartQA a 81,3 e un punteggio ToolSandbox che suggerisce che può agire su ciò che vede anziché limitarsi a descriverlo. Ha anche una media di 69,4 su 28 benchmark che Liquid pubblica rispetto a modelli sibling esplicitamente nominati, il che almeno ti dice come il fornitore immagina il proprio vicinato.

Se il compito è isolare un oggetto — un ritaglio di prodotto, una persona su uno sfondo caotico, un primo piano con capelli svolazzanti o un bordo trasparente — LFM2.5-VL-3B non produce quel risultato e nessun prompt, per quanto accurato, riuscirà a farglielo fare. WeVisOne-VL-2B sì, e il margine nelle tabelle di matting è ampio: 6,6 di differenza media assoluta contro 15,4 di SAM2-Matting su P3M-500-NP, 15,8 contro 23,0 per una pipeline Qwen3-VL-8B più SAM2 sullo split WeRefMat con prompt linguistico.

C’è un altro caso in cui WeVisOne presenta un’affermazione degna di nota: l’assenza. Tencent riporta un tasso di rifiuto del 50,2% su RefCOCOg per le query il cui target non è nell’immagine, rispetto a 0,5 e 0,6 di due modelli di grounding specializzati sulla stessa tabella. Se la tua pipeline elabora migliaia di ritagli e la maggior parte non contiene nulla che ti interessi, un modello che dice in modo affidabile "non c’è" ti risparmia un classificatore a valle. La scheda di LFM2.5-VL-3B non riporta un dato di rifiuto comparabile, quindi non c’è nulla da mettergli accanto — una lacuna nelle prove, non una perdita.

Niente di tutto ciò è un motivo per scegliere uno e ritirare l'altro, e vale la pena essere onesti su dove si colloca un router. OrcaRouter non serve nessuno dei due modelli; nessuno dei due è nel nostro catalogo, e nessuno dei due è ospitato in un luogo che possiamo verificare, in particolare per WeVisOne. Quello che offriamo è lo stack circostante: se la tua pipeline usa un modello visione ospitato per la parte di lettura e un modello self-hosted per la parte di mascheramento, le chiamate ospitate passano attraverso una sola chiave API al prezzo di listino del provider, senza ricarichi, il failover le sposta su un altro provider quando uno peggiora, e il DSL di routing ti consente di mettere entrambe le parti dietro un unico endpoint, così la tua applicazione non sa mai quale delle due ha risposto.

Cosa lo risolverebbe davvero

Un banco di prova indipendente, gestito da qualcuno che non appartiene a nessuno dei due fornitori, sulle stesse immagini, che riporti sia una statistica di rilevamento sia una statistica di segmentazione per entrambi i modelli. Questo non esiste. Finché non esisterà, la posizione difendibile è quella noiosa: questi modelli rispondono a domande diverse, i loro numeri pubblicati sono misurati con strumenti diversi, e la scelta tra loro è determinata da ciò che il tuo codice a valle si aspetta di ricevere — una frase o una maschera.

Se da questo confronto devi portare via una sola cosa, porta via la forma delle prove. Liquid AI ti ha dato una tabella che puoi falsificare. Tencent ti ha dato un documento che puoi leggere e una scheda che ti dice, con franchezza, ciò che il modello non farà. Nessuno dei due ti ha dato un numero confrontabile con quello dell'altro, e qualsiasi articolo che stampi 87,9 accanto a 79,7 senza questa avvertenza ti sta vendendo una classifica che non esiste.