Una card del titolo generata con scritto 'WeVisOne-VL-4B vs MiniCPM-V 4.7 1B' con il sottotitolo 'Spendere token visivi o comprimerli via?' e tre chip: '1.960 token per immagine', 'compressione 4x e 16x' ed 'Entrambi Apache 2.0', sopra una griglia densa di quadrati e una pila corta con una freccia tra loro.
Guides & Insights

WeVisOne-VL-4B vs MiniCPM-V 4.7 1B: due scommesse opposte su a cosa serve un token visivo

Autore

Elias Hawthorne

Data di pubblicazione

Ultimi modelli · 20Vedi tutti i modelli →
Benchmark: Artificial Analysis · aggiornato ogni giorno
Torna a tutti gli articoli

MiniCPM-V 4.7 1B ottiene 86,1 su OCRBench. WeVisOne-VL-4B ottiene 52,0 su TotalText. Mettendo quei due numeri uno accanto all'altro, il modello 1B sembra superare il modello 4B di trentaquattro punti nella lettura del testo — il che sarebbe un risultato notevole, ed è anche un errore di categoria. OCRBench misura se un modello è in grado di trascrivere i caratteri in un'immagine. TotalText, come lo riporta Tencent, misura l'F1 per localizzare ciascuna istanza di testo attraverso soglie IoU da 0,5 a 0,95. Uno è riconoscimento, l'altro è geometria. MiniCPM-V 4.7 1B e WeVisOne-VL-4B sono stati rilasciati a nove giorni di distanza nell'ottobre 2026, entrambi da laboratori cinesi, entrambi Apache 2.0, e dissentono radicalmente su a cosa servano i token visivi: uno li comprime eliminandoli, l'altro li spende per la precisione.

Quel disaccordo è l'intero confronto. Tutto il resto — numero di parametri, memoria, righe di benchmark — ne deriva.

Compressione versus precisione

MiniCPM-V {{1}}4.7 1B{{/1}} eredita uno schema di compressione anticipata {{2}}intra-ViT{{/2}} da LLaVA-UHD v4 e lo espone come interruttore runtime tra compressione dei token visivi {{3}}4×{{/3}} e {{4}}16×{{/4}}. L'obiettivo è inserire più immagini, e più video, in un budget fisso: la model card dichiara un contesto di {{5}}262,144 token{{/5}}, un valore predefinito di 128 frame video e uno schema di tiling {{6}}448×448{{/6}} con un numero di slice configurabile. Comprimi presto, mantieni la sequenza breve e un modello 1B può guardare un video lungo su un telefono.

WeVisOne-VL-4B fa la scelta opposta. La sua valutazione viene eseguita con un massimo di 1.960 token visivi per immagine e il suo decoder di pixel opera sulle feature ViT pre-merging, mantenendo deliberatamente il dettaglio ad alta risoluzione che la compressione iniziale scarta. Ecco perché può produrre un alpha matte a risoluzione piena a stride 1 e perché non può affatto elaborare una griglia video: il decoder la rifiuta. La precisione costa token, e i token costano latenza.

Nessuna delle due scommesse è sbagliata. Sono risposte a domande diverse. MiniCPM chiede "quanto posso vedere in una volta su un telefono?" WeVisOne chiede "con quanta precisione posso descrivere dove si trova una cosa?"

La storia delle dimensioni è più strana di 1B contro 4B

• Parametri — WeVisOne-VL-4B 4,83B denso vs MiniCPM-V 4.7 1B denominato 1B, sebbene i metadati del suo repository indichino 2B in BF16

• Formato dei pesi — safetensors F32 a circa 19 GB rispetto a BF16 a circa 3,1 GB, oppure 0,67 GB con Q4_K_M più un proiettore visivo da 0,90–1,11 GB

• Contesto — non pubblicato per WeVisOne-VL-4B rispetto a 262.144 token sulla carta per MiniCPM-V 4.7 1B

• Video — rifiutato dal decodificatore pixel rispetto a 128 frame per impostazione predefinita

• Input multimodale — singola immagine per turno rispetto a immagine e video

• Quantizzazione — nessuna distribuita dal fornitore rispetto alle varianti int4, AWQ, GPTQ, GGUF e FP8

• Runtime sul dispositivo — nessuno vs iOS, Android, HarmonyOS, oltre a llama.cpp e Ollama

• Licenza — Apache 2.0 per il codice scritto da Tencent vs Apache 2.0

La riga della memoria è quella che ridefinisce il confronto. Un modello da 1B a quattro bit sta in meno di un gigabyte prima del proiettore visivo; un modello da 4.83B in F32 ne richiede circa diciannove. Non sono concorrenti per lo stesso slot. Uno è un componente che distribuisci all'interno di un'applicazione; l'altro è un servizio che esegui su una GPU.

A generated scoreboard titled 'WeVisOne-VL-4B vs MiniCPM-V 4.7 1B - the scoreboard'. Left column: Parameters 4.83B dense, Visual tokens up to 1,960, Context unpublished, Pixel output masks and alpha mattes, Video rejected, License Apache 2.0. Right column: Parameters 1B name and 2B metadata, Visual tokens 4x / 16x compression, Context 262,144 on paper, Pixel output none, Video 128 frames default, License Apache 2.0. Footer: 'Both sets vendor-reported; no shared benchmark and no independent run.'

Leggere le righe del benchmark senza ingannare te stesso

Entrambi i fornitori hanno pubblicato tabelle, ed entrambe le tabelle sono auto-selezionate. MiniCPM-V 4.7 1B riporta OCRBench 86,1, MathVista 74,3, CharXiv Reasoning 48,8, LongVideoBench 53,4 e MotionBench 54,55. WeVisOne-VL-4B riporta LVIS F1 mean 55,3, RefCOCOg test 81,8, PixMo-Count test 89,6, TotalText F1 mean 52,0, ReasonSeg val gIoU 71,2 e P3M-500-NP MAD 7,3. Non compare nemmeno un benchmark in entrambi gli elenchi. Non esiste un modo difendibile per calcolare un vincitore da questi documenti, e qualsiasi articolo che lo faccia sta inventando un risultato.

A screenshot of the Hugging Face model card for tencent/WeVisOne-VL-4B, captured 23 October 2026, showing the Image-Text-to-Text tag, an apache-2.0 licence label, a model size of 5B params in F32, and a note that the model is not deployed by any Inference Provider.

La lettura equa è più ristretta e comunque utile. MiniCPM-V 4.7 1B è insolitamente forte nel ragionamento sulle immagini per le sue dimensioni: un 74,3 su MathVista da un modello che sta in un telefono è il numero di cui i suoi autori sono più orgogliosi, ed è dichiarato dal fornitore e non replicato. WeVisOne-VL-4B è insolitamente forte nel produrre geometria: maschere, matte, riquadri e un tasso di rifiuto misurato del 96,4% su WeRef-Bench quando l'oggetto non è presente. La scheda di MiniCPM non pubblica alcuna metrica di rifiuto, e quella di WeVisOne non pubblica alcun benchmark di ragionamento. Ogni modello tace esattamente là dove l'altro è esplicito.

Ciò che ciascuno non può fare

WeVisOne-VL-4B non può guardare un video, non può sostenere una conversazione a più turni su un'immagine e non può essere eseguito su un telefono. Non ha un dato pubblicato sui token al secondo né build quantizzate, il che significa che chiunque lo distribuisca si impegna a usare una GPU e a misurare da sé il throughput. Il codice di fine-tuning è ancora una casella non spuntata nella TODO list del progetto.

MiniCPM-V 4.7 1B non può restituire una maschera o un alpha matte. Ti dirà che nell'immagine c'è una persona e all'incirca dove; non ti fornirà un ritaglio dai bordi morbidi. Comporta anche i rischi ordinari di una famiglia di modelli completamente nuova: un nuovo model_type in Transformers, un requisito di versione minima 5.18.0 e prime segnalazioni di malfunzionamenti nella decodifica video in alcune combinazioni di CUDA e torchcodec. Il suo contesto da 262K è un dato sulla carta — non è stato dimostrato che il post-addestramento lo sfrutti appieno.

A screenshot of the Hugging Face model card for openbmb/MiniCPM-V-4.7-1B, captured 23 October 2026, showing 403 likes, 78,345 downloads last month, 2B params in BF16, an apache-2.0 licence, support for iOS, Android and HarmonyOS, day-0 chip support for Rockchip, Houmo, Intel, AMD and Arm, and mixed 4x/16x visual token compression.

Il costo di una seconda chiamata

In pratica questi due modelli non sono sostituti, e l'architettura interessante li usa entrambi: un modello piccolo ed economico per descrivere e ragionare sull'immagine, e un modello di percezione per restituire la geometria. Questo trasforma una chiamata di inferenza in due, ed è qui che il costo smette di essere una nota a piè di pagina.

Il contributo di OrcaRouter a quella forma è quello noioso che conta — una singola chiave per oltre 200 modelli, con il prezzo di listino del provider trasferito a un markup dello 0% e failover automatico quando un endpoint upstream si degrada. Un taglio di prezzo del fornitore sul lato generalista arriva sul nostro lato lo stesso giorno, perché non c'è alcun livello di markup da aggiornare. Né WeVisOne-VL-4B né MiniCPM-V 4.7 1B sono oggi in quel catalogo, quindi la metà della pipeline dedicata alla percezione è ancora qualcosa che devi ospitare tu. Quello che eviti è un secondo contratto e un secondo set di credenziali per la metà che lo è.

Come eseguiresti l'uno o l'altro

WeVisOne-VL-4B è l'installazione più impegnativa. La model card documenta Transformers, vLLM, SGLang e Docker Model Runner, ma mask_decoder.pt è un componente obbligatorio: se carichi il checkpoint senza il pacchetto di inferenza del progetto ottieni box e testo, nessuna maschera. La decodifica è greedy fino a 1.960 token visivi per immagine, e non esiste una cifra pubblicata di throughput, quindi la prima cosa che farai sul tuo hardware è misurarla.

MiniCPM-V 4.7 1B è quello più semplice. Richiede Transformers 5.18.0 o versione successiva, e con esso è arrivato l'ecosistema: build per llama.cpp, Ollama, SGLang e vLLM, oltre alle quantizzazioni int4, AWQ, GPTQ e FP8, e a un modello draft separato DSpark da 213 milioni di parametri per il decoding speculativo. Se il tuo obiettivo è un telefono, una macchina Intel o una scheda Rockchip, questa è la strada con l'asfalto già pronto.

Quale scommessa prendere

Se il vincolo è il dispositivo, scegli MiniCPM-V 4.7 1B. Nulla in WeVisOne-VL-4B è pensato per un telefono, e la quantizzazione, il supporto runtime e la gestione video sul fronte MiniCPM sono il prodotto di un laboratorio che ha distribuito diverse generazioni di modelli on-device.

Se il vincolo è l'output — ti servono maschere, matte, box densi per piccoli oggetti o una risposta affidabile "non presente" — prendi WeVisOne-VL-4B e prevedi il budget per la GPU. Tieni presente che stai lavorando su un paper di due giorni fa senza valutazione indipendente, e che i numeri del matting sono quelli di Tencent.

Se ti servono entrambe le cose, ti servono due modelli. Questa è la conclusione onesta, ed è quella che supportano le tabelle di benchmark degli stessi due fornitori: hanno ottimizzato per cose diverse e nessuno dei due ha cercato di battere l'altro.