面壁智能与 OpenBMB 在 2026 年 10 月中旬发布 MiniCPM-V 4.7，第一次把总参数 350 亿的 MoE 多模态模型塞进手机——官方称在 iPhone 17 Pro Max 上仅用约 3GB 内存跑出 13+ token/s 的解码速度。模型、文档与权重集中在 OpenBMB/MiniCPM-V 仓库（github.com/OpenBMB/MiniCPM-V，26,753 星为 GitHub API 2026-10-15 快照）。听起来像「装个 App 就能跑大模型」，但真上手会发现三个绕不开的现实：手机版模型下载体积约 16.6GB；桌面端想吃 LES 加速得自己编译一个叫 llama.cpp-omni 的推理引擎；而最省事的 Ollama 官方模型库里，截至 2026 年 10 月 15 日依然没有 MiniCPM-V 4.7——想开箱即用，官方库里只有上一代 4.6。这篇 SOP 把三条路一次讲清：手机直装、桌面自建、Ollama 省事路线，每条都给适合谁、步骤、验收标准和常见坑。先交代分工：本篇与同批开源篇同讲 MiniCPM-V 4.7，那边谈模型能力与生态，本文只管「怎么跑起来」；本站此前写过《4GB 显存跑 27B》的文本大模型搬家路线（airllm 方案）和《本地部署工具横评》的通用工具选型，本文与两者划清边界——这里是多模态 MoE 模型的端侧原生路线，聚焦单模型部署实操，不重复通用工具对比。文中所有数字口径截至 2026-10-15，以官方页面实时显示为准。
动手前，先看懂两个官方数字
第一个数字是 3GB。官方文档的原文口径是：MiniCPM-V 4.7 35B-A3B 在 iPhone 17 Pro Max 上「以约 3GB 内存实现 13+ token/s 解码」。注意这里的 3GB 指模型运行时的内存占用口径，不是你手机的空闲内存下限——35B MoE 的专家权重平时放在闪存里，按需流式加载进内存，靠这套 MoE-SSD 机制，手机才装得下 350 亿总参数。手机官方 App 的硬件要求表给出的推荐设备内存是 35B-A3B 机型 RAM 至少 12GB，验证机正是 12GB 的 iPhone 17 Pro Max；内存更小的设备会自动 fallback 到更小的专家缓存，能跑但明显变慢（官方口径，本站未实测降级幅度）。
第二个数字是 13+ token/s。这是官方文档给 iPhone 17 Pro Max 的实测口径，背后是三项技术的叠加：LES（Lookahead Expert Scheduling，前瞻专家调度）用跨层路由预测提前预加载下一层可能用到的专家权重，让加载与计算重叠；细粒度分层量化压低专家权重的存储和内存带宽开销；DSpark 投机采样进一步提升解码效率。官方称 LES 带来约 5 倍真机提速且不损失模型能力。还有一个容易混淆的点：官方另有 iPad Pro M4 的演示视频口径在传播中出现，与 13+ 不同——本文一律采用官方文档原文 13+ token/s（iPhone 17 Pro Max、约 3GB 内存），其余传播口径不采信。
理解了这两个数字，选路逻辑就清楚了：想在路上跑、有一部新手机，走路线一；想在自己的电脑上折腾、要完整控制权，走路线二；只想五分钟体验多模态问答，走路线三。下面这张硬件门槛表帮你先对号入座。
<table> <tr> <th>版本与形态</th><th>量化口径</th><th>下载体积</th><th>官方推荐设备内存</th><th>出处</th> </tr> <tr> <td>4.7 35B-A3B · 手机版（-les 拆分）</td><td>q3gud-im（Q3_K 专家）</td><td>约 16.6GB（主文件+40 个专家分片+视觉模块）</td><td>RAM ≥ 12GB</td><td>官方 App 硬件表，iPhone 17 Pro Max 12GB 验证</td> </tr> <tr> <td>4.7 1B · 手机版</td><td>Q4_K_M</td><td>约 1.8GB（含视觉模块）</td><td>RAM ≥ 4GB</td><td>官方 App 硬件表</td> </tr> <tr> <td>4.7 35B-A3B · 桌面 GGUF</td><td>Q4_K_M</td><td>约 22GB</td><td>官方未给显存门槛，本站未实测</td><td>Ollama 发布页标签口径</td> </tr> <tr> <td>4.7 1B · 桌面 GGUF</td><td>Q4_K_M</td><td>约 1.8GB</td><td>官方未给门槛，本站未实测</td><td>Ollama 发布页标签口径</td> </tr> <tr> <td>4.6 · 对照项（Ollama 官方库）</td><td>库标注 1b、vision</td><td>拉取时按 tag 显示</td><td>官方库条目未标</td><td>Ollama 官方库，2026-10-15 快照</td> </tr> </table>路线一：手机/平板直装，官方 App 就位
适合谁：手里有 RAM 12GB 级旗舰手机（iPhone 17 Pro 系列验证过）想完整体验 35B-A3B 的用户；或 RAM 4GB 以上、只想跑 1B 版尝鲜的用户。这是三条路里唯一「全离线」的路——模型下载到本机后，问答不联网。
前置条件：一部 iOS/安卓/鸿蒙设备；约 17GB 可用存储（35B-A3B）或 2GB（1B）；装 App 本身不需要任何开发工具。官方演示应用与源码都在 OpenBMB/MiniCPM-V-Apps（github.com/OpenBMB/MiniCPM-V-Apps）仓库，覆盖 iOS、安卓、鸿蒙 NEXT 三端。
步骤：最省事的入口是官方预编译包——iOS 走 TestFlight 公共链接（仓库 README 提供），安卓与鸿蒙在仓库的 GitHub Releases 页下载 APK/HAP 安装包，README 说明安装与签名等细节都在 DOWNLOAD.md。装好后打开 App，进 Settings 里的 Model Management（模型管理），选你要的模型点 Download All，下载完成点 Use This Model 激活，然后在对话里发一张图片开始提问。想从源码编译也有完整路径：iOS 需 Xcode（验证版本 26.1.1，部署目标 iOS 16.6）、CMake 3.28 以上，先跑仓库自带的 ./scripts/build_xcframework.sh 生成 llama.xcframework，再在 Xcode 里换成自己的签名团队、打开设备的开发者模式后运行；安卓需 Android Studio 加 NDK 27（项目锁定 27.0.12077973），真机须为 64 位 ARM（arm64-v8a），./gradlew assembleDebug 或直接 IDE 运行，模型文件可用 adb push 侧载；鸿蒙需 DevEco Studio 5.0 以上，在签名配置里勾选自动生成签名（要华为开发者账号）后运行。
验收标准：App 内对任意本地图片提出「这张图里有什么」一类问题，模型用图片内容作答，即算部署成功。1B 版在 4GB 内存设备也应能对图问答，速度慢属正常。
常见坑：一是存储与闪存速度——35B-A3B 的专家权重从闪存流式读取，慢速存储直接拖慢解码，官方明确提示需要快内部存储，下载前确认约 17GB 余量。二是内存不足的降级——小于 12GB RAM 的设备会自动用更小的专家缓存，能跑但速度明显下降，官方口径如此，本站未实测差值。三是分片完整性——35B-A3B 手机版的主文件与 experts/ 目录（40 个分片加 manifest）必须配套，混用不匹配的文件会触发一致性检查直接拒载，官方建议直接用 App 内下载，自带分片校验。四是别把 NPU 期望带进来——这个 App 走 llama.cpp 通用推理路径，吃 CPU/GPU 通用算力；官方宣传的瑞芯微、后摩、Intel、AMD、Arm 芯片 Day-0 适配是面向芯片厂商的另一条路线，普通用户短期内别指望手机 NPU 被用上。五是 iOS 自编译才涉及签名与开发者模式，TestFlight 安装不需要。
路线二：桌面自建，llama.cpp-omni 加速
适合谁：想在自己电脑上跑 4.7、需要接口集成或本地服务的开发者；关心 LES 加速、愿意自己编译的用户。这条路的代价是门槛最高，收益是完整控制权。
前置条件：一台 Windows/Linux/macOS 电脑；git 与 CMake；硬盘空间按量化档位预留（Q4_K_M 约 22GB 起）。首次编译需 C/C++ 工具链，macOS 用 Xcode 命令行工具，Linux 装 build-essential。
步骤：第一步拉代码与权重。引擎仓库有两个入口：官方文档中 LES 链接指向 OpenBMB/llama.cpp-omni（github.com/OpenBMB/llama.cpp-omni，2026-10-14 有推送），社区原仓库 tc-mb/llama.cpp-omni（github.com/tc-mb/llama.cpp-omni）星数更高、文档更全，两者代码同源、各自独立建仓。权重方面，桌面用官方标准量化：Hugging Face 或 ModelScope 上的 openbmb/MiniCPM-V-4.7-35B-A3B-gguf 与 openbmb/MiniCPM-V-4.7-1B-gguf，提供 F16 到 Q4_K_M 等常规量化档位，官方权重表说明 GGUF 版面向低内存 CPU 推理。第二步编译，官方 README 给的命令是：
cmake -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build --target llama-omni-server --target llama-omni-cli -jCMake 会自动探测加速后端：macOS 启用 Metal，Linux 加 NVIDIA 显卡启用 CUDA。不想编译的用户，Releases 页有 Windows/macOS 预编译安装包。第三步运行，README 的基础用法是 ./build/bin/llama-omni-cli -m /path/to/模型.gguf，常用参数包括 -c（上下文长度，默认 4096）、-ngl（GPU 层数，默认 99）、--no-tts（关闭语音输出只出文本）。
这里必须诚实交代一件事：截至取材日，llama.cpp-omni 的 README 快速上手示例是围绕 MiniCPM-o 4.5 的全双工语音管线编写的，模型文件结构、演示流程都以那一版为准；README 与 LES 技术文档中关于 MiniCPM-V 4.7 的支持细节，以官方仓库 README（github.com/OpenBMB/llama.cpp-omni）和 LES 文档（tc-mb/llama.cpp-omni 仓库 docs/les/ 目录）为准，本站未实测 4.7 标准量化 GGUF 在该引擎上的加载命令，不在此编造。稳妥的做法是：按上面已核实的命令完成构建，然后对照官方 README 与 OpenSQZ/MiniCPM-V-CookBook 仓库的 GGUF 量化指南选择运行方式。另外，4.7 官方文档列出的支持推理框架还包括 SGLang、vLLM 与原版 llama.cpp，显卡充裕的用户也可以走 Transformers + FP8/int4 量化权重路线，示例代码在官方文档 minicpm_v4dot7_en.md 里，本文不展开。
验收标准：对本地一张图片提问并得到与图片内容相关的回答即算通。如果你顺手接了 llama-omni-server，用 curl 打一次 chat 接口拿到文本回复也算验收通过。
常见坑：一是别把手机版的 -les 拆分模型拿到桌面用——官方标准 GGUF 仓库不带 -les 变体，那个专家分片拆分是为手机 App 定制的产物，桌面环境直接用标准整模型量化即可。二是显存门槛官方未公布，35B-A3B 的 Q4_K_M 就有约 22GB 文件体积，内存吃紧的机器建议先从 1B 版验证流程再上大模型。三是两个 llama.cpp-omni 仓库并存，认准官方文档里的链接，别拉错分支——手机端 Demo 的子模块用的是它的 ios-omni 分支。四是编译警告中「ignoring duplicate libraries」一类提示是官方说明里的无害警告，可以直接忽略。
路线三：Ollama 省事路线，官方库里只有 4.6
适合谁：只想五分钟跑起来看看效果、不想编译任何东西的用户；以及已经在用 Ollama 管理本地模型的用户。这条路的核心现实是本文的文眼：MiniCPM-V 4.7 尚未进入 Ollama 官方模型库。
现状核对（2026-10-15）：Ollama 官方库（ollama.com/library）里 MiniCPM 系列有三条：minicpm-v（550 万次拉取）、minicpm-v4.5（5.46 万次）、minicpm-v4.6（6.95 万次，标注 1b 与 vision）。其中 minicpm-v4.6 于 2026 年 6 月 25 日进入官方库（官方 README 更新日志口径），至今仍是库里最新一代。MiniCPM-V 仓库主页的更新日志也印证了这个时间线。
步骤：装好 Ollama 后一条命令即可：
ollama run minicpm-v4.64.6 同样具备图像理解能力，在会话中引用本地图片提问即可体验多模态问答。
但还有半个新选择要说清楚：官方 4.7 文档末尾给了 Ollama 链接，指向发布者页面 ollama.com/openbmb/minicpm-v4.7——这是 OpenBMB 官方账号上传的发布页，不在官方精选库里，截至取材日页面已提供可用标签：1b（Q4_K_M 约 1.8GB）、35b-a3b（Q4_K_M 约 22GB，默认 latest 同此档）、q8_0 与 fp16 更高精度档，上下文窗口 256K。也就是说现在就能用 ollama run openbmb/minicpm-v4.7 拉取运行，只是它享受不到官方库条目的收录待遇，何时转正官方没有时间表。想等官方库收录，就盯 ollama.com/library 页面的 MiniCPM 条目。
验收标准：ollama run minicpm-v4.6（或 ollama run openbmb/minicpm-v4.7）拉取完成后，在会话中对图片提问并得到相关回答即算通。
常见坑：一是 latest 标签默认指向 35b-a3b 的 22GB 量化，小内存机器直接 run 会让 Ollama 拉一个拉不动的模型，先明确加 :1b 标签。二是发布者页与官方库是两回事，模型说明页的更新维护节奏与官方库不同，遇到问题先看发布页的 tag 更新时间。三是 Ollama 路线跑的是整模型量化，没有手机版的专家流式加载机制，22GB 文件就得占 22GB 内存级别资源，「3GB 内存跑 35B」的说法在 Ollama 路线上不成立。
延伸阅读
FAQ
Q1：所谓 3GB 内存，到底什么手机能跑？ A1： 官方文档口径是 35B-A3B 在 iPhone 17 Pro Max 上以约 3GB 内存运行、13+ token/s 解码——3GB 是模型运行内存占用，不是手机总内存要求。官方 App 硬件表给 35B-A3B 的推荐设备内存是 RAM 至少 12GB，验证机为 12GB 的 iPhone 17 Pro Max；更低内存设备会自动降级专家缓存，能跑但明显变慢。1B 版推荐 RAM 至少 4GB。结论：12GB 旗舰跑 35B-A3B 是官方验证路径，4GB 老机型请选 1B 版。
Q2：Ollama 官方库什么时候会有 4.7？
A2： 截至 2026-10-15 没有官方时间表。官方库最新仍是 2026 年 6 月 25 日入库的 minicpm-v4.6。不过 OpenBMB 已在 Ollama 上开设发布者页面 openbmb/minicpm-v4.7，可立即用 ollama run openbmb/minicpm-v4.7 拉取（1b 约 1.8GB、35b-a3b 约 22GB），只是该页面不属于官方精选库。转正进度盯 ollama.com/library 即可。
Q3：llama.cpp-omni 和原版 llama.cpp 是什么关系？ A3： 官方 README 的定位是「基于 llama.cpp 构建的高性能全模态推理引擎」，兼容 llama.cpp 的接口与生态，支持 GGUF 量化，覆盖 Windows/Linux/macOS。它与原版是并存关系而非替代：4.7 官方文档把 LES 加速链接指向 OpenBMB/llama.cpp-omni，同时 4.7 的支持框架列表里也有原版 llama.cpp；手机官方 Demo 的 llama.cpp 子模块用的正是 llama.cpp-omni 的 ios-omni 分支。目前 OpenBMB 与 tc-mb 两个同名仓库并存，代码同源。
Q4：跑 MiniCPM-V 4.7 需要 GPU 吗？ A4： 分路线看。路线一手机端不需要，吃手机 CPU/GPU 通用算力。路线二官方未给 4.7 的显存门槛（本站未实测），但引擎对无独显场景友好：CMake 自动探测后端，macOS 用 Metal，CPU 推理是 llama.cpp 生态基本能力，官方 GGUF 权重表也明示面向低内存 CPU 推理；有 NVIDIA 显卡则自动走 CUDA 加速。路线三取决于你拉的 tag：1b 版普通电脑即可，35b-a3b 的 22GB 量化对内存/显存要求不低。
Q5：权重可以商用吗？许可条款是什么？ A5： 按 OpenBMB 官方项目文档 project_en.md 的 Model License 节原文：MiniCPM-o/V 模型的权重与代码均以 Apache-2.0 许可证开源。官方同时提供可选的登记问卷和使用声明（声明内容为免责性质，不构成额外许可限制）。Apache-2.0 是标准开源许可证，具体商用权利与义务以许可证原文为准；官方代码仓库 LICENSE 文件与该口径一致。
选路的一句话总结
要全离线的手机体验，走路线一直装官方 App，记住 12GB 内存与 17GB 存储两道门槛；要桌面控制权和 LES 加速，走路线二自建，认准官方 README 与官方 GGUF 仓库；只要最快跑起来，走路线三先用官方库的 4.6 过瘾，想尝鲜 4.7 就从官方发布者页拉 openbmb/minicpm-v4.7，同时等它进入 Ollama 官方库的那一天。三条路的终点是同一个验收动作：丢一张图给模型，它能答上来，你就已经在本地跑起多模态大模型了。