LFM2.5-Encoders：能在 CPU 上跑长文档的小编码器，长上下文比 ModernBERT 快 3.7 倍

它解决的是哪一半问题

站内大部分推理信号讨论的是生成式模型怎么跑得起、跑得快。但生产系统里还有另一半负载：意图路由、安全过滤、策略检查、PII 识别、文本分类。这些任务不需要生成，需要的是理解一段输入并给出标签——它们整天在跑，通常跑在 CPU 上，而且输入长度在持续变长。

这一类任务的主力一直是编码器模型：BERT 定义了这个门类，ModernBERT 在准确率、速度和上下文长度上又推了一步。LFM2.5-Encoders 是在 LFM2 架构上继续往前的一步，主张是成本随输入变长而缓慢增长。

三个可直接对照的数字

• 参数量 230M / 350M：在 GLUE、SuperGLUE 与多语任务上追平或超过更大的编码器
• 上下文 8,192 token：延迟随输入变长的增长速度是它的卖点，不只是长度本身
• CPU 长上下文快约 3.7 倍：对照组是 ModernBERT-base

怎么造出来的

这一步值得单看：两个编码器不是从零训练的，而是从对应的 LFM2 解码器骨干初始化（LFM2.5-230M 与 LFM2.5-350M），再把因果解码器改造成双向编码器：

1. 双向注意力掩码——每个 token 同时看得到左右两侧，而不只是前面
2. 非因果短卷积——对称补齐，让每个 token 的卷积同时混入两侧邻居
3. 掩码语言建模——训练时遮蔽 30% 的 token

训练分两段：先在大规模网页语料上以 1,024 token 上下文做通用语言能力，再扩到 8,192 token 做长上下文适配，同时强化事实性、法律与多语能力。

什么时候该考虑它

它不与生成式模型竞争，而是替换掉「用大模型做分类」这个常见但昂贵的做法。判断线很直接：如果一项任务的输出是标签、路由决定或抽取结果，而不是一段自然语言，那么用编码器几乎总是更便宜；这次的增量是把「输入很长」这个原本会逼你上 GPU 的条件，重新拉回 CPU 可承受的范围。

同一家此前发布过面向多语检索的 LFM2.5-Retrievers；这次是通用编码器，掩码语言目标预训练，所以分类、token 级任务和检索都能在其上微调。