LFM2.5编码器，把长文本搬回CPU

Liquid AI 把优化重点转向长文本编码

Liquid AI 今天（2026 年 7 月 28 日）发布了 LFM2.5-Encoders，目标是在 CPU 上更快地处理长上下文编码任务。与负责逐 token 生成答案的 LFM2.5-1.2B-Thinking 不同，这次的新模型更关注文档向量化、语义匹配、检索和排序等“读完再判断”的工作负载。

LFM2.5-Encoders 是一组面向长上下文理解与检索场景优化的编码器模型。 编码器不会像聊天模型一样连续生成文本，而是把输入转换为向量、相关性分数或任务特征，因此更适合 RAG 检索、文档聚类、语义搜索、去重和分类系统。

这次发布真正值得关注的地方不是“又一个 embedding 模型”，而是 Liquid AI 明确把 CPU 长上下文推理当成了核心产品指标。过去两年，开源模型一直在把上下文窗口从 8K 推到 32K、128K，甚至更长，但窗口长度只是模型“理论上能读多少”，并不等于普通服务器“实际读得起”。

编码器不是缩小版聊天模型

编码器推理是一次性理解输入并生成表示，解码器推理则需要按照顺序逐个生成 token。 两者虽然都能处理文本，但计算形态和性能评价方式完全不同。

聊天模型通常包含两个阶段：prefill 阶段先读取提示词，decode 阶段再逐 token 输出答案。长上下文会显著增加 prefill 时间和 KV Cache 占用，而输出越长，decode 阶段的累计延迟也越高。

编码器通常不需要 decode 阶段。它读取整段文本后，通过一次或少量前向计算输出 embedding 或相关性结果，因此不会出现“每秒生成多少 token”这一典型聊天模型指标。对编码器而言，更有意义的数据是每秒处理多少输入 token、单篇文档延迟、峰值内存、批处理吞吐量，以及检索或排序质量。

这一区别也意味着，不能直接拿 LFM2.5-Encoders 的吞吐量与 LFM2.5-1.2B-Thinking 的生成速度比较。前者是文档处理引擎，后者是答案生成器，它们更像搜索引擎的索引模块与最终回答模块，而不是同一赛道的两个聊天机器人。

为什么长上下文特别考验 CPU

CPU 长上下文推理的主要瓶颈是内存带宽、注意力计算量和中间激活占用，而不只是模型参数量。 一个模型即使只有数亿参数，在输入长度从 2K 增至 32K 后，也可能因为注意力矩阵和数据搬运开销而明显变慢。

传统全注意力的计算量会随序列长度近似按平方增长。输入从 8K 增至 32K，相当于长度扩大 4 倍，未经优化的注意力计算量理论上可能扩大至约 16 倍。实际实现会使用分块计算、融合算子和更节省内存的 attention kernel，但长文本仍然会迅速暴露 CPU 的带宽短板。

LFM 系列的核心思路是让不同类型的序列模块分担工作。Liquid AI 此前公开的 LFM2.5 家族采用 LFM 混合架构，将注意力机制与门控短卷积等模块组合使用；短卷积擅长以接近线性的方式处理局部信息，注意力层则负责建立距离更远的依赖关系。

这种设计可以类比为文档审阅团队：卷积模块先快速扫描局部段落，注意力模块再处理跨章节引用，而不是让每一个词都与全文所有词反复比对。它不代表长上下文成本会消失，但能减少昂贵算子占据的比例，从而更贴近 CPU 和边缘设备的硬件特征。

这次发布瞄准的是 RAG 前半段

LFM2.5-Encoders 最直接的落地场景是本地 RAG 的文档摄取、召回和排序链路。 RAG 是先从外部资料中检索相关内容，再让生成模型基于这些内容回答问题的系统架构。

一套典型 RAG 系统至少包含文档切分、向量化、召回、重排和答案生成五个环节。开发者经常把注意力集中在最后的生成模型，却低估了前四个环节的成本：当知识库包含数十万份长文档时，重新生成 embedding、更新索引和执行候选重排，可能比生成几百字答案更消耗总算力。

LFM2.5-Encoders 的价值就在这里。它不是要替代大语言模型，而是试图让企业在普通 x86 服务器、开发者工作站或边缘设备上完成更多预处理工作，把 GPU 留给确实需要生成和复杂推理的环节。

以下场景尤其适合 CPU 优化的长上下文编码器：

• 企业知识库更新： 新增合同、报告和内部文档后，在后台持续生成向量，不必占用线上 GPU。
• 长文档语义搜索： 对论文、法律材料、财报和技术手册进行章节级或全文级表示。
• 候选结果重排： 在关键词或向量召回后，对数十个候选段落进行更精细的语义匹配。
• 隐私敏感部署： 医疗、法务和政企数据留在本地服务器，不必将原文发送至外部服务。
• 离线应用： 在没有独立显卡或网络连接不稳定的环境中完成分类、聚类和检索。

LFM2.5-Encoders 与主流方案怎么选

LFM2.5-Encoders 的差异化方向是 CPU 长上下文效率，而不是单纯追求更大的参数规模。 在正式替换现有检索模型前，开发者仍应同时比较质量、上下文长度、语言覆盖和部署生态。

| 模型或产品 | 参数规模 | 标称上下文 | 主要定位 | CPU 部署特点 | |---|---:|---:|---|---| | LFM2.5-Encoders | 以官方具体检查点为准 | 面向长上下文 | 编码、检索与排序 | 将 CPU 长文本吞吐和内存效率作为主要卖点 | | BGE-M3 | 约 568M | 8,192 tokens | Dense、Sparse 与多向量检索 | 中文与多语言检索生态成熟，基线工具较多 | | jina-embeddings-v3 | 约 570M | 8,192 tokens | 多语言、多任务 embedding | 可通过任务指令适配检索、分类和聚类 | | ModernBERT-base | 约 149M | 8,192 tokens | 通用编码与下游微调 | 参数较小，适合分类、抽取和检索实验 | | ModernBERT-large | 约 395M | 8,192 tokens | 更高容量的通用编码 | 质量潜力更高，但内存与延迟也相应增加 |

这张表不能直接得出“谁最好”的结论。BGE-M3 的优势是检索模式完整、中文应用广泛；ModernBERT 的优势是编码器生态熟悉、下游微调路径清晰；LFM2.5-Encoders 则押注混合架构和 CPU 长上下文效率。

如果现有知识库主要由 500 至 1,000 token 的短切片组成，LFM2.5 的长上下文优势未必能体现。相反，如果任务需要处理完整章节、多页合同或跨段落关系，减少切片数量可能同时改善召回质量和索引复杂度，这才是新模型更值得测试的场景。

长上下文不等于应该把整份文档直接塞进去

更长的输入窗口只能扩大可处理范围，不能自动保证检索质量。 文档越长，真正相关的信息在整体表示中越容易被稀释，单个向量也更难同时保留所有主题、实体和细节。

开发者不应因为模型支持长上下文，就取消文档结构化和切片。更合理的办法通常是保留标题层级、段落边界、页码和章节元数据，再根据任务动态决定输入粒度。例如，财报问答可以先按章节召回，再把相关章节交给长上下文编码器重排，而不是把整份年报压成一个向量。

长上下文编码也会改变索引成本的分布。较大的切片可以减少向量数量和向量数据库容量，却会增加单次编码延迟；较小的切片处理更快，但索引项更多，并且容易丢失跨段关系。LFM2.5-Encoders 如果能在 CPU 上降低长切片处理成本，最大的收益可能不是单条请求快几毫秒，而是让团队有余地选择更合理的文档粒度。

官方家族数据提供了方向，但不能替代编码器实测

Liquid AI 已经在 LFM2.5 家族中证明自己重视设备端部署，但生成模型数据不能直接视为编码器成绩。 官方披露的 LFM2.5-1.2B-Thinking 在 AMD Ryzen NPU 与 FastFlowLM 环境下，16K 上下文的 decode 吞吐量约为 52 tokens/s，在完整 32K 上下文下约为 46 tokens/s。

从 16K 增至 32K 后，吞吐量由约 52 tokens/s 降至约 46 tokens/s，降幅约 11.5%。这个结果说明 LFM2.5 家族对长上下文扩展有明确优化，但测试硬件是 NPU，任务是生成式 decode，并非此次编码器在通用 CPU 上的文档吞吐量。

Liquid AI 另一款 LFM2.5-8B-A1B 则采用 8B 总参数、约 1B 激活参数的 MoE 路线，并把上下文窗口由上一代的 32,768 tokens 扩展至 128,000 tokens。该模型支持 llama.cpp CPU 推理，但它仍是推理型生成模型，与 LFM2.5-Encoders 的评测口径不同。

这种区分很重要。厂商最容易展示的是某一台高端桌面 CPU、特定线程数和量化格式下的最好结果，而生产环境更关心普通云主机上的 P95 延迟、并发吞吐以及内存峰值。

现在还缺哪些关键答案

LFM2.5-Encoders 是否真正领先，最终要由统一硬件上的第三方基准决定。 截至今天，官方发布内容是判断产品方向的主要依据，开发者不应只凭“fast”或“long-context”两个标签迁移生产系统。

后续测试至少需要公开以下条件：

1. 处理器型号与线程数。 同为 CPU，服务器级 AMD EPYC、Intel Xeon 与笔记本处理器的内存带宽差异很大。
2. 输入长度分布。 512、8K 和 32K tokens 的平均吞吐量不能混为一个数字。
3. 数值精度与量化方式。 FP32、BF16、INT8 和 INT4 的内存占用、速度与质量损失不同。
4. 批处理规模。 Batch 1 反映交互延迟，大 batch 更接近离线建库吞吐。
5. 检索质量。 速度测试应同时报告 MTEB、BEIR 或具体业务数据集上的 Recall、nDCG 与 MRR。
6. 运行时版本。 ONNX Runtime、PyTorch、llama.cpp 或其他引擎会直接影响算子融合与线程调度。
7. 完整内存数据。 模型权重、运行时占用和长输入中间激活都应计入，而不只是模型文件大小。

如果官方模型只在特定运行时上快，迁移成本可能抵消性能收益；如果它能在标准 CPU 环境、常用推理框架和不同输入长度下保持优势，LFM2.5-Encoders 才会真正改变本地检索模型的选择逻辑。

判断：方向比单次跑分更重要

LFM2.5-Encoders 是一次有现实价值的模型上新，因为 AI 应用的成本瓶颈正在从“能否生成”转向“能否持续处理全部私有数据”。 当模型进入企业知识库、桌面端和边缘设备后，GPU 不可能承担每一次文档更新、每一次检索和每一次重排。

Liquid AI 选择优化 CPU 长上下文，避开了与超大生成模型正面比参数的竞争，也抓住了 RAG 系统里更隐蔽但更稳定的算力需求。对开发者而言，它最有吸引力的地方不是让聊天回答更聪明，而是让长文档处理从昂贵的专用算力任务，变成可以在普通计算节点后台执行的基础工作。

目前更稳妥的结论是：LFM2.5-Encoders 值得进入本地 RAG 和长文档检索的候选清单，但还不值得仅凭官方宣传替换成熟方案。先用自己的文档长度、语言分布和 CPU 规格做 A/B 测试，再比较端到端召回率、P95 延迟和每万篇文档的处理成本，才是判断它是否真的“更快”的有效方式。

参考来源

• LFM2.5-Encoders for Fast Long-Context Inference on CPU：Liquid AI 在 Hugging Face 发布的官方介绍，说明 LFM2.5-Encoders 的长上下文与 CPU 推理定位。
• LiquidAI/LFM2.5-1.2B-Thinking：LFM2.5-1.2B-Thinking 官方模型页，包含 32K 上下文、GGUF、ONNX 以及 AMD Ryzen NPU 性能信息。