WeVisOne-VL-4B 對比 MiniCPM-V 4.7 1B：關於視覺 token 用途的兩種相反押注

MiniCPM-V 4.7 1B 在 OCRBench 上得分 86.1。WeVisOne-VL-4B 在 TotalText 上得分 52.0。把這兩個數字並排放在一起，1B 模型似乎在閱讀文字上以三十四分之差勝過 4B 模型——這會是個驚人的結果，同時也是一種範疇錯誤。OCRBench 衡量的是模型能否轉錄圖像中的字元。而依照騰訊的報告方式，TotalText 衡量的是在 IoU 閾值 0.5 到 0.95 下定位每個文字實例的 F1。一個是辨識，另一個是幾何。MiniCPM-V 4.7 1B 與 WeVisOne-VL-4B 於 2026 年 10 月相隔九天發布，兩者都來自中國實驗室、都採 Apache 2.0，且它們對視覺 token 的用途有根本分歧：一個把它們壓縮掉，另一個則把它們用於提升精確度。

那個分歧就是整個比較的核心。其他一切——參數數量、記憶體、基準測試列——都由此而來。

壓縮與精確度的取捨

MiniCPM-V 4.7 1B 繼承了 LLaVA-UHD v4 的 ViT 內部早期壓縮方案，並將其作為 {{1}}4×{{/1}} 與 {{2}}16×{{/2}} 視覺 token 壓縮之間的執行階段切換功能。重點在於把更多影像與更多影片塞進固定預算：模型卡宣稱具備 {{3}}262,144 個 token{{/3}} 的上下文、預設 {{4}}128 幀影片{{/4}}，以及可設定切片數量的 {{5}}448×448{{/5}} 切片方案。提早壓縮、讓序列保持簡短，{{6}}1B{{/6}} 模型就能在手機上觀看長影片。

WeVisOne-VL-4B 則做出相反的取捨。它的評估每張影像最多使用 1,960 個視覺 token，且其像素解碼器作用於合併前的 ViT 特徵，刻意保留早期壓縮所捨棄的高解析度細節。這就是為什麼它能在 stride 1 下產生全解析度的 alpha matte，也是為什麼它完全無法處理視訊網格：解碼器會拒絕它。精確度耗費 token，而 token 耗費延遲。

兩個押注都沒有錯。它們是對不同問題的回答。MiniCPM 問的是「在手機上一次能看多少？」WeVisOne 問的是「我能多精確地描述某個東西在哪裡？」

規模的故事比 1B 對 4B 還要離奇

• 參數 — WeVisOne-VL-4B 為 4.83B 稠密模型，相較之下 MiniCPM-V 4.7 1B 標示為 1B，但其儲存庫中繼資料在 BF16 下列出 2B

• 權重格式 — F32 safetensors 約 19 GB，而 BF16 約 3.1 GB；或 Q4_K_M 為 0.67 GB，再加上 0.90–1.11 GB 的視覺投影器

• 上下文 — WeVisOne-VL-4B 未公布；MiniCPM-V 4.7 1B 帳面上則為 262,144 個 token

• 影片 — 被像素解碼器拒絕 vs 預設 128 幀

• 多模態輸入 — 每輪單一影像 vs 影像與影片

• 量化 — 廠商未隨附任何量化版本，對比 int4、AWQ、GPTQ、GGUF 與 FP8 變體

• 裝置端執行環境 — 無 vs iOS、Android、HarmonyOS，加上 llama.cpp 與 Ollama

• 授權條款 — 騰訊編寫的程式碼採用 Apache 2.0，對比 Apache 2.0

記憶體那一列正是重新界定這項比較的關鍵。一個 1B 模型採四位元時，在加上視覺投影器之前，佔用不到 1 GB；而一個 4.83B 模型以 F32 表示，則約需 19 GB。它們並不是爭奪同一個位置的競爭者。一個是你內嵌在應用程式中一起交付的元件；另一個是你跑在 GPU 上的服務。

如何不騙自己地讀懂基準測試列

兩家廠商都公布了表格，而兩份表格都是自行挑選的。MiniCPM-V 4.7 1B 回報 OCRBench 86.1、MathVista 74.3、CharXiv Reasoning 48.8、LongVideoBench 53.4 與 MotionBench 54.55。WeVisOne-VL-4B 回報 LVIS F1 平均 55.3、RefCOCOg test 81.8、PixMo-Count test 89.6、TotalText F1 平均 52.0、ReasonSeg val gIoU 71.2 與 P3M-500-NP MAD 7.3。兩份清單中沒有任何一項基準測試同時出現。從這些文件裡，沒有任何站得住腳的方法可以算出誰勝誰負，而任何這樣做的文章，都是在編造結果。

公平的解讀更為狹窄，但仍有用。就圖像推理而言，MiniCPM-V 4.7 1B 以其實際規模來看強得異常——一個能塞進手機的模型在 MathVista 上拿到 74.3，是作者最引以為傲的數字，而這是廠商自行報告且未經重現的。WeVisOne-VL-4B 在產出幾何資訊方面強得異常——遮罩、去背遮罩、邊界框，以及在物體不存在時於 WeRef-Bench 上測得 96.4% 的拒答率。MiniCPM 的模型卡未公布任何拒答指標，而 WeVisOne 的模型卡未公布任何推理基準。每個模型緘默之處，正是另一個模型大聲張揚之處。

每一個無法做到的事

WeVisOne-VL-4B 無法觀看影片、無法就影像進行多輪對話，也無法在手機上執行。它沒有公布每秒 token 數，也沒有量化版本，這意味著任何部署它的人都得投入 GPU，並自行對吞吐量進行基準測試。微調程式碼仍是專案待辦清單上一個尚未勾選的項目。

MiniCPM-V 4.7 1B 無法回傳遮罩或 alpha matte。它會告訴你影像中有人，以及大致位置；但不會給你邊緣柔和的去背剪影。它也帶有全新模型家族的常見風險：Transformers 中出現新的 model_type、最低版本需求為 5.18.0，以及早期有報告指出在某些 CUDA 與 torchcodec 組合中會發生影片解碼故障。其 262K 上下文只是紙上數字——訓練後階段尚未被證明能充分利用它。

第二通電話的成本

在實務上，這兩個模型並非彼此的替代品，而有趣的是，真正有意思的架構會同時使用兩者：一個小而便宜的模型負責描述影像並進行推理，另一個感知模型則負責回傳幾何資訊。如此一來，一次推論呼叫就變成兩次，而這正是成本不再只是附註的關鍵所在。

OrcaRouter 對那樣的架構帶來的貢獻，正是那種無聊但關鍵的一環——一組金鑰即可通行超過 200 個模型，供應商牌價以 0% 加價原樣傳遞，並在上游端點劣化時自動容錯切換。通用型模型供應商一旦降價，我們這邊當天就會同步反映，因為沒有加價層需要更新。WeVisOne-VL-4B 與 MiniCPM-V 4.7 1B 目前都不在該目錄中，所以整條流程中負責感知的那一半，仍得由你自己託管。你能避免的是，為已包含在內的那一半再簽一份合約、再管理一組憑證。

你會怎麼執行其中任何一個

WeVisOne-VL-4B 是安裝需求較高的版本。模型卡說明了 Transformers、vLLM、SGLang 與 Docker Model Runner，但 mask_decoder.pt 是必要元件：若未使用專案的推論套件載入檢查點，只會取得邊界框與文字，沒有遮罩。解碼採貪婪式，每張影像最多 1,960 個視覺 token，且沒有公開的吞吐量數據，因此你在自己的硬體上要做的第一件事就是測量它。

MiniCPM-V 4.7 1B 是比較容易上手的選擇。它需要 Transformers 5.18.0 或更新版本，而生態系也隨之到位——包含 llama.cpp、Ollama、SGLang 與 vLLM 的建置版本，以及 int4、AWQ、GPTQ 與 FP8 量化，還有一個獨立的 213M 參數 DSpark 草稿模型用於推測解碼。如果你的目標是手機、Intel 小主機或 Rockchip 開發板，這就是一條已經鋪好路的路徑。

該選哪個賭注

若限制條件在於裝置，就選 MiniCPM-V 4.7 1B。WeVisOne-VL-4B 沒有任何部分是為手機設計的，而 MiniCPM 這邊的量化、執行環境支援與影片處理，都是出自一家已推出數代裝置端模型的實驗室之手。

如果限制條件在於輸出——你需要 {{1}}遮罩{{/1}}、{{2}}去背遮罩{{/2}}、{{3}}密集小物件邊框{{/3}}，或可靠的 {{4}}「不存在」答案{{/4}}——那就選 {{5}}WeVisOne-VL-4B{{/5}}，並為 GPU 編列預算。要明白，你依據的是一篇才發表兩天、尚無獨立評測的論文，而且去背數據是 {{6}}Tencent 自家{{/6}}的。

如果你兩者都需要，你就需要兩個模型。這是誠實的結論，也是兩家廠商各自的基準測試表所支持的結論：它們針對不同的事物進行優化，而且兩者都沒有試圖擊敗對方。