LFM2.5 编码器：CPU 上的长上下文高速推理

尺寸虽小，实力却很强：在 GLUE、SuperGLUE 和多语言任务上，可媲美甚至超越更大的 encoder。

支持 8,192-token 上下文，而且随着输入变长，延迟增长较为缓慢。

CPU 上速度很快：在长上下文场景中，速度约为 ModernBERT-base 的 3.7 倍。

借助这些模型，你可以构建低成本、全天候运行的意图路由器、策略检查器、PII 检测器和文本分类器。下方提供了在线演示。

为什么要构建通用 encoder

上个月，我们发布了专为多语言搜索打造的 LFM2.5-Retrievers。LFM2.5-Encoders 与它们同属一个模型家族，但用途更加广泛。它们使用 masked-language objective 进行预训练，因此既可以针对分类和 token 级任务进行 fine-tune，也可以用于搜索。搜索只是 encoder 所能实现的众多能力之一。正因如此，我们选择构建通用模型，而不是直接复用 retriever。

Encoder 为许多现代生产级 NLP 应用提供了核心能力，例如分类器、意图路由器和安全过滤器。这些任务通常需要全天候运行，大多部署在 CPU 上，同时还要处理越来越长的输入。BERT 奠定了这类模型的基础，而最近 ModernBERT 又进一步提升了准确率、速度和上下文长度。LFM2.5-Encoders 则基于 LFM2 架构更进一步：随着输入长度增加，其计算成本增长得更为缓慢。

Encoder 是如何构建的

我们分别使用对应的 LFM2 decoder backbone 初始化 encoder：LFM2.5-230M 和 LFM2.5-350M。随后，通过以下几项改动，将每个 causal decoder 转换为 bidirectional encoder：

• 双向 attention mask：现在，每个 token 都能看到左右两侧的 token，而不再只能看到它之前的 token。

• 非因果短卷积：我们采用对称 padding，让每个 token 的卷积能够融合其左右两侧的相邻 token。

• Masked language modeling：训练时，我们会 mask 30% 的 token。

两个模型均分为两个阶段训练：

• 通用语言能力：在大规模 Web 语料库上，以 1,024-token 上下文进行短上下文 masked-language objective 训练。

• 长上下文适配：在完整的混合数据集上，将上下文扩展到 8,192 token，并增强模型在事实、法律和多语言方面的能力。

我们针对每项任务对各个模型进行 full fine-tuning，并报告最终得分。整张表共包含 14 个模型，覆盖从 GLUE、SuperGLUE 和多语言分类基准中选取的 17 项任务。

我们报告的是五个 held-out seed 的平均值，因此每次运行得到的结果都较为稳定。完整框架和原始结果均已开源。

LFM2.5-Encoder-350M 在 14 个模型中排名第四。排在它前面的三个模型体量都更大，其中还包括一个参数量为 3.5B、规模接近其 10 倍的模型。LFM2.5-Encoder-230M 超过了 ModernBERT-base 和所有 EuroBERT 模型，同时它的体量还小于其中大多数模型。在这些任务上，两款模型的得分也都显著高于我们自己的 LFM2.5-Retrievers。

CPU 和 GPU 上的推理速度

我们的 encoder 继承了 LFM2 backbone 的高速推理能力。由于我们的两款 encoder 和 ModernBERT 都支持 8,192-token 上下文，因此我们在完整的上下文长度范围内进行了速度测试。

我们的 encoder 在 CPU 上优势最为明显。在所有序列长度下，LFM2.5-Encoder-230M 都是速度最快的模型，即使面对短输入，它也比体量更小的 ModernBERT-base 更快。随着输入长度增加，ModernBERT 的吞吐量会急剧下降；而 LFM2.5-Encoders 的吞吐量会先上升到中等区间，随后才逐渐回落。在 8,192 token 下，ModernBERT-base 完成一次 forward pass 需要超过一分半钟，而 LFM2.5-Encoder-230M 只需约 28 秒，速度约快 3.7 倍。对开发者来说，这意味着只需使用笔记本电脑的 CPU，就能在 30 秒内扫描或分类一整份合同、一篇文字记录，或者一条很长的客服对话线程。

GPU 上也呈现出类似趋势，只是差距相对较小：在 Apple GPU 上，当输入少于约 1K token 时，ModernBERT-base 速度领先；从约 2K token 开始，我们的 encoder 会反超。这说明，对于长输入，LFM2.5-Encoders 是速度更快的选择；如果使用 CPU 运行，其优势更是非常显著。

我们使用 fine-tune 后的 LFM2.5-Encoders 构建了下方这些演示。每个演示都运行在仅使用 CPU 的 Hugging Face Space 中：

• Zero-shot prompt 路由：以自由文本定义你自己的路由通道。模型只需一次处理，就能计算完整 prompt 与所有通道之间的匹配得分。

• Zero-shot 策略检查：根据以自由文本编写的公司规则检查文本。模型只需一次处理，就能计算每个 token 与每条规则之间的匹配得分。

• 拼写检查：逐个 token 纠正拼写错误。

• PII 检测：识别并移除 16 种语言中的 40 类个人信息。

• Masked-diffusion 文本生成（额外功能）：将 encoder 作为聊天机器人运行，通过迭代 unmask 的方式生成文本，而不是从左到右生成。

如何使用和 fine-tune LFM2.5-Encoders

如果你需要处理高吞吐量的文本理解任务，例如分类、路由、抽取或评分，而且任务需要持续运行并保持低成本和高速度，那么可以选择 LFM2.5-Encoder。对于这类任务，fine-tune 后的 encoder 比生成式 LLM 更小、更快，运行成本也低得多，并且能够直接部署在你已有的 CPU 上。

在两种 encoder 规格之间：

• LFM2.5-Encoder-350M：在准确率最重要时选择它。

• LFM2.5-Encoder-230M：在硬件资源更紧张或需要更高吞吐量时选择它。

只需几行代码即可开始使用。通过 transformers 加载模型，然后直接运行 masked-token prediction，或者挂载你自己的 head，并针对具体任务进行 fine-tune。

加载并运行模型

安装最新版本的 transformers：

pip install -U transformers

运行 masked-token prediction：

from transformers import AutoModelForMaskedLM, AutoTokenizer
import torch

model_id = "LiquidAI/LFM2.5-Encoder-230M"  # or "LiquidAI/LFM2.5-Encoder-350M"
tok = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
mlm = AutoModelForMaskedLM.from_pretrained(model_id, trust_remote_code=True)

text = f"The capital of France is {tok.mask_token}."
enc = tok(text, return_tensors="pt")
with torch.no_grad():
    logits = mlm(**enc).logits
pos = (enc["input_ids"][0] == tok.mask_token_id).nonzero()[0].item()
print([tok.decode([t]).strip() for t in logits[0, pos].topk(5).indices.tolist()])
# -> ['Paris', 'Strasbourg', 'Paris', 'Lyon', 'Versailles']

对于 downstream task，可以加载 encoder body 并挂载你自己的 head，例如 classification、token classification、regression 或 retrieval：

from transformers import AutoModel

body = AutoModel.from_pretrained(model_id, trust_remote_code=True)

如果你的 GPU 支持，请使用 Flash Attention 2，以获得最高效率：

pip install flash-attn

针对你的任务进行 fine-tuning

Base encoder 提供的是通用表征，而不是特定任务的输出。因此，你需要针对每项任务分别进行 fine-tune。我们的 fine-tuning 教程介绍了如何使用 8k 上下文，对长篇法律文档进行 fine-tuning。

开始使用 LFM2.5-Encoders

两款 encoder 均为 open-weight 模型，目前已经可以在 Hugging Face 上使用：

• 下载：在 Hugging Face 上获取 LFM2.5-Encoder-230M 和 LFM2.5-Encoder-350M。

• 试用：直接在浏览器中运行上方演示，无需进行任何配置。

• Fine-tune：通过我们的 fine-tuning 教程，让 encoder 适配你的任务。

我们已经迫不及待想看到你会用它们构建出什么了。

如果你使用了这项工作，请引用发布博客：

@article{liquidAI2026Encoders,
  author = {Liquid AI},
  title = {LFM2.5-Encoders: Fast at Long Context, Even on CPU},
  journal = {Liquid AI Blog},
  year = {2026},
  note = {www.liquid.ai/blog/lfm2-5-encoders},
}

本文提及的模型：5 个

本文提及的 Space：5 个

本文提及的论文：2 篇

本文提及的 Collection：1 个

CPU 图表没有说明使用的具体 CPU。8k 上下文下的 28 秒，是在 Apple silicon 上运行单条序列得到的，还是在多核 x86 处理器上测得的？这对你们描述的使用场景很重要，因为在实际业务中，“扫描合同”往往意味着要扫描四万份合同。

另一个问题是 trust_remote_code=True。目前还没有 ORT 或 OpenVINO 路径，因此按照这篇文章操作的人，在 CPU 上使用的都是 PyTorch eager。我敢说，这 28 秒里相当一部分开销来自 eager mode，而不是模型架构本身。你们是否计划提供 int8 或 ONNX 导出？那些需要全天候提供这类模型服务的人，真正需要的正是这些能力。

我们在 Tenki 使用由 Firecracker microVM 承载的裸金属 EPYC。我可以分别在 16、64 和 128 vCPU 下运行 encoder_eval 以及你们的延迟测试，并发布测试结果。无论结果如何，都值得弄清楚你们所说的“你已经拥有的硬件”，究竟是指笔记本电脑，还是服务器。

另外补充一点：策略检查演示是我愿意付费使用的功能。目前还没有一个合适的位置，可以在与 Agent 相同的 sandbox 内部放置一个运行在 CPU 上的 guardrail，因此它要么必须调用外部 API，要么就根本不会被执行。

· 注册或登录后发表评论

本文提及的模型：5 个

本文提及的 Space：5 个

本文提及的论文：2 篇

本文提及的 Collection：1 个