一个模型处理文字、图片、视频和图文混排

三个版本的输入能力相同，主要差别在模型规模、完整向量维度和运行成本。

2B、4B、9B 分别输出 2048、2560、4096 维完整向量。

每个版本都能处理纯文本、图片、视频、视觉文档，以及文字和图片交错出现的内容。查询和候选内容也可以附带任务指令，因此同一张图片在“找外观相似商品”和“找能回答问题的页面”两个任务中，可以得到不同的向量表示。

这些向量适合承担搜索和推荐系统的第一轮召回：先从海量内容中找出最相关的一小批，再交给更复杂的排序模型处理。它也能用于分类、聚类和 Agent 记忆等需要比较内容相似度的场景。

把多种内容变成同一种数字坐标

文字、图片和视频的内部表示并不相同。WeMM-Embedding 使用同一个原生多模态骨干处理它们，并保留各个片段在输入中的原始顺序，因此能够直接理解“文字—图片—文字”这类图文混排内容。

多种输入最终汇聚到一个专用位置。

输出经过归一化后，可以直接计算余弦相似度。

模型会在输入序列中加入专用的 <embedding> token，读取这个位置最后一层的隐藏状态，再做 L2 归一化，得到最终向量。这个 token 相当于要求模型把此前的文字、画面、视频帧和任务指令压缩成一个坐标。

同一序列还可以放入多个 embedding token，分别表示不同片段或不同粒度。这样，长视频、视觉文档和图文混排内容不必先被粗暴拆成互不相关的模态块。

两阶段训练让“相似”变成“真正相关”

把不同内容放进同一个向量空间，只解决了“能比较”的问题。

两阶段训练继续解决“比得准”。

第一阶段使用数亿级多模态配对建立覆盖面，让文字、图片、视频、视觉文档和交错内容先进入同一个空间。训练采用对比学习，让正例靠近、负例远离；同一批次只放同一种任务，避免跨任务样本变成没有难度的廉价负例。

真实业务数据中，被当作负例的内容可能其实与查询有关。重复感知屏蔽会排除这类假负例，分级相关性则继续区分完全相关、部分相关、主题接近和无关，让相似度不只停留在 0 或 1。

第二阶段把重点从覆盖面转向难区分的边界。数据经过语义重采样、质量清理和难负例挖掘，再加入 reranker 的排序信号；9B 模型把样本之间的相似度分布蒸馏给 2B 和 4B，9B 自身则通过模型合并继续提升。最终得到的排序信号比粗略主题分类更细，更适合检索和推荐。

9B 两套 MMEB 总分最高，模型已经进入微信业务

这套训练最终落在公开评测、微信内部任务和线上业务三组结果上。

9B 追求最高质量，2B 和 4B 则把重点放在性能与部署成本的平衡。

在 MMEB-v2 中，2B、4B、9B 的总分分别为 77.9、79.2、80.6。表内 2B 级对比模型为 47.8 到 74.8，8B 到 9B 对比模型为 53.2 到 78.4；其中 Qwen3-VL-Embedding-8B 为 77.8，WeMM-Embedding-2B 的 77.9 略高于它。9B 的图片、视频和视觉文档分项分别为 81.9、74.3、83.3。

MMEB-v2 汇总 78 个数据集，其中图片和视频使用 Hit@1，视觉文档使用 NDCG@5。因此 80.6 是同表综合分数，不能直接理解成“80.6% 的查询成功”。

在覆盖 190 项任务的 MMEB-v3 中，三个版本的总分分别为 56.0、58.2、59.5。2B 的文本和 Agent 分项为 45.3、45.1；4B 的 58.2 高于表内多种 7B 到 8B 模型的 26.3 到 47.1；9B 的文本、Agent 和 MCMR 分项为 48.8、51.0、49.3。在同表结果中，9B 在 MMEB-v2 和 MMEB-v3 中都是总分最高的模型。

在微信内部 26 项离线任务中，2B 平均分为 72.0，对照 Qwen 模型为 60.9。线上还进行了 14 次 A/B 测试，结果均取得改善并完成全量上线，覆盖视频号、公众号、朋友圈和电商业务。

Matryoshka 让向量从 2048 维裁到 256 维

Matryoshka 的作用，是让同一个模型输出的长向量可以按预算截短。

256 维把裸向量存储和点积计算规模降到完整 2048 维的八分之一。

2B 模型默认输出 2048 维向量，也支持 64、128、256、512、1024、1536 等前缀维度。截取前若干维后重新做一次 L2 归一化，就能直接作为短向量使用，不需要为每一种维度重新训练模型。

在 MMEB-v2 的图片和视频子集上，256 维保留了完整维性能的 98.7%。如果使用 FP16，每一维占 2 字节：一条 2048 维向量占 4096 字节，256 维占 512 字节；十亿条向量的裸容量由 4.096 TB 降到 512 GB。

这里计算的只是裸向量，不包含 ANN 索引、ID、元数据、副本、量化和冷热分层。64、128 维的质量损失更明显，视觉文档对截断也更敏感。实际部署时可以先用 256 维做低成本召回，再对少量候选使用更长向量或 reranker。

2B、4B、9B 怎么选

三档模型的选择，需要在吞吐、显存、索引成本和检索质量之间取平衡。

优先从业务规模和质量目标出发，再决定模型大小与向量维度。

2B 更适合高并发、海量内容和成本敏感的召回系统；4B 适合希望提高质量、又不能承担 9B 成本的场景；9B 适合质量优先的检索，或作为教师模型和重排阶段使用。三档模型都可以通过 Matryoshka 进一步调整向量长度。

基础依赖可以通过 requirements.txt 安装。推理可以使用 Transformers 5.2.0 或 Sentence Transformers，后者提供查询与文档的统一编码接口，并能直接选择截断维度。服务化支持 vLLM 0.27.0 的 pooling 模式，以及 SGLang 0.5.9 的 embedding 模式；视频服务需要相应补丁。

MMEB-v3 的下载、编码和打分流程已经提供，视频评测默认采样 64 帧。腾讯代码和模型权重采用 Apache 2.0，底层 Qwen3.5、数据集和第三方组件仍需分别核对许可证。当前开放范围包括模型权重、推理、服务和评测，不包括完整训练数据、训练算力和完整训练流程。

实际选型可以先用 2B 和 256 维建立基线，再依次比较 512 维、完整维度、4B 和 9B。只有当业务数据上的召回质量、批量吞吐、索引成本和稳定性同时达到要求，模型才真正适合上线。