SingVL_S1_4B 對比 LFM2.5-VL-3B：機率對抗段落

問SingVL_S1_4B是否勝過LFM2.5-VL-3B，本身就是個不成立的提問；而最快浪費一週的方法，就是照樣去回答它。這些模型中，一個會針對影像寫出成段文字；另一個則只會為你交給它的每個選項回傳機率，從不自己吐出任何一個字。這個差異不是能在排行榜上分出高下的品質差距。它決定你的哪些管線可以使用哪個模型，而且是在查閱任何基準測試之前就決定了。所以，誠實的比較要反過來做：先從你的程式碼需要收到什麼開始，再看哪個模型能產生它。

兩種不同的傳回型別

Liquid AI 的 LFM2.5-VL-3B 是一般意義上的視覺語言模型。給它一張圖片和一個問題，它就會逐個 token 生成答案，這表示它能描述場景、進行多輪對話、呼叫函式、轉錄一頁文字並附上版面標註，或為你指名的物件回傳邊界框。它於 2026 年 8 月 12 日發布，以 LFM2.5-2.6B 語言主幹為基礎，搭配 SigLIP2 NaFlex 視覺編碼器，並明確主打裝置端部署——在 Apple M5 Max 上以低於 3.3 GB 的記憶體達到每秒 228 個 token，且除了原生檢查點外，也同步發布 GGUF、ONNX 與 MLX 版本。

inclusionAI 的 SingVL_S1_4B 於 2026 年 11 月 11 日悄然上傳，只做一件事，而且是在單次前向傳遞中完成。你給它一個狀態——文字、JSON、最多四張圖片——以及一個具名問題的字典，每個問題都宣告一種類型（選擇題、標籤為「noul」的是/否，或 2 到 10 級的有序分數）及其候選答案。它會回傳每個候選答案的機率。沒有取樣步驟、沒有溫度要設定、也沒有輸出要解析。模型卡本身從頭到尾都以這套詞彙撰寫，連 API 範例也不例外。

如果你的端點需要回傳「這張發票來自 Acme，日期為三月，總額 1,240.00」，LFM2.5-VL-3B 做得到，而 SingVL_S1_4B 做不到。如果你的端點需要 {"is_invoice": 0.97, "quality": {"1": 0.02, "2": 0.11, "3": 0.87}}，情況則相反。這就是整個決策，而以下所有內容都圍繞著它的邊界。

規格表，並排顯示而不使用表格

• 參數 — SingVL_S1_4B 在 BF16 下約為 4.54B，分佈於兩個分片、總計 9.1 GB；LFM2.5-VL-3B 則為 3.1B，其語言主幹為 2.6B。

• 輸出 — SingVL_S1_4B 透過單次前向傳遞回傳各選項的機率；LFM2.5-VL-3B 則回傳生成的文字、工具呼叫或結構化版面標註。

• 背景 — SingVL_S1_4B 僅處理文字時可接受 65,536 個輸入 token，但一旦附加圖像便降至 10,000；LFM2.5-VL-3B 則宣稱端到端支援 32,768 個 token。

• 每次請求的影像數量 — SingVL_S1_4B 上限為四張，每個影像的處理器上限為 1,806,336 像素；LFM2.5-VL-3B 接受單張與多張影像輸入，並將大尺寸影像切割成 512×512 區塊外加一張縮圖。

語言 — LFM2.5-VL-3B 列出十五種，從阿拉伯語到越南語；SingVL_S1_4B 的模型卡則完全未宣稱支援任何語言。

• 授權條款 — LFM2.5-VL-3B 依 LFM Open License v1.0 發布，其量化衍生版本已流通在外；SingVL_S1_4B 則未附授權欄位，也沒有 LICENSE 檔案。

• 部署 — LFM2.5-VL-3B 提供原生、GGUF、ONNX 與 MLX 建置版本，另有 WebGPU 示範，以及 vLLM、SGLang 與 llama.cpp 途徑；SingVL_S1_4B 則是指複製該儲存庫，並在 8173 連接埠執行其專屬的 FastAPI 伺服器。

生態系 — LFM2.5-VL-3B 自八月起便已在 Hub 上架，並已獲得社群的量化版本與移植支援；SingVL_S1_4B 在撰寫本文時才剛發布一天，下載次數為零。

其中兩行比表面上看起來更具決定性。授權條款那一行是第一項：沒有授權條款的儲存庫，不授予任何人重新散布或出貨的權利，而「廠商還沒說」並不是你能放進合規審查裡的許可。部署那一行是第二項：能在手機上執行的 ONNX 建置版本，與期待 CUDA 裝置的 Python 伺服器，無論參數量怎麼說，都不是在競逐你架構中的同一個位置。

為什麼基準測試的數字不能相減

{{1}}兩張卡片{{/1}}都在名稱重疊的資料集上回報分數，而這種重疊是個陷阱。{{2}}SingVL_S1_4B{{/2}} 在 RealWorldQA 上回報 82.17、BLINK 上 72.11、MMMU-Pro vision 上 50.17，以及 InfographicVQA 上 96.31。{{3}}LFM2.5-VL-3B{{/3}} 在 RealWorldQA 上回報 73.1、BLINK 上 61.5、MMMU Pro 上 30.5，以及 ChartQA 上 81.3。{{4}}並排放在一起，看起來像一場潰敗。但這完全不是在做任何比較。{{/4}}

第一個原因是作答模式。每個 SingVL_S1_4B 數值，都是先對一組提供的選項評分，再取機率最高者而產生；這本質上比生成自由形式答案、再讓評分者比對來得容易。Decision Index 衡量的正是這一點，也明白指出：其分數已針對猜測機率校正，因此猜測不計分，但模型仍然完全不必產生字串——只需排序別人寫好的候選項。生成式模型從零開始回答同一個問題，為了在圖表上得到同一點，付出的是更多工夫。

第二個原因在於執行者是誰。這兩組數據都是廠商自行報告，且各自使用廠商自己的評測框架。兩者都尚未被中立實驗室重現。SingVL_S1_4B 還推出僅一天，且尚未向 Decision Index 的公開重現工具包提交任何內容——卡片裡附有製作一份重現的說明，這表示有意圖，卻什麼也證明不了。LFM2.5-VL-3B 則已經讓人們跑了三個月，這不等同於經過審核的數字，但確實意味著它的數據至少曾被陌生人看過。

第三是版本漂移。LFM2.5-VL-3B 自家的模型卡將其 OCRBench v2 數值標註為僅限英文子集。SingVL_S1_4B 的 InfographicVQA 列是在一個有其自身正規化的套件內報告的。兩個資料集名稱相同但子集不同的數字並不是同一個數字，誠實的做法是停止將它們相減。

效率主張僅屬於單方。

LFM2.5-VL-3B 的主打賣點不是準確度，而是在記憶體上限內的吞吐量：低於 3.3 GB，在 M5 Max 上每秒 228 個 token，在 Ryzen AI Max+ 395 上每秒 116 個，在 Galaxy S26 Ultra 上每秒 20 個。最後一個數字對產品設計至關重要，因為它決定了功能是在裝置上執行，還是需要往返伺服器。SingVL_S1_4B 儲存庫中沒有任何可比的宣稱，也沒有可用來做出這種宣稱的量化版本——你拿到的是 BF16 分片和一個伺服器指令碼。

反面來說，單次前向傳遞具有生成式模型無法比擬的成本結構。為一個問題對四個選項評分只需一次傳遞；生成 200 個 token 的描述則需要 200 次循序傳遞。如果你的任務確實是分類——這份文件是不是收據、這個畫面是否包含人物、這個刊登內容是否合規——SingVL_S1_4B 的設計應該讓每次決策更便宜，而且它回傳的是一個校準過的數值，可讓閾值據以採取行動，而不是一句還得靠解析器才能存活的句子。這項優勢是結構性的，不取決於廠商的基準測試是否正確。它同樣尚未被實驗室以外的任何人測量過，因此請把它視為一項預期，而非事實。

查明真相的代價

LFM2.5-VL-3B 今天下午就能在筆電上評估。MLX 版本可在 Apple silicon 上執行，GGUF 版本可透過 llama.cpp 在 CPU 上執行；如果你想在下載任何內容前先看看，也有託管的 playground 可供試用。切換成本只是設定檔中的一個模型識別碼，而風險有限，因為權重已取得授權，且格式是標準的。

SingVL_S1_4B 需要一張 GPU 和一個下午的設定時間。你需要 Python 3.12、與你的顯示卡相符的 PyTorch 建置版本、該儲存庫自身的需求，以及一個免費連接埠。伺服器只提供單一路由——POST /v1/systemone——並使用扁平 JSON 內容，對於研究產物來說，這異常容易接上；而模型卡也提供了可用於文字與圖片請求的 curl 範例。你無法做的是把既有的 OpenAI 形式用戶端指向它，因為它並不是那種形式。這個端點是為 Decision Index 評估套件設計的，而該套件也是為它設計的。

這種不對稱性正是「我該先試哪一個」的實用答案。如果你尚未確認一個會回傳機率的模型對你的流程有幫助，那麼成本低廉的實驗，就是拿這個模式去對照某個已經在提供服務的對象。OrcaRouter 以每百萬輸入 token 0.042 美元的價格提供 TypeSafe Jev 1.14，只需一組金鑰，這是一個可實際運作的決策端點，讓你在一小時內用自己的任務對它做基準測試，無需自行託管檢查點，也無需呈報處理授權問題。SingVL_S1_4B 並未在那裡提供——它完全沒有託管供應商——因此你今天真正能做的比較是「型別化決策評分是否能在我的資料上勝過生成」，而不是「這個特定的新檢查點是否勝出」。在花錢處理第二個問題之前，先取得第一個答案。

每個所屬之處

• 你必須閱讀並引用的文件——LFM2.5-VL-3B。它會產生轉錄內容，並附上版面標籤，而它的 OCR 列是真正的能力，而非分數。

• 螢幕、表單與 GUI — LFM2.5-VL-3B。ScreenSpot-v2 達到 80.7，而相較於前一代在 grounding 方面的改進，正是本次發布的重點。

• 任何能在手機或筆記型電腦上執行的——LFM2.5-VL-3B，而且毫無懸念，因為替代方案需要伺服器。

• 在昂貴呼叫前面加一道閘門——兩者皆可，而若能自行架設，SingVL_S1_4B 的形態更合適，因為閘門需要的正是一個機率。

• 固定分類體系上的多標籤分流——原則上可使用 SingVL_S1_4B。其選擇題與評分題型可直接對應到分類體系，而生成式模型則必須透過提示與後處理，將其約束回單一分類體系。

• 內容審核——並非毫不費力。SingVL_S1_4B 自己的說明卡顯示，套用技能提示後，其仇恨迷因那一列從 71.64 跌到 43.28，這正好警告了提示敏感度問題，而這類問題在偽陰性代價高昂的領域中尤其關鍵。

• 本季商業部署——LFM2.5-VL-3B，僅以授權理由為依據。

仍未測量的部分

真正有意思的問題不是哪個模型更好，因為它們並不在同一場競賽中；而是：一個訓練在視覺骨幹之上的 45 億參數分類器，能否在只需一個標籤和一項置信度的狹窄任務切片上，匹敵通用視覺模型。若能，許多管線的成本結構就會改變，因為單次前向傳播與生成一段文字是不同量級的開銷。目前 inclusionAI 之外無人知曉——該儲存庫才發布一天，授權條款空白，基準測試也是實驗室自家的。

同時，通用模型已經可用、已授權、已量化、有文件，而且快到能在手機上執行。當團隊問起該把其中哪一個投入生產時，目前的答案就是那個無趣的選項，而有趣的那個，則是附帶一個程式碼儲存庫的假設。