LFM2.5-Encoders for Fast Long-Context Inference on CPU

适用于CPU的LFM2.5编码器：实现长上下文快速推理

返回文章列表

[0

团队

]

文章

2026年7月28日发布

[-1

点赞

35

[

• +29

费尔南多·费尔南德斯·内托

fernandofernandes

关注

LiquidAI

埃多阿尔多·莫斯卡

EdoardoMosca

马克西姆·拉邦

mlabonne

莱昂妮·莫尼加蒂

iamleonie

今天，我们在Hugging Face上发布了两个新的编码器模型：LFM2.5-Encoder-230M和LFM2.5-Encoder-350M。这些模型在保持与大型模型相当质量的同时，随着输入长度增加仍能保持稳定速度。这意味着你可以在现有硬件（包括CPU）上运行文档级规模的任务。

你将获得以下优势：

• 同级别最佳表现：在GLUE、SuperGLUE和多语言任务中表现优于或至少匹配更大编码器。

• 8,192 token上下文支持，输入长度增加时延迟增长缓慢。

• CPU加速：在长上下文任务中速度比ModernBERT-base快约3.7倍。

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

为何构建通用型编码器

上个月我们发布了面向多语言搜索的LFM2.5-Retrievers。LFM2.5-Encoders来自相同技术家族但适用范围更广。它们通过掩码语言目标进行预训练，因此可以微调用于分类、token级任务和搜索。搜索只是编码器能实现的功能之一，这也是我们选择构建通用模型而非复用检索器的原因。

编码器驱动着许多现代NLP生产应用：分类器、意图路由器、安全过滤器。这些任务通常全天候在CPU上运行，处理越来越长的输入。BERT确立了这类模型的基准，而ModernBERT最近进一步提升了准确率、速度和上下文长度。LFM2.5-Encoders在LFM2架构上更进一步，随着输入增长，成本增加缓慢。

编码器构建方式

我们从对应的LFM2解码器主干初始化编码器：LFM2.5-230M和LFM2.5-350M。随后通过以下调整将每个因果解码器转换为双向编码器：

• 双向注意力掩码：每个token现在可以同时看到前后token，而不仅是之前的token。

• 非因果短卷积：对称填充使每个token的卷积能混合两侧邻居信息。

• 掩码语言建模：训练时对30%的token进行掩码。

我们分两个阶段训练这两个模型：

• 通用语言能力：在1,024 token上下文的大型网络语料库上进行短上下文掩码语言目标训练。

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

基准测试结果

我们在每个任务上对每个模型进行完整微调并报告结果。表格中展示了从GLUE、SuperGLUE和多语言分类中选取的17个任务的14个模型表现。

我们报告了五个保留种子的平均值，因此数值在不同运行间保持稳定。完整框架和原始结果已开源。

LFM2.5-Encoder-350M在14个模型中排名第四。排在它前面的三个模型都更大，包括一个近为其10倍大小的35亿参数模型。LFM2.5-Encoder-230M在准确率上超越ModernBERT-base和所有EuroBERT模型，同时体积比其中大多数模型更小。两者在此测试中表现也明显优于我们自己的LFM2.5-Retrievers。

CPU和GPU上的推理速度

我们的编码器继承了LFM2主干的快速推理能力。由于我们的编码器和ModernBERT都支持8,192 token上下文，我们测量了整个范围内的速度表现。

我们的编码器在CPU上的表现最为突出。在此，LFM2.5-Encoder-230M在所有序列长度上都最快（即使是短输入也比更小的ModernBERT-base更快）。随着输入长度增加，ModernBERT的吞吐量会急剧下降，而我们的LFM2.5-编码器则先上升至中等水平后逐渐趋于平稳。在8,192个token时，ModernBERT-base每次前向传递需要超过一分钟半，而LFM2.5-Encoder-230M仅需约28秒。这大约快了3.7倍。对于开发者而言，这意味着你可以在笔记本电脑CPU上，用不到30秒的时间扫描或分类完整的合同、转录文本或长支持线程。

在GPU上，类似模式也存在但差距较小：在Apple GPU上，ModernBERT-base在约1K token以下表现更优。我们的编码器从约2K token开始超越。这表明对于长输入，LFM2.5-编码器是更快的选择，如果使用CPU，这种优势会更加显著。

LFM2.5-Encoder 示例

我们使用微调后的LFM2.5-编码器构建了以下示例。每个示例都在仅使用CPU的Hugging Face空间中运行：

• 零样本提示路由：以自由文本形式定义自己的路由通道。模型通过一次遍历对整个提示与每个通道进行评分。

• 零样本策略检查：将文本与以自由文本形式编写的公司规则进行比对。它通过一次遍历对每个token与每条规则进行评分。

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

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

• 掩码扩散文本生成（额外功能）：将编码器作为聊天机器人使用，通过迭代去掩码而非从左到右生成文本。

如何使用和微调LFM2.5-编码器

当有大量需要理解的任务（如分类、路由、提取或评分）且需要持续运行并保持低成本和高速度时，请选择LFM2.5-编码器。对于这类任务，微调后的编码器比生成式大语言模型更小、更快且运行成本更低，而且可以运行在你已有的CPU上。

在两个编码器尺寸之间：

• LFM2.5-Encoder-350M：当准确性最为关键时选择它。

• LFM2.5-Encoder-230M：当需要更严格的硬件限制或更高吞吐量时选择它。

你只需几行代码即可开始。使用transformers加载模型。然后直接运行掩码标记预测，或附加自己的头部并微调以适应你的任务。

加载并运行模型

安装最新版transformers：

pip install -U transformers

运行掩码标记预测：

from
transformers
import
AutoModelForMaskedLM, AutoTokenizer
import
torch

model_id =
"LiquidAI/LFM2.5-Encoder-230M"
# 或 "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']

对于下游任务，加载编码器主体并附加自己的头部（分类、token分类、回归、检索）：

from
transformers
import
AutoModel

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

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

pip install flash-attn

为您的任务进行微调

基础编码器为您提供通用的表示形式，而非任务输出。因此您需要针对每个任务对其进行微调。我们的微调教程将指导您如何在8k上下文的长法律文档上进行微调。

开始使用LFM2.5-Encoders

这两个编码器均为开放权重，目前已在Hugging Face上发布：

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

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

• 微调：使用我们的微调教程将编码器适配到您的任务。

我们迫不及待想看到您能构建出什么。

引用

如果您使用本工作，请引用发布博客：

@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

本文提及的空间 5

本文提及的论文 2

本文提及的集合 1

社区

hashbender

约4小时前

[2

CPU性能图表中没有说明具体使用的是哪种CPU。那个在8k上下文时耗时28秒的测试，是使用苹果硅芯片的单序列处理，还是多核x86处理器？这对您描述的使用场景非常重要，因为实际中"扫描合同"通常意味着要扫描四万个合同。

另一个问题是trust_remote_code=True参数。目前还没有ORT或OpenVINO的实现路径，因此按照本文操作的用户都只能在CPU上使用PyTorch的eager模式。我敢打赌这28秒中相当一部分时间消耗在eager模式而非架构本身。是否有计划支持int8量化或ONNX导出？这些是需要全天候运行这些模型的用户真正需要的。

我们在Tenki使用裸金属EPYC服务器配合Firecracker微虚拟机。我可以使用16、64和128个vCPU运行encoder_eval和您的延迟测试，并发布结果。无论"您已有的硬件"是指笔记本还是服务器，这些数据都值得了解。

补充说明：政策合规检查演示是我最愿意付费购买的功能。目前还没有好的方案可以在与智能体处于相同沙箱环境的CPU上运行防护机制，因此要么调用外部API，要么就无法执行。

查看翻译

回复

编辑

预览

通过拖拽、粘贴或点击此处上传图片、音频和视频

点击此处上传图片

评论

· 注册或登录以发表评论

• +23

/think