LFM3-VL-2B vs WeVisOne-VL-2B: tre giorni di distanza, scommesse opposte

LFM3-VL-2B è apparso su Hugging Face il 19 ottobre 2026. WeVisOne-VL-2B è apparso il 22 ottobre. Due modelli, entrambi intorno ai due miliardi di parametri, entrambi open-weight, entrambi provenienti da laboratori ben noti, pubblicati a 72 ore di distanza l'uno dall'altro. Ci si aspetterebbe che siano quasi sostituti. Sono più simili a scommesse opposte su cosa significhi "visione": uno risponde a domande su ciò che vede, l'altro restituisce la forma precisa di ciò che vede.

Questa distinzione è facile da sfuggire su una scheda tecnica, perché entrambe le schede elencano i box e entrambe elencano l'OCR. La differenza sta nel formato di output e nell'obiettivo di addestramento, e determina se puoi inserire uno dei due modelli in una pipeline senza uno strato di parsing. Determina anche quale dei due abbia una ragione d'essere dopo che i modelli general-purpose migliorano.

Due definizioni del vedere

LFM3-VL-2B è il modello generalista di Liquid AI. Accetta testo, immagini e video a 2 fps, restituisce testo, supporta il ragionamento passo passo, dispone di una finestra di contesto di 128K e copre 16 lingue. L'architettura è un modello denso da 1.92B — un backbone linguistico da 1.73B, un encoder visivo interno da 164M e un proiettore da 25M — con build BF16, GGUF, MLX a 4 bit e ONNX pubblicate. Il post che presenta la famiglia Liquid lo descrive come un modello in grado di «guardare, ragionare e comprendere il mondo fisico», e il percorso video è davvero nuovo per la famiglia.

WeVisOne-VL-2B è il modello di visione WeChat di Tencent. È costruito su un backbone Qwen3-VL con circa 2,4 miliardi di parametri sotto Apache 2.0, e il suo scopo è la percezione unificata: rilevamento open-vocabulary, localizzazione referenziale, conteggio, pointing, localizzazione OCR, segmentazione referenziale e alpha matting promptable. Restituisce coordinate normalizzate tramite token dedicati, oltre a maschere tramite un decoder pixel separato da 9,6 milioni di parametri che deve essere caricato insieme al modello linguistico.

Un modello è un lettore. L'altro è uno strumento di misura. La sovrapposizione nelle loro tabelle di benchmark è reale, ma è la sovrapposizione di due prodotti diversi che misurano la stessa scena.

Il formato dell'output è il prodotto

WeVisOne-VL-2B codifica le coordinate come token da <0> a <1000>, contrassegna ogni istanza con un token <OBJ> e restituisce None quando il target richiesto è assente. È quest'ultimo dettaglio quello che i professionisti notano: la scheda riporta un tasso di rifiuto di 50,2 su RefCOCOg, contro circa 0,5 per Rex-Omni e LocateAnything. È addestrato a dire "non è qui" anziché inventare un riquadro.

Il decoder dei pixel non è opzionale. La segmentazione e l'alpha matting richiedono mask_decoder.pt, un modulo da 9,6 milioni di parametri attivato dal token oggetto. Se carichi solo il modello linguistico, ottieni le coordinate ma non le maschere. Il repository GitHub include il pacchetto di inferenza che collega i due, e il modello è a turno singolo e solo immagini per progettazione: il decoder dei pixel rifiuta le griglie video.

LFM3-VL-2B non ha un contratto equivalente. Descriverà una regione, conterà oggetti o ragionerà su una scena in prosa, e la sua riga di grounding (RefCOCO-avg 90.5) suggerisce che è competente nella localizzazione. Ma l'output è testo. Per una pipeline che necessita di una maschera, la differenza tra 90.5 e un poligono analizzabile è la differenza tra una demo e un prodotto.

Numeri di ancoraggio che non puoi sottrarre

Le due schede riportano entrambe risultati della famiglia RefCOCO, e non sono la stessa misurazione. LFM3-VL-2B riporta RefCOCO-avg 90,5, che calcola la media degli split delle espressioni referenziali. WeVisOne-VL-2B riporta RefCOCOg 77,1 F1 medio per il rilevamento referenziale e RefCOCO testA 82,9 cIoU per la segmentazione referenziale. RefCOCOg è uno split diverso con espressioni più lunghe e più conversazionali; cIoU è una metrica diversa da F1.

Sottrarre 77,1 da 90,5 produce un numero che non significa nulla. La lettura onesta è che entrambi i modelli sono forti nella localizzazione referenziale sui propri harness, che nessuno dei due harness è stato riprodotto in modo indipendente e che le definizioni delle metriche differiscono abbastanza da lasciare la classifica irrisolta. La stessa cautela vale per l'OCR: LFM3-VL-2B riporta OCRBench v1 86,3, mentre WeVisOne-VL-2B riporta OCR HierText 30,5, che è un benchmark diverso su un dataset più difficile.

Dove il confronto è limpido, favorisce lo specialista sul suo terreno: WeVisOne-VL-2B riporta un F1 di rilevamento COCO di 55,2, LVIS 53,3 e Dense200 61,4, rispetto a un modello che non pubblica affatto un F1 di rilevamento. Non è una vittoria per default. È un promemoria del fatto che il generalista non è stato addestrato per essere valutato in quel modo.

Il matte è il fossato

Il matting alfa con prompt è la funzionalità che né LFM3-VL-2B né la maggior parte dei modelli della sua classe dimensionale offre. WeVisOne-VL-2B riporta una differenza media assoluta di 6,6 su P3M-500-NP per i matte con bordi morbidi — il confine semi-trasparente attorno a capelli, vetro e pelliccia che una maschera di segmentazione binaria trasforma in un taglio netto. La scheda è schietta sui limiti: i confini alfa fini si degradano in presenza di occlusione, bassa risoluzione e trasparenza. Ma per i ritagli di prodotto, il compositing e la sostituzione dello sfondo, un matte è l'output di cui la pipeline ha effettivamente bisogno.

Questo è l'argomento più forte a favore dell'esistenza del modello. Un generalista da 2B può descrivere un'immagine; non può consegnarti un canale alfa morbido. Tencent ha costruito un piccolo modello attorno a un decodificatore di pixel perché ottenere quell'output da un grande modello general-purpose è costoso, e il fratello da 4B esiste per i team che hanno bisogno di maggiore accuratezza nello stesso compito.

Video e pensiero sono l'altro fossato

Il fattore distintivo di LFM3-VL-2B va nella direzione opposta. Accetta video a 2 fps e riporta Video-MME 62.8 senza sottotitoli, MVBench 69.4 e MMMB 85.2. WeVisOne-VL-2B è a turno singolo e solo immagini; il suo decoder dei pixel rifiuta le griglie video. Se il tuo input è una clip, il confronto è chiuso prima ancora che inizi la tabella dei benchmark.

La modalità thinking aggiunge un secondo divario. LFM3-VL-2B riporta MathVista 84,2 con il thinking contro 68,5 senza, e MMMU 55,7 contro 48,6. WeVisOne-VL-2B non prevede il chain-of-thought per scelta progettuale, per efficienza. Si tratta di una scelta ingegneristica legittima per un componente di percezione e di un limite invalicabile per un modello con cui si vuole ragionare su un grafico.

Memoria, licenza e il prezzo d'ingresso

• Parametri — LFM3-VL-2B 1.92B denso vs WeVisOne-VL-2B circa 2.4B, più un decodificatore pixel da 9.6M.

• Memoria — circa 3,84 GB BF16 calcolati aritmeticamente per LFM3-VL-2B, con una build MLX a 4 bit; all'incirca 9,1 GB di pesi in F32 e una stima di 4,9 GB in BF16 per WeVisOne-VL-2B, secondo note di deployment di terze parti anziché la scheda.

• Input — testo, immagine e video a 2 fps rispetto a sola immagine e testo, singolo turno.

• Output — prosa, facoltativamente con ragionamento vs testo, coordinate normalizzate, maschere e alpha matte.

• Contesto — 128K vs non dichiarato come finestra su scala documentale; il vincolo è il decoder dei pixel.

• Licenza — LFM Open License v1.0, uso commerciale sotto i $10M di ricavi annuali rispetto ad Apache 2.0 a qualsiasi dimensione.

• Pubblicato — repository 19 ottobre 2026, annuncio della famiglia 27 ottobre vs repository 22 ottobre 2026.

La riga della licenza è l'opposto della storia abituale. Il modello di Tencent è quello con licenza permissiva; quello di Liquid è quello con un tetto di ricavi. Per un'azienda che sviluppa un prodotto di percezione commerciale, Apache 2.0 elimina un elemento di due diligence che la licenza LFM crea. Ciò non rende i modelli intercambiabili, ma significa che il modello più piccolo e più generale porta con sé il vincolo legale maggiore.

Nessuno dei due modelli ha un prezzo per la versione hosted

Entrambe le schede pubblicano i pesi e nessuna delle due pubblica una tariffa API per token. Hugging Face non elenca alcun provider di inferenza per LFM3-VL-2B; anche la scheda di WeVisOne-VL-2B non presenta un endpoint ospitato, sebbene esistano port comunitari per LiteRT, Core AI, GGUF e Android. Questa è l'attuale configurazione del tier vision da 2B: i pesi sono gratuiti, il serving è a tuo carico e il costo reale è dato dalla GPU e dal lavoro di integrazione.

Se preferisci noleggiare quella fascia invece di possederla, OrcaRouter instrada modelli vision hosted — tra cui Qwen3-VL-8B — attraverso un'unica API con il prezzo di listino del provider trasferito senza ricarico, allo 0% di markup, e con la fusione di modelli se vuoi che un modello di percezione e un modello di ragionamento rispondano come un panel. Non serviamo nessuno dei due checkpoint in questo confronto, e nulla qui implica che lo facciamo. Il punto rilevante è che noleggiare un modello hosted leggermente più grande è una terza opzione legittima quando nessuno dei due modelli open-weight è disponibile con un endpoint.

Come scegliere

• Scegli WeVisOne-VL-2B se l'output è di tipo geometrico: box, maschere, alpha matte, conteggi o un segnale di "non presente". Sceglilo se Apache 2.0 non è negoziabile, o se stai costruendo una pipeline di cut-out, compositing o percezione robotica.

• Scegli LFM3-VL-2B se l'input include video, se hai bisogno di ragionamento su un grafico o un modulo, oppure se vuoi un unico piccolo modello che risponda a domande generali anziché misurare forme.

• Prendili entrambi solo se sei pronto a gestire due pipeline. Condividono una classe di parametri e quasi nient'altro, e il costo di integrazione del far finta del contrario è superiore al costo del secondo modello.

Il divario di tre giorni tra i loro repository è una coincidenza. La divergenza in ciò che restituiscono non lo è. Due laboratori hanno esaminato lo stesso budget 2B e l'hanno speso per output diversi, e la domanda giusta non è quale sia migliore — è quale output il tuo prossimo passo della pipeline possa effettivamente consumare.