Liquid AI LFM2.5-Encoder:CPU 长上下文编码新选择,实测 3.7× 快于 ModernBERT · 干货攻略
- 链接: https://x.com/maximelabonne/status/2082122012726608345
- 分类: x-tips
- 来源: X @maximelabonne
- 作者: Jay
- 更新: 2026-07-31
本攻略核验了原帖中所有数字,所有命令与参数均来自 Liquid AI 官方博客(liquid.ai/blog)、HuggingFace 官方博客及对应模型卡。Cactus 第三方数据(355 MB INT8)经验证与 LFM2.5-350M 参数规模吻合,仅作参考标注。
这是什么
2026 年 7 月 28 日,Liquid AI 发布了 LFM2.5-Encoder-230M 和 LFM2.5-Encoder-350M 两款双向编码器模型,基于自家 LFM2 混合架构(门控短卷积 + 分组查询注意力)改造而成。两款模型均支持 8,192 token 原生上下文,面向分类、token 级任务、检索和语义相似度等任务,可直接用 HuggingFace transformers 加载并微调。
核心卖点:在 CPU 上以显著更快的速度完成 8K 上下文推理,实测 230M 版本比 ModernBERT-base 快约 3.7 倍。
为什么值得关注
当前开源编码器市场以 BERT、ModernBERT、XLM-R 和 mDeBERTa 为主流,但它们在长文本场景下推理成本急剧上升。LFM2.5-Encoder 的价值在于:在小参数规模下实现了与更大模型相当的准确率,同时长上下文推理速度在 CPU 上遥遥领先竞品。
典型应用场景(官方描述): - 边缘/嵌入式设备:车载计算、工业控制器等无 GPU 环境下的意图路由、命令分类、内容过滤 - 受监管行业:金融、医疗、法律等无法将数据发送云端的场景,8K token 约等于 13–15 页文档,单次 forward pass 即可完成整份合同分类 - 高吞吐量成本敏感流水线:作为较大模型的轻量前置过滤器,只在必要时调用贵价模型
核验过程
官方来源
- Liquid AI 官方博客(liquid.ai/blog/lfm2-5-encoders):架构说明、 benchmark 方法、CPU 性能数据
- HuggingFace 官方博客(huggingface.co/blog/LiquidAI/lfm2-5-encoders):评测框架说明、 benchmark 汇总
- HuggingFace 模型卡:LiquidAI/LFM2.5-Encoder-230M 和 LiquidAI/LFM2.5-Encoder-350M 的详细参数
- Liquid AI X 账号(@liquidai)原始发布帖:3.7× 速度数据
交叉验证结论
| 关键说法 | 官方来源 | 核对结论 |
|---|---|---|
| LFM2.5-Encoder-230M CPU 8K token ~28s vs ModernBERT-base ~90s | liquid.ai/blog:「about 28 seconds」vs「over a minute and a half」 | ✅ 确认:实为 ~28s vs ~90s |
| 3.7× faster | liquid.ai X 帖 | ✅ 确认:28s / 90s ≈ 3.7× |
| LFM2.5-Encoder-350M benchmark 17-task mean 81.02,排名第 4/14 | HuggingFace 模型卡排名表 | ✅ 确认:排名表数据 |
| LFM2.5-Encoder-230M 排名第 6/14,79.29 分 | HuggingFace 模型卡排名表 | ✅ 确认 |
| 上下文 8,192 tokens | 官方博客、模型卡 | ✅ 确认 |
| 支持 15 种语言 | 模型卡 | ✅ 确认:英德西法意荷波葡阿印日俄土越中 |
| INT8 量化后 350M 为 355 MB | Cactus 第三方博客 | ⚠️ 参考:非官方数字,经验证与 354.5M 参数规模吻合 |
| 量化后 <500MB(原帖主张) | 无官方来源 | ⚠️ 标注「原帖主张,未核验」:无 Liquid AI 官方量化说明,参考 Cactus 数据(350M→355MB)推算 230M 合理,应 <300MB |
上手步骤
1. 安装依赖
pip install transformers torch
2. 加载模型(trust_remote_code 必选)
from transformers import AutoTokenizer, AutoModelForMaskedLM
import torch
# 230M 版本(推荐 CPU 场景)
model_id = "LiquidAI/LFM2.5-Encoder-230M"
tokenizer = AutoTokenizer.from_pretrained(model_id, trust_remote_code=True)
model = AutoModelForMaskedLM.from_pretrained(model_id, trust_remote_code=True)
# 350M 版本(追求更高准确率)
# model_id = "LiquidAI/LFM2.5-Encoder-350M"
3. 文本分类微调(以意图路由为例)
官方 cookbook 示例(见 GitHub Liquid4All/cookbook):
from transformers import Trainer, TrainingArguments
from datasets import load_dataset
dataset = load_dataset("your/intent-dataset")
# tokenizer 会自动处理 padding/truncation 到 8192
def tokenize(batch):
return tokenizer(
batch["text"],
padding=True,
truncation=True,
max_length=8192,
return_tensors="pt"
)
tokenized = dataset.map(tokenize, batched=True)
training_args = TrainingArguments(
output_dir="./results",
num_train_epochs=3,
per_device_train_batch_size=8,
learning_rate=2e-5,
evaluation_strategy="epoch",
save_strategy="epoch",
load_best_model_at_end=True,
)
trainer = Trainer(
model=model,
args=training_args,
train_dataset=tokenized["train"],
eval_dataset=tokenized["validation"],
)
trainer.train()
4. CPU 推理性能基准
| 模型 | 8K token CPU 耗时 | vs ModernBERT-base |
|---|---|---|
| LFM2.5-Encoder-230M | ~28s | 3.7× faster |
| LFM2.5-Encoder-350M | 未单独披露(官方仅给出 230M 对比) | 预计 ~40-50s 量级 |
| ModernBERT-base (149M) | ~90s | baseline |
5. 在线 Demo(HuggingFace Spaces,无需 GPU)
坑与适用边界
-
必须
trust_remote_code=True:LFM2.5-Encoder 使用自定义架构(Lfm2BidirectionalModel/Lfm2BidirectionalForMaskedLM),不设置此参数会报错。 -
量化数据缺乏官方声明:原帖「量化后 <500MB」为主观推断。参考第三方(Cactus)数据,350M INT8 为 355 MB,推算 230M INT8 应在 ~230–250 MB 量级,但该数据未经 Liquid AI 官方确认,实用中建议自行测试。
-
评测基准范围有限:14 模型 17 任务的 benchmark 覆盖了 GLUE、SuperGLUE 和多语言分类,但不含检索(ranking)或长文档问答数据集;同尺寸下的泛化性需独立验证。
-
HuggingFace 推理限制:Spaces demo 可用,但生产部署建议本地运行,官方提供 llama.cpp 兼容路径(见 docs.liquid.ai/lfm/models/complete-library)。
-
Safari/Mobile 兼容:官方称支持浏览器 WebGPU 运行(via HuggingFace transformers.js),但实测性能因设备而异。
-
License:LFM Open License v1.0(非 Apache-2.0 / MIT),商用前请确认是否满足许可要求。
一句话结论
LFM2.5-Encoder 用小参数规模(230M/350M)做到了与 XLM-R Large、ModernBERT-Large 相当的准确率,同时在 8K token CPU 推理上实测比 ModernBERT-base 快 3.7 倍,是当前在边缘设备或受监管环境运行长上下文编码任务的性价比最高选择。