编码器模型是搜索、分类和安全过滤背后的主力，但它们有一个问题。当输入长度增长到数千个 token 时，CPU 上的推理延迟会攀升到分钟级别。Liquid AI 的最新发布正是为了解决这一问题，推出了一对专为在 CPU 硬件上进行高效长上下文推理而设计的小型编码器模型。
LFM2.5-Encoder 系列提供 2.3 亿和 3.5 亿参数两个版本，在 CPU 上处理 8,192 个 token 的速度约为同等规模的 ModernBERT-base 模型的 3.7 倍。在该长度下，ModernBERT-base 每次前向传播需要 90 秒以上，而 LFM2.5-Encoder-230M 大约只需 28 秒。
性能提升来自底层架构。两个模型都以 Liquid AI 的 LFM2.5 解码器主干为初始权重，并通过三项改造转换为双向编码器：让 token 能同时看到两侧内容的双向注意力掩码、采用对称填充的非因果短卷积，以及掩码比例为 30% 的掩码语言建模训练。两阶段的训练流程先在短上下文长度下建立通用语言能力，再在由事实性、法律和多语言数据混合而成的语料上扩展到 8,192 个 token。
对于这一尺寸级别的模型，基准测试的结果很能说明问题。在 GLUE、SuperGLUE 和多语言分类任务的测试中，350M 版本在参与测试的 14 个编码器模型中排名第四，仅落后于更大的模型，其中包括一个 35 亿参数的参评模型。230M 版本则击败了 ModernBERT-base 和所有 EuroBERT 模型，而它的体积比其中大多数模型都更小。
对于在生产环境中部署的开发者来说，CPU 上的速度优势是最大的亮点。许多编码器工作负载（意图路由、策略检查、PII 检测、拼写检查）持续运行在服务器 CPU 而非 GPU 上，在这些场景中，长输入下的延迟会直接影响吞吐量。Liquid AI 已在 Hugging Face Spaces 上发布实时演示，展示完全在 CPU 上运行的零样本提示路由、策略检查和多语言 PII 检测。
这两个模型采用宽松的开源许可证发布，可通过标准的 Hugging Face Transformers 流水线集成。Flash Attention 2 可作为可选的 GPU 加速方案，但设计理念很明确：编码器不应依赖 GPU 才能实用，即使每个请求需要处理数千个 token 也是如此。
婷 翻译
来源：Hugging Face Blog（2026 年 7 月 28 日）；[Liquid AI models](https://huggingface.co/LiquidAI/LFM2.5-Encoder-230M）