Clef 與 LFM2.5 2.6B Base 對比：在 H200 上為 55 GB，或在筆記型電腦上為 5.4 GB

這是一場硬體在模型之前就決定爭論走向的比較。 Cloudflare/clef 是一個 270 億參數的多模態決策模型，由 Qwen3.8-27B 後訓練而成，其儲存庫由十二個主幹分片加上一個小型聯合結構描述頭組成，總大小略超過 55 GB。 LiquidAI/LFM2.5-2.6B-Base 是一個 26.9 億參數的純文字檢查點，其權重為單一 5.4 GB 檔案，由 Liquid AI 於 2026 年 8 月 1 日依 LFM Open License 發布。Cloudflare 自家公布的 Clef 延遲——中位數 209.3 毫秒、p95 238.6 毫秒——是在單張 H200 上測得的。Liquid AI 為其 LFM2.5 系列設定的預期部署環境是筆電、手機或 Ryzen 掌機。兩家廠商都把自家模型描述為小巧、快速且高效，而兩者各自就不同的機器而言，說的都是實話。

第一道落差背後還有第二道落差，而這道落差才是真正會改變計畫的。無論是 Clef還是LFM2.5 2.6B Base，都不會以你可能預期的方式，開箱即用地回答問題。Clef 來的時候已經針對一項它無法偏離的任務完整訓練完成：它會回答打字輸入的問題，而且不會做其他任何事。Liquid 檢查點來的時候完全未經任何訓練——它是基礎模型，刻意未經指令微調，而 Liquid AI 自家的模型卡也說它只建議用於重度微調。所以真正的問題不是哪一個跑起來比較便宜。而是你買的是一個完成品元件，還是一種起始材料，而針對它們各自，答案也不一樣。

每一個在哪裡執行，以及為什麼這就是整個比較

部署形態對這兩個模型來說並非次要細節。對決策模型而言，它本身就是架構，因為 209 毫秒的前向傳遞和「在你面前的機器上執行」這個說法，正是同一項主張從不同端說出來。

• 參數 — Clef 為 27B，保留 Qwen3.8-27B 視覺編碼器；LFM2.5 2.6B Base 則為純文字 2.69B。

• 磁碟 — 供 Clef 使用的 55 GB 儲存庫；Liquid 檢查點的單一 5.4 GB safetensors 檔案，並隨附發布量化 GGUF、ONNX 與 MLX 版本。

• 硬體 — Cloudflare 在單一 H200 上以 torch 2.11 和 transformers 5.10.2 測試 Clef，其延遲數據即來自該次執行。Liquid AI 將此檢查點後訓練而成的同系列模型，在 Apple M5 Max 上以每秒 220 個 token 運行，在 AMD Ryzen CPU 上為 113 tok/s，記憶體用量低於 2.5 GB，而廠商指出在手機上可達到 30 tok/s。

• 上下文 —— Clef 為 65,536 個 token，根據 Workers AI 模型頁面與發布文章；LFM2.5 2.6B Base 為 131,072 個 token。

• 輸入 — Clef 會讀取文字、JSON、圖片與影片影格，並將它們一起評分。Liquid 檢查點僅支援文字。

• 授權 — Clef 採用 Apache-2.0。LFM2.5 採用 LFM Open License v1.0，這是原始碼可見授權，而非 OSI 開源授權：商業使用的前提是貴組織的年營收低於 1,000 萬美元；一旦超過這條界線，該授權便不授予商業使用權。這項門檻是採購時必須正視的事實，而不是附註。

每次決策的成本與每個 token 的成本不是同一個問題

這裡誘人的做法，是把兩項價格相除，然後宣布誰勝出。但這套做法一旦碰上這兩個模型實際做的事，就站不住腳。

Clef 在 Cloudflare 的 Workers AI 上每百萬輸入 token 為 $0.24。它的輸出不是散文，所以常見的輸出 token 計費項目並不存在；你只需為狀態付費一次，然後取回一個分佈。對於每天做出數百萬個微小決策的路由層來說，那個數字就是全部的營運成本，而這個數字你只能從供應商取得，而不是從你自己的電費帳單。

LFM2.5 2.6B Base 每次呼叫的成本為零，但它無法做出決策。若要從它身上得出「每次決策成本」，你首先得針對你的任務對它進行微調，這意味著要彙整資料、執行訓練工作、評估結果，然後才會發現它在 kVA 和工程時間上要你付出多少代價。一個 2.6B 檢查點所帶來的誘人經濟效益是真實的，但這些效益取決於尚未發生的工作，而那個比較每詞元價格的人，卻直接跳過了這一點。

坦白說，這是兩筆不同的購買。Clef 是一個元件，有標價，也有代管費用。Liquid checkpoint 則是一種原材料，其成本就是你無論如何都得支付的訓練運行費用——而它的回報是，之後你能完全擁有成品，到那時，一次決策的邊際成本真的就只是電力。對於範圍狹窄、量大且穩定的任務，這種取捨通常是正確的。對於你尚未明確界定的任務，這就本末倒置了，因為你無法朝著一個自己描述不出來的目標進行微調。

未經訓練的基礎模型不是比較差的模型，而是不同的起跑線。

人們很容易把 Liquid 檢查點缺少基準測試表這一點，解讀為隱藏的弱點。事實並非如此。用指令遵循基準來評分一個預訓練基礎模型，衡量的會是「缺少微調」這件事，而不是這個基底的品質；這正是為什麼 Liquid AI 要對後訓練的 LFM2.5-2.6B 進行基準測試，而讓基礎模型保持未評估。這個空白是你自己就能驗證的，而這正是重點：下載 5.4 GB，在自己的任務上跑自己的評估，在決定要部署任何東西之前就先知道答案。

Clef 的表格呈現的是形狀相反的證據，問題也正好相反。Cloudflare 公布了四十幾列基準測試資料、一整套工作流程評估集，以及一份延遲分布，而這些全都是由 Cloudflare 在其自家的 Decision Index 上產出的，沒有任何第三方重現過其中任何一項。Clef 那一欄的資訊量遠比 Liquid 那一欄豐富，但裡頭沒有一個數字經過其他人查核。這比一片空白更有力，卻也比乍看之下更弱。

你能自行量測的部分，也以同樣方式劃分。有了 Liquid 檢查點，你可以量測一切——它在你自己的磁碟上是 5.4 GB。有了 Clef，Apache-2.0 權重同樣任你下載與執行，但要達到 Cloudflare 的 209 毫秒中位數，就需要 Cloudflare 所使用的那一類 GPU，因此實務上大多數團隊會透過託管端點來量測它，並在取得其延遲的同時，一併承接供應商的可用性。

路由層適合放在哪裡，分別就它們每一個而言

Clef 與任何 LFM2.5 變體都不是 OrcaRouter 上的路由，而本文並非可用性宣告——型錄對兩者都回傳 404，因此 Clef 來自 Cloudflare 的 Workers AI 或你自己的 GPU，而 Liquid 檢查點則來自其自身的發行管道。

在這裡，路由層真正的作用，正是這兩種模型所共同暗示的模式。一個小型且有界的評分器負責做出決策，而一個更大的通才模型則依據該決策付諸行動，這在結構上就是一種雙模型架構——而 Clef 自家的骨幹讓這後半段的具體樣貌變得清晰，因為 Cloudflare 後訓練所依據的模型 Qwen3.8 27B，正是一個列出的路由，在 262,144 個 token 的上下文下，每百萬輸入 token 收費 $0.33、每百萬輸出 token 收費 $2.40。在 200 多個模型前面放一個端點，意味著便宜的决定者與有能力的執行者位於同一把金鑰之後，透過路由 DSL 組合成單一次呼叫，而不是靠手工接線串起來，並具備自動容錯移轉，因此某個供應商狀況不佳的午後，不會連帶把決策路徑也拖垮。反過來說，如果你是自行託管 Liquid 檢查點，並拿你的微調成果與它必須勝過的模型相比，那麼同一個端點正是讓這項比較變成一次設定變更、而非一輪採購流程的關鍵。

TypeSafe 的 Jev 1.13 特別值得在自託管情境中被點名：它是 Cloudflare 用來對照評測的決策模型，並刻意採用相同的POST /v1/systemone 請求形式，與 Clef 一致，它是一條公開列出的路由，在 65,536 token 的上下文下，每百萬輸入 token 收費 0.042 美元，而且這是一種省力的方式，能在你把一次訓練執行花在一個或許根本不需要存在的基底之前，先了解有界決策模型是否有助於你的管線。

哪一個，做什麼用的？

當任務範圍狹窄、處理量大、規格明確到足以據此撰寫訓練資料，並且受制於路由式 API 無法解決的兩項硬性限制之一時，就採用 Liquid 檢查點：資料不得離開你的基礎設施，或者它必須執行的機器就是你桌上那台。LFM 1.0 營收門檻是最該先檢查的事，因為它決定這項授權是否甚至可供你使用。

當決策本身已可枚舉、狀態塞得進 64K、你要的是校準過的機率而非一句話，而熱路徑上的 209 毫秒正是你想買下的特性時，就採用 Clef。它固定的 schema 正是賣點所在——一種可審計、可重現、無需解析器的輸出形狀——而 55 GB 的佔用空間，則是換來能在第一次就準確、而非等跑完一輪訓練才準確的骨幹模型所付出的代價。

你不應該做的是按參數量來挑選。一個必須先經過訓練才能回答的 2.69B 模型，並不是一個已經能回答的 27B 模型的縮小版；而標題裡的兩個數字——55 GB 和 5.4 GB——描述的是兩種不同的預算，不是同一個尺度上的兩個點。

那個懸而未決的問題，而且對兩者來說都是同一個問題。

兩家廠商都尚未發表經得起獨立檢驗的證據。Cloudflare 的 Decision Index 測試是由自家執行且未經重現；Liquid AI 的吞吐量數據是該廠商自行在其選擇的硬體上測得的結果。LFM2.5 2.6B Base 在設計上完全沒有任何基準測試，而 Clef 表格則出於選擇而有大量基準測試。

對 Liquid 檢查點來說，缺失的證據要補上成本很低，而且完全操之在你——這個檔案小到可以在一個下午內用筆電評估完。但對 Clef 來說則不然：要重現 209 毫秒的中位數，需要 Cloudflare 使用的硬體，以及沒有任何 Cloudflare 以外的人組建過的那種狀態。這種不對稱——勝過兩份規格中的任何內容——才是你這個月要以這兩者中的哪一個為規劃核心時，應該依據的關鍵。