H Company这周开源了NeoMME,一族260M和800M参数的多语言多模态编码器,用来给视觉文档检索做骨架。它最大的技术选择是把图像patch和文本token塞进同一个双向Transformer从零训练,不再像ColPali那批模型那样,先拿一个预训练视觉塔配一个因果语言解码器拼接起来。官方给出的两个headline数字很唬人:260M版本在L40S显卡上每秒能编码51.3页文档,是ColModernVBERT的两倍;经过压缩后,每页的检索索引存储从约1.5MB压到6kB,缩小255倍。
但把竞品全景摆出来看,故事没有官方博客写得那么整齐。260M版本确实是同量级里的尖子生,800M版本却在速度上被一个参数更少的对手反超。所谓"两个尺寸都站上帕累托前沿",其实是两种完全不同的产品定位。
一个Transformer吃两种输入
视觉文档检索这几年基本都在"嫁接"生成式视觉语言模型:预训练视觉编码器出特征,投影层对齐到语言模型输入空间,再交给因果解码器处理。问题是检索、分类这类任务根本不需要自回归生成能力,这套架构等于白白背了一份解码器的参数和算力。ModernBERT把双向编码器的效率做法带回主流,ModernVBERT在此基础上换了双向文本编码器,但视觉那头仍然挂着一个独立的SigLIP2视觉塔。
NeoMME走得更彻底:图像被切成32×32的patch,和文本token一起进同一个双向Transformer,没有另外预训练的视觉塔,也没有现成的文本编码器或解码器可以复用。训练目标也不走常见的对比学习,而是用掩码离散扩散——随机遮住文本token,让模型结合可见的图像patch去猜。遮盖比例越高,模型就越被逼着去读图,而不是靠语言常识蒙答案。微调阶段套用ColPali的做法,把文档页面直接当图片检索,同时输出稠密向量和更精细的后期交互向量。
260M赢麻了,800M却跑输更小的对手
在ViDoRe v3基准上,NeoMME-260M拿到0.523的nDCG@10,是所有参数量低于800M的模型里最高的,和参数量大它14倍的ColQwen2.5-v0.2(0.524)几乎打平。作为对照组的ColModernVBERT,参数量相近(250M),得分却只有0.261——差不多是NeoMME-260M的一半。
- 结论.官方吹的"两倍吞吐",对比对象本来就是一个检索质量差了一倍的模型,这不是纯速度上的胜利,是质量和速度一起赢。
问题出在800M版本。它的nDCG@10是0.556,同样落在帕累托前沿上,但编码速度只有每秒21.2页,反而比250M量级的ColModernVBERT(26.0页/秒)还慢。同一档位的Vultron Flash(约850M)用0.565的分数反超了NeoMME-800M,虽然它测速用的是1344×2048分辨率而非NeoMME的2048×2048,严格意义上不能直接对比。
| 模型 | 参数量 | ViDoRe v3 nDCG@10 | 判断 |
|---|---|---|---|
| NeoMME-260M | 260M | 0.523 | 同量级最强,兼具速度 |
| ColModernVBERT | 250M | 0.261 | 质量明显落后,速度反而不慢 |
| NeoMME-800M | 800M | 0.556 | 帕累托前沿,但编码慢于更小对手 |
| Vultron Flash | 850M | 0.565 | 同量级质量反超NeoMME-800M |
| ColQwen2.5-v0.2 | 3.75B | 0.524 | 14倍参数仅微弱领先 |
这说明"单塔架构更省算力"这个卖点,目前只在260M这个体量上兑现了。参数往上走到800M,速度优势反而消失,H Company自己也没有在博客里解释原因,只留下一个待验证的问题。
255倍压缩是真的,但别照搬到生产环境
存储压缩这块数字算是硬指标。NeoMME用两招组合拳:分层token池化把相似的图像patch向量合并成一个均值向量,减少存储的向量数;非对称量化把文档端的向量压到int8甚至二值,查询向量因为不落盘可以保留更高精度。池化因子8配合int8查询、二值文档,能把每页存储从约1.5MB压到6kB,缩小255倍,同时保住95%以上的基线检索质量。如果只用池化因子10加int8量化,压缩倍数降到39倍,但质量保留能到99%以上——这是一条可以按存储预算自己挑点位的曲线,不是单一答案。
需要提醒的是,51.3页/秒这个吞吐数字的测试条件很窄:用的是bfloat16、torch.compile、FlashAttention 2,单独调过batch size,不包含图像解码、存储写入、压缩和建索引这些环节。真实场景里把几百万页PDF摄入一个向量数据库,瓶颈往往在I/O和索引构建,不是模型前向计算本身。这个数字更适合理解成"模型端编码能力的上限",而不是端到端的摄入速度。
- 提醒.255倍压缩和6kB/页的成本估算目前只覆盖向量本身,真正上量后还要算上元数据和ANN索引的额外开销。
H Company为什么要自己造检索器
H Company的主业是Runner H这类AI Agent,视觉文档检索通常是Agent做视觉RAG(检索增强生成)时的底层能力——先从一堆截图或PDF页面里找出相关页,再交给生成模型作答。自研一个比ColPali系检索器更小更快的编码器,对一家Agent公司来说更像是把关键基础设施收回自己手里,而不是单纯发一篇论文。
NeoMME全部权重按Apache 2.0协议开源,已经进了Hugging Face Transformers库,门槛不高。对做视觉RAG的团队来说,260M版本值得马上试,它在同量级里目前找不到更强的对手;800M版本更适合先观察,除非后续有独立复测证明它的吞吐短板只是这次基准测试的偶然,否则在需要高吞吐的场景里,它未必比更小的ColModernVBERT划算。