MiniCPM-V 4.7 35B-A3B 對上 PixelUMM：在基準測試做出判斷之前，一份授權條款就已決定了這一切

有一個決定，你可以在完全不必閱讀任何基準測試的情況下，就在 MiniCPM-V 4.7 35B-A3B 與 PixelUMM 之間做出，而這很可能正是最重要的決定。MiniCPM-V 4.7 35B-A3B 是 Apache-2.0。PixelUMM 的模型檢查點則不是——它是以 NVIDIA 的 One-Way Noncommercial License 發布，該授權僅允許研究與評估用途，而且 NVIDIA 自己都表示這個檢查點「尚未驗證可用於生產環境或高風險用途」。如果你正在打造某個打算販售的東西，那麼這兩個模型之一根本行不通，其餘的比較就只是學術討論。如果你是在做研究，那麼領域就開闊了，而有趣的問題就變成：NVIDIA 的無編碼器設計實際上是在賭什麼——因為它賭的正是 MiniCPM-V 4.7 所採用的架構。

兩款模型都悄然發布。PixelUMM 的權重於 2026 年 10 月 1 日 21:40 UTC 上架 Hugging Face，沒有部落格文章、沒有新聞稿，也沒有主題演講；專案頁面網址仍顯示「preview」。MiniCPM-V 4.7 在 10 月 6 日以同樣方式現身，而 OpenBMB 直到 10 月 12 日才為它加上模型卡、授權條款或效能宣稱區。兩者都沒有經過任何人獨立評估，也都沒有可供讀者引用的基準測試表——PixelUMM 的模型卡完全沒有回報任何分數，而 MiniCPM-V 4.7 的效能宣稱則存在於圖表圖片中，而非文字裡。以下內容將區分儲存庫所述之事，與兩間實驗室之外尚未有人證實之事。

以一段話說明 PixelUMM 是什麼

PixelUMM 是一個擁有 15,199,672,064 個參數的僅解碼器 Transformer，配備迭代式像素生成頭，建構於鎖定特定修訂版的 Qwen3-8B 主幹之上。它的核心主張寫在模型卡的第一行，而且確實反其道而行：沒有 VAE，也沒有視覺編碼器。傳統統一模型會帶有兩個視覺介面——一個是產生語意特徵以供理解的視覺 Transformer，另一個是產生重建潛在表示以供生成的變分自編碼器——PixelUMM 兩者皆無。影像被切成 16×16 像素區塊，影片被切成四幀時空小管，而兩者僅透過單層線性投影送達主幹，並由迭代去噪負責生成工作。論文將其描述為混合 Transformer（Mixture-of-Transformers），將共享注意力與任務專屬參數配對。它能處理文字轉影像、以影像為條件的文字生成、以影片為條件的理解與影片生成，包括以 96 幀、24 fps、四秒進行的文字轉影片。

圍繞它的線索歷時約四週，全程悄無聲息。GitHub 儲存庫 nv-tlabs/PixelUMM 於 2026 年 9 月 4 日在 Apache-2.0 下建立，當月大部分時間都只有單一提交。9 月 28 至 29 日，初始提交上線，arXiv 編派了預印本 2609.38597，其作者名單橫跨 NVIDIA 與滑鐵盧大學。模型儲存庫本身則於 10 月 1 日 21:40 UTC 出現，距離最後一次加入論文引用的 GitHub 提交晚了八分鐘。論文沒有刊載場合欄位——沒有會議，也沒有「已獲接受於」——這讀起來像是一個研究團隊把研究產物直接推上線，而非產品發布；不過這是對證據的觀察，並非對意圖的宣稱。

MiniCPM-V 4.7 35B-A3B 是什麼

MiniCPM-V 4.7 35B-A3B 是 OpenBMB 在 MiniCPM-V 系列中首款 MoE 作品：256 個專家，每個 token 啟用 8 個，40 層，262,144 個 token 的上下文視窗，以及 248,144 個 token 的詞彙表，總參數 35.2B 中約有 3B 為活躍參數。視覺部分透過 SigLIP2 模組運作，搭配 LLaVA-UHD v4 的 ViT 內早期壓縮，以及可選的混合 4x/16x 視覺 token 壓縮模式——預設為 16x 以提升吞吐量，需要精細細節時則用 4x。它能理解單張圖片、多張圖片與影片，並以文字作答。它不會生成圖片。

這張卡片的主要宣稱是：這是首個開源 MoE 模型，能透過 Lookahead Expert Scheduling、細粒度逐層量化，以及經由獨立 DSpark 草稿進行的推測取樣，實現無損、流暢的裝置端推理，並據稱在 iPhone 17 Pro Max 上達到每秒 13 個以上的 token。該數字由廠商自行報告、未經重現，且未加限定。該卡片也宣稱，其整體 Instruct 模式分數高於 Qwen3.6 35B-A3B，且推理時間更短——這項宣稱出現在一張圖表圖片中，這表示它不是可引用的數字，也不應被當成可引用的數字。

MiniCPM-V 4.7 明確領先之處，不在任何排行榜上，而是在其支援陣容，而這些全都是真實且可下載的：base、FP8、int4、AWQ、GPTQ 與 GGUF 權重；支援 SGLang、vLLM、llama.cpp、Ollama 與 OpenVINO；iOS、Android 與 HarmonyOS 應用程式；以及 Rockchip、Houmo、Intel、AMD 與 Arm 名列首日晶片支援。六週前，對這個模型最誠實的批評是：它是一個沒有文件記載的檢查點。如今已不再如此——它是一個有文件記載、但沒有基準測試的檢查點。不同的問題，而且更小。

藏在比較背後的架構論點

這兩個模型在某個根本問題上意見相左，而這點值得點明，因為它是這場對決中，保存期限比任何一個模型都更長的部分。

• 視覺如何傳遞至語言模型——PixelUMM 使用原始像素與單一線性投影，整個堆疊中沒有任何預訓練視覺編碼器；MiniCPM-V 4.7 則使用 SigLIP2 編碼器，搭配 ViT 內部的早期壓縮以及可設定的降採樣比率。

• 生成如何運作 — PixelUMM 透過與自迴歸文字預測聯合訓練的流匹配頭，迭代地預測像素；MiniCPM-V 4.7 只生成文字，別無其他。

• 這麼做換來的是什麼——PixelUMM 得到一組權重，既能描述一張影像，也能生成一張，代價是僅限研究用途的授權，且未經生產環境驗證；MiniCPM-V 4.7 則得到一個小巧、可量化、能部署在手機上的模型，它能讀懂世界，卻無法重繪世界。

• 參數量 — 15.2B 偏稠密，對比 35.2B 總量、其中 3B 為啟用參數。啟用參數量才是預測推論成本的那一項，而在這個軸線上，MiniCPM 模型是兩者中較小的一個，且小了一個數量級。

• 磁碟上的權重 — PixelUMM 的儲存庫包含 491 個檔案，涵蓋四種檢查點變體；MiniCPM-V 4.7 的基礎建置為十六個 BF16 分片，約 70 GB。

• 授權 — 檢查點採用 Apache-2.0 與 NVIDIA One-Way Noncommercial；Apache-2.0 僅適用於 PixelUMM 的原始碼，而 Qwen3-8B 基底則另行採用 Apache-2.0。PixelUMM 卡片亦註明其包含衍生自 BAGEL 的修改後程式碼，因此上游條款會疊加適用。

• 公開評估——雙方皆無。MiniCPM-V 4.7 至少提出了效能宣稱；PixelUMM 的模型卡則完全未載明任何基準測試數據。

哪一個是你實際上能放到使用者面前的

把授權條款和部署方式一起考慮，選擇多半自然就明朗了。

PixelUMM 是較有趣的研究產物，卻是較不實用的產品。非商業檢查點直接擋住了顯而易見的商業用途，模型卡上沒有推論部署配方，沒有量化版本，沒有上下文長度數字，而 83 個讚對上零次記錄下載，意味著作者之外基本上沒有人跑過它。它目前的價值在於，它是一篇強而有力的已發表論證：在統一模型中，視覺編碼器可能並非必要。無論你會不會載入權重，這個論證都值得關注。

MiniCPM-V 4.7 是那個有通往正式上線之路的模型，而這條路雖然狹窄卻真實存在。Apache-2.0 消除了授權問題。六種量化格式與五種推論執行環境意味著你不必自行編寫自訂核心。未量化版本需要兩張以上 GPU 是門檻；量化版本與裝置端方案則是變通之道，而裝置端的宣稱正是尚未經過獨立驗證的那一點。把它當成一個你今天就能跑起來的模型，以及一項你還不能寄予厚望的效能宣稱。

對於那些答案是「兩者都不選，我們會呼叫其他東西」的團隊，最接近 MiniCPM 形態的託管等效方案是 Qwen3.6 35B A3B——同樣的 35B 總參數、同樣的 3B 啟用參數、同樣的 262K 上下文、同樣支援文字-圖像-影片輸入——而它透過 OrcaRouter 以供應商定價提供、零加成，每百萬輸入 token 0.25 美元、每百萬輸出 token 1.48 美元，並在供應商路由品質下降時自動容錯移轉。這並非本文中任一款模型的替代品；它是對照組，告訴你自行架設一個 70 GB 稀疏多模態 MoE 實際上買到的是什麼。

這會落在何處

撇除架構不談，剩下的就是兩個低調的釋出，卻指向相反方向。NVIDIA 發表了一件論文級成品，其授權條款讓大多數人無法使用，還有一個沒有訓練配方、沒有基準測試、也沒有下載項目的儲存庫。OpenBMB 則發表了一個附有文件、採寬鬆授權、可多執行環境運作的模型，並附帶一項引人注目的效率宣稱，卻沒有評估表可佐證。

能讓兩者各自拍板定案的一件事：對 PixelUMM 而言，是任何獨立重現都行——0 次下載意味著世上根本不存在外部資料點，而免編碼器主張正是那種一碰到第二個實作就會證明成立、否則徹底崩解的論點。對 MiniCPM-V 4.7 而言，則是一張基準測試表，或在 DSpark 草稿上重現出來的接受長度，因為那是該系列中唯一帶有已發表數字的部分。兩者目前都還不存在。這兩點正是這兩個模型仍值得持續關注、而非歸檔封存的原因——它們在公開歷程中還處於比報導所暗示的更早期階段，而且打造它們的實驗室都尚未稱其為正式發布。