一句话看懂：Hcompany 发布了一款名为 NeoMME 的多模态原生多语言编码器，用单一双向 Transformer 同时处理图像和文本，不依赖任何预训练视觉塔或因果语言模型。相比同等规模的传统方案，它在文档检索任务上吞吐量更高、索引存储大幅压缩，且模型权重已开源。
事件核心：发生了什么
Hcompany 于 2026 年 9 月 3 日在 Hugging Face Blog 正式发布 NeoMME，提供 260M 和 800M 两个参数规模。与当前主流的视觉语言模型（VLM）不同，NeoMME 没有采用“预训练视觉编码器 + 投影层 + 因果解码器”的三段式架构，而是将图像切分为 32×32 的非重叠 patch，经小型 MLP 投影后与文本 token 一同送入同一个双向 Transformer。模型使用掩码离散扩散目标从头训练，文本侧支持 131k 词表的多语言 tokenizer，上下文长度达 16,384 token，足以处理最多两张 4K 图像。
针对视觉文档检索，团队基于 ColPali 的页面图像思路微调出 NeoMME-Retriever，单次前向即可同时输出稠密向量和后期交互（late-interaction）向量。在 ViDoRe v3 基准上，两个尺寸的模型均位于 nDCG@10 与模型大小的帕累托前沿。在 NVIDIA L40S 上以 2048×2048 输入测试时，260M 模型每秒可编码约 51 页文档，吞吐量约为 ModernVBERT 的两倍。通过分层 token 池化与非对称量化，后期交互索引的存储量从每页约 1.5 MB 压缩到 6 kB，体积缩小约 255 倍，同时保留超过 95% 的原始 nDCG@10 性能。模型权重以 Apache 2.0 协议在 Hugging Face Transformers 中完整开源。
为什么重要
NeoMME 的价值在于它验证了一条不同于生成式 VLM 的技术路线。文档检索、分类、token 标注等任务并不依赖自回归文本生成，传统 VLM 中因果解码器和独立视觉塔所带来的参数与算力开销属于结构性冗余。NeoMME 将图像和文本置于同一计算路径，既能简化预训练和并行化的复杂度，也有助于降低推理阶段的算力需求，这在长文档批量处理场景中意义直接。
从行业竞争看，ModernBERT 此前已展示了双向编码器在纯文本领域的高效性，ModernVBERT 则保留独立视觉塔做图文检索。NeoMME 进一步把视觉塔也去掉，用共享 Transformer 覆盖两种模态，在延迟和吞吐数据上给出了可量化的对比结果。对于正在构建企业级文档检索、RAG 或多语言多模态基础设施的团队来说，这意味着在召回质量与部署成本之间可能多出一个此前不存在的选择。
对用户/开发者/创作者的影响
对开发者而言，NeoMME 已可直接通过 Hugging Face Transformers 调用，260M 版本的低延迟特性适合 CPU 或低功耗 GPU 环境下的近实时文档解析；800M 版本则可服务于对精度要求更高的检索任务。Apache 2.0 许可意味着商用集成门槛较低，无需担心权重授权问题。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
对企业在做视觉 RAG 或文档知识库选型时，NeoMME-Retriever 的索引压缩能力值得关注——存储占用缩减两个数量级后，海量页面级的后期交互检索在内存和磁盘成本上会明显更友好，团队公开的 95% 性能保持率提供了量化参考。对创作者或普通用户来说，NeoMME 本身是一个编码器而非生成模型，短期内不会有直接可玩的聊天或绘图界面，但其背后的文档理解效率如果进入下游产品，会间接改善多语言 PDF 搜索、扫描件问答等体验。
值得关注的后续
第一，NeoMME 的 800M 模型在更大规模文档集上的检索上限尚无第三方独立评测，后续是否有研究团队复现其 Pareto 表现值得跟踪。第二，当前技术报告以视觉文档检索为主要测试场景，模型在通用图像理解或视频帧级任务上的泛化能力目前公开信息有限。第三，Hcompany 已提供 Visual RAG demo，下一步是否会围绕 NeoMME 推出商业 API 或企业服务，将影响它在开发者和企业采购中的实际扩散速度。
