认识 WeMM-Embedding：微信把每天调用十亿次的多模态向量模型开源了，2B 打赢 8B

先讲一个我最近才反应过来的事。

我在微信里打一句"上次朋友发我的那个海边遛狗的视频"，能把它翻出来。我发一张截图问"这个报错怎么解"，能搜到公众号里对应的那篇文章。我在视频号刷到一半划走，下次打开首页它还在。

这些事太平常了，平常到我从来没问过一句：文字和视频，是怎么被放到同一个空间里比距离的？

答案是 Embedding（嵌入向量）。但真相比"文本走文本模型、图像走图像模型"要粗暴得多——微信视觉团队在 2026 年 9 月 4 日揭的谜底是：他们用一个模型，把文本、图像、视频、视觉文档，以及这些东西任意插花混在一起的玩意儿，全塞进同一个向量空间。

这模型不是实验室 demo。它在线上每天被调用十亿次量级，撑着视频号、直播、公众号、电商和朋友圈的推荐与检索。

然后他们把它开源了，叫 WeMM-Embedding。

最扎心的一条数据不是 9B 拿了第一，而是 2B 拿了 77.9 分，把此前最强的 8B 开源模型（Qwen3-VL-Embedding 8B，77.8）挤了下去。 小四倍的参数，打平甚至微超。这已经不是"小模型够用"了，这是在问那些堆参数的方案：你多出来的 60 亿参数都干嘛去了？

什么是 WeMM-Embedding

WeMM-Embedding（WeChat Multi-Modal Embedding）是腾讯微信视觉团队开源的通用多模态嵌入模型系列，提供 2B、4B、9B 三个尺寸，把文本、图像、视频、视觉文档以及任意交错（interleaved）的多模态输入，编码到同一个统一向量空间里，输出经过 L2 归一化的 Embedding。

代码在 github.com/Tencent/WeMM-Embedding，Apache 2.0 协议，权重、推理代码、评测工具全部开放。技术报告在 arXiv:2608.24053。模型权重 Hugging Face 和 ModelScope 都有（tencent/WeMM-Embedding-2B / 4B / 9B）。

先把几个容易误解的点说清楚：

第一，它不是生成模型。 你问它问题，它不会回答你一句话。它吐出来的是一串数字——一个向量。它的价值在"比距离"：两个东西语义上像不像，算一下余弦相似度就知道。它是检索、推荐、聚类、去重、RAG 的底座，不是那个站在台上说话的。

第二，它不是一个"文本模型 + 图像模型"的拼接货。 官方明确说骨干基于 Qwen3.5 原生多模态架构——图像、视频和文字从一开始就在同一个模型里共同处理，不是各编各的再想办法对齐。这是它和上一代方案最本质的区别。

第三，它不含音频。 官方 README 里写得很直接：Audio input is not currently supported。在 MMEB-v3 的音频任务上，分数是 0——不是跑崩了，是压根不支持，评测里直接记 0 分。这点必须提前知道，别拿它去做音视频混合检索然后骂它不行。

第四，向量是这么取出来的：取最后一层隐藏状态在专用 <embedding> token 位置上的向量，再做 L2 归一化。后面你会看到，这个设计让"套娃"玩法变得特别干净。

它有什么特点

• 一套模型，五种输入：文本、图像、视频、视觉文档（截图、PDF、扫描件那类）、以及图文视频任意交错的输入。以前做"以图搜文 + 以文搜视频"要接三四个模型，现在一个够了。跨模态检索不再是"几个系统缝合"，而是一次前向传播。

• Matryoshka 套娃表示学习（MRL）：这是我最喜欢的一个设计。模型原生支持多档维度——

  模型	支持维度
  WeMM-Embedding-2B	64 / 128 / 256 / 512 / 1024 / 2048
  WeMM-Embedding-4B	64 / 128 / 256 / 512 / 1024 / 2560
  WeMM-Embedding-9B	64 / 128 / 256 / 512 / 1024 / 2048 / 4096

  想省存储就截短，想追精度就用满。**2B 模型在 256 维时，仍能保留全维度下 98.7% 的图像与视频性能。**截完再归一化一次就行：

  embedding = torch.nn.functional.normalize(embedding[..., :d], dim=-1)

  这意味着你不用为了换个维度重新训练、重新灌库。一套向量库，容量和精度自己拨旋钮。做向量数据库的朋友应该懂这有多省事——改维度不用全量重建索引，这能救回好几个通宵。

• 两阶段训练：第一阶段用数亿级异构数据做大规模多模态对齐，引入任务特定指令、任务一致批处理（task-consistent batching）和去重感知掩码（dedup-aware masking）；第二阶段用精选数据微调，加上语义 ID 引导的重采样、MLLM 数据清洗、重排序器（reranker）监督信号和跨尺度知识蒸馏。官方消融说，第二阶段这几板斧累计带来 2.2 分的提升。

• 跨尺度知识蒸馏：9B 当老师，把能力压给 4B 和 2B。这就是为什么 2B 能打赢 8B——**它不是被"缩"小的，是被"教"小的。**这条路线我觉得比继续堆参数有意义得多。

• 统一 Pair-based 数据格式：弱监督对、描述对、检索对、分类对、分级相关性对，全部被翻译成"源—目标匹配"这一个问题，多任务联合训练。数据工程上很笨，但很有效。

• 开箱能服务化：官方实测 vLLM 0.27.0 和 SGLang 0.5.9 可以直接起 embedding 服务，还贴心地给了 scripts/serve_vllm.sh、scripts/serve_sglang.sh 一键脚本。不是那种"论文很漂亮，跑起来全靠自己悟"的项目。

• 评测代码也开源了：mmeb_v3_eval/ 里是完整的 MMEB-v3 评测流水线（基于 VLM2Vec 官方实现改的，支持多机多卡、64 帧视频采样）。敢把评测脚本一起放出来，说明这个分数是真敢让人复现的。

谁在用、能干什么

这部分不用编——它是从微信自己的生产环境里长出来的，不是先在排行榜上刷分再找落地场景。

最硬的案例就是微信自己：WeMM-Embedding 已大规模部署在微信的推荐与搜索系统，覆盖视频号、直播、公众号、电商内容和朋友圈，每日调用量 10 亿量级。生成的多模态向量被用于候选检索、排序特征构建、用户序列建模和跨域内容理解。

补两个内部数据：在 26 项内部任务基准上，WeMM-Embedding-2B 相比同规模基线从 60.9 提升到 72.0，分类、搜索、跨域匹配、文章相关、视频相关五类任务全部提升；团队做了 14 次在线 A/B 测试，持续拿到正向收益。

我一直觉得"线上日调用十亿次"这句话的含金量被严重低估了。 榜单第一可以调参调出来，十亿次日调用调不出来——那意味着它在真实脏数据、真实长尾 query、真实流量高峰下没崩。

公开榜单成绩（MMEB-v2，78 个数据集，图像/视频用 Hit@1，视觉文档用 NDCG@5）：

模型	尺寸	平均分	图像	视频	视觉文档
VLM2Vec	2B	47.8	59.7	29.0	44.0
GME	2B	55.4	51.9	33.9	76.8
VLM2Vec-V2	2B	59.3	64.9	34.9	69.2
Qwen3-VL-Embedding	2B	73.2	75.0	61.9	79.2
WeMM-Embedding	2B	77.9	79.6	70.8	80.7
WeMM-Embedding	4B	79.2	80.8	72.1	82.0
Qwen3-VL-Embedding	8B	77.8	80.1	67.1	82.4
VLM2Vec	8B	53.2	65.5	34.0	49.1
GME	8B	59.2	56.0	38.6	79.3
WeMM-Embedding	9B	80.6	81.9	74.3	83.3

（表中 DME-Small / DME-Medium 为闭源榜单提交，未公开权重或推理端点，此处略去。）

MMEB-v3（190 个任务，覆盖 78 个 v2 任务 + 53 个文本任务 + 47 个 Agent 任务 + 11 个音频 + MCMR）：WeMM-Embedding-9B 拿到 59.5 的 V3-All 总分，文本 48.8、Agent 51.0、MCMR 49.3；2B 也有 56.0。对比一下同量级的 Qwen3-VL-Embedding 8B（53.5）、Tianmu-Emb-Uni 8B（53.3）、E5-Omni 7B（47.1）。注意 Audio 一栏全是 0——再次提醒，它不支持音频。

能干的事，往具体了说：

• 多模态 RAG：把 PDF、截图、表格、产品图、教学视频全编码进同一个向量库，用户用自然语言问，直接召回跨模态片段。以前做这件事要维护两套索引 + 一套融合排序，现在一层就够。
• 以图搜视频 / 以视频搜视频：视频号那种量级的场景已经验证过了。做内容平台、媒资管理、电商素材库的，这是现成答案。
• 视觉文档检索：合同、发票、论文、扫描件，用文字描述去搜。这个子项上 9B 拿 83.3，是三项里最高的。
• Agent 的长期记忆检索：MMEB-v3 里 Agent 任务 51.0 分（9B），意味着 Agent 存的"记忆"可以带截图、带录屏，照样能被语义召回。这块我挺看好的。
• 去重与聚类：短视频搬运、电商同款、图片盗用，向量一算就知道。
• 推荐召回与排序特征：微信的原生用途，不用多解释。

如果你正好在看向量数据库，本站的 Milvus 和 MTEB 榜单 可以对照着看——一个是存这些向量的地方，一个是衡量向量好坏的尺子。

初体验：把第一组向量跑出来

最短路径其实就三步，建议先用 2B 跑通，别一上来就拉 9B。

第一步，拉代码装依赖。 官方推荐 transformers==5.2.0，理由是不同版本预处理行为可能有差异、影响复现——这个版本别乱动。

git clone https://github.com/Tencent/WeMM-Embedding.git
cd WeMM-Embedding
pip install -r requirements.txt

requirements 里关键几项：

torch
transformers==5.2.0
qwen-vl-utils[decord]==0.0.14
sentence-transformers==5.7.0
accelerate>=1.1.0

qwen-vl-utils 负责图像和视频的预处理，decord 是视频解码后端。缺了它，视频这条路走不通。

第二步，先跑官方示例。 仓库 examples/ 下有现成脚本，传一张图一个视频就能出结果：

python examples/transformers_inference.py \
  --model /path/to/WeMM-Embedding-2B \
  --image /path/to/image.jpg \
  --video /path/to/video.mp4 \
  --dimension 2048

不加 --dimension 就输出完整维度。这个脚本会分别输出文本、图像、视频三个独立的向量——拿这三个向量两两算余弦相似度，就是"以文搜图""以图搜视频"的最小原型。

内部核心就这几行（节选自官方脚本）：

from transformers import AutoModel, AutoProcessor
from qwen_vl_utils import process_vision_info

prompt = processor.apply_chat_template(
    messages, tokenize=False, add_generation_prompt=False
)
images, videos, video_kwargs = process_vision_info(
    messages, image_patch_size=16,
    return_video_kwargs=True, return_video_metadata=True,
)

第三步，用 Sentence Transformers 或起服务。 想少写代码就用 Sentence Transformers，encode() 直接吃文本/图像/视频，而且可以直接传 Hugging Face 模型 id，不用先下载权重：

python examples/sentence_transformers_inference.py \
  --model tencent/WeMM-Embedding-2B \
  --image /path/to/image.jpg \
  --video /path/to/video.mp4 \
  --dimension 2048

要在生产环境起服务，vLLM 一行（记得带上模型自带的 embedding chat template，别漏了）：

MODEL_PATH=/path/to/WeMM-Embedding-2B
vllm serve "$MODEL_PATH" \
  --runner pooling \
  --chat-template "$MODEL_PATH/embedding_chat_template.jinja"

SGLang 稍微多一步（要打视频补丁）：

MODEL_PATH=/path/to/WeMM-Embedding-2B
python scripts/patch_sglang_video.py
python -m sglang.launch_server \
  --model-path "$MODEL_PATH" \
  --is-embedding \
  --enable-precise-embedding-interpolation

两个避坑提醒：一是视频很吃显存，64 帧采样是官方评测配置，自行调低帧数省资源；二是先定死维度再灌库——虽然有套娃兜底，但向量库和索引建完之后再改，工程上仍然是麻烦事。建议从 512 或 1024 起步，够用就好。

进阶

我想把话说得直白一点：多模态 Embedding 这件事，过去两年最尴尬的地方不是效果不好，而是每家都在自己造轮子，然后没人知道别人的轮子圆不圆。现在微信把已经在十亿级日调用上验证过的那套轮子，连评测脚本一起 Apache 2.0 扔了出来，这件事的意义比 80.6 分这个数字大得多。

我的个人判断：2B 这一档才是这次开源的真正主角。 77.9 分、256 维保留 98.7% 性能，意味着一张消费级显卡就能跑起一套能用的多模态检索系统。以前这是有 GPU 预算的团队才敢想的事。

也要泼点冷水：它不支持音频，做不了音视频一体的检索；MMEB-v3 里 190 个任务还有大量未覆盖的长尾；论文里那些收益是微信场景下的，你的数据分布和它差得越远，账就得重算。开源给你的是起点，不是结论。

一个务实的起步建议：拿你自己的一批真实 query 和文档，先做 500 条的小样本召回评估，看 Hit@5 到底多少。跑通了再谈上量——这比盯着榜单数字纠结选 2B 还是 9B 有用得多。

更多开源技术干货和学习资料，关注公众号「遇码」，领取专属福利。