认识 MiniCPM-V 4.7：350 亿参数塞进 3GB 内存，端侧 MoE 第一次跑顺了

先看一组让我觉得不太对劲的数字。

一个总参数 350 亿的模型，跑在一部手机上，只占 3GB 内存，解码速度 13 token/s 以上。

我第一反应是：又来造词了。350 亿参数就算压到 4bit，光权重也得 17GB 上下，怎么塞进 3GB？

翻完官方 README 才发现，人家说的每一个字都是真的，但这句话里藏着一个反常识的前提——MoE 模型每次推理只激活一小部分参数（这里约 30 亿），可你的手机内存里仍然得放着完整的专家权重。所以真正的难题从来不是"算得快不快"，而是**"专家权重在硬盘里，要的时候来不及搬"**。

这就是 MiniCPM-V 4.7 真正解决的事情。它不是把模型缩小了，而是把"搬东西"和"算东西"这两件事摞到了一起。

端侧 AI 的瓶颈，这两年一直在悄悄换人：先是算力，然后是显存，现在是带宽。谁能把 I/O 藏进计算里，谁就能把大模型塞进小设备。

什么是 MiniCPM-V 4.7

MiniCPM-V 4.7 是面壁智能联合开源社区 OpenBMB 于 2026 年 10 月 12 日开源的新一代端侧多模态大模型，提供 35B-A3B（MoE）与 1B 两种规格，代码与权重均采用 Apache 2.0 协议，主打单图、多图、文档与视频理解，并能在手机、车机、PC 等端侧设备上本地运行。

代码在 github.com/OpenBMB/MiniCPM-V，权重在 Hugging Face 与魔搭 ModelScope 都有，Ollama 里也能直接拉：openbmb/minicpm-v4.7。

几个容易搞混的点，先掰清楚：

第一，它是视觉语言模型（VLM），不是纯文本模型。 同门还有 MiniCPM5-2B（语言基座）和 MiniCPM-o 4.5（全模态，能看能听能说）。MiniCPM-V 这条线专门管**"看得懂"**——图片、截图、扫描件、PDF、视频帧。

第二，35B-A3B 是这一代的新物种。 名字里 35B 是总参数，A3B 是每次推理实际激活的约 30 亿。这是 MiniCPM-V 系列第一次上 MoE。1B 版本则继续守着极致轻量，官方口径是相比上代 MiniCPM-V 4.6 基础能力持续提升，综合得分与推理效率都显著领先 Qwen3.5 0.8B。

第三，它背后是"密度定律"这条路线。 面壁从 2023 年就在讲一件事：模型能力的提升速度，快过参数量增长和成本下降的速度。翻译成人话——端侧参数总量有天花板，唯一出路是把每个参数的潜力榨干。这条路线不是嘴上说说，相关成果已经发在 Nature Communications 上。

第四，Apache 2.0，商用没有雷。 代码和权重都是，由清华大学自然语言处理实验室与面壁智能共同开发。

它有什么特点

首个端侧无损流畅的开源 MoE。 这句话里最贵的词是"无损"。之前端侧跑 MoE 的提速套路基本是砍专家——固定专家集合、限制专家数量，速度上去了，能力也跟着塌了。MiniCPM-V 4.7 走的是另一条路：能力一分不减，速度提 5 倍。
LES（前瞻专家调度），这是全篇最值得记住的东西。 MoE 的专家权重放不进内存，只能搁在硬盘/闪存里，用到时才加载。传统做法是"用到谁搬谁"，于是每生成几个 token 就卡一下等 I/O。LES 的思路极其朴素：跨层路由预测下一层可能用到哪些专家，趁当前这层还在算的时候，先把下一批专家并行搬到内存里，同时优先计算已经加载好的专家。加载和计算重叠起来，等待时间就被吃掉了。配合权重量化与存储布局优化（减少权重读取的分散），官方给出的端侧真实加速是 x5。这套实现开源在 llama.cpp-omni，目前是业界独家的开源方案。
4 倍 / 16 倍混合视觉 token 压缩。 基于 LLaVA-UHD v4，在视觉编码器内部就提前把视觉 token 压掉。代码里就是 downsample_mode 这个参数：默认 "16x" 走效率，要抠细节就切 "4x"。一张高清大图可以切成最多 36 片（max_slice_nums）来保细节，也可以压得更狠换速度。这个取舍权交给了你，而不是写死在模型里。
性能—效率的帕累托前沿被往前推了一格。 官方口径：Instruct 模式下，35B-A3B 用更短的推理时间，拿到了比 Qwen3.6 35B-A3B 更高的综合得分。这点我认为比绝对分数更重要——端侧场景里，"快一点、弱一点"和"强一点、慢一点"从来都不是真选项，能同时往前走才算数。
芯片和系统是 Day0 适配，不是"计划中"。 发布当天即支持 Intel（CPU / GPU / NPU，走 OpenVINO）、AMD、Arm、瑞芯微、后摩，媒体口径还包含 NVIDIA 与 Apple；系统覆盖 iOS、安卓、鸿蒙。往前追溯，面壁已与高通、联发科、华为昇腾、紫光展锐等数十家芯片厂商建立合作。
量化版本给得很全。 35B-A3B 有 FP8、int4、AWQ、GPTQ、GGUF、DSpark 六种，1B 有 int4、AWQ、GPTQ、GGUF、DSpark 五种。也就是说你不用自己动手量化——这活儿又慢又容易翻车。
SRFT（Self-Replay Fine-Tuning）微调方案同步开源。 让模型一边学新技能、一边"复习"自己原来的输出，从而减少灾难性遗忘。关键是它沿用标准微调流程，不用改模型结构、不用改损失函数，提前生成的回放数据还能复用。对想做垂直场景（比如自家票据、自家工单截图）的人来说，这比模型本身更值钱。
生态不用重新学。 适配 SGLang、vLLM、llama.cpp、Ollama，transformers 侧用标准的 AutoModelForImageTextToText 加载，一行 transformers serve 就能起一个 OpenAI 兼容接口。

我一直觉得"端侧模型"这个词被用坏了。很多所谓的端侧模型，本质是把云端模型砍到只剩聊天能力，能跑在本地只是因为它"跑得起来"。 MiniCPM-V 4.7 不一样：它先保证能力无损，再去解决速度问题。 顺序反了，做出来的东西就是两个物种。

用在哪儿

智能座舱。 这是 MiniCPM 系列目前落地最硬的场景。面壁的 SuperMate 智舱方案以 MiniCPM-V 与 MiniCPM-o 作为智能底座，公开报道口径是 2026 年将完成超 30 万台量产车的交付，合作车企涵盖长安马自达 EZ-60、吉利银河 M9、上汽大众、广汽集团等 6 个品牌；其中长安马自达 EZ-60 是面壁端侧模型的首个量产车型，2026 年 4 月已有三个汽车品牌进入量产状态。座舱为什么非要端侧？隧道里没信号、地下车库没信号，你总不能让车机跟用户说"网络异常"。

手机。 2026 年 7 月，MiniCPM 系列端侧大模型进入三星旗舰手机供应链，成为首家打入国际手机大厂供应链的国产端侧 AI 模型，三星在 2026 年新品上采取"谷歌方案 + 面壁方案"的双轨策略。手机厂商真正在意的从来不是跑分，是数据不出域——相册、截图、聊天记录这类东西，端侧跑完就地销毁，比任何隐私声明都好使。

PC 与本地工具链。 社区里已经长出一批现成的玩法：Ollama-OCR 用本地 VLM 从图片和 PDF 里抠文字；comfyui_LLM_party 把语言与视觉模型接进 ComfyUI 工作流；OpenAvatarChat 在一台 PC 上跑交互式数字人对话。

具身智能。 MiniCPM-Robot 以 1.5B 参数做端侧 VLA 模型，已与乐聚机器人、吉利汽车等合作，展厅导览、园区巡检方案已落地。机器人身上没有服务器机柜，端侧是唯一解。

规模数据。 截至 2026 年 10 月，MiniCPM 开源模型系列全球累计下载量突破 6000 万次，覆盖文本、视觉、语音全模态，发布后连续多日霸榜 GitHub Trending 与 HuggingFace 趋势榜。

初体验：从跑通到跑快

方案一：不想折腾，直接 Ollama。

bash

ollama run openbmb/minicpm-v4.7

适合先看看效果。想接进自己的应用，Ollama 起的就是 OpenAI 兼容接口。

方案二：Transformers 跑图片理解。

bash

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

python

import torch
from transformers import AutoModelForImageTextToText, AutoProcessor

model_id = "openbmb/MiniCPM-V-4.7-35B-A3B"
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)
out = generated_ids[:, inputs.input_ids.shape[1]:]
print(processor.batch_decode(out, skip_special_tokens=True)[0])

有个坑值得单独说一句：downsample_mode 必须同时传给 apply_chat_template 和 generate。前者决定占位符数量，后者控制视觉编码器的行为，只传一边会得到莫名其妙的结果。这种"参数要在两个地方重复一遍"的设计，我第一次也栽了。

跑视频时参数要换一档：max_num_frames=128、stack_frames=1、max_slice_nums=1、use_image_id=False，生成长度给到 2048。

方案三：起个服务给业务用。

bash

pip install "transformers[serving]>=5.18.0"
transformers serve openbmb/MiniCPM-V-4.7-35B-A3B --port 8000 --host 0.0.0.0

然后就是一个标准 OpenAI 风格的 /v1/chat/completions。生产环境追求吞吐的话，上 vLLM 或 SGLang。

方案四：真上手机。 端侧这套看 llama.cpp-omni（LES 的实现就在这里）与 MiniCPM-V-Apps（iOS / 安卓 / 鸿蒙示例）。

选型建议，我的个人立场：

你的情况	建议
显存 ≤ 8GB，只想试试效果	直接 1B，或者 35B-A3B 的 GGUF / int4
有 24GB+ 显卡，要效果	35B-A3B BF16 / AWQ，`downsample_mode="4x"`
要做票据、工单、报表解析	35B-A3B + SRFT 微调，别指望通用模型认得你家的表
要塞进手机 / 车机	走量化版 + DSpark 投机采样，先跑 1B 验证链路
追求服务吞吐	vLLM / SGLang，别用 transformers 原生 generate

几句丑话说在前面：3GB 是特定部署方案下的运行内存占用，不等于 350 亿参数的完整模型只占 3GB 存储，别拿这个数字去买硬盘；官方目前没有公开明确的上下文长度与局限性章节，长文档场景请自己实测；1B 版本再强也是 1B，别拿它去啃复杂推理；发布才一两天，跑分均为厂商自报，第三方复现还得等等。

进阶

更多开源技术干货和学习资料，关注公众号「遇码」，领取专属福利。