本文整理 Liquid AI 發布的 LFM2.5-Encoder-230M 與 LFM2.5-Encoder-350M 雙向編碼器模型特色，包含其非因果架構調整、8,192 token 長文本處理能力、在 CPU 上的推理優勢，以及近期透過 GGUF 格式與 llama.cpp 支援在本地運行的技術細節與應用場景。
近年自然語言處理領域多由自回歸解碼器主導，然而在文本分類、語意搜尋檢索、意圖路由與內容過濾等任務中，雙向編碼器（Bidirectional Encoder）仍然扮演著基礎骨幹的角色。Liquid AI 先前推出了以長文本與邊緣推理為取向的基礎架構，並在近期進一步釋出兩款雙向編碼模型：LFM2.5-Encoder-230M 與 LFM2.5-Encoder-350M。
隨著開源社群對輕量化本地部署的需求增加，開發者近期可以在 Hugging Face 上取得官方提供的 GGUF 格式模型，包含 LFM2.5-Encoder-350M-GGUF 與 LFM2.5-Encoder-230M-GGUF。同時，社群也在 Reddit 的 LocalLLaMA 討論板 分享了相關測試（該討論串標題誤植為 250M），並提及這批模型藉由 llama.cpp 的 Pull Request #29862 整合進跨平台推理管線，讓一般個人電腦與低功耗設備能直接執行填空遮罩（Masked Language Modeling）與特徵抽取。
LFM2.5-Encoder 的架構設計與改進
這兩款編碼器直接繼承自 Liquid AI 的 LFM2 混合架構，分別以 LFM2.5-230M 與 LFM2.5-350M 兩款解碼器為基礎改裝而來。為了將原本只能從左到右預測的生成式模型轉換為雙向理解架構，團隊進行了幾項關鍵調整。
雙向注意力機制與非因果卷積
傳統因果解碼器會使用下三角遮罩限制每個 token 只能看到前文。在 LFM2.5-Encoder 中，這層限制被替換為全雙向注意力遮罩，使序列中的每個位置都能同時吸收前後文的資訊。
此外，LFM2 架構內部包含用於混合局部特徵的短卷積層（Short Convolutions）。研發團隊將原本具因果特性的卷積核調整為對稱中心填充（Symmetric Center Padding），讓每個位置在卷積運算時能均勻讀取相鄰兩側的資訊，形成對稱的雙向局部特徵提取。
提高遮罩比例的兩階段訓練
在預訓練目標方面，模型採用遮罩語言模型（MLM）訓練機制。與經典 BERT 所使用的 15% 遮罩比例不同，LFM2.5-Encoder 將隨機遮罩比例提高至 30%。這項調整參考了近年針對中小型編碼器的實證研究，證明適度提高遮罩密度有助於模型學習更緊湊的表徵。
訓練流程主要分為兩個階段：
- 第一階段：在 1,024 token 的上下文長度下，使用大規模網路文本語料進行基礎語言能力訓練。
- 第二階段：長上下文適應階段，將序列長度擴展至完整的 8,192 tokens，並混合多語言、法律與事實性文件，涵蓋 15 種語言的理解需求。
效能評測與 CPU 長文本推理優勢
多數企業管線中的分類器與前置過濾模組通常全天候運作，且經常部署在沒有獨立 GPU 的伺服器或邊緣設備上。當輸入文本長度增加時，傳統自注意力機制的計算複雜度往往會使 CPU 推理時間急遽拉長。
根據 Liquid AI 官方技術文章 公布的數據，LFM2.5-Encoder 架構在計算成本上的增長幅度相對平緩。
基準測試表現
在涵蓋 GLUE、SuperGLUE 與多語言分類任務的 17 項評測中，參數規模約 354M 的 LFM2.5-Encoder-350M 在 14 款受測編碼器中名列前茅，得分僅次於少數參數量達數十億級別的模型。參數量較小的 LFM2.5-Encoder-230M 在平均表現上也超越了同等級的 ModernBERT-base 與 EuroBERT。
CPU 環境下的長文本處理延遲
兩者最明顯的差異出現在 CPU 運行環境。當處理長度達 8,192 tokens 的完整長文件時，ModernBERT-base 單次前向傳播（Forward Pass）耗時超過 90 秒，而 LFM2.5-Encoder-230M 約在 28 秒左右完成，速度約提升 3.7 倍。在長度低於 1,000 tokens 時，兩者在 GPU 上的表現差距較小，但只要輸入長度持續增加，LFM2.5-Encoder 的計算延遲曲線便展現出更平穩的延展特性。
本地部署與 GGUF 生態支援
隨著 GGUF 格式檔案釋出，開發者不需要依賴龐大的 Python 機器學習依賴庫，即可透過編譯好的輕量 C++ 執行檔或輕量腳本執行模型。
在社群示範中，使用者可以直接透過如下指令執行填空遮罩測試：
uv run fill-mask.py LFM2.5-Encoder-350M-F16.gguf "The capital of France is [MASK]."
這項特性讓模型可以直接整合進終端工具、本機應用程式或網頁前端（配合 WebGPU）。
在實際落地應用上，這類模型主要適合三種場景：
- 邊緣設備與車載系統：在欠缺 GPU 的嵌入式環境中執行語音指令分類、意圖過濾與離線安全檢查。
- 具法規遵循要求的本地系統：金融、醫療與法務文件動輒數十頁，透過 8k 上下文長度，可以在不傳送資料至雲端的前提下，直接由本機 CPU 完成長合約分類或機敏資訊（PII）偵測。
- 高吞吐分流管線：在大型模型前端擔任輕量分流器（Router），先過濾無效請求或將任務分派至不同專長模型，降低整體運算成本。
常見問題
LFM2.5-Encoder 與先前的 LFM2.5-Retriever 有何不同？
LFM2.5-Retriever 是專門針對雙塔檢索（Retrieval）任務調整的特化模型。LFM2.5-Encoder 則是通用的遮罩語言模型骨幹，具備完整的雙向注意力結構，能作為特徵抽取器，也能進一步微調為分類器、排序器（Reranker）或實體辨識模組，適用範圍比檢索專用模型更廣。
這款模型可以直接用來進行長篇對話生成嗎？
這款模型本質上是雙向編碼器而非自回歸解碼器，因此主要輸出為語意特徵（Embeddings）與分類分數，而非逐字生成句子。官方展示過使用遮罩擴散（Masked Diffusion）技術以迭代去噪方式生成文字的實驗，但一般的生成對話情境仍建議選擇因果解碼模型。
8K 上下文在實際應用中對應多少文字量？
8,192 tokens 大約等同於 12 至 15 頁標準英文單行間距文件。這代表使用者可以將完整的合約章節、技術規格書或長篇客服紀錄單次輸入模型，無須將文本切成大量短片段再進行組合。
結語
Liquid AI 推出的 LFM2.5-Encoder-230M 與 LFM2.5-Encoder-350M 為長文本自然語言理解提供了輕量化的替代方案。透過雙向卷積調整與 30% 遮罩訓練，模型在保有準確度的同時降低了長文本運算負擔。隨著 GGUF 規格與 llama.cpp 支援的完備，需要低功耗、本地化或嚴格隱私保護的文字分類與過濾任務，在現有 CPU 硬體上有了更實用的選擇。
