Hugging Face 新增 LFM2.5 Encoders，在长上下文 CPU 推理上挑战 ModernBERT

Hugging Face 新增了两款 Liquid AI encoder 模型，可处理 8,192-token 输入，并在长上下文 CPU 速度上挑战 ModernBERT。这一发布让一个具体主张受到检验：文档级语言处理并不总是需要 GPU 或生成式模型。

Liquid AI 表示，其 2.3 亿参数 encoder 在测试 CPU 上完成一次 8,192-token 前向推理约需 28 秒。该公司对比中，ModernBERT-base 则需要超过 90 秒。这个报告中的差距使 LFM2.5 与 ModernBERT 的竞争不只是基准准确率之争，也关乎部署经济性。

这一结果之所以重要，是因为 encoders 在幕后承担着分类、路由、提取、审核和个人信息检测等持续性工作负载。这些系统通常需要检查每一份传入文档或消息。因此，即使单项任务看起来并不复杂，较慢的模型也可能消耗大量基础设施资源。

Liquid AI 已发布模型权重、评估工具、模型卡和仅 CPU 演示。不过， headline 性能仍是厂商自行运行的结果。包括处理器配置和优化运行时支持在内的重要部署细节，仍需要更广泛的独立测试。

Hugging Face 新增两款开放权重 LFM2.5 Encoders

此次发布将 Liquid AI 的 decoder 架构改造为两款面向任务的 encoder，专为长文档和常规计算硬件打造。

Liquid AI 于 2026 年 7 月 28 日在 Hugging Face 发布 LFM2.5-Encoder-230M 和 LFM2.5-Encoder-350M。两者均支持最长 8,192 tokens 的上下文，并采用该公司的 LFM2 混合架构。

encoder 读取输入后，为分类、检索、提取或 token 级决策生成上下文表征。与 causal language model 不同，它的主要任务不是从左到右生成下一个 token。

这种差异同时影响成本与行为。工单路由器需要选择去向，而不是撰写回复。隐私过滤器需要定位敏感片段，而不是生成流畅段落。

Liquid AI 将现有的 230M 和 350M decoder 骨干模型调整为适用于这些更聚焦任务的模型。它将 causal attention mask 替换为双向 attention，使每个 token 都能考虑两侧文本。该公司还通过对称 padding，将架构中的短卷积改为非因果形式。

训练采用 masked language modeling，即隐藏部分选定 token，再由模型根据周围上下文进行预测。Liquid AI 表示，训练中遮蔽了 30% 的 token。

该公司采用两阶段训练计划。初始训练在大型网页语料库上覆盖 1,024-token 序列。第二阶段使用旨在增强事实、法律和多语言能力的数据，将上下文扩展至 8,192 tokens。

230M model card 列出约 2.297 亿个参数。350M 版本约含 3.545 亿个参数。两者的 hidden size 均为 1,024，词表包含 65,536 个条目。

根据 model card，它们支持 15 种语言，包括英语、西班牙语、法语、阿拉伯语、印地语、日语、越南语和中文。

Liquid AI 将较小模型定位于延迟和内存限制更严格的场景，并将较大版本作为偏重准确率的选择。两者都需要针对具体任务进行 fine-tuning，才能成为可用于生产环境的分类器、路由器或提取系统。

对于任何将 LFM2.5 encoder 解释为现成应用的说法，这一点都很重要。基础模型提供语言表征，但组织仍需添加输出 head，并针对目标任务进行训练。

这些模型采用 Liquid AI 的 LFM Open License v1.0。称其为开放权重，意味着开发者可以下载并运行训练后的参数；这并不意味着该发布采用标准的宽松软件许可证。

Hugging Face 提供分发渠道、model cards、社区讨论和演示。Liquid AI 则提供架构、权重、评估和实现。这种安排让实验更容易开展，同时将核心性能主张的责任保留在模型开发者身上。

因此，眼前的变化很具体：开发者现在拥有两款可下载的长上下文 encoder，设计重点是 CPU 部署，而非 GPU 优先的生成。

为什么长上下文 CPU 推理才是真正的价值所在

核心机会不是更小的 chatbot，而是能够检查完整工作文档、成本更低的决策层。

生产级语言系统会执行许多完全不需要生成文本的任务。它们标记请求、检测违反政策的内容、分类情绪、识别实体、对段落排序，并决定哪个更大的模型接收 prompt。

这些操作的运行频率可能远高于用户可见的 chatbot 回复。一个 agent 平台可能会在生成前，根据多项安全规则评估 prompt；也可能在交付结果前再次对其分类。

通过大型生成式模型运行每个阶段，会增加延迟和硬件需求。对于需要可预测标签或 token spans 的任务，这也可能引入不稳定的输出。

fine-tuned encoder 提供了另一条路径。它在一次前向推理中读取相关文本，并返回任务特定的评分。模型可保留在本地进程内，而无需将每份文档发送至外部服务。

上下文长度决定了这一过程是否能看到完整源文本。较早的 encoders 往往围绕更短的序列设计，迫使开发者将合同、转录稿或支持线程拆分为多个 chunks。分块可能让决策与改变其含义的证据分离。

8,192-token 窗口并不能覆盖所有长文档，但它能覆盖远多于经典 512-token BERT 部署的文本。这种差异可以减少分块以及外围聚合逻辑。

Liquid AI 通过仅 CPU 的 Hugging Face Spaces 展示了这一方法。其演示涵盖 prompt routing、policy linting、拼写检查和 personally identifiable information 检测。

据称，PII 演示可检测 16 种语言中的 40 类信息。Policy linting 会根据以自由文本提供的规则对 token 进行评分。Prompt routing 则将完整 prompt 与用户定义的路由类别进行比较。

这些演示明确了 Liquid AI 希望赢得的工作负载：高吞吐量的理解任务，具有有限输出和持续性基础设施成本。

本地 policy filter 对 agent 系统尤其相关。过滤器可在与应用相同的环境中运行，从而减少将内部文本暴露给另一个远程 endpoint 的需要。

同样的逻辑也适用于本地技术文档。构建可搜索知识库的团队，需要在任何生成式回答出现之前完成分类、提取和检索阶段。

CPU 部署扩展了这些阶段可运行的位置。开发者笔记本、应用服务器或 edge device 都可以执行模型，而无需预留独立 accelerator。

不过，“可在 CPU 上运行”并不自动意味着在任何规模下都即时或低成本。一次 28 秒的推理对单份合同可能可行，对交互式界面却可能不合适。批处理吞吐量也不同于单文档延迟。

更有力的主张是操作灵活性。团队可以将专用语言处理部署在数据所在之处，再将 GPU 或远程模型留给真正需要生成能力的任务。

这种分工给那些为每项语言操作销售通用推理能力的厂商带来压力，也促使团队在默认使用 large language models 之前，先衡量更小的 encoder 是否能够满足需求。

LFM2.5 与 ModernBERT 的差异归根结底在于架构

Liquid AI 报告的速度优势会随输入长度增加而扩大，因为其混合骨干架构并非在每一层都应用完整 attention。

ModernBERT 是最明确的对手，因为它同样面向高效双向编码和 8,192-token 上下文。它于 2024 年末发布，针对更长输入、现代硬件和改进训练更新了 BERT 设计。

最初的 BERT research 确立了双向预训练作为语言理解基础的方法。随后，ModernBERT 将这一方法与面向当前部署需求的架构和训练更新结合起来。

Liquid AI 则采取另一条路线。LFM2 将 grouped-query attention 与 gated short-convolution blocks 交错组合。Attention 用于跨序列连接信息，而短卷积则以更低的计算开销聚焦相邻 token。

随着输入变长，这种混合结构的重要性愈发突出。完整 self-attention 会比较序列中的各个位置，因此其计算负担会随长度快速上升。卷积层则将更多工作限制在局部邻域内。

Liquid AI 并没有移除 attention，而是减少了架构为其完整成本买单的频率。模型仍能在遥远位置之间交换信息，同时通过成本更低的局部操作处理许多层。

为适应 encoder 用途，Liquid AI 让这些局部操作具备双向性。对称 padding 使卷积能够融合当前 token 前后的相邻内容。完整 attention 层同样获得双向 mask。

这一机制构成了 LFM2.5 与 ModernBERT 对比的核心论点。Liquid AI 押注于混合序列处理能够保持有竞争力的理解能力，同时减缓长输入延迟的增长。

根据发布结果，LFM2.5-Encoder-230M 在所有 CPU 序列长度下都是测试中最快的模型。其优势在 8,192-token 上限时最为明显。

Liquid AI 报告称，较小的 LFM2.5 模型在该长度下约需 28 秒，而 ModernBERT-base 超过 90 秒，形成所述的 3.7 倍优势。

该公司在 Apple GPU 上观察到更为有限的模式。据称，ModernBERT-base 在约 1,000 tokens 以下领先；Liquid AI 的 encoders 则从约 2,000 tokens 开始领先。

这一交叉点说明了取舍。针对长输入优化的架构选择，并不保证在短输入上同样领先。许多生产环境中的分类请求仍远低于 2,000 tokens。

参数量也令简单的速度比较变得复杂。ModernBERT-base 约含 1.49 亿个参数，而 Liquid AI 较小的 encoder 约含 2.3 亿个参数。LFM2.5 模型更大，但据称在长 CPU 序列上更快。

因此，该 benchmark 测试的不只是参数量。Kernel 行为、内存访问、序列长度、运行时配置和处理器特性都会影响测得的延迟。

通过这一机制来理解 LFM2.5 encoder，它并不是 attention-based models 的通用替代方案。它提出的是，混合序列操作更适合长上下文 CPU 工作负载。

开发者应针对实际输入分布进行 benchmark。一个以短消息为主的系统，可能会偏好与处理法律协议或长篇转录稿的系统不同的架构选择。

他们还应在微调后测量完整流水线耗时。分词、批处理、输出头、后处理和数据传输都可能改变仅在模型前向传播中可见的优势。

基准测试质量具有竞争力，但证据仍有限制

Liquid AI 提供了一套可信的可复现性材料，但其结果尚不足以确定在不同 CPU、运行时或专业任务中的生产性能。

该公司评估了来自 GLUE、SuperGLUE 和多语言分类套件的 17 项任务中的 14 个模型。每个模型均针对每项任务接受了完整的监督式微调。

Liquid AI 报告了五个留出随机种子的平均值。使用多个种子可降低某次异常有利的训练运行决定排名的风险。

其 350M 编码器以报告的 17 项任务平均分 81.02 排名第四。排在其前面的模型是 XLM-R XL、ModernBERT-large 和 XLM-R large。

XLM-R XL 以 83.06 领先，包含 35 亿个参数。ModernBERT-large 以 3.95 亿个参数获得 81.68 分。XLM-R large 则以 5.6 亿个参数达到 81.34 分。

LFM2.5-Encoder-230M 以 79.29 排名第六。ModernBERT-base 以 78.19 排名第七。这些平均分支持了 Liquid AI 的说法，即其编码器在相应规模下仍具竞争力。

但这些结果并未显示其在每项任务上都持续领先。ModernBERT-base 在若干单项基准上超过了 230M 的 LFM2.5 模型，而 Liquid AI 则在其他项目中领先。

汇总排名还混合了不同类型的评估。任务包括自然语言推理、释义检测、情感分析、语义相似度和多语言分类。

平均分有助于比较通用能力，但可能掩盖特定部署真正重要的指标。策略系统关注的是漏报率和校准，而不是它在无关情感任务中的排名。

Liquid AI 已发布其评估工具链，提高了复现的可能性。该仓库包含下游微调代码，以及与所报告比较相关的配置。

不过，开放代码并不等于独立验证。Liquid AI 选择了训练流程、比较设置、聚合方法和推理环境。

CPU 延迟声明带来了最大且尚未解答的问题。公开文章描述了序列长度和耗时，但没有明确说明所测试的 CPU 配置。

这一遗漏会影响解读。笔记本处理器、云服务器 CPU、内存通道、指令集、线程数和功耗限制都可能产生截然不同的表现。

当前加载说明还使用了 trust_remote_code=True，允许仓库提供的代码通过 Transformers 库执行。拥有严格软件控制的组织在部署前需要审查该代码。

模型卡未提供成熟的 ONNX 或 OpenVINO 部署路径。这些运行时通常对优化 CPU 推理、量化和跨平台服务的团队很重要。

量化性能是另一个悬而未决的问题。已发布的比较并未证明 LFM2.5 在转换至更低精度后会如何表现，也未证明相同的相对优势是否能够保留。

该版本也缺乏覆盖持续并发的生产证据。处理单个长序列衡量的是延迟，而始终在线的分类器还需要考察吞吐量、尾延迟、内存使用和负载下的稳定性。

准确性同样需要谨慎对待。基准微调并不能证明其在某个组织的合同、安全规则、客户用语或隐私类别上的表现。

评估 LFM2.5 与 ModernBERT 的团队应在相同硬件和优化设置下复现两个模型。还应测试真实工作负载中的短篇、中等长度和最坏情况下的文档。

评估应纳入失败成本。如果更快的 PII 检测器漏掉了当前系统能够捕获的敏感标识符，其价值就很有限。路由模型还必须避免将请求发送到不合适的下游工具。

这些限制并不会否定这一发布。它们界定了有前景的架构结果与部署决策之间的差异。

Hugging Face 开发者接下来应关注什么

三个信号将决定这一发布会成为实用的 CPU 标准，还是仍仅是一个有趣的厂商基准测试。

第一个信号是独立的硬件复现。开发者需要看到 Apple silicon、主流 x86 笔记本和服务器处理器上的结果，并公开线程数和内存配置。

复现不应只测量 8,192 token 的端点。真实数据集包含不同长度的内容，因此百分位延迟和每小时处理的文档数能提供更清晰的运行图景。

如果独立测试保留了显著的长上下文优势，Liquid AI 的架构论点就会更有说服力。如果在同等运行时优化后差距缩小，实施选择很可能比标题中的结论更能解释结果。

第二个信号是优化运行时支持。ONNX 导出、OpenVINO 集成、稳定的量化方案和原生库支持，将使这些模型更易于在实验性 Python 环境之外运行。

这些补充也将检验混合骨干网络能否良好适配广泛部署的 CPU 工具链。依赖自定义即时执行的模型，即使基准结果出色，也可能面临采用阻力。

成功的 8 位或更低精度部署将加强本地推理的论点。它们可以在将任务准确性维持在可接受范围内的同时减少内存占用并提升吞吐量。

反之，则会削弱这一比较。ModernBERT 和其他成熟编码器受益于成熟的优化路径，因此原始架构速度并不保证部署后的系统最佳。

第三个信号是任务级采用情况。Hugging Face 下载量可提供早期指标，但已发布的微调模型和可复现的案例研究更重要。

有价值的证据包括：根据组织规则衡量的策略过滤器、针对真实标识符测试的多语言 PII 系统，以及在持续应用流量下运行的路由器。

开发者应关注误报率、漏报率、校准、内存使用和尾延迟。这些指标揭示模型是否改善了系统，而不只是提升了排行榜排名。

Liquid AI 的微调示例为团队提供了分类任务的起点。下一步是获得并非由架构设计者提供的用户证据。

竞争对手的回应将在这些信号中提供另一条线索。ModernBERT 实现可以获得优化内核，而其他长上下文编码器可以采用混合或稀疏处理方式。

生成式模型厂商也有空间通过更低成本的分类端点作出回应。不过，远程服务仍面临数据传输、连接性和本地控制方面的限制，而设备端编码器可以避开这些限制。

对知识工作者而言，这一进展可能使本地文档组织更迅速、更具隐私性。合同、转录稿、笔记和支持记录可以在任何文本离开受控环境之前完成分类。

对企业采购方而言，这一发布提出了一个更明确的问题：每项语言任务都需要生成式推理吗，还是专用编码器能以更低的基础设施需求提供所需决策？

对开发者而言，正确的回应是测量。构建具有代表性的测试集，定义准确性阈值，记录输入长度分布，并在部署硬件上比较完整流水线。

Hugging Face 让这一实验更易开展，因为两个 LFM2.5 变体及其支持材料均可在同一处获得。不过，可获取性不应替代验证。

Liquid AI 提出了明确的技术主张：当架构限制重复的全注意力计算时，长上下文理解可以留在 CPU 上完成。其基准测试为这一主张提供了可信的初步支持。

尚未解决的问题是：在每个模型都获得同等优化后，独立部署能否复现这一优势。这个问题应指导下一轮测试、微调和生产报告。

如果你的团队持续处理长文档，请将 LFM2.5 与当前服务于工作负载的编码器进行比较。使用真实文档、公开的硬件信息和任务特定的错误指标。

最重要的结果不会是另一个平均基准分数，而是证明小型编码器能够审阅完整的工作上下文、满足准确性要求，并在数据所在位置可预测地运行。