Hugging Face H Company 于 9 月 3 日发布 NeoMME:260M/800M 参数的多模态编码器,从零训练单一双向 Transformer,不用视觉塔与因果解码器,检索质量与 3.75B 模型持平,索引可压到 6KB/页保留 95% nDCG@10。
Hugging Face 的 H Company 团队(Aurélien Lac、Tony Wu 等)于 2026 年 9 月 3 日在官博发布了 NeoMME——一族 260M 与 800M 参数的多模态多语言编码器。它不套 SigLIP2/CLIP 这种预训练视觉塔,也不接因果解码器,而是从零训练一个双向 Transformer同时吃文本 token 与图像 patch。发出来当天中文圈几乎没有系统解读,本文按堆栈简化、性能、索引压缩三个维度把技术报告的关键数字与工程含义整理清楚,并给出一份从 ColPali 系统迁移过来的现实检查表。
ColPali 打开视觉文档检索这条路之后,主流做法一直是"视觉塔 + 投影 + 语言模型"三段式:拿一个预训练好的 SigLIP2 或类似的视觉编码器出图像 embedding,用一个投影层把它映射进语言模型的 token 空间,再让一个因果解码器处理拼起来的多模态序列。ColQwen2.5-v0.2 用 3.75B 参数走的就是这条路,ModernVBERT 用 250M 参数走的是砍掉投影层但保留 SigLIP2 视觉塔的折中版。

四种编码器架构对照:从左到右分别是 CLIP 式双塔、VLM 借用式(ColQwen2.5)、ModernVBERT 的混合式,以及 NeoMME 的原生单塔。图片来源:Hugging Face / Hcompany
问题在于,检索、分类、token 标注这些下游任务本来就不生成文本,为它们扛着一个因果解码器纯粹是浪费——参数、显存、吞吐都要为一个用不到的自回归模块付账。NeoMME 的思路激进得多:既然不需要生成,就干脆不要视觉塔和解码器,从零训练一个双向编码器把两种模态的算力路径合成一条。
技术报告里给出的架构细节值得一条条读:图像被切成 32×32 不重叠的 patch,经一个小 MLP 投影后与文本 token 一起进 Transformer;上下文长度 16,384,足够放下两张 3840×2160 的 4K 图;大部分层用对称的滑动窗口注意力,每第 6 层加一次全局注意力,最后一层也是全局注意力;tokenizer 是从零训练的 131k 词表 BPE,语料包含多语文本、代码、数学和"机器生成的图像文字描述",因此天然支持多语言。此外它还堆了几乎全套现代改良——GQA、QK-normalization、gated attention、2D RoPE、squared-ReLU MLP——这些改良在 ModernBERT 上已被验证过。
不用视觉塔就等于放弃了 CLIP 那套图文对比学习积累下来的表征,怎么补回来?NeoMME 用的是离散 masked-diffusion 文本降噪:对纯文本样本,从 0 到 1 之间均匀采样一个掩码率,再按这个比例随机遮住 token 让模型还原;对多模态样本则把掩码率区间抬到 0.3–1,图像 patch 完全可见,让模型只靠图像重建被遮住的文本。
关键在于这个区间的下沿。低掩码率时模型可以纯靠上下文补出被遮的词(比如把 "The [MASK] sat on the mat" 补成 "cat",根本用不上图),高掩码率则强制模型学会图像描述式的建模——只有把图看懂才能填出被抹掉的大段文字。整个预训练打包了约 5240 亿 token,其中 2900 亿来自纯文本样本,比 ModernBERT 的 2T 预算小很多,所以采用了对数据效率友好的 NorMuon 优化器。
这块中文圈之前几乎没人解释清楚过。国内做 RAG 落地的同学更多是"取一个开源 embedding 换上",很少去追它是怎么被训出来的。理解这个目标函数很重要:它决定了这个模型在你实际的、不是官方 benchmark 里的文档上会怎么表现。学术图表和研报页面因为图文严格互相印证,通常能吃到掩码扩散的红利;而设计手册、含大量装饰性图的营销文档,掩码扩散给的信号会稀薄一些。
顺带对比一下和 CLIP 那条主流线的差别。CLIP 用图文对比学习,本质上要求模型学到"这张图对应这段说明"这种全局配对关系;masked-diffusion 则是学"给定图,补出这段被遮的具体描述",粒度更细也更贴近文档检索的下游需求——毕竟检索本来就不需要判定"哪张图配哪段话",而是要判定"这一段查询与这一页内容够不够像"。这也解释了为什么 NeoMME 拿掉视觉塔之后,在页面级检索上不但不掉分,反而在 300M 以下段位直接把 SOTA 抬了一大截。
预训练完 backbone 后,作者用 ColPali 的 page-image 方法微调出 NeoMME-Retriever,把 PDF 的每一页当整张图索引,跳过 OCR,把版式、图表、字号这些视觉线索全保留在向量里。retriever 加了两个联合训练的头:dense 头对 backbone 隐藏态做均值池化出一个归一化向量,late-interaction 头把每个 text token 或 image patch 单独投影到 128 维的归一化向量——一次前传两种表示都能拿到,用户按存储预算与召回精度自己选。
在 ViDoRe v3 上的 nDCG@10(数值越高越好)如下:
| 模型 | 参数量 | ViDoRe v3 | 备注 |
|---|---|---|---|
| ColModernVBERT |
免费获取企业 AI 成熟度诊断报告,发现转型机会
| 250M |
| 0.261 |
| 混合式基线 |
| ColSmol-256M | 256M | 0.207 | — |
| NeoMME-260M | 260M | 0.523 | 300M 以下最佳 |
| ColSmol-500M | 500M | 0.340 | — |
| Vultron Flash | 0.8B | 0.565 | 同尺寸最佳 |
| NeoMME-800M | 800M | 0.556 | 与 Vultron 差 0.009 |
| ColQwen2.5-v0.2 | 3.75B | 0.524 | 与 NeoMME-260M 几乎持平 |
| ColPali v1.3 | 2.92B | 0.430 | — |

260M 参数的 NeoMME 在 ViDoRe v3 上打到 0.523,与 3.75B 参数的 ColQwen2.5-v0.2 仅差 0.001,参数量差 14 倍。图片来源:Hugging Face / Hcompany
值得诚实指出的一点:在 800M 段位 NeoMME 并不是第一名,Vultron Retriever Flash 0.8B 的 0.565 仍然高出 0.009。这个差距在生产环境是否可感因场景而异——但如果你冲着"最新最好"来的,NeoMME-800M 目前不是这个答案。它真正立得住的是 260M 段位那次 Pareto 突破。
吞吐是另一头故事:官方在 NVIDIA L40S(一张 24GB 显存的推理卡)上、2048×2048 的输入尺寸下,NeoMME-260M 达到约 51 页/秒,是 ColModernVBERT(26 页/秒)的近两倍。

同一张 L40S 卡上,NeoMME-260M 在 2048×2048 时 51 页/秒,1024×1024 时 220 页/秒;ColQwen2.5-v0.2 与 ColModernVBERT 都被拉开一个数量级。图片来源:Hugging Face / Hcompany
Late-interaction(多向量)范式的长期痛点是存储爆炸:每页产生数千个向量、每个向量 float32,一张 A4 页面在 2048×2048 采样下大约要占 1.5MB 索引空间。中文企业文档动辄以百万页计,直接落地就是几个 TB 的 ANN 索引磁盘账。
NeoMME 团队把这块打成了两条正交手段:分层 token 池化(对相似的文档向量聚类,取簇心均值)加非对称量化(文档向量量化到 int8 或 binary,查询向量保留高精度)。因为查询向量是即时生成的、不落盘,所以文档侧激进量化不影响查询精度。

图片来源:Hugging Face / Hcompany。我们从官方标注的 5 个点里挑出这三档(原图另标了未压缩基线 3.9×/390KB 与更激进的 pool 20× · 2.4KB/页 · 92.6%):pool 10× + int8/int8 = 39KB/页 · 保留 99.2%;pool 19× + int8/int8 = 20.5KB/页 · 保留 98.1%;pool 8× + int8/binary = 6KB/页 · 保留 95.2%。
把它换算成中文场景可能更直观。假设一家咨询公司要把 1000 万页历史交付物、投标书、行研报告都做成视觉 RAG 索引:
这就是"压缩 255 倍"这个抽象数字在生产上的实际含义:不是节省几个百分点的云盘费,而是让整个部署形态从"分布式向量集群"退回到"单机服务"。对中小团队来说这是一次量变到质变。
需要提醒的是,Pareto 前沿上的每个甜点都是官方在 ViDoRe v3 上跑出来的通用配置,落到你自己那批文档上不能直接照抄。工程做法是把 8×/binary 与 10×/int8 两档都索引一份很小的样本(几千页足够),拿离线评测集算 nDCG@10 后再选——这一步跳过去,等半年后发现召回质量掉了 3 个点已经找不回原因。这也是查询向量保留高精度带来的一个隐藏收益:查询侧永远没被量化过,所以离线评测能干净地归因到文档侧的哪档配置有问题。
原文没有明确说迁移成本,但从架构和 API 的差异反推,一份现实的检查表大概是这样:
你目前的堆栈:如果已经跑在 ColPali、ColModernVBERT 或 ColSmol 上,NeoMME-Retriever 的 API 与 ColPali 系一致(同样返回 late-interaction 向量),改动主要在模型 checkpoint 与预处理路径。dense 头是"顺便送的",可以先只用 late-interaction 保持行为一致,等观测到 P50/P95 指标稳定后再切压缩配置。
多语言场景:NeoMME 的 tokenizer 是从零训练的 131k BPE,中文、代码、数学都在训练语料里。但词表固定,无法为特定行业术语微调 tokenizer——如果你的文档里有大量 OOV 的化学名、法条编号、方言,效果需要实测。
算力前提:官方 benchmark 用的是 L40S(24GB 显存)。260M 在这张卡上做批量 2048×2048 推理是舒服的;如果只有 T4/L4 这类 16GB 卡,需要降输入分辨率到 1024 或 768,吞吐会成倍上升但小字与图表的可读性会掉。
微调路径:作者把 dense 与 late-interaction 版本各自导出了 Sentence Transformers checkpoint 供社区微调(NeoMME-260M-Retriever-ST-dense / -ST-late),因为 ST 目前每个模型只支持一个 retrieval head。想同时训两个头需要用 NeoMMEForRetrieval 加自定义 Trainer。
不适合的场景:如果你的召回目标是"页面里某个具体表格单元格"这种更细粒度的定位,multi-vector + 全局池化的这一套仍是"页级"检索;需要用 NeoMME 做初筛后再接一个 OCR + 结构化解析步骤。
许可:全部 checkpoint 都是 Apache 2.0,商用无障碍;技术报告见 arXiv 2609.01657。
最后一句偏个人判断的话:过去两年视觉文档检索一直被"视觉塔够不够大"、"要不要接 VLM"这种参数堆砌式的问题带偏了方向。NeoMME 的意义与其说是"新 SOTA",不如说是给出一个存在性证明——把整个堆栈砍到只剩一个双向 Transformer,检索质量与吞吐都能撑住。对做企业 RAG 的团队来说,这比多刷一次 leaderboard 有意思得多。
关注公众号

扫码关注,获取最新 AI 资讯
3 步完成企业诊断,获取专属转型建议
已有 200+ 企业完成诊断