MiniCPM-V 4.7 1B

MiniCPM · 1.55B 参数 · dense · 原生多模态(视觉塔)· GQA 2KV · 混合线性注意力(24 层里 6 层全注意力)· 256K ctx · 开源 2026-10-12 · 1.55B 端侧 / 256K 上下文 / Apache 2.0 / 多模态 / CPU 可跑档

关于 MiniCPM-V 4.7 1B 的完整介绍(点开看;上面就是结论表)

面壁 OpenBMB 2026-10-12 发布的 MiniCPM-V 4.7 端侧小杯(HF: openbmb/MiniCPM-V-4.7-1B,许可 **Apache 2.0**)。1.55B dense(官方文档口径),与 35B-A3B 共用同一套 SigLIP canvas M-RoPE 视觉塔(27 层 / patch 14 / 4×·16× 混合压缩)+ processor,面向 iOS/Android/HarmonyOS 端侧与低资源场景,支持单图/多图/视频。架构:24 层(6 层全注意力 + 18 层线性注意力)/ GQA 2KV / head_dim 256 / 原生 256K ctx。KV 已按 config 一手核到并建 arch_detail:复算 0.047G/4K。权重 Q4 ~1G / FP8 ~1.6G / BF16 ~3.1G:CPU 或 1-2G 显存即可跑。收录理由:≥1B 窗口内的端侧档代表,站长点名『1B/2B 都要看』,给读者端侧选型答案页。 2026-11-10 核到官方 GGUF 仓库(openbmb/MiniCPM-V-4.7-1B-gguf)已带 mmproj-model-f16.gguf(1.11GB,另有 4x 压缩变体),llama.cpp 看图通道可用。

实测速度:什么卡、什么量化、多少 token

显卡卡数量化上下文框架 / 版本decode tok/sprefill tok/s单流/并发投机口径来源
Apple Silicon(具体芯片型号官方帖未指明)1 卡Nativ v0.4.x 端侧引擎(量化档位未明示)未报Nativ(github.com/Blaizzy/nativ) · v0.4.x31524000单流无口径不全·不进对比 缺 2 项OpenBMB 官方 X 帖:MiniCPM-V 4.7 上 Apple Silicon(Nativ 合作 day-0) OpenBMB(官方,vendor 口径) · 2026-10-13

每行是一次真实测量的完整口径:哪张卡、几张卡、什么量化、多大上下文、哪个框架哪个版本、单流还是并发、开没开投机—— 缺一项就会标出来,缺项的行不参与对比与偏差计算。本站实测行没有外链,但日志路径就是原始数据所在。 想看同一张卡跑别的模型,从这个表的显卡名点进那张卡的页面。

速查:什么卡、跑多少 token

AMD R9 295X2 8G140 t/s(8G · 推算)
NVIDIA RTX 5070 12G140 t/s(12G · 推算)
AMD Radeon VII 16G200 t/s(16G · 推算)
NVIDIA RTX 4090 24G200 t/s(24G · 推算)
NVIDIA RTX 5090 32G200 t/s(32G · 推算)
NVIDIA RTX PRO 5000 Blackwell 48G(工作站)200 t/s(48G · 推算)

推算值按 Q8_0、8K 上下文、单流;真实测量看下面的实测速度表。没有实测的模型这里只有推算,本站不把推算写成实测。

架构常数(已核实)

层数24
KV 头数2
每头维度256
需全量 KV 的层6 / 24
滑窗长度无(全层线性)
原生上下文上限256K
KV 每 4K(FP16)0.047 G
KV 每 1K token0.01 G

来源:openbmb/MiniCPM-V-4.7-1B / config.json(抓取于 2026-11-08)。KV 公式:2 × 层数 × KV头数 × 头维 × 精度字节 × token(滑窗层按 — 封顶)。

上下文档位(按 Q8_0)

上下文KV总需显存16G 水位内
4K0.05 G2.7 G够
8K0.09 G2.7 G够
32K0.38 G3 G够
128K1.5 G4.1 G够

* 含 1G 框架开销;可用水位按 Windows 口径 88% = 14.1G。

各显存档位能开多大

显存推荐量化8K 总需最多可开
4GQ8_0(估算)2.7G74240(约 73K)
6GQ8_0(估算)2.7G231424(约 226K)
8GQ8_0(估算)2.7G262144(约 256K)
10GQ8_0(估算)2.7G262144(约 256K)
11GQ8_0(估算)2.7G262144(约 256K)
12GQ8_0(估算)2.7G262144(约 256K)
16GQ8_0(估算)2.7G262144(约 256K)
20GQ8_0(估算)2.7G262144(约 256K)
22GQ8_0(估算)2.7G262144(约 256K)
24GQ8_0(估算)2.7G262144(约 256K)
32GQ8_0(估算)2.7G262144(约 256K)
48GQ8_0(估算)2.7G262144(约 256K)
64GQ8_0(估算)2.7G262144(约 256K)
96GQ8_0(估算)2.7G262144(约 256K)
128GQ8_0(估算)2.7G262144(约 256K)
256GQ8_0(估算)2.7G262144(约 256K)
512GQ8_0(估算)2.7G262144(约 256K)

「最多可开」已扣掉权重与 1G 开销;标注为「模型原生上限」时表示显存还有余但模型只支持这么长。净可用还要再减聊天模板与系统提示词的 250 token(估算值,未逐项核实)。量化档后带「(估算)」= 官方仓库没核到这档、按公式算的权重体积(方向保守偏高);不带 = 核过官方仓库真实文件体积。

估算速度(Q8_0 · 8K)

推算 本站暂无这一模型的实测记录。

显卡状态估算 tok/s
NVIDIA RTX 5090 32G流畅200
NVIDIA RTX 5090 D 32G流畅200
NVIDIA CMP 170HX 64G(矿卡魔改)流畅200
NVIDIA RTX PRO 5000 Blackwell 48G(工作站)流畅200
AMD Instinct MI100 32G(老数据中心卡)流畅200
AMD Instinct MI50 32G(数据卡)流畅200
AMD Radeon VII 16G流畅200
NVIDIA RTX 4090 24G流畅200
NVIDIA RTX 3090 Ti 24G流畅200

同一套公式也用于显卡页,两页数字必然一致。带宽按 60–85% 效率折算(offload 场景更低),并对单流解码设经验上限,因此这里的数字比纯带宽公式保守。 总需显存 = 2.7G,对比各卡可用水位。

实测数据区

暂无实测数据。
上传实测数据

推理框架命令

llama.cpp

# 1) 取 GGUF 权重(本站核实过的仓库名)
huggingface-cli download openbmb/MiniCPM-V-4.7-1B config.json
#   GGUF 量化版通常在第三方转换仓库,搜「openbmb/MiniCPM-V-4.7-1B GGUF」
# 2) 起服务(Linux/macOS 用 ./llama-server,Windows 用 llama-server.exe)
llama-server -m MINICPM-V-4-7-1B-Q4_K_M.gguf -ngl 99 -c 8192 --port 8080

Ollama

# 本站没核实到 Ollama 仓库里有 MiniCPM-V 4.7 1B 的可用标签,所以不给命令
# 自己去查一眼:https://ollama.com/search?q=MiniCPM-V%204.7%201B

宁可不给命令,也不给一条跑不通的命令——照抄未核实的标签是新手最常见的卡死原因。

vLLM

vLLM 直接吃 Hugging Face 仓库名,这条最可靠:
vllm serve openbmb/MiniCPM-V-4.7-1B --max-model-len 8192 --gpu-memory-utilization 0.90

LM Studio

模型页搜「openbmb/MiniCPM-V-4.7-1B」→ 选 Q8_0 或 Q4_K_M → Load →
Chat Context Length 设 8192 → GPU Offload 拉到最大

仓库名 openbmb/MiniCPM-V-4.7-1B 是本站核实过的(架构常数就取自它)。Ollama 标签与 GGUF 文件名会随发布方变动,本站不保证一定存在,拉取失败请搜同名前缀。

优化要点

相关

16G 显存有哪些卡看 MiniCPM-V 4.7 1B 在 16G 这一档和别的卡/模型比是什么位置装不下 / out of memory 怎么排查先确认是权重超容量还是上下文吃光了余量小模型跑 Q8、大模型跑 Q4 对不对?量化档应该由剩余显存决定,不是由参数量决定

有 MiniCPM-V 4.7 1B 的实测数据?

上传速度 → 进入实测表,并成为这一页的第一行实测。

上传实测数据
这条内容有帮助吗?