vLLM 上的 LFM3-1.7B：九天過去，原生支援仍只是兩個待合併的 PR

Liquid AI 的LFM3-1.7B於 2026 年 10 月 27 日推出，其模型卡把 vllm serve "LiquidAI/LFM3-1.7B" 印得像是普通指令一樣。九天後，上游 vLLM 卻沒有 Lfm3ForCausalLM 架構可以執行它。取而代之的是：10 月 30 日開啟的一項功能請求、一個其他所有項目都依賴其上的 kernel pull request，以及六個仍開啟的模型 PR——其中兩個以兩種不同方式實作同一個 LFM3-1.7B 文字模型，且兩者都尚未合併。

那個落差就是這裡的全部重點，而且它很窄。模型是真的，也下載得到；執行階段支援則是一條佇列。這是一篇關於這條佇列的「目前所知」文章：哪些正在進行中、今天實際能跑的是什麼，以及在模型卡上「可與 vLLM 搭配運作」要成為部署計畫所需的那種意義上的事實之前，還必須先完成哪些事。

卡片上寫的是 vLLM。支援模型表上寫的是 LFM2。

vLLM 自身支援的模型文件列出了三個 Liquid AI 架構：{{1}}Lfm2ForCausalLM{{/1}}、{{2}}Lfm2MoeForCausalLM{{/2}} 和 {{3}}Lfm2VlForConditionalGeneration{{/3}}。其中並沒有 LFM3 的條目。另一方面，LFM3-1.7B 的模型卡指出，該檢查點「可搭配 vLLM、SGLang 以及相容於 LFM3 的 llama.cpp 版本運作」，並提供了一個未附加任何旗標的服務指令。

協調的關鍵在於檢查點本身的設定。LFM3-1.7B 帶有一個 auto_map，指向其隨附的 modeling_lfm3.py，因此 Hugging Face 端的程式碼確實存在，並會自我複製到允許遠端程式碼的載入器中。vLLM 針對這次移植的追蹤 issue #64645——「[Feature]: Support LiquidAI LFM3 models」，由 abhijithneilabraham 於 10 月 30 日開設——直言其後果：「vLLM 沒有 Lfm3ForCausalLM。」其列出的替代方案，是多數人這個月最終會採用的變通做法：「透過檢查點的遠端程式碼，搭配 Transformers 後端來執行 LFM3。這會放棄分頁式注意力與 conv 狀態快取。」

這個取捨值得直說，因為「跑在 vLLM 上」和「跑在 vLLM 的 transformers 後端上」是兩種不同的產品。Paged attention 是讓 vLLM 能批次處理長度差異極大的請求、又不浪費 KV 記憶體的機制；conv state cache 則是同樣的概念套用到這個架構的短卷積層。把這兩者都拿掉，你得到的是一個可運作的端點，但它已經放棄了 vLLM 存在的兩大理由。對於以低併發服務的 1.7B 模型來說，這或許是個可接受的週末專案，卻不是可接受的生產形態。

為什麼一個 1.7B 模型還需要做 kernel 工作？

LFM3-1.7B 並非對 vLLM 已支援的 LFM2 系列進行單純的重新調校。它是一個二十四層的混合架構，包含三種層類型，而非兩種：13 個門控短卷積層、5 個視窗大小為 256 個 token 的滑動視窗注意力層，以及 6 個全注意力層。該檢查點的設定檔明確列出其幾何參數——conv_L_cache: 7、sliding_window: 256、128K 詞彙表——而 vLLM issue 本身列出的差異還包括 QK RMSNorm、每頭 sigmoid 注意力輸出閘門、三明治正規化，以及全注意力層上的部分 RoPE（partial_rotary_factor: 0.5），並採用與 Gemma 4 相同的零尾配置形式。

弄壞 port 的數字是七。LFM2 的短卷積寬度是三個 tap；LFM3 把它加寬到七個。vLLM 的 Triton causal_conv1d 核心會展開一組固定寬度，而正如追蹤 issue 所言：「Triton causal_conv1d 的 prefill 核心展開寬度 2 到 4，decode 核心展開 2 到 6，因此寬度為 7 的模型目前無法在 CUDA 上執行。」

所以堆疊中的第一個 PR 根本不是模型。#64647，〈[Kernel] Support width-7 causal conv1d〉，由 abhijithneilabraham 於 10 月 30 日開啟，涉及兩個檔案、新增 186 行：它把 prefill kernel 從寬度 2–4 擴展到 2–7，並把 decode kernel 從 2–6 擴展到 2–7，同時讓兩個 wrapper 對超出此範圍的任何值拋出 ValueError。該 PR 自己的說明解釋了為何拒絕和擴展同樣重要：在這次變更之前，「較寬的權重會在沒有對應分支的情況下執行，並回傳錯誤的值。」無聲的數值損壞比直接拒絕更糟，而且這種問題只會在你碰巧試用的那個模型上才顯現出來。

有一個注意事項值得與那個 PR 一起說明。其作者明確表示，他們沒有 CUDA 機器：CPU 參考路徑通過了 96 項測試，Triton 核心則是透過對核心 AST 進行靜態分析來檢查，而 GPU 驗證則留給 CI。這是誠實的揭露，而非缺陷，但這意味著其他每個 LFM3 PR 都依賴的那一項變更，尚未在大多數讀者將用來執行它的硬體上經過驗證。

同一文字模型的兩種實作

在六天內，兩個各自獨立的團隊分別為 vLLM 撰寫了原生 LFM3 支援。它們並非同一個修補程式的變體；而是恰好安裝了相同架構名稱的獨立設計。

PR #64959，〈[Model] Add LiquidAI LFM3 (Lfm3ForCausalLM)〉，由 atmikshetty 於 11 月 1 日開啟，是較保守的那個：共七個檔案，且根據其自身描述，它重複使用寬度 7 的 ShortConv、Lfm2MLP、LFM2 權重映射器與現有的比例 RoPE，未變更任何核心元件。它將模型註冊到註冊表，將其加入混合模型測試集與支援模型表，並且——對任何讓它跑起來的人來說很有用——記錄了它驗證時使用的 serving 旗標：--reasoning-parser qwen3 --tool-call-parser qwen3_coder --enable-auto-tool-choice。其驗證章節報告：在 A100-SXM4-40GB 上以 BF16 執行時，324 項核心測試通過、註冊表與初始化測試通過，以及與 Hugging Face 遠端程式碼參考實作的對數機率比較。

PR #65826「[Model] Add LFM3-Text」由 paulpak58——也就是 Liquid AI——於 11 月 5 日開啟，是廠商自家的版本：共十個檔案、新增 829 行，包括位於 transformers_utils/configs/lfm3.py 下自己的 config 類別，以及自己的測試模組。它最初以「[Model] Add LFM3」開啟，並在同日該系列被拆成四個堆疊式 PR 後重新命名：#65826 用於文字、#65827 用於視覺語言、#65828 用於音訊、#65829 用於全模態，每個都建立在前一個之上。

兩者與其說是衝突，不如說是並行，而討論清楚展示了依賴關係網。在 kernel PR 上，paulpak58 於 11 月 4 日寫道：「我們有自己的 LFM3 模型內部 PR，但這是一個我們可以支持的乾淨新增。」在社群文字 PR 上，abhijithneilabraham 提出合併可能得先合併 Liquid 的 transformers 工作——「我相信這個 PR 的合併需要 @paulpak58 的 transformers PR」——atmikshetty 回覆說 Lfm3Config 尚未進入 transformers 發行版，因此該分支「透過 trust_remote_code 從檢查點載入設定，執行時則使用原生 vLLM 模型。」這就是大多數讀者不會想到的第二道關卡：即使是已合併的 vLLM PR，也需要一個有地方發佈的設定類別。

在 transformers 這邊，對應的 PR 是 #50322，標題為「[Model] LFM3 Family: LFM3-Text」，於 11 月 3 日開啟，目前仍處於開啟狀態，是從一個更大的家族 PR 拆分出來的。它本身關於卷積的說明與 vLLM issue 相符：短卷積「在 LFM3 中僅使用 torch（Hub 的 causal_conv1d 核心支援寬度 2-4，LFM3 使用 7）」。

視覺語言部分也在重複。除了 Liquid 的 #65827 之外，一個獨立的 LFM3-VL PR（#65450，於 11 月 3 日開啟）仍處於開啟狀態，並依賴社群文字 PR。因此截至今天，兩個陣營共有六個開啟的 LFM3 PR，且沒有任何一個已合併。

現今實際運作的是什麼

撇開臆測，11月5日的實際情況看起來是這樣。

• vLLM，原生支援——在標準版本上不可能。登錄檔中沒有 Lfm3ForCausalLM，支援模型表中也沒有 LFM3 這一列，而原本會加入它的 PR 尚未合併。

• vLLM、transformers 後端 — 官方文件記載的替代做法，使用檢查點內附的遠端程式碼與 trust_remote_code。你會失去分頁注意力（paged attention）與卷積狀態快取（conv state cache）；但可保留 OpenAI 相容伺服器。

• SGLang——廠商自家的伺服器路徑。Liquid 的發布文章中，其吞吐量數據是在單張 NVIDIA B300 上以 BF16 搭配 SGLang 測得，其中包括在 1,024 個並行請求下每天 36 億個 token。vLLM 在該文中僅作為提供競爭模型服務的執行環境出現。

• llama.cpp — 這張卡提到「LFM3 相容的 llama.cpp 版本」，這是實質的限定條件，而非樣板文字；Liquid 的裝置端數據是 llama.cpp 在 Q4_0、32K 上下文下的結果。

• MLX — 另一個獨立的 vLLM-Metal 專案在 0.33.0 版發行說明中列出了 LFM3 文字 MLX 檢查點，需搭配 --trust-remote-code 使用。那是與上游 vLLM 不同的程式碼庫，並不代表支援 CUDA。

• Hosted — Liquid 自家的 API 與遊樂場。這張卡片沒有提供費率表，因此無法從公開資料估算每 token 的成本來做預算。

兩個數字讓自架的主張更具體。權重小到記憶體並非限制——Liquid 聲稱在 4 位元下約需 1 GB——而廠商表示，128K token 的上下文大約要 1.6 GB 的 KV 快取。真正的限制在於服務堆疊，而不是 GPU。

按順序來說，什麼會改變這一點？

這條依賴鏈異常乾淨，也讓值得關注的重點異常明確。首先 #64647 必須合併，因為其他每個 LFM3 PR 不是包含該 commit，就是疊在它之上。接著，兩個文字 PR 之一必須在審查中勝出——社群版有更完整的驗證紀錄，Liquid 版則有同時負責 transformers 端的作者。然後 Lfm3Config 必須進入 transformers 的正式發行版，否則每個部署都仍得傳入 trust_remote_code。唯有如此，LFM3-VL-2B、LFM3-Audio-2B 和 LFM3-Omni-2B 才變得現實可行，而它們還卡在後續 PR 之後，那些 PR 都假設文字模型已經納入。

這一切都不應被解讀為對節奏的批評。從發布到完成一套經過測試的完整 kernel 加模型 PR 堆疊只花了九天，這已經很快；而兩個獨立團隊在一週內就做出可運作的實作，這更能說明 LFM3 與 LFM2 有多接近，而不是說明有任何延遲。但模型卡是一種相容性聲明，而對 LFM3-1.7B 目前狀態的誠實解讀是「可透過 transformers 後端與 vLLM 相容」，而不是「受 vLLM 支援」。

如果你這週需要一個小型工具呼叫模型

LFM3-1.7B 是個很吸引人的目標。它廠商回報的數字，正好在小模型通常會失手的項目上表現強勁——BFCL V4 為 71.39、ToolSandbox 為 80.36、IFEval 為 96.66、SWE-bench Verified 為 43.40——整體平均為 49.37，Liquid 稱其領先自家 LFM2.5-2.6B 的 31.55。這些都是廠商自家的評測，由打造該模型的公司執行，沒有獨立重現，截至今日我們也找不到任何 Artificial Analysis 的收錄；請把這個排名當成假設，把個別數字當成宣稱。附帶的警語也來自同一來源：模型卡建議不要用於代理式編碼與複雜的多步推理，而知識類基準也呼應這項建議——GPQA Diamond 的 63.37 與 128K 下 RULER 的 65.56，並不是通才模型會有的數字。

所以這個決定其實不在於模型本身，而在於你是否負擔得起建立在目前還是一個尚未合併的 pull request 的推論服務路徑上。如果你能執行 SGLang 或 llama.cpp，你今天就能使用 LFM3-1.7B，而 vLLM 的問題就只是學術問題。如果你的技術棧依政策必須使用 vLLM，那你就是在 transformers 後端缺少 paged attention 與等待之間做選擇。

對於無法等待的工作負載，還有第三個值得點名的選項：改為路由其他東西。OrcaRouter 並未提供 LFM3-1.7B——今天查詢我們的目錄會回傳超過 200 個模型 ID，其中沒有 Liquid 的——所以這不是要推銷透過我們來呼叫它。更簡單的重點是：一個尚未合併的核心 PR，對生產路徑而言是很糟的單點故障。以單一 API 和自動容錯移轉來前置代理託管模型，代價只是改一項設定，還能讓你在其原生支援合併的那天換入 LFM3-1.7B，而不是在你完成押注它的那天。如果你是要修改模型，而不只是呼叫它，我們自己的 LFM3-1.7B-abliterated 版本是對相同檢查點所做的拒絕方向消融，而且它正好繼承了這個服務處境。

簡短版本

LFM3-1.7B 已推出，規模小，非常適合它受訓所針對的單輪工具呼叫工作。它的 vLLM 支援目前正由兩個團隊撰寫，建立在一個核心擴充之上，而該擴充的作者尚未在 CUDA 上執行過它。先關注 #64647——當寬度為 7 的卷積合併後，其餘技術堆疊會迅速推進，模型卡上的「可與 vLLM 搭配運作」就不再是關於遠端程式碼的陳述，而開始是關於分頁注意力與批次處理的陳述。在那之前，任何引用此模型「首日 vLLM 支援」的人，引用的都是該儲存庫尚未包含的內容。