PAN 2 對比 LFM2.5-2.6B-Base：兩種專為微調而設計的檢查點

關於 LFM2.5-2.6B-Base，首先會注意到的是「Base」這個詞。Liquid AI 這個 26.9 億參數的檢查點並不是讓你拿來聊天的模型；它是預訓練基底，後訓練的 LFM2.5-2.6B 變體皆由此製作，並公開發布，好讓其他人能做出自己的版本。PAN 2 則是同一類物件放大三十倍：一個來自 MBZUAI 的 Institute of Foundation Models、具 290 億參數的擴散 Transformer，以 Apache-2.0 授權發布，訓練設定檔放在儲存庫中，目的是供人改編，而不只是拿來使用。把它們並排一看顯得荒謬——一個是能在筆電上跑的語言模型，另一個則是需要四張 B300 的影片世界模型。但兩者都是附帶授權的基底產物，而對任何實際工作就是拿一個檢查點、讓它去做它未曾受訓去做的事的人來說，真正有意思的比較根本不在能力。而在於各自給你什麼可用的東西，以及在你弄清楚之前，持有這玩意兒要付出什麼代價。

先從授權條款開始，因為這是唯一一項硬性的差異

PAN 2 本身的程式碼與權重採用 Apache-2.0。第三方元件——作為文字編碼器的 Qwen3.5-9B、作為 VAE 的 Wan 2.2、Diffusers——依其各自條款使用，且不由 MBZUAI 重新散布；你需向原作者下載。這是乾淨、乏味、對企業法務友善的安排，也是擁有審查流程的公司能夠採用 PAN 2 的主要原因。

LFM2.5-2.6B-Base 依 LFM1.0 授權條款發布，Hugging Face 將其記錄為 其他，並附上 LICENSE 檔案連結，而非 SPDX 識別碼。這並非批評——Liquid 的授權允許在營收門檻內進行商業使用，這對開放權重發布而言是常見且合理的形式——但它與 Apache-2.0 是不同的形式，而這個差異並非你在微調之後才會發現的細節。若你的法務團隊有一份預先核准的授權清單，這兩款模型中有一款會列在其中，另一款則需要進一步討論。

這種不對稱與參數量多寡的方向正好相反，值得細細思量。擁有字串的是那個小模型；而那個龐大模型，則是你無須徵求任何人同意就能直接部署的。

基礎檢查點實際上究竟能給你什麼

LFM2.5-2.6B-Base 採用混合架構：共三十層，其中二十二層是雙閘控短卷積區塊，八層是分組查詢注意力。這種組合正是 LFM 系列的核心特色——卷積區塊在長序列長度下成本低廉，注意力區塊則負責維持召回能力——這也是為什麼該模型能在 2.69 億個參數下承載 131,072 個權杖的上下文。訓練使用了 34 兆個權杖，詞彙量為 128,000 個權杖，涵蓋十六種語言，包括阿拉伯語、日語、韓語、泰語和越南語。

它所沒有的，是任何後訓練。沒有指令微調，沒有名符其實的聊天模板，沒有安全對齊。基礎模型只預測下一個 token，就只做這件事，這使它不適合在指令遵循基準上評估，卻適合用來評估 LoRA 在你的領域上收斂得有多快。Liquid 另行發布同系列的後訓練版本，而該版本有 GGUF 與 ONNX 組建，這是最清楚表明意圖的聲明：這個模型家族是為了在你擁有的裝置上運行。

PAN 2 給你相當多的輔助架構，但在某個特定方面給你更少的自由。儲存庫隨附預訓練與監督式微調的訓練設定檔——config/pretrain_29B_720p.yaml 和 config/sft_29B_720p.yaml——而文件會告訴你將它們的資料路徑指向你自己的潛在表徵。所以微調路徑確實存在。但它預期的資料不是文字。它是以特定結構化描述格式標註的影片潛在表徵：依序的事件、綁定到行動者的動作、攝影機運動，且必須在文字編碼器 1,536 個 token 的預算內。如果你想在自己的領域上微調 PAN 2，你的第一個專案不是一次訓練作業，而是一條將你的影片素材轉成該格式的資料管線；儲存庫提供你驗證器，但不提供標註器。

• 微調算力 — LFM2.5-2.6B-Base：單一 GPU、在工作站上跑 LoRA，數小時而非數週。PAN 2：一個在 BF16 下、尚未計入優化器狀態就達 67.37 GB 的 transformer，再加上 15.87 GB 的凍結編碼器與一個 VAE，處理影片潛在表徵。多節點，而且還沒有人發表過做法。

• 你必須提供的資料 — LFM2.5-2.6B-Base：文字，格式依你的任務所用而定。PAN 2：影片，加上依該儲存庫結構描述（schema）的結構化世界狀態字幕。

• 你會得到什麼——LFM2.5-2.6B-Base：一個文字生成器，而在後訓練之後，則是一個助理或代理策略。PAN 2：一段最長 20 秒、704×1248、24 fps 的影片，展示某個動作所造成的後果。

• 授權 — LFM2.5-2.6B-Base：LFM1.0、其他，請自行閱讀。PAN 2：其自身權重採用 Apache-2.0。

在他們幾乎持平的那一項基準測試中

確實有重疊，而且規模小得值得注意。OpenBMB 的 MiniCPM5-2B 模型卡將 LFM2.5-2.6B 與自家的 2B 模型及其他多個模型一起做基準測試，其中一列是長上下文。在 AA-LCR 上，OpenBMB 回報 LFM2.5-2.6B 為 5.3，MiniCPM5-2B 則為 59.0。在 NoLiMa 上，是 0.7 對 68.1。在 LongBench v2 上，是 30.3 對 43.7。

那些是競爭對手回報、且出自競爭對手自家評測框架的數字，而發布這些數字的模型卡在這種比較中有明顯的利益關係。但兩項最困難的長上下文探針上的差距幅度，並不是評測框架的選擇所能解釋掉的，而且這有助於糾正把「131,072 個 token 的上下文」解讀為能力宣稱的做法。上下文視窗是一種容量；長文本召回則是一種行為表現。Base 檢查點具備前者，而根據第三方證據，後者並不多——這正是為何預期用途是微調，而不是開箱即用的長文件助理。

PAN 2 沒有對等的交叉檢核。MBZUAI 之外沒有人對它做過基準測試，而模型卡上的數字是唯一存在的數據。這比 LFM2.5-2.6B-Base 的證據地位更弱，即使這個模型的運行成本高出上百倍——這提醒我們，獨立評測會隨著採用而出現，而採用則取決於能否實際運行這個東西。

保留每個檢查點的成本

LFM2.5-2.6B-Base 約有 27 億個參數。在 BF16 格式下，其權重可輕鬆維持在 6 GB 以下，而經過後訓練的同系列模型之 GGUF 版本更將其降至遠低於此。你可以讓它常駐在與你其餘技術堆疊相同的機器上，連夜對它進行微調，然後忘了它的存在。

PAN 2 總計 86.17 GB、橫跨六十個檔案，而真正關鍵的數字不是總量，而是它的形狀。Transformer 本身佔 67.37 GB，且每個推論 worker 都持有一份完整副本——該儲存庫自帶的推論腳本為每張 GPU 執行一個 worker，每個 worker 取用每第 N 個 prompt，因為那條路徑上沒有張量平行分片。vLLM 配方則是分片選項，其亮點是在四張 B300 上，以約 119 秒處理十三秒的 704×1248 影片，其中分類器無關引導平行化橫跨兩個 rank，Ulysses 序列平行化則橫跨兩個。預設配置是八張 H200。五十步取樣器且每一步都啟用引導，意味著每個片段要進行一百次前向傳遞，而這正是配方中每一項配置選擇背後的算術依據。

所以，誠實的成本比較不是「6 GB 對上 86 GB」，而是「每次推論的邊際成本為零，對上每兩分鐘產出就要動用一個多 GPU 節點」。一個微調過的 2.6B 模型回答一次查詢，成本小到無法衡量。微調過的 PAN 2 渲染一段二十秒的短片，則要占用一個 GPU 節點三分鐘，而且在你確定微調是否有效之前，你會跑上數百次。

在路由器接觸到其中任一者的位置

這兩個模型都不是路由層能夠提供服務的對象。LFM2.5-2.6B-Base 是基礎檢查點，沒有值得路由過去的託管端點——它就是一個你下載的檔案。PAN 2 則完全沒有託管端點，無論是 MBZUAI 還是其他任何人都沒有。如果你的計畫涉及其中任何一個，你的計畫就涉及 GPU。

之所以還是要提到路由，是因為幾乎沒有人會單獨部署一個基礎模型。微調後的 LFM2.5 只是應用程式中的一個元件，而這個應用還需要一個通用推理模型；PAN 2 模擬也只是整條流程中的一個階段，其第一階段是由語言模型撰寫結構化說明文字。那個周邊層正是單一 API 能發揮價值的地方，讓你能以單一 API 存取200 多個模型：你可以把微調後的檢查點留在自己的硬體上，將一般性呼叫以供應商定價經由 OrcaRouter 路由，並享有0% 加價轉嫁，還能在供應商暫時出狀況時自動容錯切換。就 PAN 2 流程而言，說明文字階段正是具有彈性的部分——該報告依完整計畫完成率，對 Claude Opus 5.5、GPT-6 Astra、Kimi K3 與 Qwen3.8-Flash 進行排名，而Qwen3.8-Flash 已上架 OrcaRouter，因此你可以測試哪個規劃器真的能完成你的計畫，而不必佈建四個模型。

OrcaRouter 不會做的是託管任何一個檢查點。說它會，就是那種聽起來像功能、實際上卻像 bug 的說法。

「基礎模型」框架所掩蓋的是什麼

這兩個發布版本嚴格來說都尚未完成。LFM2.5-2.6B-Base 依設計並未進行指令微調；PAN 2 的限制章節指出，約三分之二的模擬計畫至少包含一個未執行的步驟。兩者都不是產品。差別在於「尚未完成」在各自情況下所指的意思。

對於 LFM2.5-2.6B-Base 而言，「未完成」只是整條流程中的一個階段，而廠商早已完成其下游環節——經過後訓練的模型已經存在，量化版本也已存在，並且基礎檢查點已公開發布，供想要走不同路線的人使用。這個落差是有意為之，且已有文件記載。

對 PAN 2 而言，未完成是整個發布版本的狀態。權重已經上線，框架支援於 11 月 10 日到位，而公開場合中唯一被提到的相關說法，就是同日下午實驗室自家 X 帳號上的一則兩段貼文。它的限制並不是交給下游使用者的設計選擇；而是團隊正在公開指名的未解問題。如果你微調 PAN 2，你會連同權重一起繼承這些問題。

那才是真正的比較，而它不會歸結為在兩個模型之間給出建議，因為它們並不是替代品。它歸結為一個關於你專案的問題：你是在調適一個已知良好的元件，還是在一個失效模式仍待測量的研究產物上建構？LFM2.5-2.6B-Base 是第一種。PAN 2 是第二種，而 Apache-2.0 授權是第二種甚至能成為選項的唯一原因。