MiniCPM-V 4.7 與 Gemma 4 12B：一個端出基準測試成績，另一個端出成績的圖片

打開 MiniCPM-V 4.7 的模型卡，捲動到評估區段。你會看到三張圖：效能對推論時間的前緣圖、整體視覺語言比較，以及整體語言比較。你不會看到表格。現在打開 Gemma 4 12B 的模型卡，捲動到相同位置。你會看到 MMLU Pro、AIME 2026、LiveCodeBench v6、GPQA Diamond、Codeforces ELO、MMMU Pro、MATH-Vision，以及文件解析錯誤率，每一項都附有可複製到試算表的數字。兩款模型都是開放權重，都是 Apache 2.0，也都定位為可運行於自有硬體的多模態模型——而只有其中一款能讓你核對它的工作成果。像這次發布這類版本背後的已記錄 AI 失誤與代理事件，都彙集在 the OrcaRouter AI Incident Archive，其中每一條目都附有自己的來源、嚴重程度、信心等級與爭議標記。

那種不對稱才是真正的比較。OpenBMB 於 2026 年 10 月 12 日發佈的 MiniCPM-V 4.7，以及 G​oogle DeepMind 於 2026 年 6 月 3 日發佈的 Gemma 4 12B，並不是同一類物件，而差異不在於規模。而在於每家廠商願意把自身主張中的多少內容放進文字裡。

各供應商會用數字告訴你的事

Gemma 4 12B 的模型卡公布了它相對於五個同系列型號與一個前代型號的得分，並依基準名稱標明評估測試框架。具體就 12B Unified 變體而言，廠商回報的成績為：MMLU Pro 77.2、AIME 2026 無工具 77.5、LiveCodeBench v6 72.0、GPQA Diamond 78.8、Codeforces ELO 1659、Tau2 三次執行平均 69.0、MMMLU 83.4，以及——最能誠實界定 12B 模型定位的數字——Humanity's Last Exam 無工具 5.2。在視覺方面，它回報 MMMU Pro 69.1、MATH-Vision 79.7，以及 OmniDocBench 1.5 上平均編輯距離 0.164，此處數值越低越好。

那些是廠商提供的數字。沒有獨立第三方非得認同它們，而在一個部署如此廣泛的模型上，其中有些數字經不起換用不同測試框架的考驗。但這些數字是可證偽的，而這正是關鍵所在。如果你自己的評測在 MMLU Pro 上得到 62，你就知道你的設定或這張卡有問題。

MiniCPM-V 4.7 的模型卡以文字提出四項數值主張，完全沒有基準測試表格。35B-A3B 變體在 iPhone 17 Pro Max 上使用約 3 GB 記憶體，解碼速度達每秒 13 個 token 以上。Lookahead Expert Scheduling 在真實裝置上帶來 5× 加速。1B 變體在總體分數與推論效率上勝過 Qwen3.5 0.8B。而在 Instruct 模式下，35B-A3B 以更少的推論時間達到比 Qwen3.6 35B-A3B 更高的總體分數。其餘一切——比較的每一個面向——都存在於圖表影像中。

那並非不誠實。圖表承載資訊，而前沿圖可說是比一張列出在不同批次大小下測得之各項基準分數的表格，更能總結速度與品質的取捨。但圖表無法被引用、無法被重新推導，也無法在沒有人解讀像素位置的情況下，與另一家廠商的圖表相比較。當一個模型唯一的公開評估只是一張圖片時，正確的立場是：在有人實際測量它之前，把它當作未經測量。

這兩種架構解決的是不同的問題。

讀過評估章節之後，各項設計便出現明顯分歧，而這比任何單一分數都是更有用的訊號。

Gemma 4 12B 採用無編碼器架構。它沒有獨立的視覺塔，也沒有獨立的音訊編碼器：原始影像切片與音訊波形會透過輕量線性層，直接投影到語言模型的嵌入空間。G​oogle 表示的原因是延遲與單次微調——一個模型、一次訓練執行、涵蓋所有模態。取捨在於，該公司正押注一個僅解碼器 Transformer 能在沒有專用視覺前端的情況下，學會看得足夠好。它自家的 MMMU Pro 成績為 69.1，而確實搭載約 550M 參數視覺編碼器的 31B 同系列模型則為 76.9，這顯示這項押注在細緻視覺推理上有所損失。

MiniCPM-V 4.7 則走相反的路線。它保留專用的視覺塔——1152 隱藏寬度、27 層、980 像素圖磚——並將工程資源投注在讓那座塔變得低廉。借用自 LLaVA-UHD v4 的 ViT 內早期壓縮，會在編碼器內部而非之後減少視覺 token；而混合的 4×/16× 降採樣切換，則讓呼叫端能依每個請求在細節與成本之間做選擇。在語言端，35B-A3B 是一個 256 專家的混合模型，每個 token 啟用 8 個專家，並在 40 層中以 3:1 的線性注意力對全注意力模式分層配置。

這種設計的實際結果是，MiniCPM 的影片處理路徑異常明確。模型卡公開了 max_num_frames 為 128、一個會將子影格合成為主影格之間網格的 stack_frames 參數，以及分別針對圖像（36）與影片（1）的切片數量指引。如果你正在打造能讀取螢幕錄影或講座影片的東西，這種對取樣內容的控制程度正是其特色所在。Gemma 4 12B 也能處理影片，將其視為影格序列，但它的模型卡記錄的是格式，而非取樣成本效益。

真正決定它的那些列

• 參數 — 總計 35.21B，256 個專家中啟用 8 個，外加一個 1.55B 的稠密同系列模型，對比 11.95B 稠密模型

• 輸入模態 — 文字、圖像、影片，並標明 OCR 與 PDF 解析；相對地，文字、圖像、影片與原生音訊

• 上下文 — 262,144 個 token，相較於 12B 上的 262,144 個 token；E 系列同級型號則為 128K

• 授權條款 — Apache 2.0，權重可下載 對比 Apache 2.0，權重可下載

• 已發布的評估 — 前沿與比較圖表、四項文字敘述主張，對比橫跨八個同系列項目的完整數值表格

• 獨立評估——截至撰寫本文時，兩個 4.7 版本都尚未收錄於 Artificial Analysis；相對地，卻有一個 Artificial Analysis 頁面列出其智能排名與吞吐量

• BF16 下的記憶體——35B-A3B 的權重大約 70 GB，1B 約 3.1 GB，而對比約 24 GB

• 已推出的量化格式 — GGUF、bitsandbytes、AWQ、GPTQ、FP8、int4，與上游檢查點相比，另含來自 Google 與第三方的社群 GGUF 與 QAT 建置

• 由廠商命名的服務路徑 — SGLang、vLLM、llama.cpp、Ollama、Transformers、OpenVINO vs Transformers，而更廣泛的生態系則由社群提供

• 裝置端方案 — iOS、Android、HarmonyOS 應用程式，加上 Rockchip、Houmo、Intel、AMD 與 Arm 的首日支援，對比針對筆記型電腦與消費級 GPU 最佳化的設計

三種工作負載，三種答案

大規模的螢幕與文件理解。這正是 MiniCPM-V 4.7 設計所針對的方向，也是其文件說明最為紮實之處。4× 降採樣模式、36 切片設定、OCR 與 PDF 解析的 cookbook 範例條目，以及影片的明確影格取樣控制，全都描述了一套將渲染內容轉為結構化文字的流程。Gemma 4 12B 在這裡也同樣可信——其 OmniDocBench 編輯距離 0.164 是真實的文件解析數據——但廠商的產品卡將文件解析視為眾多能力之一，而非核心組織原則。

任何需要聽見聲音的用途。Gemma 4 12B 原生支援音訊，其模型卡上 CoVoST 為 38.5、FLEURS 為 0.069。MiniCPM-V 4.7 則不支援。OpenBMB 的音訊相關工作屬於獨立的 MiniCPM-o 產品線，而 4.7 的模型卡完全未列出音訊模態。若你的輸入包含語音，這場比較還沒開始就結束了——其中一個模型需要在前端加上轉錄步驟，另一個則不需要。

在固定預算下只用單張消費級 GPU。Gemma 4 12B 採 4 位元量化可放進 8 GB 以內，還留有上下文空間；35B-A3B 的 4 位元版本則塞不進單張消費級顯卡，而它那張卡本身的效能敘事，講的是手機維持 3 GB 常駐記憶體，而不是一張有 70 GB 專家權重可供分頁的 GPU。若限制條件是「你手上已經有的那一張卡」，答案就是 12B，而 1B 版本則是唯一適用的 MiniCPM。

買方應計入價格的落差

兩個模型都可免費下載，因此授權條款這一行平分秋色，真正的成本在於它之後的一切。對 Gemma 4 12B 而言，生態系已有四個半月的時間追上：Google 自家提供的量化版本、社群 GGUF 轉換、QAT 檢查點，以及獨立索引，讓你能在同一尺度上將它與上百個其他模型比較。對 MiniCPM-V 4.7 而言，你才剛踏入新架構第八天——新的 model_type、新的注意力佈局、最低 Transformers 版本要求——而廠商自己的模型卡一開頭就附註，CUDA 版本不相符會導致透過 torchcodec 進行的影片解碼失效。

這不是在批評該模型。這是採用任何新事物在最初兩週都會付出的標準代價，也是為什麼一個僅附圖表評估的低調發布，不適合直接進入正式生產路徑，卻很適合做並行對照測試。要讓這種測試成本低廉，做法是在評估新系統時讓現有系統繼續提供服務；這是路由問題，而不是建模問題。

OrcaRouter 在單一 OpenAI 相容端點背後，以 0% 加成執行 200 多個託管模型， 供應商牌價原樣傳遞，因此嘗試第二個模型的成本只是一次設定變更，而不是第二份合約。其路由 DSL 可在單次呼叫中同時容納主要與備援，而自動容錯移轉能在供應商狀況不佳時讓主要路徑保持運作。這裡的重點是涵蓋範圍說明：我們的型錄收錄 Gemma 4 26B-A4B 與 Gemma 4 31B，而不是這個 12B，且完全沒有收錄 MiniCPM-V 4.7。本文談到的兩個模型都是你自己執行的檢查點——路由器是圍繞它們運作的元件，而不是呼叫它們的方式。

什麼能讓它塵埃落定

目前的比較明顯失衡，而且這種失衡既容易說明，也容易修正。Gemma 4 12B 提供的數字是可以質疑的。MiniCPM-V 4.7 的說法則只能全盤接受或否定：每秒 13 個 token、3 GB、5 倍加速、在某個未具名的整體評分上勝過一個有具名的競爭對手。上述每一項若放進表格的一列都會更有用，而 OpenBMB 顯然有能力做出這樣的表格——這個系列先前的模型卡都附有標準的基準測試網格。

因此，這種有用的策略是刻意設計成不對稱的。如果你本週就需要做出決定，Gemma 4 12B 是那種你可以根據公開數據預測其表現的模型，而且它的音訊支援是再多的等待也無法讓 MiniCPM-V 4.7 增加的能力。如果你是為手機、HarmonyOS、Rockchip 板卡打造，或是要讀取螢幕與文件，而 4× 降採樣路徑正好合適，那麼 MiniCPM-V 4.7 的工程設計比 Google 在這個規模下推出的任何東西都更貼合你的問題——而缺少那張表是讓你自行量測的理由，而不是忽視它的理由。

最後還有一件事值得直說，因為它不符合兩家廠商各自的說法框架。這兩個模型都不是在跟前沿 API 爭奪同一批買家；它們競爭的是「乾脆不在本地跑模型」這個決定。Gemma 4 12B 最有力的論點是：四個月的生態系意味著那條平淡無奇的路線行得通；MiniCPM-V 4.7 最有力的論點是：3 GB 的 1B 模型能跑到 12B 去不了的地方。先選定限制條件，再選模型——等基準測試表出來時，它只會在你已經選好的類別裡重新排列模型。