Liquid AI釋出LFM2.5-Encoder-230M和LFM2.5-Encoder-350M：在CPU上以8K上下文保持快速的雙向編碼器

Liquid AI近日釋出了兩個開源權重的雙向編碼器：LFM2.5-Encoder-230M和LFM2.5-Encoder-350M。這兩款模型均為掩碼語言模型，基於LFM2混合骨幹架構，支援8192令牌的上下文長度。

編碼器通常用於分類器、意圖路由、安全過濾和PII檢測等任務。這些任務通常持續執行，且往往沒有GPU支援，同時輸入長度日益增加。BERT奠定了該領域的基石，ModernBERT進一步提升了準確率、速度和上下文能力。Liquid AI認為，LFM2架構延續了這一發展方向，因為其計算成本隨輸入長度增長更慢。

從解碼器到編碼器的轉換

這兩款編碼器並非從頭訓練，而是從LFM2.5-230M和LFM2.5-350M解碼器骨幹初始化，並透過三項修改轉換而來：

1. 將因果注意力掩碼替換為雙向掩碼，使每個令牌能夠關注兩側的上下文。
2. 使用對稱中心填充使LFM2短卷積變為非因果，確保每個令牌的卷積混合兩側相鄰資訊。
3. 使用30%掩位元速率的掩碼語言建模目標進行訓練，這比BERT的15%更高，Liquid AI引用證據表明在此規模下更高掩位元速率更有益。

訓練分為兩個階段：第一階段在1024令牌短上下文中使用大型網頁語料庫進行MLM訓練，建立通用語言能力；第二階段將上下文擴充套件到8192令牌，使用完整資料混合，增強事實、法律和多語言能力。

架構上，骨幹網路交錯使用門控短卷積塊和分組查詢注意力，與LFM2技術報告一致。兩個檢查點均使用1024隱藏維度和65536令牌詞彙表，支援15種語言，採用LFM Open License v1.0許可證。

基準測試結果

Liquid AI在GLUE、SuperGLUE和多語言分類的17項任務上評估了14個模型。每個模型針對每個任務進行全微調。LFM2.5-Encoder-350M的17任務平均得分為81.02（±1.00），排名第四。前三名均為更大模型：XLM-R XL（3.5B，83.06）、ModernBERT-large（395M，81.68）和XLM-R large（560M，81.34）。排名第一的模型幾乎是其10倍大小。

LFM2.5-Encoder-230M得分為79.29（±1.02），排名第六，超過了ModernBERT-base（78.19）以及所有EuroBERT模型，包括EuroBERT-610M（75.87）和EuroBERT-2.1B（72.19）。兩款新編碼器還優於Liquid AI自家的檢索模型LFM2.5-ColBERT-350M（76.18）和LFM2.5-Embedding-350M（75.68）。這一差距正是Liquid AI構建通用編碼器而非複用檢索模型的原因。

該方法已開源，採用Apache-2.0許可證。所有模型使用fp32主權重和bf16自動轉換，確保公平比較。所有模型使用相同的AdamW最佳化器配置。學習率根據每個模型和任務從10個值和3個種子中選擇，最終得分基於5個全新種子的平均值。Transformers版本固定為4.56.2，避免依賴漂移。

應用場景與部署環境

釋出方指出了三個典型場景：首先，邊緣和嵌入式裝置（如汽車車載計算或工業控制器）沒有多餘GPU，也無法承受雲端往返延遲；其次，金融、醫療和法律等監管嚴苛或本地化部署的系統，檔案長且敏感，不能離開內部基礎設施；最後，高吞吐量、成本敏感的管道，其中小型編碼器作為大型模型前的廉價第一道處理。

Liquid AI還給出了上下文視窗的實際意義：8192令牌約等於13到15頁內容，一次前向傳播即可覆蓋完整合同或完整病歷。

為展示微調後的編碼器效果，研究團隊提供了五個演示，均在僅CPU的Hugging Face Spaces中執行，涵蓋零樣本提示路由、零樣本策略檢查、拼寫檢查、PII檢測（支援16種語言的40種資訊型別）以及一個掩碼擴散演示（將編碼器用作聊天機器人，透過迭代去掩碼生成文本）。

使用指南

兩款編碼器透過transformers載入。模型體以Lfm2BidirectionalModel暴露，掩碼LM載入使用Lfm2BidirectionalForMaskedLM。兩者都透過auto_map連線，因此每次載入呼叫時需設定trust_remote_code=True。基本編碼器產生通用表示而非任務輸出，因此需要微調。Liquid AI的微調教程展示了在8K上下文配置下處理長法律文件的方法。模型選擇建議：需要最高準確率時選用350M，硬體更受限或吞吐量要求更高時選用230M。