WeVisOne-VL-4B vs LFM2.5-VL-3B: uno specialista del matting contro un velocista edge

Liquid AI pubblica un dato di velocità per LFM2.5-VL-3B e Tencent non ne pubblica nessuno per WeVisOne-VL-4B. Quell'asimmetria, più di qualsiasi riga di benchmark, è la sfida. LFM2.5-VL-3B è un modello edge da 3,1 miliardi di parametri ottimizzato per rispondere in un solo passaggio: 228 token al secondo su un Apple M5 Max, 20 token al secondo su un Galaxy S26 Ultra, meno di 3,3 GB di memoria, sedici lingue. WeVisOne-VL-4B è un modello di percezione da 4,83 miliardi di parametri che spenderà fino a 1.960 token visivi e un decoder da 9,6 milioni di parametri per consegnarti un alpha matte a piena risoluzione. Uno è costruito per essere abbastanza veloce da stare dentro l'interfaccia di un telefono; l'altro è costruito per produrre pixel. Si sovrappongono sulla parola "vision" e quasi da nessun'altra parte.

Ciò rende questo un confronto che vale la pena fare con attenzione, perché la versione ovvia — affiancare le tabelle dei benchmark, dichiarare un vincitore — sarebbe sbagliata in un modo specifico e istruttivo.

Le tabelle di benchmark non comunicano tra loro

Entrambi i modelli pubblicano numeri sulle espressioni referenziali ed entrambi i numeri sembrano comparabili. Non lo sono. LFM2.5-VL-3B riporta un P@1 medio su RefCOCO pari a 87,9. WeVisOne-VL-4B riporta un F1 medio sul test RefCOCOg pari a 81,8. Split del dataset diverso, metrica diversa, modello di errore diverso: P@1 chiede se il box classificato al primo posto è corretto, l'F1 medio calcola la media di precisione e richiamo su soglie IoU da 0,5 a 0,95. Un modello può vincere su una e perdere sull'altra con un ampio margine senza che nessuno dei due risultati sia sorprendente.

La stessa trappola è presente in ogni altra riga. Il punteggio 80,7 di Liquid su ScreenSpot-v2 misura il grounding degli elementi UI; Tencent non ha un numero ScreenSpot. Il tasso di rifiuto del 96,4% di Tencent su WeRef-Bench misura se il modello rifiuta di rispondere quando l'oggetto non è presente; Liquid non pubblica affatto una metrica di rifiuto. Nessuno dei due vendor ha valutato il modello dell'altro, quindi nessuna riga in nessuna delle due tabelle è un confronto testa a testa.

Ciò che si può dire onestamente è indicativo. LFM2.5-VL-3B è un forte generalista per la sua dimensione — una media di 69,4 su 28 benchmark di visione secondo il conteggio di Liquid, a 0,7 punti da Qwen3.5-4B — e il suo salto in ScreenSpot-v2 da quasi zero nella generazione precedente a 80,7 è il singolo miglioramento più ampio nella sua tabella. WeVisOne-VL-4B non compete su quell'asse. Le sue affermazioni più forti riguardano il rilevamento denso di piccoli oggetti, il rifiuto e l'output a livello di pixel, nessuno dei quali LFM2.5-VL-3B tenta.

Che cosa è fisicamente ciascun modello

• Parametri — WeVisOne-VL-4B 4,83B denso (checkpoint F32) vs LFM2.5-VL-3B 3,12B denso (BF16)

• Percorso visivo — un backbone Qwen3-VL più un decoder pixel da 9,6M rispetto a una base testuale ibrida convoluzione-attenzione LFM2.5-2.6B più un encoder SigLIP2 NaFlex 400M

• Memoria — circa 19 GB su disco per il checkpoint F32 4B, contro meno di 3,3 GB di occupazione totale per il 3B

• Contesto — nessun dato pubblicato per WeVisOne-VL-4B rispetto a 32.768 token per LFM2.5-VL-3B

• Lingue — non specificate per WeVisOne-VL-4B rispetto a 16 per LFM2.5-VL-3B, con un vocabolario da 128K costruito per sistemi di scrittura non latini

• Tipi di output — box, punti, maschere e alpha matte vs solo box e testo

• Licenza — Apache 2.0 per il codice realizzato da Tencent rispetto alla LFM Open License v1.0

• Velocità — non pubblicata vs 228 tok/s su un M5 Max, 116 tok/s su un Ryzen AI Max+ 395, 20 tok/s su un Galaxy S26 Ultra

Il divario di capacità che decide davvero

LFM2.5-VL-3B può dirti dove si trova una persona in un'immagine. WeVisOne-VL-4B può dirti dove si trova una persona, restituire una maschera binaria per quell'istanza e restituire un alpha matte continuo con bordi morbidi — capelli, pelliccia, tessuti trasparenti, motion blur — a piena risoluzione. Questa è una differenza categoriale, non una differenza di qualità. Se il tuo prodotto deve comporre un soggetto su uno sfondo nuovo, ritagliare la foto di un prodotto o gestire la sostituzione dello sfondo di una videochiamata, LFM2.5-VL-3B non ha nulla da offrirti e nessun prompt engineering può cambiarlo.

Esegui il confronto nell'altro senso e succede la stessa cosa. Se il tuo prodotto deve trovare un pulsante sullo schermo di un telefono in 40 millisecondi, WeVisOne-VL-4B è del tutto inadatto: è un modello da 4,83B senza alcun dato di latenza pubblicato, senza build quantizzate per l'edge e con un decoder che presuppone un'immagine per turno. Liquid distribuisce build GGUF, MLX, ONNX e native, oltre a una finestra di contesto da 32K e benchmark di tool-calling. Tencent distribuisce un pacchetto di inferenza per la ricerca e serving vLLM/SGLang.

Il rifiuto è la rubrica sottovalutata

Una capacità nella tabella di Tencent merita attenzione anche se non ti occupi mai di matting. Su WeRef-Bench, WeVisOne-VL-4B rifiuta correttamente il 96,4% delle query relative a oggetti che non sono nell'immagine, contro il 73,0% del miglior baseline elencato dagli autori; su PR-Bench il tasso di rifiuto è del 52,6% contro il 10,8% di Qwen3-VL-4B. Il modello restituisce None invece di inventare un box. Un rilevatore che allucina è peggiore di nessun rilevatore, perché il fallimento è silenzioso e il codice a valle si fida di esso.

La documentazione di LFM2.5-VL-3B non riporta un dato di rifiuto, quindi non c’è nulla con cui confrontarsi — che è proprio il punto. L’assenza di prove non è un fallimento, ma se stai costruendo un agente che decide se cliccare qualcosa, la presenza di un tasso di rifiuto misurato è un motivo concreto per guardare prima al modello Tencent.

Il licensing è il differenziatore silenzioso

È qui che i due divergono in un modo che conta per chiunque distribuisca commercialmente. I pesi di WeVisOne-VL-4B sono Apache 2.0 per il codice scritto da Tencent, con i componenti di terze parti che mantengono le proprie condizioni. LFM2.5-VL-3B viene distribuito con la LFM Open License v1.0, che è gratuita per uso commerciale al di sotto di una soglia di ricavi e richiede un accordo commerciale al di sopra. Se siete un piccolo team, la differenza è teorica. Se non lo siete, uno di questi è una revisione legale e l'altro è una riga in un file delle dipendenze.

Nessuna delle due licenze ti concede un servizio in hosting. WeVisOne-VL-4B non ha alcuna API; LFM2.5-VL-3B è un rilascio di pesi, e qualsiasi hosting di terze parti è un accordo a sé. Dirlo chiaramente conta più di quanto non contasse prima, perché un modello senza endpoint è un impegno a possedere lo stack di inferenza.

Dove OrcaRouter è adatto, e dove non lo è

Nessuno di questi modelli è oggi nel catalogo di OrcaRouter, quindi qui non c’è nulla che permetta di chiamarli. Quello che la piattaforma offre è il contesto decisionale. La maggior parte dei team che valuta un VLM edge da 3B non sostituisce un modello con un altro — ne aggiunge un secondo accanto al modello general-purpose già in produzione, e il costo operativo di un secondo contratto con un fornitore, di una seconda chiave e di una seconda modalità di errore di solito uccide l’esperimento prima ancora che lo faccia il modello.

Instradare entrambi gli intenti attraverso un unico endpoint, con oltre 200 modelli dietro un'unica chiave a 0% di markup rispetto al prezzo di listino del provider, significa che il modello di percezione può essere una decisione di routing anziché un progetto di integrazione. Se il modello edge non è disponibile, il failover automatico invia la richiesta altrove invece di restituire un 503. Questa è la parte che OrcaRouter risolve davvero qui; i pesi e la GPU sono ancora tuoi.

Quale scegliere?

Scegli LFM2.5-VL-3B se il lavoro è vincolato dalla latenza e di tipo testuale: comprensione dello schermo, agenti UI, OCR di documenti con layout, traduzione sul dispositivo, tool calling. È più veloce di quasi qualsiasi cosa della sua dimensione, rientra nel budget di memoria di un telefono e Liquid ha pubblicato abbastanza numeri perché tu possa verificare le affermazioni rispetto al tuo carico di lavoro.

Scegli WeVisOne-VL-4B se il lavoro finisce in pixel. Segmentazione, matting, rilevamento denso di piccoli oggetti o qualsiasi pipeline in cui "il modello ha detto no" deve essere una risposta affidabile. Accetta di essere un early adopter: non esiste alcuna esecuzione indipendente di benchmark, non esiste alcun endpoint ospitato, il codice di fine-tuning è ancora nella lista TODO e il paper ha due giorni.

L'unica cosa da non fare è scegliere tra loro in base a un singolo punteggio di benchmark. Nessuno li ha confrontati tra loro, sugli stessi dati.