OpenBMB MiniCPM-V 4.7 官方技術解析：35B-A3B MoE 與 1B 端側多模態模型架構、效能與部署指南

文章摘要：清華大學自然語言處理實驗室（THUNLP）與面壁智能（ModelBest）於 2026 年 10 月 12 日正式開源 MiniCPM-V 4.7 多模態大模型系列，採用 Apache-2.0 授權協議。本次更新同步推出系列首款混合專家架構模型 MiniCPM-V-4.7-35B-A3B 與輕量級稠密模型 MiniCPM-V-4.7-1B，延續單圖、多圖、文件解析與影片理解能力，並結合自研前瞻專家調度（LES）、精細層級量化與 DSpark 投機取樣技術，讓 35B 級 MoE 模型在行動裝置端流暢運行。本文完全依據官方開源倉庫與模型卡資料，整理兩款模型的技術細節、實測數據、推論參數與完整官方連結。

MiniCPM-V 4.7 系列核心定位與雙規格概覽

根據 OpenBMB/MiniCPM-V 官方 GitHub 倉庫與官方中文技術指南，MiniCPM-V 4.7 針對不同算力與記憶體條件的端側與本地場景，提供兩種規格：

1. MiniCPM-V-4.7-35B-A3B：這是 MiniCPM-V 系列首款混合專家（MoE）模型，總參數量為 35B，單次激活參數為 3B。官方測試指出，透過自研的前瞻專家調度（LES, Lookahead Expert Scheduling）技術、精細層級量化與 DSpark 投機取樣，該模型在 iPhone 17 Pro Max 上僅需 3 GB 記憶體即可達到每秒 13 個 Token 以上（13+ tokens/s）的解碼速度，且不犧牲模型原有的路由精度。在 Instruct 模式下，35B-A3B 以更短的推論時間取得高於 Qwen3.6 35B-A3B 的綜合評測得分。
2. MiniCPM-V-4.7-1B：針對輕量級端側部署設計的 1B 級稠密（Dense）模型（Hugging Face 模型頁標籤顯示包含視覺模組之總參數規模約 2B），體積小巧，可完整常駐於行動裝置記憶體中。根據 1B 官方模型卡，1B 版本在 Instruct 模式下持續提升前代 MiniCPM-V 4.6 的基礎能力，並在綜合評測得分與推論效率上顯著領先 Qwen3.5 0.8B。

全系列程式碼與模型權重均採用 Apache-2.0 授權協議，支援 iOS、Android 與 HarmonyOS NEXT 作業系統，並於發布首日支援瑞芯微（Rockchip）、後摩智能（Houmo）、Intel、AMD 與 Arm 等晶片平台。

35B-A3B MoE 與 1B Dense 官方規格對照表

根據 OpenBMB/MiniCPM-V 官方主頁、MiniCPM-V 4.7 技術指南以及 OpenBMB/MiniCPM-V-Apps 端側應用倉庫，兩款模型的官方規格對照如下：

核心技術解析：端側無損流暢 MoE 推論與高效視覺架構

在行動裝置上運行 MoE 模型時，雖然單一 Token 只激活少數參數，但不同 Token 在各層會動態選擇不同專家，裝置記憶體無法一次容納全部 35B 專家權重。若單純將專家權重存放在 SSD 按需載入，頻繁的載入等待會拖慢生成速度。若強行固定專家子集，則會限制動態路由並導致模型能力下降。

根據 MiniCPM-V 4.7 中文技術指南與 LES 官方技術文件，開發團隊透過以下技術協同解決此瓶頸：

1. LES（Lookahead Expert Scheduling，前瞻專家調度）

LES 前瞻專家調度技術透過跨層路由預測，提前從 SSD 載入下一層可能用到的專家權重。當實際路由器選出專家後，系統會優先計算已經預先載入命中的專家，並利用這段運算時間在背景並行載入其餘所需專家，大幅縮減 I/O 等待時間。

跨層預測僅用於「預取與排程」，實際運算仍嚴格遵循模型原有的 Token 級路由，預測未命中的專家也會正常載入並參與計算，因此無須額外訓練且完全不損失模型精度。

2. 精細層級量化與儲存佈局優化（MoE-SSD）

除了排程預取，系統在權重存取上同步進行兩項優化：

• 精細層級混合精度量化：降低專家權重的儲存佔用與記憶體頻寬開銷，同時保留模型能力。在 MiniCPM-V-Apps 中，視覺投影器與 ViT 權重（mmproj）統一保留 f16 精度以維持視覺感知品質，35B-A3B 的路由專家權重則採用 Q3_K（mix_q3gud_im）量化。
• 連續儲存佈局與權重拆分：將專家權重重新打包為連續儲存佈局，減少零散讀取並提升快閃記憶體（Flash/SSD）循序讀取效率。針對手機端應用，官方將路由專家從主 .gguf 中剝離至獨立的 experts/ 目錄（包含 40 個分片與 manifest.json），以便按需從 SSD 分頁讀入。

3. DSpark 投機取樣與端側實測加速數據

官方同步釋出針對兩款模型訓練的投機解碼草稿模型（Draft Model）：MiniCPM-V-4.7-35B-A3B-DSpark 與 MiniCPM-V-4.7-1B-DSpark，將投機取樣整合至推論流程。

根據 LES 官方技術文件在 iPad Pro 11 吋 M4（16 GB） 上針對多項資料集測得的解碼速度，各階段加速效果如下表所示：

而在 iPhone 17 Pro Max（12 GB 整機記憶體） 上，MiniCPM-V 4.7 35B-A3B 僅需佔用 3 GB 記憶體即可達到 13+ token/s 的解碼速度。

4. ViT 內提前壓縮與 Self-Replay Fine-Tuning（SRFT）

• 高效視覺編碼架構：基於 LLaVA-UHD v4 的 ViT 內提前壓縮技術（Intra-ViT Early Compression），模型在視覺編碼器內部提早壓縮視覺 Token，降低後續編碼層的運算開銷，並支援 4x 與 16x 混合視覺 Token 壓縮率。
• Self-Replay Fine-Tuning（SRFT）微調方案：官方同步開源 SRFT 微調方案，並支援 SWIFT 與 LLaMA-Factory 等微調框架，協助開發者以低成本擴展模型能力並減少原有能力遺忘。

快速上手教學：Transformers、vLLM、SGLang 與 OpenVINO

根據 MiniCPM-V-4.7-35B-A3B 與 MiniCPM-V-4.7-1B 官方模型卡說明，以下整理標準推論與部署方式。

1. 環境安裝與 CUDA 相容性處理

安裝 Hugging Face Transformers（需 >=5.18.0）與視覺相依套件：

pip install "transformers[torch]>=5.18.0" torchvision torchcodec

官方特別提醒，torchcodec（用於影片解碼）在部分 CUDA 版本可能出現相容性錯誤（例如 torch>=2.11 預設綁定 CUDA 13.1，在 CUDA 12.x 環境下可能報錯 RuntimeError: Could not load libtorchcodec）。可選擇以下任一方式解決：

# 解法一：改用 PyAV (av) 替代 torchcodec，無 CUDA 版本限制，圖片與影片推論皆支援
pip install "transformers[torch]>=5.18.0" torchvision av

# 解法二：安裝時指定對應環境的 CUDA 版本（例如 CUDA 12.8）
pip install "transformers>=5.18.0" torchvision torchcodec --index-url https://download.pytorch.org/whl/cu128

2. 使用 Transformers 進行圖片與影片推論

以下為官方提供的 Python 載入與推論範例（將 model_id 改為 "openbmb/MiniCPM-V-4.7-1B" 即可切換至 1B 模型，多圖與影片場景推薦啟用 Flash Attention 2）：

import torch
from transformers import AutoModelForImageTextToText, AutoProcessor

model_id = "openbmb/MiniCPM-V-4.7-35B-A3B"  # 或 "openbmb/MiniCPM-V-4.7-1B"
processor = AutoProcessor.from_pretrained(model_id)
model = AutoModelForImageTextToText.from_pretrained(
    model_id,
    torch_dtype="auto",
    device_map="auto"
)

# 圖片推論範例
messages = [
    {
        "role": "user",
        "content": [
            {"type": "image", "url": "https://huggingface.co/datasets/openbmb/DemoCase/resolve/main/refract.png"},
            {"type": "text", "text": "What causes this phenomenon?"},
        ],
    }
]

downsample_mode = "16x"  # 若需更精細的視覺細節可改為 "4x"
inputs = processor.apply_chat_template(
    messages,
    tokenize=True,
    add_generation_prompt=True,
    return_dict=True,
    return_tensors="pt",
    downsample_mode=downsample_mode,
    max_slice_nums=36,
    enable_thinking=False,
).to(model.device)

generated_ids = model.generate(
    **inputs,
    downsample_mode=downsample_mode,
    max_new_tokens=512,
    # 官方推薦 Instruct 模式取樣參數
    do_sample=True,
    temperature=0.7,
    top_p=0.95,
    top_k=100,
    min_p=0.0,
    presence_penalty=0,
    repetition_penalty=1.03,
)

generated_ids_trimmed = [
    out_ids[len(in_ids):] for in_ids, out_ids in zip(inputs.input_ids, generated_ids)
]
output_text = processor.batch_decode(
    generated_ids_trimmed, skip_special_tokens=True, clean_up_tokenization_spaces=False
)
print(output_text[0])

若要進行影片推論，只需將訊息中的 "type" 改為 "video"，並在 apply_chat_template 中傳入 max_num_frames=128, stack_frames=1, max_slice_nums=1, use_image_id=False。

3. 官方進階視覺參數說明表

呼叫 apply_chat_template 時可自訂下列參數（注意：downsample_mode 必須同時傳給 apply_chat_template 與 generate，其餘參數僅需傳給 apply_chat_template）：

4. 部署 OpenAI 相容 API 服務（vLLM、SGLang、Transformers Serve 與 Docker）

官方支援多種伺服器與本地容器啟動方式，並支援 Function Calling 工具呼叫：

# 方式一：使用 Hugging Face 內建輕量伺服器 transformers serve
pip install "transformers[serving]>=5.18.0"
transformers serve openbmb/MiniCPM-V-4.7-35B-A3B --port 8000 --host 0.0.0.0

# 方式二：使用 vLLM 部署
pip install vllm
vllm serve "openbmb/MiniCPM-V-4.7-35B-A3B"

# 方式三：使用 SGLang 部署
pip install sglang
python3 -m sglang.launch_server --model-path "openbmb/MiniCPM-V-4.7-35B-A3B" --host 0.0.0.0 --port 30000

# 方式四：使用 Docker Model Runner 直接運行
docker model run hf.co/openbmb/MiniCPM-V-4.7-35B-A3B
docker model run hf.co/openbmb/MiniCPM-V-4.7-1B

常見問題解答（FAQ）

Q1：桌面端 GGUF 與手機端 Demo 所用的 GGUF 檔案有什麼不同？

根據 OpenBMB/MiniCPM-V-Apps 官方文件說明，官方提供兩套不同用途的 GGUF 檔案：

1. 標準量化版（桌面 / 伺服器端）：位於 openbmb/MiniCPM-V-4.7-35B-A3B-gguf 與 openbmb/MiniCPM-V-4.7-1B-gguf，提供 F16、Q4_K_M、Q5_K_M、Q6_K、Q8_0 等常規檔位，專家權重內嵌於單一檔案中，適合電腦與伺服器依記憶體大小選用。
2. 端上拆分版（手機 Demo 專用）：位於 tc-mb/MiniCPM-V-Apps-gguf，包含 -les 主文件與剝離出來的 experts/ 目錄（40 個專家分片 + manifest.json）。因為手機無法將整個 15.5 GB 以上的內嵌檔案放進單一 Metal buffer 或常駐記憶體，必須透過拆分版按需從 SSD 分頁讀入。

Q2：為什麼官方主頁寫 iPhone 17 Pro Max 僅用 3 GB 記憶體，而端側 App 倉庫寫推薦記憶體 ≥ 12 GB？

兩者分別指稱不同層級的記憶體指標：MiniCPM-V 官方主頁的 3 GB 指的是 35B-A3B 模型在啟用 LES 與 MoE-SSD 串流後，推論過程本身所佔用的執行期記憶體。而 MiniCPM-V-Apps 倉庫表格中的 ≥ 12 GB 則是預留了行動作業系統、Demo 應用程式本身與專家快取餘量後的「手機整機實體記憶體（RAM）」推薦規格（iPhone 17 Pro Max 即配備 12 GB RAM）。記憶體較小的裝置仍可運行，但會自動退化為較小的專家快取，生成速度會明顯下降。

Q3：MiniCPM-V 4.7 與同倉庫的 MiniCPM-o 4.5 定位有何差異？

根據 OpenBMB/MiniCPM-V 模型概覽表，MiniCPM-V 4.7（35B-A3B MoE 與 1B）專注於單圖、多圖、文件與影片等「視覺與語言理解」任務。而 MiniCPM-o 4.5（9B）則是端到端全模態（Omnimodal）模型，除了視覺理解外，還支援中英雙語即時語音理解與生成、聲音克隆，以及邊看、邊聽、邊說的全雙工多模態即時串流互動。

官方資源與相關連結彙整

以下為 MiniCPM-V 4.7 官方開源倉庫與模型權重連結：

• GitHub 官方程式碼與技術文件：

• OpenBMB/MiniCPM-V 官方主倉庫

• OpenBMB/MiniCPM-V 中文 README 總覽

• MiniCPM-V 4.7 官方中文技術指南（minicpm_v4dot7_zh.md）

• MiniCPM-V 4.7 官方英文技術指南（minicpm_v4dot7_en.md）

• OpenBMB/MiniCPM-V-Apps（iOS / Android / HarmonyOS 端側本地推論應用與源碼）

• LES 前瞻專家調度官方技術說明（llama.cpp-omni）

• LLaVA-UHD v4（ViT 內部視覺 Token 提前壓縮技術）

• Hugging Face 官方模型權重與量化倉庫：

• MiniCPM-V 4.7 Hugging Face 官方模型合集（Collection）

• openbmb/MiniCPM-V-4.7-35B-A3B（35B MoE 主模型）

• openbmb/MiniCPM-V-4.7-35B-A3B-gguf（35B GGUF 量化版）

• openbmb/MiniCPM-V-4.7-35B-A3B-AWQ（35B AWQ W4A16 量化版）

• openbmb/MiniCPM-V-4.7-35B-A3B-int4（35B int4 量化版）

• openbmb/MiniCPM-V-4.7-1B（1B Dense 主模型）

• openbmb/MiniCPM-V-4.7-1B-gguf（1B GGUF 量化版）

• OpenBMB Hugging Face 官方組織主頁