想做本地版的「网页截图 → 按钮坐标」自动化（给 GUI Agent 用），第一步是找个能在纯 CPU 上跑的视觉模型。我选了两个最小的候选——Qwen3-VL-2B 和 Gemma-4-E4B——用真实的网页截图测了一圈：识别速度、细节质量、坐标精度。结论很有代表性：一个看得懂但给不出坐标，一个给坐标但瞄不准。
环境：llama.cpp mtmd 多模态，纯 CPU，Q4_K_M 量化，temperature=0/0.3，真实网页截图 6 张。2026-08-24 实测。
速度：Gemma 快 2.9 倍
差距的根源在视觉编码的 image token 数量：Gemma 每图只产生约 292 个 image token，Qwen3-VL 是 1018~1789 个（图表类图片更夸张），prefill 成本差 3~6 倍。两者文本 decode 速度其实相近——慢在「看」，不在「说」。
质量 v1：各有硬伤
| 能力 | Qwen3-VL-2B | Gemma-4-E4B |
|---|---|---|
| 细节识别 | 准确：能读出「登录领取限时福利」「致态 TiPlus9100 ¥2088.51」等真实文字，几乎无幻觉 | 幻觉明显：「京东」认成「京商」，编造不存在的「全品类/服饰/家居」导航 |
| 按钮坐标 | 不输出像素坐标，只给「左上角/右上角」定性描述 | 输出 (x,y,w,h)，但自述「基于网页惯例的估计」，漏掉中央登录弹窗等关键按钮 |
典型的互补型缺陷：Qwen 是「看得懂说不清」，Gemma 是「敢说但说错」。
质量 v2：提示词优化能救多少
我改了四件事：① 强制 JSON 数组输出；② 在提示词里注入图片真实像素尺寸；③ 要求 bbox 紧贴元素边界；④ 每元素只出现一次。并用 glm-4v 做第三方参照。
- Qwen3-VL 改善明显：注入真实尺寸后开始给出合理的坐标区间，大按钮（登录/关闭）可用，小文字按钮仍偏移
- Gemma 依旧幻觉：坐标给得更大胆但更不准，仍会漏检弹窗
- 最大教训：VLM 不确定图片的真实像素尺寸——把「图片是 1440×1000」写进提示词是坐标任务的关键一步，很多教程没提
复现方法
想自己跑一遍的折腾党，关键配置都在这：
- 模型下载：HuggingFace 直连超时的话用 hf-mirror.com 镜像（实测 51 MiB/s vs 直连 60 KiB/s）。Qwen3-VL-2B：主文件 1.11GB + mmproj 0.82GB；Gemma-4-E4B：主文件 4.98GB + mmproj 0.99GB——多模态模型必须带 mmproj 文件，那是视觉编码器
- 启动命令：
llama-server -m 模型.gguf --mmproj 视觉.gguf -c 8192 --host 127.0.0.1 --port 端口；Gemma 必须加--reasoning off（默认 thinking 会吃掉 token 预算且不输出可见文字） - 采样：temperature=0 稳定输出；Qwen 出现重复坍塌时调到 0.3
- 两个坑：脚本里用
--port不能用-p（会被当成 prompt）；PowerShell .ps1 含中文需 BOM 编码，否则提示词乱码——测试提示词建议统一用英文 - 图片解码：PNG 走内置 stb 解码零依赖；JPEG 需要 ffprobe.exe 在 PATH 里
给 GUI Agent 实践者的建议
- 速度优先 / 简单页面：Gemma-4-E4B（12.7s/图），但必须配坐标校验（元素文本匹配 + 边界外剔除）
- 精度优先 / 文字密集页面：Qwen3-VL-2B + 尺寸注入提示词，接受 3 倍耗时
- 工程兜底：VLM 输出坐标后，用 DOM/DOM-less 方案（如图像模板匹配）二次校准；纯 VLM 坐标直接点击在生产上还不可靠
- 本地图快：JPEG 解码需要 ffprobe 在 PATH；PNG 走内置 stb 解码无依赖
2B 级别模型的天花板就在这了；要真正可用的坐标精度，得看 7B+ 的专用 GUI 模型（如 UI-TARS），那是另一篇的题材。推理速度的原理看纯 CPU 推理实测。
免责声明：两模型均为 Q4 量化 + 纯 CPU 环境，坐标精度结论不适用于原生高精度定位模型；测试样本有限。