LFM3-VL-2B vs WeVisOne-VL-4B: Cosa si ottiene davvero con 2,5× i parametri

La tabella di benchmark di Tencent stessa depone contro l'acquisto ovvio. WeVisOne-VL-4B, il maggiore dei due modelli di percezione pubblicati dal team WeChat Vision il 22 ottobre 2026, è peggiore nell'alpha matting con prompt a riquadro rispetto al proprio fratello 2B: 7,3 di differenza media assoluta su P3M-500-NP contro il 6,6 del 2B, dove un valore più basso è migliore. Il modello rispetto al quale la maggior parte degli acquirenti lo valuterà davvero, però, non è il suo fratello ma LFM3-VL-2B — il modello di visione on-device da 1,92B di Liquid AI, i cui pesi sono comparsi il 19 ottobre e che è stato annunciato con il resto della famiglia LFM3 il 27 ottobre.

Mettili fianco a fianco e la domanda interessante non è quale dei due sia più intelligente. È che cosa ti danno in cambio due volte e mezzo i parametri, e quanto costano. La risposta breve, dalle stesse tabelle dei fornitori: ti danno rilevamento denso, accuratezza nel referring e un tasso molto migliore di rifiuto di rispondere quando l'oggetto non c'è. Non ti danno un generalista, non ti danno il video e non ti danno un modello che puoi mettere su un telefono. Tutto ciò che segue viene dalle due tabelle pubblicate con le cuciture lasciate visibili — nessun harness indipendente ha riprodotto i numeri di nessuno dei due modelli.

Che cosa ciascuno è in realtà

LFM3-VL-2B è un modello denso da 1,92 miliardi di parametri: un backbone linguistico da 1,73 miliardi, un encoder visivo interno da 164 milioni e un proiettore da 25 milioni. Il backbone è lo stack tri-ibrido di Liquid — 24 livelli suddivisi in 13 convoluzioni corte con gating, 5 livelli di attenzione a finestra scorrevole con una finestra di 256 token e 6 livelli di attenzione globale. Accetta testo, immagini e video alla risoluzione nativa, campionando i video a 2 fotogrammi al secondo, gestisce un contesto di 128K token, copre 16 lingue e offre una modalità di pensiero opzionale che produce un passaggio di ragionamento prima della risposta. Il suo output è prosa.

WeVisOne-VL-4B è costruito su un backbone Qwen3-VL ed è denominato 4B, sebbene i metadati di Hugging Face lo arrotondino a 5B e gli articoli di terze parti collochino il conteggio effettivo vicino a 4,83B. Non risponde tanto in prosa quanto emette geometria: riquadri e punti come token di coordinate normalizzate da 0 a 1000, un marcatore OBJ (id token 152678) dopo ogni riquadro previsto, e la stringa letterale None quando il target è assente. Maschere e alpha matte richiedono un secondo artefatto, mask_decoder.pt, un decodificatore pixel da 9,6M di parametri che prende lo stato nascosto di ciascun token OBJ e il riquadro previsto e restituisce alpha a risoluzione piena con stride 1. È a turno singolo e solo immagini, e genera direttamente output strutturato, senza catena di pensiero.

Il contrasto in un solo passaggio:

• Dimensioni — LFM3-VL-2B dense da 1,92B rispetto a WeVisOne-VL-4B da circa 4,83B, più un decoder da 9,6M obbligatorio per le maschere

• Input — testo, immagine e video a 2 fps rispetto a testo e una singola immagine

• Output — prosa e un passaggio di riflessione rispetto a token di coordinate, box, maschere, matte o un None esplicito

• Contesto — 128K token rispetto a nessun limite di inferenza pubblicato sulla scheda; il paper descrive l'addestramento a 4,096 e 8,192 token

• Copertura linguistica — 16 lingue dichiarate vs nessuna dichiarata

• Licenza — LFM Open License v1.0, gratuita per uso commerciale al di sotto di 10 milioni di dollari di fatturato annuo, rispetto ad Apache 2.0 per il codice scritto da Tencent

• Runtime — GGUF/llama.cpp, MLX a 4 bit, ONNX e BF16 vs BF16 tramite Transformers, vLLM o SGLang

L'aggiornamento è disomogeneo, e l'articolo mostra dove

WeVisOne-VL-2B e WeVisOne-VL-4B sono la stessa architettura su due scale, addestrati sullo stesso insieme di circa 100M immagini attraverso lo stesso curriculum in tre fasi, e valutati sulla stessa tabella. Questo rende il confronto tra fratelli la prova più limpida disponibile su cosa fanno i parametri extra — e non va in un'unica direzione.

Dove il 4B vince nettamente, stando ai numeri di Tencent:

• Rilevamento Dense200 — F1 medio 71,3 rispetto a 61,4, il maggiore incremento singolo

• LVIS — 55,3 vs 53,3, un modesto miglioramento di 2 punti

• Rilevamento referenziale RefCOCOg — 81,8 test vs 78,2

• Segmentazione referenziale RefCOCO — 84,5 cIoU su testA rispetto a 82,9

• ReasonSeg — 71,2 cIoU su val rispetto a 60,9, un salto di 10 punti nella segmentazione basata sul ragionamento

• Puntamento PointBench — 71,9 vs 62,9

• WeRefMat referring matting — 9,8 di differenza media assoluta sullo split referring rispetto a 15,8, una riduzione dell’errore del 38%

Dove non lo fa:

• P3M-500-NP imbottitura della cassa — 7,3 contro il 6,6 del 2B, peggiore

• Opacizzazione scatola PPM-100 — 6,1 vs 5,3, peggiore

• Ref-ZOM cIoU — 72,2 test contro 73,4, il 2B di nuovo in vantaggio

Lo schema è leggibile anche se la causa non è pubblicata: il 4B è avanti sui compiti difficili e condizionati dal linguaggio — referring segmentation, reasoning segmentation, referring matting su scene reali — e non offre nulla in più sui set di matting più facili con prompt box, dove entrambi i modelli sono già vicini al tetto e il decoder da 9.6M potrebbe stare facendo la maggior parte del lavoro. Due dei tre benchmark di matting con prompt box vanno nella direzione sbagliata. Se l'alpha matting su un box fornito è il tuo unico compito, il 4B non è un upgrade; è un modo più costoso per ottenere la stessa risposta, leggermente peggiore.

Oggetti assenti: meglio, ma non ancora risolto

La colonna più utile del paper è quella che quasi nessuna scheda di modello visivo pubblica. RefCOCOg-Rej è una variante in cui ogni espressione è modificata in modo che non esista alcun oggetto corrispondente nell'immagine. Un modello che non sa dire "no" inventerà un riquadro, e ogni ritaglio, conteggio e maschera a valle eredita quella fabbricazione.

WeVisOne-VL-4B rifiuta correttamente nel 67,4% dei casi, contro il 50,2% del 2B. Si tratta di un miglioramento reale e consistente — un guadagno di 17 punti che trasforma la modalità di fallimento di una pipeline da un lancio di moneta a due casi su tre. Significa anche che il 4B restituisce ancora un riquadro ad alta confidenza per circa una query su tre relativa a un oggetto assente. Sul WeRef-Bench interno di Tencent, il tasso di rifiuto è del 96,4%, ma quel benchmark è composto da 2.880 query in inglese e cinese costruite dal laboratorio stesso, quindi misura una distribuzione più favorevole rispetto a quella pubblica. Il riassunto onesto è che il modello ha un comportamento di astensione utilizzabile e non ha risolto il problema; se la tua applicazione non può tollerare una regione allucinata, serve una soglia o un controllo aggiuntivo, qualunque modello si scelga.

Il numero che sembra comparabile e non lo è

È allettante mettere il 90,5 RefCOCO-avg di LFM3-VL-2B accanto all'81,8 RefCOCOg di WeVisOne-VL-4B e annunciare una vittoria di 8,7 punti del modello più piccolo. Non fatelo. Sono split diversi e metriche diverse: Liquid riporta una media sull'intera famiglia RefCOCO, Tencent riporta l'F1 test di RefCOCOg per il rilevamento referenziale. Sottrarli produce un numero senza referente.

La stessa trappola si annida nell'OCR. LFM3-VL-2B ottiene 86,3 su OCRBench v1, un composito di riconoscimento del testo, spotting e ragionamento; WeVisOne-VL-4B ottiene un F1 medio di 52,0 su TotalText, un benchmark di localizzazione del testo in scena. Uno è un esame ampio, l'altro è un compito di predizione densa. Non sono la stessa capacità misurata due volte.

Quindi le due tabelle dei fornitori non si incrociano su un unico dato realmente confrontabile. Ciò che si può confrontare onestamente sono le funzionalità e i costi, ed è per questo che il resto di questo confronto riguarda l'idoneità più che una classifica. Chiunque pubblichi un vincitore basandosi su queste due tabelle se lo sta inventando.

La memoria è il vero prezzo

Nessuno dei due modelli ha un prezzo per token pubblicato al 28 ottobre 2026. La scheda di Liquid collega l'accesso API e Playground tramite la sua console, ma non è stato pubblicato alcun listino prezzi per LFM3-VL-2B; i tracker di terze parti che elencano le tariffe dei modelli testuali di Liquid non coprono il modello vision. Tencent non ha alcun endpoint ospitato. Dunque il confronto è un confronto di self-hosting, e il conto è espresso in memoria.

• LFM3-VL-2B — circa 3,84 GB in BF16 calcolati aritmeticamente dal numero di parametri, con build MLX a 4 bit, GGUF e ONNX pubblicate insieme

• WeVisOne-VL-4B — circa 9,7 GB in BF16 secondo stime di terze parti, circa 19 GB in F32, più il necessario mask_decoder.pt

Quel divario di 2,5× non è solo una GPU più grande. È una classe di dispositivo diversa. La scheda LFM3-VL-2B dichiara esplicitamente che il modello è pensato per il lavoro on-device — domande su video, documenti, grafici e schermate di app, individuazione di oggetti, ragionamento spaziale per i robot — e le build MLX a 4 bit e GGUF sono il modo in cui quella promessa viene mantenuta: un laptop, un telefono, un telaio robotico. I percorsi documentati di WeVisOne-VL-4B sono Transformers, vLLM e SGLang su BF16, senza alcuna build quantizzata ufficiale e senza runtime on-device. Vuole una GPU server.

Il supporto del framework conviene verificarlo sul proprio percorso anziché sulla tabella. Il video a 2 fps è una capacità del modello in LFM3-VL-2B, ma se un determinato runtime accetti una griglia video è una questione separata, e la model card, i port e le PR upstream non sono sempre stati d'accordo su questo. Testa la combinazione esatta che intendi rilasciare.

OrcaRouter non ospita nessuno dei due modelli. È stato verificato sul catalogo il 28 ottobre 2026, non dato per scontato — né la linea LFM3 di Liquid né WeVisOne di Tencent compaiono nell'elenco dei modelli — pertanto nulla di quanto segue va interpretato come una via d'accesso all'uno o all'altro. Ciò che il catalogo dei modelli OrcaRouter offre è Qwen3-VL-8B, nelle varianti instruct e thinking, che è l'opzione pragmatica se la tua esigenza effettiva è un modello vision ospitato con un prezzo pubblicato oggi anziché un checkpoint self-hosted. Una sola chiave dà accesso a tutto ciò al prezzo di listino del provider, senza ricarichi, e se stai prototipando con un modello open-weight non ancora comprovato, eseguirlo attraverso un router con failover è meglio che collegare un percorso di produzione a un checkpoint che non ha ancora ricevuto una valutazione indipendente.

Quale scegliere?

Scegli WeVisOne-VL-4B quando il risultato da consegnare è la geometria — maschere, alpha matte, box densi, conteggi, pointing — su immagini statiche, quando le query sono condizionate dal linguaggio anziché da prompt box, e quando hai una GPU da dedicare.

• Scegli WeVisOne-VL-2B invece del 4B quando il tuo compito è il matting con prompt a box su scene ordinarie; sui numeri pubblicati il modello più piccolo è migliore in questo e costa meno della metà della memoria

• Scegli LFM3-VL-2B quando l'input include video, quando il documento è lungo, quando la risposta deve essere una frase anziché un poligono o quando il dispositivo non è un server

• Non scegliere nessuno dei due se questa settimana ti serve un endpoint ospitato con un prezzo per token pubblicato — nessuno dei due fornitori lo offre, e nessuna quantità di benchmarking colma questa lacuna

• Scegli entrambi solo se accetti due schemi di output e due percorsi di integrazione; l'intervallo di parametri condiviso "circa da 2B a 5B" maschera due prodotti diversi

Cosa cambierebbe questo

Tre cose. Un harness indipendente che esegue entrambi i modelli sulle stesse immagini con gli stessi prompt — fino ad allora, tutto quanto sopra è una tabella del fornitore letta con attenzione, il che è meglio di una tabella del fornitore letta con noncuranza ma non è prova di qualità. Una build quantizzata di WeVisOne, o un runtime on-device, che sposterebbe l’argomento sulla memoria da decisivo a negoziabile. E un prezzo per token pubblicato da entrambe le parti, che sostituirebbe l’aritmetica sui gigabyte con un numero su cui si può basare un budget.

Il meno probabile dei tre è quello che conterebbe di più per questa specifica combinazione: il supporto video nel pixel decoder di WeVisOne. Al momento il generalista 2B accetta un video mentre lo strumento 4B non può, e nessun numero di parametri può rimediare a una modalità che non è mai stata addestrata.