MiniCPM-V 4.7：OpenBMB 上傳了一個 35B-A3B 視覺語言模型，既沒有模型卡、沒有授權，也沒有基準測試

MiniCPM-V 4.7 於 2026 年 10 月 6 日晚間登上 Hugging Face，以openbmb/MiniCPM-V-4.7-35B-A3B這個儲存庫的形式現身——而它是 MiniCPM 系列歷來推出過最古怪的東西之一，因為幾乎沒有任何東西與它一同發布。沒有模型卡。沒有 README。沒有宣告的授權條款。沒有基準測試表、沒有發布貼文、沒有技術報告，OpenBMB 自家的 GitHub 文件裡也沒有任何條目——截至本週，那份文件仍稱 MiniCPM-V 4.6 為「MiniCPM-V 系列中最新、最有效率的模型」。真正存在的，是 16 個 bfloat16 權重分片，共 70.4 GB，描述的是一個 352 億參數的專家混合視覺語言模型，具備 256K 上下文視窗，以及異常激進的混合注意力設計。這已足以說明這個模型是什麼。但還不足以說明它擅長什麼，而本文把這兩件事嚴格區分開來。

到底，一個位元都不差

該儲存庫建立於 2026 年 10 月 6 日 18:36 UTC，並在十二分鐘後的 18:48 UTC 進行了最後一次提交。在這之間，上傳者推送了權重檔案以及 Transformers 載入器所需的設定，然後就停止了。完整的檔案清單共有十八個項目：

• 權重 — 十六個 safetensors 分片，命名為 model-00001-of-00016 到 model-00016-of-00016，其中索引檔 model.safetensors.index.json 回報張量總大小為 70,425,751,648 位元組。

• 參數量——Hugging Face API 讀取到 35,212,875,824 個參數，全部為 BF16。請注意，這是總數，而對於稀疏 MoE 而言，這並非在任何給定 token 上實際啟用的參數數量。

• 設定 — config.json（2,984 位元組）、generation_config.json（186 位元組）、preprocessor_config.json、processor_config.json。

• 分詞器 — tokenizer.json（20 MB）、tokenizer_config.json，以及 chat_template.jinja（7,250 位元組）。

• 缺少 — README.md。直接抓取原始檔案會回傳 HTTP 404。在 Hugging Face 上，缺少 README 就代表沒有模型卡，也就代表沒有授權欄位，也就代表該儲存庫完全沒有 license: 標籤。

這個儲存庫有三個讚、零次下載，而且討論分頁是空的。社群上傳的 70 GB 檢查點，通常幾小時內就會引來留言——詢問量化版本、推論服務，以及授權條款是什麼等問題。這個卻沒有，這與它只是被少數關注 openbmb 組織的人發現，而不是向任何人公告的情況相符。

架構，直接從 config.json 讀出

因為沒有卡片可供改寫，設定檔是主要來源，而且它提供了異常豐富的資訊。類別是MiniCPMV4_7ForConditionalGeneration，模型類型是minicpmv4_7，而且它是由 Transformers 5.2.0 儲存的——這些全都表明這是隸屬於 MiniCPM-V 主線脈絡的 OpenBMB 第一方檢查點，而不是掛著這個名字的社群微調版本。

• 語言主幹 — model_type: qwen3_5_moe_text。一款衍生自 Qwen3.5 的稀疏 MoE，這是 MiniCPM-V 系列首次採用 Qwen-MoE 文字堆疊，而非驅動 MiniCPM-V 4.5 與 4.6 的稠密小型 Qwen 變體。

• 稀疏性——256 個專家，每個 token 選取 8 個，專家中間大小為 512，並有一個大小相同的共享專家。一個採用 8-of-256 路由模式的 35B 總量檢查點，在每次前向傳遞中只會啟用其中一小部分，而這正是 A3B 名稱的重點：權重很大，運算量卻不大。

• 深度與寬度——40 個隱藏層、隱藏大小 2048、16 個注意力頭，其中包含 2 個鍵/值頭，頭維度為 256。

• 混合注意力——layer_types 陣列長度為 40 個項目，並且每三個linear_attention 層對一個full_attention 層，固定間隔為 4。四十層中有十層採用傳統注意力；其餘三十層使用 Mamba 風格的線性路徑，卷積核大小為 4。這是檔案中影響最深遠的單一設計選擇，也是更廣泛領域在 2026 年一路發展的相同方向。

• 位置編碼 — RoPE，theta 為 10,000,000，以及 partial_rotary_factor: 0.25，表示每個頭的維度中只有四分之一會進行旋轉。已啟用多模態 RoPE，並搭配 mrope_interleaved: true、區段分割為 [11, 11, 10]，以及 mrope_mode: canvas。

• 上下文 — max_position_embeddings: 262144，且分詞器的 model_max_length一致。256K 個 token。

• 多詞元預測 — mtp_num_hidden_layers: 1，單一投機解碼頭，與 MiniCPM-V 4.6 採用的是同一招。

• 視覺塔 — minicpmv4_7_vision，隱藏大小 1152、27 層、GELU-tanh 激活函數、patch 大小 14，搭配 image_size為 980，以及 insert_layer_id為 6，也就是視覺嵌入被拼接進語言堆疊的位置。這座塔的形狀接近 MiniCPM-V 4.6 中的版本，因此視覺端屬於演進而非重建。

• 視覺壓縮 — downsample_mode: "16x" 以及 max_slice_nums: 9 位於影像處理器中。MiniCPM-V 4.6 導入了可切換的 4x/16x 詞元壓縮機制；4.7 的設定將 16x 設定宣示為預設值，切片器則允許高解析度輸入最多使用九個子影像。

• 詞彙 — 248,144 個 token，其中 <|image_pad|>位於 id 248,056，而 <|video_pad|>位於 248,057。影片是一等輸入，正如自 MiniCPM-V 4.5 以來一直如此。

• 一個耐人尋味的殘留 —— tokenizer 設定仍宣告 <|audio_start|>、<|audio_end|> 與 <|audio_pad|>。這幾乎可以肯定代表詞彙表是與 omni MiniCPM-o 分支共用的，而不是 MiniCPM-V 4.7 能處理音訊。若將它解讀為音訊功能，會是單憑設定無法排除的錯誤。

家族告訴我們，而這個儲存庫沒有告訴我們的事

4.6 世代是基準點，而對比才是重點。MiniCPM-V 4.6 於 2026 年 5 月 11 日發布，是一個 13 億參數的模型，建構於 SigLIP2-400M 視覺編碼器與 Qwen3.5-0.8B 語言模型之上，採用 Apache-2.0 授權，並有一個明確的宣傳賣點：它在 Artificial Analysis Intelligence Index 上得分 13——這是廠商回報的數字——同時使用的 token 數量遠少於同級小型模型，而且它能在 iOS、Android 與 HarmonyOS 上運行，邊緣適配程式碼也已開源。它的整體定位就是「小巧、高效、裝置端」。

MiniCPM-V 4.7 是 1.3B 乘以大約 27。35B-A3B 這個名稱讓它歸入稀疏旗艦而非手機所佔據的級別。OpenBMB 究竟是打算將它作為邊緣系列的伺服器端夥伴、未來小型模型的教師，還是作為能力上限測試，這一點在任何地方都沒有說明，而儲存庫中也沒有任何暗示。

真正新穎、而且值得任何關注這個系列的人特別注意的是，Qwen-MoE 主幹，加上 3:1 的線性注意力對全注意力比例。兩者都是不同以往的做法。OpenBMB 針對這個系列發表的一切內容，仍都圍繞 4.6 撰寫，因此這個檢查點進度超前於自身的說明文件。

目前還無法知道的是什麼——以及為何那份清單很重要

這裡的缺口有多大，值得直言不諱，因為面對 70 GB 的檢查點，誘惑就在於用看似合理的推斷把它填滿。

• 沒有授權條款。這不是形式問題。MiniCPM-V 4.6 採用 Apache-2.0，而社群早已對這個系列抱持這樣的期待。一個缺少 授權條款：標籤的儲存庫，在多數司法管轄區預設為保留所有權利——在該標籤出現之前，你無法安全地在其上進行開發。那一個缺失的檔案，是這個儲存庫裡影響最深遠的缺漏。

• 沒有基準測試，無論是廠商回報的還是其他來源的。沒有任何一個數字可爭論。今天任何人引用 MiniCPM-V 4.7 的 MMMU 或 OCRBench 分數，都是在引用來源中不存在的東西。

• 沒有獨立評估。Artificial Analysis 與類似追蹤器會依名稱索引模型；一個沒有模型卡、也沒有發布公告的檢查點，通常會有一段時間處於未被量測的狀態。

• 沒有服務部署指引。發佈的權重在 vLLM、SGLang 或 llama.cpp 中是否能以原生方式運行，尚未由 OpenBMB 以外的任何人測試過。自訂程式碼路徑（MiniCPMV4_7ForConditionalGeneration、MiniCPMV4_7Processor、MiniCPMV4_7ImageProcessor、MiniCPMV4_7VideoProcessor）全都需要trust_remote_code，而且 MoE 加上線性注意力的組合，並非每個推論引擎都有對應的 kernel。

• 沒有量化版本。MiniCPM-V 4.6 推出了 GGUF、AWQ、GPTQ 和 BNB 變體，並於 2026 年 6 月登上 Ollama 的模型庫。4.7 則完全沒有。對一個 35B 模型來說，這是有筆電和叢集之間的差別。

• 未說明與 4.6 的關係。OpenBMB 可能是在取代 edge 產品線、延伸該產品線，或測試某個毫不相干的東西。該儲存庫沒有說明，GitHub README 也沒有——截至其 2026 年 9 月 8 日的提交，README 仍將 4.6 列為目前的發行版本。

時間軸還有一種看似合理但未經證實的解讀：儲存庫建立與最後一次提交之間相隔十二分鐘、沒有卡片，也沒有任何貼文——這正是檢查點在為發布預先鋪陳、而非發布之後才出現時的樣子。那是關於意圖的假設，不是關於該產物的既成事實，而且應被當作假設來看待。

當實際上有東西要執行時，你會如何實際執行它

目前這裡還沒有任何內容可以直接引用為受支援的路徑，但組態確實限制了選項。35B 參數的 BF16 檢查點在計入 KV 快取之前，就需要大約 70 GB 的加速器記憶體，因此在量化版本問世之前，單張 GPU 的業餘玩家部署根本不可行。256K 上下文與 3:1 線性注意力比例意味著，KV 快取的成長速度遠慢於相同深度的傳統 transformer，這正是該架構值得付出複雜度代價的原因——長上下文多模態工作正是這種設計能回本的地方。當有顯示卡出現時，首先要檢查的是授權條款、是否已發布官方 vLLM 或 SGLang 配方，以及 16x 降採樣的預設值能否換成 4.6 所揭露的 4x 設定。

對於想在模型一變得可用就立刻評估這類模型的團隊來說，真正的實務問題不在權重本身，而在於圍繞權重的周邊管線工程。一個跑在你自己 GPU 上的模型，依然需要它周遭的一切——一個路由器，把 200 多個託管模型收在同一把金鑰之後，價格依各供應商的定價計算，不額外疊加我們的加價，並在供應商服務品質下降時自動故障轉移。這正是 OrcaRouter 的用途，而且值得直說：MiniCPM-V 4.7 本身並不是託管模型，它是你自己部署的開放權重檢查點。路由器在這裡的重要性在於它是架構的另一半——你的 4.7 機器把困難案例交給的前沿模型，可透過你已經寫好的同一個用戶端存取。

現況，以及唯一需要重新整理的檔案

MiniCPM-V 4.7 已經存在。它的權重今天就能下載，權重數量精確無誤，而它在訓練時期的設計選擇——稀疏 MoE、3:1 線性注意力、256K 上下文、16 倍視覺壓縮——全都可從設定檔中清楚看出。不存在的是 OpenBMB 對這款模型能做什麼、實際執行成本為何，或你被允許用它做什麼的任何說明。對於一個上一款視覺模型是 1.3B Apache-2.0 邊緣版發布、還附有完整比較表的實驗室來說，這是個突兀的落差，而明智的姿態是緊盯儲存庫，而不是緊盯討論聲量。唯一需要持續重新整理的檔案是 README.md：它一出現，就會載明授權條款、基準測試，而且很可能還會解釋一個 35B 的 MiniCPM-V 為何會出現在一個以小模型為基礎的系列中。

在那之前，誠實的總結就是那個無聊的答案。這是來自真實實驗室的真實檢查點，被悄悄地上傳，而誠實的問題——它到底好不好——沒有答案。

OrcaRouter 只需一組金鑰，就能存取 200 多個託管模型，各供應商的定價原樣傳遞、零加成，並在供應商之間自動容錯移轉。供應商定價原樣傳遞、零加成MiniCPM-V 4.7 並不在其中——它是開放權重的檢查點，由你自己部署服務，而路由器則是位於交接另一端的角色。