本地多模态推理实战：被忽视的视觉参数与四类模型横评

一、写在前面：一个被长期忽略的参数

很长一段时间里，我都用本地推理服务以纯文本模式完成日常的代码生成与文档处理任务，效率还算理想。但心里始终存着一个疑问：明明加载的是具备视觉能力的模型，为什么服务端只能处理文字，识别不了图片？

直到某天翻查推理框架的文档，才注意到一个此前被完全跳过的启动参数——用于指定视觉编码器权重的投影文件路径。大致形式如下：

--mmproj ../model-vision-encoder-f16.gguf

就这一个参数。

换句话说，此前几个月的使用方式，相当于买了一台带摄像头的手机，却只用它打电话。模型本身支持多模态，只是推理服务启动时没有显式加载视觉编码模块，于是退化成了纯文本模型。这个细节在文档里并不显眼，却直接决定了多模态能力能否被激活。

既然发现了，就没有理由继续浪费。于是把手头四款支持视觉输入的模型全部拉出来，从纯文字识别到看图生成网页代码，挨个跑了一遍，记录下这场“多模态修罗场”的真实表现。

二、多模态推理的机制：为什么一个参数如此关键

在展开实测之前，有必要先把机制讲清楚，否则容易把“模型不行”和“配置不对”混为一谈。

当前主流的开源视觉语言模型，通常采用“视觉编码器 + 语言模型”的组合结构。视觉编码器负责把图像切分成图块并提取特征，语言模型负责结合文本指令进行理解与生成。两者之间需要一个投影层（projection）把视觉特征映射到语言模型的表示空间。

在本地推理框架中，语言模型权重与视觉投影权重往往是分开存放的：

• 语言模型权重：负责文本理解与生成，纯文本模式下只需加载这一部分；
• 视觉投影权重：即 --mmproj 指向的文件，负责把图像特征接入语言模型。

这也解释了一个常见困惑：同一份模型文件，别人能识图，自己却不能。差别往往不在模型，而在启动时是否加载了视觉投影权重。此外还需注意：

1. 配套性：视觉投影权重必须与语言模型权重来自同一模型版本，混用不同版本的投影文件会导致输出错乱甚至崩溃。
2. 精度选择：投影权重常见 F16、量化等版本，F16 精度更高但占用显存更多，量化版本更省资源但可能损失细节。
3. 服务端与客户端配合：多模态请求需要以特定格式在消息中携带图像数据（通常为 base64 编码或本地路径），仅启动参数正确还不够，调用侧也要按多模态协议组织请求。

理解这三点，后面的实测结果才有解释力。

三、测试准备：两个场景、四款模型、一张显卡

为了让对比有实际参考价值，测试设计遵循“贴近真实开发需求”的原则：

测试组	任务	测试素材
测试组一	纯文字识别（OCR）	基准对比表格截图
测试组二	网页截图转 HTML 代码	自行设计的网页应用截图

硬件环境为单张 24GB 显存的消费级显卡，四款模型均在该显存条件下加载运行。测试统一采用单并发、单副本方式，尽量排除调度与批处理带来的干扰，让差异更多体现在模型本身。

需要说明的是，OCR 类任务的评价维度不只是“认得出字”，还包括版面结构还原、表格对齐、公式与符号识别、多语言混排处理等；而截图转代码任务的难点在于布局理解、组件语义推断与样式还原的平衡。两个场景恰好覆盖了“读”与“写”两类能力。

四、测试组一：纯文字识别（OCR）

4.1 测试素材与考察点

测试素材是一张信息密度较高的基准对比表格截图，包含多级表头、合并单元格、数值对比列与脚注说明。这类素材对模型的要求相当综合：

• 能否正确识别表格的行列结构，而不是把内容拉平成一段文字；
• 能否保留数值与单位的对应关系；
• 能否处理小字号、密集排版带来的识别压力；
• 能否在输出中维持 Markdown 表格语法，便于后续程序化处理。

4.2 输出表现分析

从实际输出看，模型之间的差异主要体现在三个层面：

第一层：字符级识别准确率。 多数模型对常规印刷体文字的识别都较为稳定，差异集中在相似字符（如 0 与 O、1 与 l、小数点与逗号）以及小字号区域。版面越密集，字符级错误越容易被放大。

第二层：结构还原能力。 这是区分度最高的部分。部分模型能把表格正确输出为 Markdown 表格，行列对齐良好；另一些模型虽然文字识别正确，却把表格结构拉平为连续文本，导致数值与表头的对应关系丢失，后处理成本大幅上升。

第三层：鲁棒性。 面对合并单元格、跨行跨列的表头、脚注等非标准结构时，不同模型的表现分化明显。有的模型会主动保留层级关系，有的则直接丢失部分单元格内容。

4.3 实践建议

基于这一组测试，可以总结出几条落地经验：

1. OCR 任务优先看结构还原，而非只看字符准确率。 对下游程序而言，表格结构错了，文字再准也难以使用。
2. 提示词要显式约束输出格式。 例如明确要求“输出为 Markdown 表格，保留原始行列结构，不要合并或省略单元格”，能显著提升结构还原的稳定性。
3. 对高密度素材做分块处理。 把大表格按区域裁剪后分别识别，再在程序侧拼接，往往比一次性送入整图更可靠。
4. 保留原始图片与识别结果的对照。 便于人工抽检与错误回溯，尤其在批量处理场景下。

五、测试组二：网页截图转 HTML 代码

5.1 任务难点

第二组任务更接近前端开发者的真实需求：给一张网页应用截图，让模型生成可运行的 HTML（含内联样式）。难点在于：

• 需要理解页面布局结构（导航栏、侧边栏、卡片区、表格区等）；
• 需要推断组件语义，而不是简单堆叠 div；
• 需要在“还原度”与“代码简洁度”之间取舍；
• 颜色、间距、圆角、阴影等视觉细节难以精确从像素反推。

5.2 输出表现分析

四款模型在这一任务上的表现差异比 OCR 更明显，大致可分为三类：

结构型输出。 能正确划分页面区域，生成合理的语义标签与层级结构，样式虽不完美但可读性强。这类输出最适合作为开发起点，人工微调成本低。

像素模仿型输出。 倾向于用大量绝对定位与内联样式逼近截图外观，视觉上更接近，但代码可维护性差，响应式适配几乎无从谈起。

简化型输出。 只还原主要区块，忽略细节组件，速度快但信息损失大，适合快速原型而非精细还原。

5.3 实践建议

1. 明确告诉模型“要结构，不要像素”。 在提示词中要求使用语义化标签、避免绝对定位、优先使用弹性布局，输出质量会明显改善。
2. 分区域生成再拼装。 对复杂页面，先让模型描述整体布局，再逐区域生成代码，比一次性生成整页更可控。
3. 把截图转代码定位为“初稿工具”。 它的价值在于跳过空白页阶段，而不是替代人工还原设计稿。
4. 建立自检清单。 生成后检查语义标签使用、布局方式、是否存在硬编码尺寸，能快速筛掉不可用的输出。

六、横向对比与选型思路

把两组测试放在一起看，可以得到几个偏工程化的结论：

• 没有全能模型。 OCR 表现好的模型，在截图转代码时未必最优；反之亦然。选型应围绕主任务，而不是追求单一榜单排名。
• 配置正确是前提。 视觉投影权重未加载、版本不匹配、请求格式错误，都会让“模型能力”无法体现。排障时应先确认链路，再怀疑模型。
• 显存与精度需要权衡。 24GB 显存下，F16 投影权重会明显挤占上下文与批处理空间。若并发需求高，量化版本或更小的模型更实际。
• 提示词工程投入产出比高。 同一模型，在结构化提示词下输出质量可以拉开明显差距，这部分成本远低于换模型。

一个可参考的选型流程是：先明确任务类型（读图取信息 / 看图生成代码 / 图文问答），再在小样本上跑通链路并固定提示词模板，最后才在候选模型间做定量对比。跳过前两步直接比模型，往往会得出误导性结论。

七、常见踩坑清单

结合实际调试过程，整理几条高频问题：

1. 只加载语言模型权重。 症状是模型对图片“视而不见”，只回复文字相关内容。检查启动参数是否包含视觉投影权重。
2. 投影权重与语言模型版本不一致。 症状是输出乱码、重复或直接报错。确保两者来自同一发布版本。
3. 请求中图像格式或编码不正确。 症状是服务端报解析错误。确认图像以约定格式（如 base64）嵌入消息体。
4. 上下文长度不足。 高分辨率截图会消耗大量视觉 token，上下文设置过小会导致图像被截断或请求失败。
5. 并发下显存溢出。 多模态请求的显存占用高于纯文本，高并发时需限制批大小或降低投影精度。

八、结语

这次实测最大的收获，不是某个模型赢了，而是意识到“能力就在那里，只是没被打开”。一个被忽略的启动参数，让本地推理服务从“只能打电话”变成“能拍照识别”。对开发者而言，类似的情况并不少见：工具的能力边界，往往取决于是否读懂了它的配置语义。

多模态本地推理已经具备相当的实用性，尤其在数据不出本地的场景下价值明显。但它不是开箱即用的魔法，链路配置、提示词设计、任务拆分、结果校验，每一环都会影响最终体验。把这几件事做扎实，本地多模态才真正称得上“可用”。