没有独显也能跑多模态：MiniCPM-V 4.7-1B 本地 OCR 实测（附源码）

前言

想在没有独立显卡 的机器上跑多模态大模型 做 OCR ？本文用 llama.cpp + GGUF 在一台 Intel 核显 + 7.8GB 内存的机器上部署了 MiniCPM-V 4.7-1B ，对 5 类图片做了完整 OCR 实测，期间踩了两个坑：llama.cpp 版本过旧导致加载视觉投影时报 unknown projector type: minicpmv4_7，以及模型默认开启思考模式导致结构化输出跑偏。部署过程、测试方法和真实结果都在下面，供同样没有显卡的读者参考。

结论先说：单栏文档和表格超出预期（5 个样本里 4 个在 94% 以上，中位数 99.51%），复杂版式和特殊符号是明确短板；但"1.55B + CPU + 2GB 内存能跑起来"这件事本身，价值很大。

一、模型规格

模型下载地址：https://www.modelscope.cn/models/OpenBMB/MiniCPM-V-4.7-1B-gguf

OCR实测项目源码下载：https://download.csdn.net/download/qq616491978/93696449

项目	内容
发布方 / 协议	OpenBMB / Apache-2.0
参数量	约 1.55B（BF16 权重约 2.97GB）
架构	`MiniCPMV4_7ForConditionalGeneration`
视觉模块	SigLIP2 + LLaVA-UHD v4（ViT 内部早期压缩）
视觉 token 压缩	支持 4x / 16x 混用（`downsample_mode`，默认 16x）
Transformers 要求	≥ 5.18.0（版本要求偏高，值得注意）
其他能力	单图 / 多图 / 视频理解、Tool Calling

官方权重仓库只提供 safetensors，GGUF 在独立仓库 OpenBMB/MiniCPM-V-4.7-1B-GGUF，量化齐全：

复制代码

MiniCPM-V-4_7-1B-Q4_K_M.gguf    640.9 MB
MiniCPM-V-4_7-1B-Q8_0.gguf     1031.4 MB
MiniCPM-V-4_7-1B-F16.gguf      1930.6 MB
mmproj-model-f16.gguf          1058.7 MB   ← 视觉投影（默认 16x）
mmproj-model-f16-4x.gguf        859.3 MB   ← 高精度版（4x）

二、部署：为什么选 llama.cpp，以及踩的一个坑

2.1 方案选型

官方给了 Transformers、transformers serve、vLLM、SGLang、llama.cpp、Ollama 几条路。我的机器上没有 NVIDIA 显卡，7.8GB 内存也吃不下 float32 全精度（约 6.2GB 权重 + 激活），所以选了 llama.cpp + Q4_K_M 这条路：

显存/内存占用小（Q4_K_M 只有 641MB）
推理服务自带 OpenAI 兼容 API，前端可以直接对接
CPU 上能跑，不需要显卡

2.2 踩的坑：旧版 llama.cpp 不认这个模型

我本地原来有个 b9986 版本的 CPU 构建，加载视觉投影时直接报错：

复制代码

clip_init: failed to load model 'mmproj-model-f16.gguf':
  load_hparams: unknown projector type: minicpmv4_7

也就是这个构建早于模型发布，不认识新的投影层类型 。换成最新的 b11582 后正常加载。

经验：这类刚发布的多模态模型，llama.cpp 侧的支持往往滞后几天。遇到 unknown projector type / unknown architecture 这类报错，第一反应应该是升级 llama.cpp，而不是怀疑权重文件损坏或反复重新下载。

2.3 启动命令

bash 复制代码

llama-server \
  -m MiniCPM-V-4_7-1B-Q4_K_M.gguf \
  --mmproj mmproj-model-f16.gguf \
  -c 8192 -t 10 -np 1 \
  --host 127.0.0.1 --port 8080 \
  --jinja --temp 0

实测 -c 8192 + 单个 slot 时，服务进程常驻内存约 1996MB。模型加载约 12 秒。

2.4 关键坑：必须关掉思考模式

这个模型的对话模板默认走 <think> 思考链。做 OCR 时如果不关，效果会明显变差。

实测同一张表格图：

默认（思考开启） ：输出 512 token 用尽被截断，内容却是 To extract the sales table, we analyze the image:... 这样的铺垫，表格根本没给完
关闭思考后：194 token，Markdown 表格完整且数字全对

关闭方式是在请求里加：

json 复制代码

"chat_template_kwargs": { "enable_thinking": false }

这是本次测试里性价比最高的一个优化，建议所有做结构化输出的场景都默认关闭。

三、测试设计

3.1 样本

自己用代码生成 5 类图片，覆盖从易到难，并为每张图配了标准答案：

图 1：5 类测试样本，覆盖票据、混排、表格、复杂版式、低质量图像

样本	难度	考察点
发票票据	简单	中文长文本、金额、税号
中英混排+代码+符号	中等	代码缩进、特殊符号、邮箱 URL
三线表格	中等	结构化数据、千分位数字
双栏密集小字说明书	困难	复杂版式、阅读顺序
模糊+倾斜+小字	困难	图像质量鲁棒性

⚠️ 关于样本的重要说明（直接影响你怎么解读后面的数字）

这 5 张测试图是我用 PIL 代码生成的合成图：白底黑字、标准字体、无噪点、无透视畸变、无光照不均。这带来两个后果，必须先讲清楚：

1. 结果系统性偏乐观。 真实场景的票据和文档多为手机拍摄或扫描件，普遍存在阴影、纸张弯曲、压缩噪点、倾斜透视，识别难度明显高于本文样本。请不要把文中的准确率直接当作你业务数据上的预期值。

2. 样本量小（5 张）且为单次推理。 没有重复实验、没有置信区间，温度设为 0 走贪心解码。因此本文结论只能反映方向性信号，不构成能力上限的判定。

3.2 评分：为什么要同时看两个指标

只用一个指标会误判，所以我用了两个：

字符准确率 = 1 − 编辑距离 / 参考字符数（已忽略空白与全半角标点差异）。对阅读顺序敏感，版式一错就掉分。
字符 F1 = 忽略顺序的字符集 F1。衡量"字到底认出来没有"，不受排版影响。

两个指标一起看，才能区分"字没认出来 "和"字认出来了但顺序错了"------这是两种完全不同的问题。测试页里的逐字对比视图就是干这个的：

图 2：逐字对比视图。绿色=正确，红色=识别错误，灰色删除线=漏识别，换行与原始排版保持一致。图中耗时（9.5s）为缓存命中后的热态数据，与第四节表格的冷启动状态不同，差异原因见 5.3 节

四、测试结果

冷启动（服务刚重启、图像编码缓存为空），命令行批量跑：

样本	准确率	字符F1	总耗时	视觉编码	生成速度
发票票据	99.51%	99.51%	33.4s	24.2s	20.3 tok/s
中英混排+代码+符号	94.33%	96.94%	24.4s	16.2s	19.6 tok/s
三线表格	100.00%	100.00%	25.7s	17.1s	18.1 tok/s
双栏密集小字	55.96%	96.41%	40.8s	29.9s	16.0 tok/s
模糊+倾斜+小字	100.00%	100.00%	25.6s	19.9s	16.0 tok/s
平均	89.96%	98.57%	30.0s	---	18.0 tok/s

测试台界面里可以看到同样的结果，每个样本逐行填入、带颜色评级：

图 3：自建测试台的内置测试结果，准确率与命令行独立计算完全一致。注意图中「平均用时 8.6s」是热态数据（视觉编码命中缓存，仅 0.1s），与第四节表格的冷启动 30.0s 相差 3.5 倍，原因见 5.3 节

4.1 别只看平均数：中位数才更能代表常态

统计量	准确率
平均	89.96%
中位数	99.51%
最低	55.96%（双栏版式）

平均数被单个双栏样本（55.96%）严重拉低。实际上 5 个样本里有 4 个在 94% 以上 ，只有复杂版式那一个崩了。换句话说：它在自己擅长的版式上很稳，短板集中在版面分析能力，而不是"整体只有 90 分"。

4.2 一个必要的基线参照

PaddleOCR 这类专用 OCR 引擎在这类干净票据上通常能接近 100%，而且在排版还原、坐标输出、批量并发上都远强于本模型。拿 MiniCPM-V 4.7-1B 去和它们比"认字"，本来就不是它的主场。

它的价值在别处：用 1.55B 的体积同时具备"识别"和"理解"两种能力------可以边看图边回答问题、边抽取结构化字段、边做判断，而专用 OCR 引擎只能给你一堆文字。

五、逐项分析

5.1 超出预期的部分

票据类几乎零错误。 发票代码、纳税人识别号（含字母数字混排 91110108MA01ABCD2X）、各项金额、千分位，全部准确，连"壹万柒仟陆佰肆拾贰元整"这种大写金额都没错。对一个 1.55B 的模型来说，这个精度是真的可以。

图 4：发票样张的原文与模型输出对比，准确率 99.51%

表格结构化能力不错。 直接按要求输出了标准 Markdown 表格，数字一个没错。用于"截图转表格"这类场景是可用的。

图 5：三线表格原文与模型输出对比，准确率 100%

轻微降质下表现稳定。 我做了倾斜 3.5° + 高斯模糊（半径 0.9）+ 小字号的图，准确率 100%。

但这里必须说清楚：这个降质强度其实很轻微 ，属于"轻微模糊"，远不是真实场景中的重度失真------手机拍摄的阴影、纸张弯曲、低分辨率翻拍这些都没有覆盖。所以合理的表述只能是"对小字号和轻微失真不敏感 "，不足以推出"抗模糊能力强"。要下这个结论，至少得补测半径 1.5 / 2.5 的高斯模糊、低对比度和 JPEG 压缩这几档梯度。

5.2 明确短板

① 双栏版式会跨栏串读，而且重复输出。

这是最严重的问题。准确率只有 55.96%，但 F1 高达 96.41%------字基本都认出来了，问题出在阅读顺序。模型把左右两栏的内容交错混合，还出现了一整行重复。

图 6：双栏复杂版式的失败案例。左侧原图为左右两栏，右侧输出把两栏内容串读，且"电池容量：5000mAh"重复了一次

原因不难理解：它是通用视觉语言模型，不是版面分析引擎，没有显式的栏框检测和阅读顺序建模。密排双栏这种版式，超出了它的能力范围。

② 特殊符号会丢。

中英混排样本里，{} | ' _ 等符号有丢失，邮箱里的 + 也没了，罗马数字 Ⅰ 被误读成 I Ⅰ。

图 7：中英混排与符号的识别情况，代码缩进丢失、部分特殊符号遗漏

这类低对比度、细笔画的符号在视觉 token 压缩（16x 下采样）后信息损失较大，属于架构层面的取舍。

提示：官方提供了 mmproj-model-f16-4x.gguf（4x 模式，保留 4 倍 token 精度），理论上能改善这类细节。我下载了但本次未做对比测试，有需要的话值得一试，代价是明显变慢。

5.3 性能特征

视觉编码是绝对瓶颈。 冷启动时它占了单张图总耗时的 60%--75%（16--30 秒），而文本生成只要 4--13 秒。

缓存影响巨大，看数据务必区分冷/热。 第四节表格里的 30.0s 是冷启动 （服务刚重启、图像编码缓存为空）；同一批图片紧接着再跑一遍，视觉编码降到 0.1s，单张平均耗时掉到 8.6s ------差了 3.5 倍 。所以请认准状态：冷启动单图约 25--40s，缓存命中后约 8s，两者不能混着比较。

六、优点总结

优点

体积与门槛 ：641MB 的 Q4_K_M，2GB 内存，纯 CPU 可跑，无显卡也能用
票据/单栏文档精度高：实测接近 100%，实用价值明确
表格转 Markdown 开箱可用
对小字号和轻微失真不敏感（但降质强度有限，见 5.1）
Apache-2.0，商用友好；GGUF 量化齐全，Q4 到 F16 都有
自带 OpenAI 兼容 API，工程接入成本低

七、结论与建议

推荐用：票据/单据信息抽取、单栏文档数字化、表格转 Markdown、截图问答、无显卡的边缘设备。

几条实践建议：

建议 enable_thinking: false，否则输出可能会跑偏
图片预处理：双栏图片先切分再送模型，能规避它最大的短板
追求细节时换 4x 版本 mmproj，但要接受速度下降
服务常驻、复用图像缓存，热态下单图可到 8s 量级
冷启动性能数据不要和热态混在一起比较

八、一点局限说明

本文结论基于 5 张自建样本、单一硬件环境（Intel 核显 + 7.8GB 内存）、单次冷启动 + 单次热缓存 的测试，且样本为合成图，未覆盖真实拍摄场景 （详见 3.1）。此外，本文未与 PaddleOCR 等专用引擎做同条件对比 ，也未测试 4x 精度 mmproj，抗模糊结论的降质强度也偏弱（见 5.1）。

综合起来：结论是方向性的，不是定论。建议你在自己的真实业务数据上复测一遍再下判断。

测试环境：Windows / Python 3.11.9 / llama.cpp b11582（CPU 构建）/ MiniCPM-V-4.7-1B Q4_K_M + mmproj-f16 / Intel UHD 核显 + 7.8GB 内存 + 12 线程

模型下载地址：https://www.modelscope.cn/models/OpenBMB/MiniCPM-V-4.7-1B-gguf

OCR实测项目源码下载：https://download.csdn.net/download/qq616491978/93696449