**摘要：**本文在无显卡的 Ubuntu 24.04 小主机上，对 EmbeddingGemma 2、Qwen3-VL-Embedding-2B、WeMM-Embedding-2B 三款多模态向量模型做了同卷图片检索实测。结果显示三款模型全部可跑通，Hit@1 集中在 12~13/15：Qwen3-VL 以 13/15 占先且图表类检索全中，EmbeddingGemma 2 以 3.1GB 内存增量与 19.2s/张的编码速度成为资源紧张场景的首选。文章同时给出关键适配代码（VL 系图片输入必须走 chat template）、三个报错的根因（torchvision 硬依赖）以及纯 CPU 建库的吞吐参考，为无显卡机器做图片向量检索提供完整可复现的账本。
EmbeddingGemma 2 图片检索实测：3 款多模态向量模型在无显卡 Ubuntu 上的完整账本
实测日期 2026-10-09。环境：Ubuntu 24.04 / AMD Ryzen 7 5700U（8C16T，AVX2）/ 30G DDR4 / 无 GPU / transformers 5.19.0 + torch 2.14.1+cpu + torchvision 0.29.1+cpu，fp32 精度。 考卷：20 张中文技术博客生产图（封面 / 竖版贴图 / 系统截图 / 数据图表 / 流程图）入库，15 条带标准答案的中文查询找图，指标 Hit@1 / Top3。 考卷脚本、内存探针与安装操作报告已打包（见文末），无显卡机器从零可复现。
TL;DR
- 没有显卡，图片检索能跑通：transformers 侧没有 llama.cpp 的多模态输入限制，三款多模态向量模型全部出向量、全部完成同卷判分。
- 质量挤在 12~13/15（Hit@1）：Qwen3-VL-Embedding-2B 以 13/15 占先，三张数据图表全部头名命中；EmbeddingGemma 2（740M 全模态）与 WeMM-Embedding-2B（2B）均 12/15。
- 资源与速度差距是倍数级的：内存增量 3.1GB / 7.7GB / 9.7GB；单张图片编码 19.2s / 34.5s / 26.3s；单条文本查询 1.79s / 6.18s / 11.47s。
- 共同失分点：文字密集的竖版贴图配模糊查询，三家分别排到第 4 / 11 / 13 名。纯视觉 embedding 不做 OCR，文字截图型图库需要前置 OCR 方案。
- 上一轮在 llama.cpp 侧图片输入被静默忽略（cos=1.000000）的问题，在 transformers 侧不存在；代价是吞吐下降与部署形态从"一个 server"变成"一个 Python 进程"。
一、测试环境
| 项 | 值 |
|---|---|
| 机器 | 无显卡 Ubuntu 24.04 小主机 |
| CPU | AMD Ryzen 7 5700U，8C16T，AVX2 / F16C（无 AVX512） |
| 内存 | 30G DDR4 |
| 推理栈 | transformers 5.19.0 / torch 2.14.1+cpu / torchvision 0.29.1+cpu |
| 精度 | fp32（EmbGemma 2 模型卡明示 FP16 会出 NaN，CPU 统一 fp32） |
| 线程 | torch.set_num_threads(12) |
权重来源全部为魔搭（国内直连速度远快于 HF）：google/embeddinggemma-2（1.5G）、Qwen/Qwen3-VL-Embedding-2B（4.0G）、tencent-community/WeMM-Embedding-2B（5.1G）。注意 WeMM 的 org 是 tencent-community，按 Tencent/ 猜会 404。
二、考卷与判分
- 文档侧：20 张图，长边统一压到 1024px（原图最大约 1080×1420 竖版贴图），逐张编码为向量；
- 查询侧：15 条中文查询（如"推理预算对比的数据图""开源协议速查卡""纯 CPU 跑大模型实测的封面"），每条人工标注正确图片；
- 判分：查询向量与全部图片向量做余弦排序，统计 Hit@1 / Top3；同时逐图计时得到入库吞吐。
文本与图片向量归一化后用同一位计算余弦；pooling 按模型架构分别处理（下文第四节）。
三、结果总表
3.1 图片检索质量 + 速度
| 模型 | 内存增量(fp32) | 图片编码均时 | Hit@1 | Top3 |
|---|---|---|---|---|
| Qwen3-VL-Embedding-2B | 7718MB | 34.5s/张 | 13/15 | 14/15 |
| EmbeddingGemma 2 | 3086MB | 19.2s/张 | 12/15 | 14/15 |
| WeMM-Embedding-2B | 9691MB | 26.3s/张 | 12/15 | 14/15 |
3.2 文本查询延迟（15 条实测折算单条）
| 模型 | 单条延迟 | 备注 |
|---|---|---|
| EmbeddingGemma 2 | 1.79s | 对照 GPU（llama.cpp，3070）：17.2ms，约百倍差距 |
| Qwen3-VL-Embedding-2B | 6.18s | |
| WeMM-Embedding-2B | 11.47s | 架构依赖的优化内核缺失，走 PyTorch 参考实现 |
3.3 内存占用（/proc/meminfo 加载前后差值，fp32）
| 模型 | 加载增量 | 说明 |
|---|---|---|
| EmbeddingGemma 2 | 3086MB | 740M 全模态，三者中仅有的 3GB 档 |
| Qwen3-VL-Embedding-2B | 7718MB | 2B fp32，符合"参数量 × 4"估算 |
| WeMM-Embedding-2B | 9691MB | 2B fp32 + processor 常驻 |
四、关键适配代码
4.1 三款模型的加载与向量提取
python
import torch
from transformers import AutoProcessor, AutoModel
def load(path):
proc = AutoProcessor.from_pretrained(path, trust_remote_code=True)
model = AutoModel.from_pretrained(path, torch_dtype=torch.float32,
trust_remote_code=True)
model.eval()
return proc, model
def pool_last(hidden, mask):
idx = int(mask.sum().item()) - 1 # 最后一个非 padding 位置
return hidden[0, idx].float().numpy()
def pool_mean(hidden, mask):
m = mask.unsqueeze(-1).float()
return (hidden * m).sum(1)[0].float().numpy() / (m.sum() + 1e-9)pooling 分工：EmbeddingGemma 2 用 mean（last_hidden_state 序列均值）；Qwen3-VL 与 WeMM 用 last-token（取最后一个非 padding 位置）。pooling 选错不报错，但质量静默下降。
4.2 VL 系的图片输入必须走 chat template
Qwen3-VL 与 WeMM 的 processor 不能只传图片（报错见第五节），需要把图片占位与文本一起经 chat template 组装：
python
msgs = [{"role": "user", "content": [
{"type": "image"},
{"type": "text", "text": "这张图片"},
]}]
txt = proc.apply_chat_template(msgs, tokenize=False, add_generation_prompt=True)
inputs = proc(text=[txt], images=[img], return_tensors="pt")
with torch.no_grad():
out = model(**inputs)
emb = pool_last(out.last_hidden_state, inputs["attention_mask"])EmbeddingGemma 2 则相反，图片直接 processor(images=img, return_tensors="pt") 裸传即可，文本侧加官方前缀 task: search result | query: {q}（实测该前缀对检索排序的影响约 0.009 MRR，可省）。
4.3 纯 CPU 文本入库吞吐参考（EmbGemma 2）
178 个文本块（459 字均值）逐小批编码，总耗时 315.9s，约 0.56 块/s：
python
for i in range(0, len(chunks), 4):
inputs = proc(text=["task: search result | query: " + t for t in chunks[i:i+4]],
return_tensors="pt", padding=True)
with torch.no_grad():
model(**inputs)2B 模型按查询延迟折算，178 块预计 18~34 分钟。CPU 建库的定位结论：一次性可接受，频繁增量重建建议换小模型或加卡。
五、排错实录（三个报错，一个根因家族）
报错 1 ：ModuleNotFoundError: Could not import module 'EmbeddingGemma2Processor' 报错 2 ：Qwen3VLVideoProcessor requires the Torchvision library but it was [...] 报错 3 （传图片时）：TypeError: embedding(): argument 'indices' (position 2) must be Tensor, not None
三个报错指向两件事：
- torchvision 是多模态 processor 的硬依赖 。缺它，三个模型的图片处理类全部无法导入。修复：与 torch 同源安装
pip install torchvision --index-url https://download.pytorch.org/whl/cpu，版本自动配对（本次 0.29.1+cpu）。 - VL 系 processor 的图片必须与文本合传 。只传
images不传text，processor 不生成 input_ids，底层 embedding 层直接拿到 None。另一个隐藏点是图片 token 需要由 chat template 展开为占位符，裸写文本不会触发视觉通路。
另有性能提示（非错误）：WeMM（Qwen3.5 架构）在 CPU 上会提示 causal_conv1d 与 flash-linear-attention 未安装并回落参考实现，文本编码因此偏慢（15 条 172s）。这两个内核主要面向 CUDA，CPU 场景暂无解，属于该模型在纯 CPU 形态的固有限制。
六、逐题明细中的共性与差异
- 共性失分：三家的非头名题完全重合在"文字密集竖版贴图 + 模糊查询"（"讲是什么的系列总纲竖图"，三家排名 4 / 11 / 13）。纯视觉 embedding 无 OCR，图内的文字信息不参与向量。图库中文字截图占比高时，需要 OCR 前置或改用文档解析方案。
- Qwen3-VL 的增量：数据图表类（柱状对比、曲线、流程图）三连头名，图表的结构化视觉特征是它的主场。
- EmbGemma 2 的分布：15 题没有一次跌出前四，方差小，适合当默认选项。
七、复现
数据包含：emb_img_test.py（首轮）、emb_img_fix.py（chat template 修复版，推荐）、mem_probe.py（内存探针 + 文本入库吞吐）、build_corpus.py（文本考卷）与安装操作报告（从裸 Ubuntu 到跑通的每条命令）。三步：建 venv 装 CPU 版三件套 → 魔搭拉权重 → 改 QUERIES 跑脚本。
八、结论
- 无显卡机器做图片向量检索是可行的，质量上三款模型都能到"可用"档（Hit@1 12~13/15），且互有胜负不多；
- 选型胜负手在资源：内存紧张选 EmbeddingGemma 2（3.1GB + 19.2s/张），追求图表检索质量且内存宽裕选 Qwen3-VL（13/15 + 34.5s/张）；
- 文字截图型图库是三个模型共同的盲区，上 OCR 前置再说；
- llama.cpp 侧的多模态向量输入（issue #30082）修复前，图片检索的本地推理只在 Python 生态成立。
完整叙事与纯 CPU 选型决策卡在同名GZH同日推文；数据包（考卷 + 脚本 + 安装报告）后台回复获取。分数为单机 fp32 实测，语料与图库不同结论可能不同。