LFM3 與 Qwen3.8-27B：16 倍規模差距，在指令遵循上縮小至 9%

LFM3-1.7B 擁有 17.3 億個參數。Qwen3.8-27B 則有 277.8 億個，外加一個視覺編碼器——權重是前者的 16.1 倍。把它們放上同一張基準測試成績表，算術結果就怎麼也不肯按常理走。在 IFBench 上——該測試檢驗模型是否遵守它從未微調過的約束——兩者差距不到百分之九。在 Terminal-Bench 2.1 上，則是 5.6 倍。兩個模型、一個固定的規模差距，結果卻會隨著你看的是哪一列，從「你怎麼會想花錢用大的那個」擺盪到「小的那個根本做不到這件事」。

那個落差就是整個決策的關鍵。這不是一則關於小型模型追上大型模型的故事，也不是一則關於大型模型被浪費在小型工作上的故事。它是一則關於任務界線的故事，而這條界線非常一致地落在遵循指令與執行計畫之間——同時也是一則關於授權條款的故事：對任何任職於營收超過某個門檻的公司的人來說，這項條款會悄悄重新排列價格比較的結果。

這些各自實際上是什麼

Liquid AI 宣布 LFM3 系列於 2026-10-27——就在本文撰寫的前一天——推出六個約 2B 級別的開放權重模型，皆從共享的 LFM3-1.7B-Base 主幹分支而來。LFM3-1.7B 是其中的文字模型：採用三重混合架構，共 24 層（13 層閘控短卷積、5 層滑動視窗注意力層，視窗大小為 256 個 token，以及 6 層全注意力層），以 22 兆個 token 進行預訓練，並在最後進行 3.5 兆 token 的中期訓練階段，其中包含代理軌跡與工具呼叫。權重已發布於 Hugging Face，Ollama 以 lfm3:latest 形式提供，下載大小為 1.7 GB，而廠商自家的模型卡建議不要用於代理式程式設計或複雜的多步驟推理。最後那句話比模型卡上任何其他內容都更重要，我們之後會再回來討論它。

Qwen3.8-27B 並不新。阿里巴巴已於 2026 年 8 月中旬在 Apache 2.0 授權下發布其權重，至今已有十週時間累積下載量、量化版本與真實使用者回報，這些都是發布僅一天的版本所沒有的。它是一個 27.78B 的稠密模型，建立在由 Gated DeltaNet 與 Gated Attention 層構成的重複區塊上，深度達 64 層，原生支援視覺與影片輸入，並具備 262,144 個 token 的上下文，可透過 YaRN 延伸至 1M。思考功能預設開啟，並可透過推理力度設定調整。

坦白說，這組配對的定位本質上是不對稱的，而這點很重要：一個模型有廠商基準測試表，卻沒有實地報告；另一個兩者都有。以下關於 LFM3-1.7B 的任何內容，都應視為對 Liquid AI 測試套件的陳述，而非對你的工作負載的陳述。

小模型不會落敗的那條規格線

先從那些即使參數增加 16 倍也完全沒有幫助的維度談起，因為這類維度比規模差異所顯示的還要多。

• 上下文視窗 — 兩者原生皆為 262,144 個 token。LFM3-1.7B 於中期訓練時達到此長度；Qwen3.8-27B 原生即具備，並可透過 YaRN 擴展至 1M。

• 語言 — LFM3-1.7B 宣告支援 16 種語言（包括英文、中文、日文、韓文、阿拉伯文與印地語）；Qwen3.8-27B 則廣泛接受多種語言訓練，但未公布總數。

• 模態 — LFM3-1.7B 是文字進、文字出；Qwen3.8-27B 則是文字、圖像與影片進，文字出。這是 27B 唯一在做本質上截然不同工作、而非把同一份工作做得更大的地方。

• 4 位元下的記憶體用量 — LFM3-1.7B 約需 1 GB，而 Qwen3.8-27B 則約需 14–16 GB。

• 以 BF16 計算的記憶體用量為 3.46 GB，相較之下約需 56 GB，這正是筆記型電腦與多 GPU 主機之間的差距。

• 授權條款 — LFM Open License v1.0 相較於 Apache 2.0。請先記住這一點。

兩邊都有 256K 的上下文視窗，才是真正令人意外的重點。上下文長度歷來都與參數量同步，而在這裡，一個只需約 1 GB 就能跑的模型，竟提供和一個需要工作站才能跑的模型相同的名目視窗。「名目」在這句話裡可是有實際份量的——1.7B 模型上的 256K 視窗，只有在模型真能在其中找到東西時才有用，而那正是下方長上下文測試列要檢驗的事。

當參數增加 16× 只換來百分之九

Liquid 執行了一套 27 列的測試套件，並公布了完整表格，包括競爭對手勝出的欄位。IFBench，這是整個比較中最乾淨、可直接對比的列，因為它是由兩家廠商共同回報的單一基準版本。

LFM3-1.7B 得分 73.03。Qwen3.8-27B 得分 79.5。兩者相差 6.5 分，不到較大模型分數的百分之九——而這個模型的規模小了 16.1 倍。對於一個主要只是「接收這些雜亂輸入、輸出這個精確的 JSON 結構、絕不破壞 schema」的工作負載而言，這樣的差距幾乎等同於雜訊，而部署上的差異則是 1 GB 對上 16 GB。

Liquid 自家的表格針對更接近的競爭對手也說明了同一點。面對 Qwen3.5-9B——一個規模是 LFM3-1.7B 五倍的模型——這個小模型在 IFBench 上以 24 分勝出（73.03 對 48.84），在 IFStruct 上以 4.5 分勝出（93.72 對 89.20），在 Multi-IF 上以 4.7 分勝出（89.10 對 84.44）。無論其他情況如何，指令遵循並不是一種會隨參數數量平滑擴展的能力，而一個訓練良好的 1.7B 可以在這方面擊敗一個平庸的 9B。

長上下文的那幾行較為模稜兩可，值得如實說明，而不是往 Liquid 有利的方向四捨五入。在 AA-LCR 上，LFM3-1.7B 拿下 52.83——以它的規模而言是實打實的分數，且大致與 Qwen3.5-4B 的 52.67 持平。在 RULER 128K 上它得分 65.56，遠超 MiniCPM5-2B 的 37.96，但遠落後於 Qwen3.5-9B 的 87.11。所以 256K 視窗並非裝飾，但也不等同於更大模型的視窗。Qwen3.8-27B 根本沒有出現在那張表中，這意味著針對這一特定配對並沒有同類可比的長上下文數字——只有一個強烈的先驗判斷：原生 262K 的 27B 會勝過名義視窗相同的 1.7B。

當 16× 的參數換來五倍半

現在來看模型卡所警告的那些資料列。這裡的每一列都是雙方廠商都有回報的基準版本，因此不會出現跨版本相減的情況。

• Terminal-Bench 2.1 — LFM3-1.7B 為 12.92，Qwen3.8-27B 則為 73.0。相差 5.6 倍。

• Humanity's Last Exam，不使用工具 — 7.17 對 30.8。4.3 倍的差距。

• GPQA Diamond — 63.37 對比 89.2。1.4 倍的差距。

• LiveCodeBench v6 — 73.46 對比 90.3。1.2 倍的差距。

那份清單的排序本身就是發現所在。差距在單次程式碼生成上最小，LFM3-1.7B 的表現約比一個規模為其十六倍的模型低 19%。差距在 Terminal-Bench 上最大，因為那里的任務不是「撰寫程式碼」，而是「在多個步驟中操作一台機器、從自身錯誤中復原，並在工作完成時停止」。這正是 Liquid 自家模型卡指出該模型所缺乏的能力，而數字也與模型卡一致。在 GPQA 和 HLE 上，差距在於知識，這是這裡最不令人意外的結果——一個以 22T token 訓練的 1.7B 模型，見識就是比一個以更多資料訓練的 27B 模型少，再多的架構設計也無法彌補。

有一列的走向正好相反，而它是兩張卡片上最耐人尋味的數字。在 AA-Omniscience 的公開分割上，LFM3-1.7B 錄得 7.07 的準確率與 92.93 的非幻覺率。這組數字意味著該模型多數時候選擇不作答，而非答錯。這是 Liquid 自家比較表中最高的非幻覺數字，領先表上所有更大的模型。Qwen3.8-27B 在 HLE 上的 30.8 則是截然相反的姿態：它懂得更多，也更敢於篤定作答。

如果你的管線的失敗模式，是「一個自信滿滿的錯誤數值落進資料庫」，那麼一個有 93% 時間選擇棄答的模型就是一項特性，而準確率天花板就是必須付出的代價。如果你的管線的失敗模式，是「本該有數值的地方卻出現 null」，那麼同樣的行為就是 bug。這正是這場對決所繫於的最關鍵一點，而沒有任何總體分數能捕捉到它。

三個你絕不能減去的數字

針對這組對決的正面交鋒頁面，往往會忍不住把兩家廠商公布的每一項基準測試數據並排列出。但其中有三項數據經不起方法論的檢驗。

SWE-bench。Liquid 報告 LFM3-1.7B 在 SWE-bench Verified 上以 OpenCode 測試框架達到 43.40。阿里巴巴報告 Qwen3.8-27B 在 SWE-bench Pro。不同的基準測試、不同的測試框架、不同的任務分佈。這兩個數字之間 18 分的差異，並不能用來衡量任何事物。如果你想要了解差距的大致輪廓，請使用 Terminal-Bench 2.1，兩者在該基準上都報告相同的版本。

任何彙總指數。Artificial Analysis 在 xhigh 推理設定下，將 Qwen3.8-27B 的 Intelligence Index 評為 33.7。截至 2026-10-28，Artificial Analysis 上完全沒有 LFM3 條目。發布僅一天的版本尚未經過獨立評估，而誠實的說法是 LFM3-1.7B 沒有任何經獨立重現的數字。本文中歸屬於它的每一項數字——以及本週其他所有地方——都源自 Liquid AI 自家測試套件、使用 Liquid AI 自行選擇的基準。

推理投入設定。Qwen3.8-27B 公布的分數在低、中、xhigh 與非推理模式之間有大幅變動；33.7 這個指數是 xhigh 的數值，而非推理的數字則明顯較低。任何將 Qwen 的數字與 LFM3 的數字配對、卻未指明推理投入設定的比較，都是在拿一個會審慎思考的模型跟一個快速模型相比，並把差異稱為架構。

能讓這件事真正定論的做法很直接：讓 LFM3-1.7B 在相同的測試框架上，以明確標示的努力設定進行一次獨立執行，最好是在社群取得權重幾週之後。在那之前，公允的總結是：廠商自報的指令遵循差距很小，而廠商自報的多步驟執行差距很大，且這兩項說法都來自同一個有利害關係的當事方。

授權才是真正的價格標籤。

這就是逆轉小型與大型比較之慣常結論的部分。

LFM3-1.7B 以 LFM Open License v1.0 發佈。其權重可免費下載與免費執行，但年營收達 1,000 萬美元或以上的實體不得商業使用。Qwen3.8-27B 以 Apache 2.0 發佈，沒有營收門檻、沒有使用領域限制，也沒有另立協議。

所以，對一間兩人新創公司來說，這筆帳很明顯：一個能塞進一 GB、每個 token 成本為零，且跑在你已經擁有的硬體上的模型，幾乎等於免費午餐。對營收超過一千萬美元的公司來說——也就是說，大多數有值得最佳化的生產推論預算的公司——便宜模型並不免費，而昂貴模型則明確取得授權。看起來像預算選項的那個模型，反而是附帶法律授權討論的模型。

那不是反對 LFM3-1.7B 的論點。那是主張先讀授權條款，再讀基準測試表，因為授權條款決定你究竟能不能取得那張基準測試表。

實際執行每一個需要什麼

LFM3-1.7B 只需一行指令即可安裝。它在 Ollama 模型庫中以 lfm3:latest 和 lfm3:1.7b 提供，兩者都是 1.7 GB 的下載，並宣告具備 256K 上下文視窗，且可在 Transformers 中執行單 GPU 微調。Hugging Face 的發佈內容包含用於 SFT、DPO 和 GRPO 的 notebook，其中包括一個完整範例：訓練模型在手機應用程式中的 108 個工具裡挑選正確的工具。如果你的目標是打造一個小型、專用且經過微調的擷取器，並讓它與資料位於同一台機器上，那麼從下載到部署確實是一條很短的路徑。

Qwen3.8-27B 是不同類型的專案。以 BF16 計算時約 56 GB，需要多 GPU 主機或激進量化；在 4 位元下則可容納於 14–16 GB，屬於高階單 GPU 或規格良好的筆電，而 KV 快取會使實際記憶體用量進一步提高。它可在 Transformers、vLLM、SGLang 與 TokenSpeed 中執行。如果你不想擁有那樣的硬體，也可使用託管版本——在 OrcaRouter 上由兩家上游供應商提供服務，第一家每百萬輸入 token $0.33、每百萬輸出 token $2.40，第二家則為 $0.40 / $4.21。

這兩家供應商之間的價差值得停下來想一想，因為這種情況只有在查看即時目錄、而不是新聞稿時才會出現。相同的權重、相同的上下文視窗，但第二家供應商的輸出價格大約貴 75%。OrcaRouter 以 0% 加成原樣傳遞供應商定價，因此兩邊價格可以並列顯示，而 自動容錯移轉意味著供應商出狀況時會被繞開，不會暴露給你的使用者。如果你正在評估將 Qwen3.8-27B 作為從小模型起步的管線的升級路徑，那就是你會放在單一金鑰後面的那一段。

把另一半說清楚：OrcaRouter 並不提供 LFM3-1.7B 的服務。它是權重下載，而執行它是在你自己的硬體上架設你自己的端點。這篇文章之所以會提到我們，理由在於升級路徑，而不是那個小模型。

誰應該選哪個？

這個決定其實不取決於基準測試表。它取決於兩個你在執行任何東西之前就能回答的問題。

若符合以下情況，請選擇 LFM3-1.7B：工作屬於單回合且受 schema 約束——抽取、分類、路由、結構化輸出、裝置端工具選擇——而且資料不能離開裝置。如果你打算進行微調，它也是正確的選擇，因為一個 1.7B 模型內建 SFT/DPO/GRPO 流程，且只需單一 GPU 預算，會是週末專案而非一季工程。256K 視窗、16 種語言與棄答行為都指向同一個使用情境：一個狹窄、高用量、隱私敏感的元件；在這種元件中，錯誤答案比沒有答案更糟，而且貴公司處於營收線以下。

如果模型必須規劃，就選 Qwen3.8-27B。多步驟代理程式、終端機作業、長時程程式設計，任何模型必須在十幾次工具呼叫中從自身錯誤復原的情況——5.6× 的 Terminal-Bench 差距不是調校問題，而是模型卡在告訴你真相。當你需要的是知識而非格式、需要視覺或影片輸入，以及當 Apache 2.0 是必要條件而非偏好時，它也是正確的選擇。

如果誠實的答案是你的管線有兩半，那就兩者都選。適合這種配對的模式，是先做一輪低成本、本地、受結構描述約束的處理，並在這一輪拒絕時提供升級到 27B 的路徑——這正是設計一個有 93% 時間會棄權的模型所要發出的訊號。這種架構會用到每個模型最好的一列，且不會用到任何模型最差的一列。

什麼會改變這個答案

有兩件事，而這兩件都值得觀察，而不是靠猜測。

第一項是對 LFM3-1.7B 的獨立評估。上述每一項能力宣稱都建立在 Liquid AI 自家的測試套件上，而這個系列中的 Base 檢查點推出時完全沒有附上基準測試表——這告訴你，該系列的數字是後訓練的故事，而不是架構的故事。在 IFBench 與 Terminal-Bench 上進行中立測試，要嘛會證實本文所述的分歧，要嘛會讓它消解。

第二個問題是，Liquid 是否會在這個主幹上推出更大的文字模型。整組比較都建立在 16 倍的參數量差距之上，而指令遵循的結果顯示，訓練配方所發揮的作用比參數量更大。如果中型的 LFM3 真的問世，有意思的問題就不再是「1.7B 能不能遵循指令」——它已經做得到了——而是「這套配方套用到四十億參數上會有什麼表現」。

在上述情況之一發生之前，有用的總結比計分板還狹隘：LFM3-1.7B 是真正優秀的指令遵循者，卻不會規劃；Qwen3.8-27B 則是真正優秀的規劃者，其授權條款足以讓你創辦一家公司。在兩者之間做選擇，不是基準測試的問題，而是這兩個句子中哪一句更能描述你的工作負載的問題。