Liquid AI 在 Hugging Face 發布了兩個新的小型編碼器模型，LFM2.5-Encoder-230M 和 LFM2.5-Encoder-350M，將它們定位為可在 CPU 上處理文件規模工作負載的長上下文 NLP 模型，而不是需要更大、GPU 密集型部署的方案。根據公司在 Hugging Face Blog 的公告，新模型支援 8,192 個 token 的輸入，並針對分類、政策檢查、路由與 PII 偵測等生產任務而設計。

這次發布之所以重要，是因為許多企業 NLP 工作仍然在當前大型語言模型的聚光燈之外運行。安全過濾器、進件分類器、意圖路由器和合規工具通常會持續處理長文檔且利潤空間很低，因此硬體成本與延遲比類 Chatbot 的生成品質更重要。Liquid AI 的主張是，這類編碼器工作負載可以轉移到既有的 CPU 基礎架構上，同時仍能與 ModernBERT 之類更大或更知名的替代方案競爭。

Liquid AI 發布了什麼，以及它適合放在哪裡

這次發布包含兩個模型：LFM2.5-Encoder-230M 和 LFM2.5-Encoder-350M。Liquid AI 將它們描述為通用編碼器，而不是狹義的檢索模型，儘管它們與先前的 LFM2.5-Retrievers 屬於同一系列。公司表示，這些新模型以 masked-language 目標進行預訓練，因此可以在更廣泛的任務上進行微調，包括文本分類、token 標註與搜尋。

這種區分對於在 embeddings、retrievers 與 encoders 之間做選擇的產品團隊來說很重要。檢索模型可能足以應付多語搜尋，但企業工作流程通常需要在整個文件或 token 層面做判斷：例如轉派客服工單、檢查政策違規，或找出個人識別資訊。Liquid AI 的範例明顯偏向這些用途。在公告中，公司強調了 zero-shot prompt routing、zero-shot policy linting、多語 PII 偵測，甚至是一個 masked-diffusion 文字生成實驗，所有示範都在僅使用 CPU 的 Hugging Face Spaces 中執行。

這些模型源自 Liquid AI 的 LFM2 架構。根據公司說法，它先以 LFM2.5-230M 和 LFM2.5-350M decoder backbone 初始化編碼器，接著透過改變 attention mask、讓短卷積變成非因果、以及使用 masked language modeling 訓練，將這些 causal decoders 轉換成雙向編碼器。Liquid AI 表示，首先在 1,024 tokens 的短上下文上訓練語言能力，之後再以更廣泛的資料混合將模型調整到 8,192 tokens 的上下文，以強化事實、法律與多語表現。

為什麼 CPU 表現是這則故事的主軸

頭條級主張不只是 benchmark 品質，而是長序列下的吞吐量。Liquid AI 表示，它的編碼器在 CPU 上特別強，因為長上下文延遲往往成為部署成本的決定因素。根據公司自己的比較，LFM2.5-Encoder-230M 在所有測試的序列長度上都比 ModernBERT-base 更快，而且在 8,192 tokens 時大約快 3.7 倍。

Hugging Face Blog 的具體例子很值得注意，因為它把 benchmark 速度轉化為營運訊息：一份完整合約、一段逐字稿或一個很長的客服討論串，在筆電 CPU 上可以在 30 秒內處理完，而 ModernBERT-base 在相同上下文長度下則需要超過一分半。對許多企業團隊來說，這會改變長文檔分類是否便宜到足以常態化執行。

在 GPU 上，Liquid AI 報告的優勢較小。根據公司說法，在 Apple GPU 上，ModernBERT-base 在大約 1,000 tokens 以下仍領先，而 LFM2.5-Encoder 模型則在約 2,000 tokens 及以上開始超前。這種模式強化了其預定市場定位：它們不一定是所有短輸入工作流程的最快選擇，但它們被行銷為適合長上下文、always-on 推論，且 CPU 經濟性很重要。

這種定位也反映了 AI 基礎架構的更大分化。生成式模型仍然吸走大部分注意力，但許多生產系統依賴更小的模型，在大型模型呼叫之前或周邊對文字進行評分、分類、過濾與路由。如果這些模型能在本地或一般 CPU 上運行，建置者就能降低成本、改善資料駐留選項，並減少對 GPU 可用性的依賴。

架構故事與更廣泛的長上下文設計趨勢相符

雖然 Liquid AI 的公告聚焦於編碼器模型，但本群組中的第二個來源、NVIDIA Developer Blog 關於長上下文 attention 設計的文章，有助於解釋為什麼這次發布會在現在出現。NVIDIA 認為，隨著 agentic 與長上下文工作負載越來越普遍，attention 越來越主導推論成本，模型架構選擇因此成為性能的重要決定因素。

NVIDIA 的文章並不是針對 Liquid AI，且它聚焦於 GPU 推論而非 CPU-first 部署。不過其核心觀點直接相關：長上下文性能受架構決策影響，例如 group size、head dimension 與 KV-state 管理，而不只是 kernel 工程。文章建議採用考慮硬體的 attention 設計，包括更高的 group size 以提升 decode 效率、與 GPU 記憶體和 tile size 對齊的 head dimension，以及透過壓縮或 sparse 與 hybrid attention 方法降低有效 KV 狀態。NVIDIA 以 TensorRT-LLM 和 NVIDIA Nemotron 3 等架構作為這種共同設計方法的例子。

這個更廣的背景讓 Liquid AI 的發布不只是例行的模型上架。公司實際上是在主張，驅動 GPU co-design 的 attention 效率邏輯，也能為 CPU 受限的編碼器工作負載帶來實際收益。Liquid AI 表示，LFM2.5-Encoders 繼承了 LFM2.5 backbone 的特性：隨著輸入長度增加，成本上升速度很慢。對於評估企業 AI 系統的使用者而言，這往往比短合成任務上的峰值性能更有價值。

證據、benchmark 與仍然屬於廠商報告的部分

這則故事中最強的性能主張都來自廠商報告。品質結果與速度比較來自 Liquid AI 自己的 Hugging Face Blog 文章，而不是獨立 benchmark 實驗室或第三方企業部署研究。Liquid AI 表示，它對每個模型在每項任務上都做了完整微調，並在 GLUE、SuperGLUE 與多語分類的 17 項任務上評估了 14 個模型，報告了 5 個保留 seed 的平均值。公司也說完整評估框架與原始結果都是開源的。

根據這些結果，LFM2.5-Encoder-350M 在 14 個受測模型中排名第 4，只有更大的模型排在前面，其中包括一個 3.5B 模型。Liquid AI 還聲稱，LFM2.5-Encoder-230M 在其報告的設定下超越了 ModernBERT-base 與所有 EuroBERT 模型，而且體積比其中大多數都小。這些都是有意義的主張，但在外部重現出現之前，讀者應將其視為公司自報結果。

NVIDIA Developer Blog 提供的是技術背景，而不是對 Liquid AI 模型的獨立驗證。該分析同樣由廠商撰寫，並建立在 NVIDIA 硬體假設上，包括以 FP8 attention compute 與 KV cache 測得的 kernel 行為。這對理解長上下文 attention 設計為何重要很有幫助，但不應被解讀為第三方對 Liquid AI CPU benchmark 優勢的確認。

還有一些實務上的未知數。來源材料沒有提供詳細的企業定價、支援條款或生產案例研究。它們也沒有說明模型在真實文檔雜訊、多租戶延遲限制，或領域轉移後的法律與合規資料集上會如何表現。對部署有興趣的建置者，很可能需要拿 LFM2.5-Encoder-230M 和 LFM2.5-Encoder-350M 對自己的語料與服務等級目標做測試。

這對建置者與企業買家意味著什麼

對 AI 建置者來說，最直接的吸引力在於工作流程設計。一個在 CPU 上仍可於 8,192 tokens 使用的小型編碼器，可以嵌入原本需要截斷、分段，或昂貴 GPU 推論的系統。這對合約審閱流程、客服分流、trust and safety 篩查、多語進件，以及政策執行都很相關。對於在大型模型之前先由小模型過濾或路由請求的混合式堆疊，這也同樣相關。

對企業 AI 團隊來說，成本故事可能比排行榜名次更重要。對 CPU 友善的推論可以簡化在受監管或預算受限環境中的部署，尤其是 GPU 容量稀缺，或資料必須留在既有 on-prem 基礎架構中的情況。若長上下文編碼器能消除把文件切成大量 chunk 並在下游重新組裝結果的需要，也可以降低工程複雜度。

對模型開發者而言，這次發布是市場持續從前沿聊天模型擴展到專用推論原語的另一個信號。ModernBERT 仍是重要的比較基準，但 Liquid AI 試圖以更具體的承諾競爭：在小模型尺寸下提供更好的長上下文經濟性。如果這項主張在實務上成立，建置者可能會把 encoders 看得不只是一般工具，而是會直接影響延遲預算與系統成本的架構決策。

接下來要關注什麼

下一個重要信號將是獨立重現。如果外部開發者確認 Liquid AI 報告的相對於 ModernBERT-base 的差距，尤其是在一般 CPU 與真實文檔工作負載上，這次發布可能會影響團隊如何架構低成本企業 NLP 系統。

另一個信號是 Hugging Face 生態中的採用情況。如果 LFM2.5-Encoder-230M 與 LFM2.5-Encoder-350M 開始出現在生產 demo、微調分類器或企業評估堆疊中，那就表示這些模型正在解決真正的營運問題，而不只是交出強勁的內部 benchmark。

也值得觀察 Liquid AI 是否會進一步擴展 LFM2 系列。LFM2.5-Retrievers 與這些新編碼器之間的關係，暗示了一項更廣泛的策略：圍繞搜尋、路由、標註與過濾等不同工作流程層，打造小型而高效率的長上下文模型。在基礎架構層面，NVIDIA 所闡述並在 TensorRT-LLM 中實作的原則，將持續影響哪些架構能在更長上下文視窗下保持實用。

Creati.ai 觀點

這次發布有趣的地方不在於它試圖擊敗最大型模型，而在於它瞄準了堆疊中被忽視的一環：必須持續且低成本運作的長文檔理解。在許多真實系統中，正是這一層決定了昂貴模型呼叫是否真的發生。如果 Liquid AI 的 CPU 主張成立，LFM2.5-Encoders 可能會成為企業 AI 團隊控制推論支出、同時不犧牲長上下文覆蓋範圍的有用構件。

更大的教訓是架構層面的。市場正在走出「更大的模型等於更好的產品」這種簡單敘事。不論是在使用 LFM2.5-Encoder-230M 的 CPU 上，還是在受 NVIDIA co-design 指導影響的 GPU 堆疊上，性能越來越取決於把模型結構與工作負載及硬體相匹配。對建置者而言，競爭優勢可能不再主要來自擁有一個 foundation model，而是來自在正確的位置選擇正確的小型模型。