小模型OCR对比速览：Qwen3VL vs Gemma4 vs Hunyuan-OCR vs GLM-OCR

小模型OCR对比速览：Qwen3VL vs Gemma4 vs Hunyuan-OCR vs GLM-OCR

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

测试环境/工具： llama.ccp（基本5.1最新代码） + SYCL （oneAPI 2026.0）
启动参数：-n -1 -ngl 50 -c 40000 --port 7877 --temp 0.1 --jinja （针对gemma4还有控制思考模式的参数 --chat-template-kwargs '{"enable_thinking":false}'）

测试模型：

模型	gguf	mmproj-gguf
Qwen3VL 2B	Qwen3VL-2B-Instruct-Q4_K_M.gguf	mmproj-Qwen3VL-2B-Instruct-Q8_0.gguf
Gemma4 E2B	gemma-4-E2B-it-Q8_0.gguf	mmproj-gemma-4-E2B-it-Q8_0.gguf
Hunyuan-OCR	HunyuanOCR-Q8_0.gguf	mmproj-HunyuanOCR-Q8_0.gguf
GLM-OCR	GLM-OCR-Q8_0.gguf	mmproj-GLM-OCR-Q8_0.gguf

🚀 核心对比速览表

	Qwen3VL	Gemma4	Hunyuan-OCR	GLM-OCR
生成速度	13.x / s ~ 14.x / s	6.x / s ~ 7.x / s	17.06 / s	18.x / s ~ 22.x / s
需要预处理图片？	最好自己预处理 或者添加启动参数--image-max-tokens	基本不用自己处理 但存在有些图片自己预处理后，识别出错率更低	最好自己预处理降低宽高	最好自己预处理 或者添加启动参数--image-max-tokens
文字类文档整体识别	基本没问题 偶尔识别错误	基本没问题 偶尔识别错误（中文识别出错率似乎高一点）	基本没问题	基本没问题
提取局部信息	基本没问题	基本没问题	不支持	不支持
复杂印刷手写混合	持续重复输出	不支持，提示太模糊	持续重复输出	持续重复输出
图表类文档整体识别	基本没问题 偶尔触发重复输出	基本没问题 某些logo没识别为文字	没整体测试 大概率没问题	基本没问题 某些logo没识别为文字
解读图表类	支持，质量还行	支持，质量还行	支持，解读质量较差	不支持

备注

测试场景:

场景	解释说明
文字类文档整体识别	电脑上的文字截图 或 手机拍照电脑屏幕（打开Word文档时） 或 手机拍照消费小票，识别图中文字
提取局部信息	手机拍照消费小票，提取关键信息，并以Json格式输出
复杂印刷手写混合	仅测试一张手机照片，拍摄一张A3纸，纸上内容是一个表格，且不规则位置存在手写批注，识别图中文字
图表类文档整体识别	复杂PPT截图（含文字，图表，流程图，网状图等），识别图中文字
解读图表类	仅测试解读复杂PPT截图中一张带X轴、Y轴的趋势图

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

• 经过阅读部分源代码的理解，估计llama.cpp对于目前支持vision的模型，其实是自带图片的预处理，主要是针对不同模型的参数和实现方式，需要预先做一些对齐工作（不同模型，情况不一样），预处理主要是resize图片的宽度、高度。
• Qwen3VL和 GLM的预处理的逻辑差不多，但是两个模型的patch_size和n_merge的不一样，接受启动参数--image-max-tokens的控制。
  • 至少在我的测试环境中，使用这两个模型且不控制--image-max-tokens 时，发现encode 图片的tokens过高时(特别裁剪过的小票类照片，高度比宽度大很多），自带预处理 resize后，会触发比较奇怪现象 -> 程序会停在encoding image slice...
  • 启动参数加上后--image-max-tokens ，自带预处理 resize时结合这个参数，计算出更小的宽、高，然后再resize，可能避过上面的问题，从而成功处理
  • 如果想自己预处理图片，我的粗略经验，针对正常宽高比照片，最好自己resize照片调整「宽或高中的较大那一个」到1000像素以下，较小的那个等比例变化；针对小票类高度很大的照片，高度可能需要调整到1400像素以下
    • 如想避过llama.cpp现在resize的逻辑，在控制宽、高像素大小外，还需要自己控制宽度、高度的数值都能被（patch_size * n_merge，qwen3vl 为 32，GLM-OCR 为28）整除
• Gemma4，在我的使用中，至今没有遇到程序停在encoding的情况，它的patch_size * n_merge 为48，并且看到同样原始图片输入，他自动resize到比较小尺寸的图片，而且encode 图片的tokens 会对比另外几个的小很多
• Hunyuan-OCR的测试不多，目前不接受启动参数--image-max-tokens的控制，最好自己预处理需要识别图片的宽、高，否则容易触发程序会停在encoding image slice...