• 大模型
• 基础模型
• 多模态
• 本地部署
• openBMB

本文带你一次选对MiniCPM-V 4.7 35B-A3B的GGUF 量化：每个量化档位代表什么、占多少磁盘和显存、适配哪张显卡，以及如何用 llama.cpp / Ollama 跑起来。这个仓库就是官方发布的 GGUF（llama.cpp 格式）权重仓库，一口气给出 16 种量化，从最省的 IQ3_XS（约 13.5 GB）到无损的 F16（约 64.6 GB），另附多模态投影文件和 DSpark 加速头，覆盖 16 GB 显卡到 80 GB 大显存的几乎所有场景。

💡 一句话背景：MiniCPM-V 4.7 35B-A3B 是 MiniCPM-V 系列首个 MoE 多模态模型——总参数 35B、每个 token 只激活 3B，支持单图、多图和视频理解。GGUF 格式专为 llama.cpp 生态设计，支持 CPU 推理和显存卸载，这也是它"能在小显存上跑"的关键。

仓库内容一览：16 种量化 + 3 个辅助文件

整个仓库只有三类文件，结构非常清爽（完整说明见 README.md）：

主模型权重（16 种量化档位）

视觉投影文件（mmproj，跑多模态必需）

• mmproj-model-f16.gguf（约 1.4 GB）：默认 16x 视觉 token 压缩，速度优先
• mmproj-model-f16-4x.gguf（约 0.8 GB）：4x 压缩，保留 4 倍视觉 token，细节更足（OCR、小字识别场景推荐）

加速组件

• dspark-MiniCPM-V-4_7-35B-A3B-F16.gguf（约 0.73 GB）：DSpark 投机采样草稿头，配合 llama.cpp 生态可显著提升解码速度——官方正是靠它 + 专家预调度实现了 iPhone 17 Pro Max 上 3 GB 内存 13+ tokens/s 的端侧推理

量化命名速读：F16、Q4_K_M、IQ4_XS 到底差在哪

不用记复杂理论，看懂命名规则就够了：

• F16：16-bit 浮点，等于没压缩的原始精度，"画质"基准线
• Q8_0 / Q6_K / Q5_x / Q4_x：数字是平均位宽（8/6/5/4 bit）。后缀 K_S、K_M 表示 K-quant 的"小/中"配置——用少量 16-bit 权重"保护"敏感层，同位宽下质量更好；无后缀（如 Q4_0）是最朴素的均匀量化
• IQx（Int-Quant）：非对称 + 重要性加权量化，同位宽下通常比 Q 系列更准。所以同是 3-bit，IQ3_XS 的可用性明显好于老式 Q3
• mix_q3gud_im：混合量化。把 MoE 专家层 FFN 权重（ffn_(gate|up|down)_exps）压到 Q3_K，其余张量保持高精度（详见 MiniCPM-V-4_7-35B-A3B-mix_q3gud_im.tensor-types.txt），专为"部分权重放显卡、部分放内存"的卸载场景设计

16 种量化显存与体积终极对照表

下表大小均按仓库中权重的实际字节数核算（1 GB = 2³⁰ B）：

⚠️ 显存估算 = 权重体积 + 视觉编码器（mmproj 约 0.8~1.4 GB）+ KV Cache 与激活开销。上下文开到 8K~16K 时，建议在上表基础上再预留 2~4 GB。

按你的显卡，30 秒对号入座

16 GB 显卡（4070 Ti Super / 3090 二手等）选 MiniCPM-V-4_7-35B-A3B-IQ3_M.gguf，或显存吃紧时选 mix_q3gud_im 并把部分层卸载到内存。日常问答、看图描述没压力，数学推理类任务请放宽预期。

24 GB 显卡（4090 / 5090 / A5000 等）闭眼选 MiniCPM-V-4_7-35B-A3B-Q4_K_M.gguf。质量损失小、速度快、留足上下文空间，是本仓库使用率最高的档位。

32~48 GB 显卡32 GB 上 MiniCPM-V-4_7-35B-A3B-Q5_K_M.gguf 很从容；48 GB 直接上 MiniCPM-V-4_7-35B-A3B-Q6_K.gguf 甚至 Q8_0，画质基本无损。

80 GB 及以上 / 不想牺牲任何东西F16 全精度跑满，配合 4x 版 mmproj 获得最高视觉细节。

纯 CPU 或"小显存 + 大内存"这正是 MoE 架构的红利区——每 token 只激活 3B 参数，CPU 解码速度完全可用。选 mix_q3gud_im，专家权重（占比最大的部分）用 Q3_K 压缩，其余高精度，内存带宽压力最小。

跑起来：llama.cpp 与 Ollama 两条路

llama.cpp（手动、可控性最强），主权重 + 视觉投影文件要同时指定：

llama-server -m MiniCPM-V-4_7-35B-A3B-Q4_K_M.gguf \ --mmproj mmproj-model-f16.gguf \ --ctx-size 16384

需要更强视觉细节时，把--mmproj换成 mmproj-model-f16-4x.gguf 即可——这就是官方"4x/16x 混合压缩"设计：默认 16x 求快，4x 求细。

Ollama（最省心），官方模型源已上线 openbmb/minicpm-v4.7，一条命令拉取：

ollama run openbmb/minicpm-v4.7

三个高频问题，一次说清

1. 量化后"画质"损失体现在哪？量化损失不体现在图片清晰度上——视觉投影文件全系保持 F16 精度。损失主要体现在复杂推理、长文一致性等语言侧能力：Q8_0/Q6_K 几乎无感，Q4_K_M 偶有小瑕疵，IQ3 档在难题上掉分较明显。而"视觉细节"想拉满，靠的是换 4x 版 mmproj，与主模型量化档位无关。

2. 为什么 clone 下来 gguf 文件只有 136 字节？这是正常的——仓库用 Git LFS 存储大文件，指针文件里记录了真实大小（也就是本文对照表的来源）。克隆时执行git lfs install && git lfs pull即可拉取真实权重；clone 地址：git clone https://gitcode.com/hf_mirrors/openbmb/MiniCPM-V-4.7-35B-A3B-gguf。

3. 手机上能跑吗？能。官方通过 Lookahead Expert Scheduling（专家预取调度）+ 细粒度分层量化 + DSpark 投机采样，让 35B-A3B 成为首个可在端侧无损流畅运行的开源 MoE 模型：iPhone 17 Pro Max 仅 3 GB 内存即可 13+ tokens/s 解码。本仓库的 dspark-MiniCPM-V-4_7-35B-A3B-F16.gguf 就是这套方案在 llama.cpp 侧的组成部分。

选型口诀：16 GB 选 IQ3_M，24 GB 选 Q4_K_M，32 GB 选 Q5_K_M，48 GB 选 Q6_K/Q8_0，显存不够就 mix_q3gud_im + 内存卸载——剩下的交给 llama.cpp 就行。

• 大模型
• 基础模型
• 多模态
• 本地部署
• openBMB