小模型OCR对比速览-续：Qwen3.5 0.8B vs MiniCPM-V-4.6

小模型OCR对比速览-续：Qwen3.5 0.8B vs MiniCPM-V-4.6

硬件环境： Intel(R) Core(TM) Ultra 7 165U

测试环境/工具： llama.ccp（基本5.14最新代码） + SYCL （oneAPI 2026.0）
启动参数：-n -1 -ngl 50 -c 40000 --port 7877 --temp 0.1 --jinja --reasoning off

测试模型：

模型	gguf	mmproj-gguf
Qwen3.5 0.8B	Qwen3.5-0.8B-Q4_K_M.gguf	mmproj-Qwen3.5-0.8B-f16.gguf
MiniCPM-V-4.6	MiniCPM-V-4.6-Q4_K_M.gguf	mmproj-MiniCPM-V-4.6-Q8_0.gguf

🚀 核心对比速览表

	Qwen3.5 0.8B	MiniCPM-V-4.6
生成速度	18.x / s	20.x / s ~ 22.x / s
需要预处理图片？	最好自己预处理 或者添加启动参数--image-max-tokens	最好自己预处理
文字类文档整体识别	基本没问题	基本没问题
提取局部信息	基本没问题	基本没问题（常有识别错误）
复杂印刷手写混合	偶尔持续重复输出	很多遗漏，错字
竖版古籍djvu截图	支持，质量还行（有遗漏，错字）	支持，质量较差（有遗漏，错字）

备注

测试场景:

场景	解释说明
文字类文档整体识别	电脑上的文字截图 或 手机拍照电脑屏幕（打开Word文档时） 或 手机拍照消费小票，识别图中文字
提取局部信息	手机拍照消费小票，提取关键信息，并以Json格式输出
复杂印刷手写混合	仅测试一张手机照片，拍摄一张A3纸，纸上内容是一个表格，且不规则位置存在手写批注，识别图中文字
竖版古籍djvu截图	古籍djvu文件的截图，繁体文字竖版，从右往左读取。一列中又有大字、又有小字

不懂为什么，今天在这个平台无法上传照片，否则测试场景直接贴图，一目了然。

需要预处理图片？避坑须知

• 经过阅读部分源代码的理解，估计llama.cpp对于目前支持vision的模型，其实是自带图片的预处理，主要是针对不同模型的参数和实现方式，需要预先做一些对齐工作（不同模型，情况不一样），预处理主要是resize图片的宽度、高度。
• 就目前而言，没看到针对Qwen3.5 0.8B没有什么特别处理，和 Qwen3VL的预处理的逻辑差不多，注意事项可以参考-->前一篇文章
• MiniCPM-V-4.6，实现方式和Qwen，GLM，Gemma4都不一样，会处理为一个缩小总览图、以及至多9个切片图片（也是在另一缩小的图片上进行切片），再把总览图、切片图一起encode，再decode
  • 至少在我的环境上多次测试看到，目前代码对很多不同尺寸的文件，预处理完后，在encode阶段，会让ggmlsycl后端计算时崩溃
  • 最好原始图片比例为4:3 或者1512x1176 。千万不能1:1，宽或高千万不能448的整数倍（448是模型参数参数中image_size，会用来计算总览图尺寸、切片的大小）。原始尺寸可能也不能太小。