一張生成的標題卡,標題為「Hy-Memory-30B-A3B vs LFM2.5-24B-A2B」,副標題為「兩個稀疏的約 25B 專家模型。其中一款提供 14.5GB 的下載檔案。」兩個標籤分別寫著「Hy-Memory-30B-A3B — 30B / 3B 活躍參數,60.1GB BF16,未發布任何量化版本」和「LFM2.5-24B-A2B — 24B / 2.45B 活躍參數,Q4_K_M 為 14.5GB,131K 上下文」,頁腳則註明兩家廠商的基準測試數據皆為自行報告且未經重現。
Guides & Insights

Hy-Memory-30B-A3B 對比 LFM2.5-24B-A2B:兩個稀疏專家模型,只有一個能在你的機器上運行

作者

Gideon Frost

發佈日期

最新模型 · 20查看全部模型 →
基準測試:Artificial Analysis · 每日更新
返回全部文章

Hy-Memory-30B-A3B 與 LFM2.5-24B-A2B是同一套構想,由兩家對誰將負責運行它意見分歧的公司打造而成。兩者都是總參數量落在 200 多億的中段、每個 token 啟用 20 億至 30 億個參數的稀疏專家混合模型——Hunyuan 團隊的記憶寫入器,總參數 30B、約 3B 啟用,於 2026 年 10 月 15 日開源;Liquid AI 的裝置端代理模型,總參數 24.0B、啟用 2.45B,於 2026 年 10 月 13 日出貨。Liquid 隨全精度權重一同發布了 14.5 GB 的 Q4_K_M GGUF,以及 13.6 GB 的量化感知訓練版本。該團隊則只發布了一個 60.1 GB 的 BF16 檢查點,完全沒有量化替代方案。數字無法告訴你的是,這一切在實際應用中是否出了任何差錯:此類模型相關的已記錄 AI 事故與代理失效,都收錄在 OrcaRouter AI 事故檔案庫,其中每筆條目都附有各自的來源、嚴重程度、信心等級與爭議標記。

這種封裝上的差異並非排程上的偶然,正確解讀它,能讓你對這兩個模型的了解,比任何一張基準測試表都還多。這也正好是這兩者通常被用錯誤理由比較的原因——人們在兩張卡上都看到「小型稀疏 MoE」,就以為它們在競爭同一個部署位置。其實並非如此。一個想進駐你筆電上的代理框架。另一個想進駐你伺服器上的記憶體管道,而這兩項工作幾乎沒有重疊。

他們唯一真正共有的那一點

兩者都是稀疏的。兩者都常駐大量參數,並在每個 token 只讀取其中一小部分。這就是它們在架構上的全部重疊之處;而值得說明稀疏性買得到什麼、買不到什麼,因為在這個規模級別中,這是最常被誤解的性質。

一個 24B-A2B 檢查點無法塞進相當於 24.5 億個參數的記憶體裡。檔案中的每一個參數都必須能被載入;活躍參數數量換來的是每詞元的輸送量,而不是佔用空間。Liquid 自家的說明卡對這點說得很直白——這個模型是 240 億參數的檢查點,而要跑它,就代表得在某處持有 240 億個參數。任何讀到「2.45B 活躍」就去找小機器的人,下場肯定不好過。同樣的道理也適用於 Hy-Memory-30B-A3B 的 3B 活躍參數數字,對照其 60 GB BF16 檔案。

除了那項共有的特質之外,兩者幾乎在所有重要的面向上都大相逕庭。

A screenshot of the Hugging Face file listing for LiquidAI/LFM2.5-24B-A2B-GGUF, showing the Liquid AI org header, 174 likes, tags for Text Generation, GGUF, 10 languages, liquid and lfm2.5_llama.cpp, a file tree on the main branch with 68 files, and a history of two commits including one titled update QAD GGUF.

注意那個儲存庫是什麼。一個發布獨立 GGUF 儲存庫的廠商,正以目前最具體的方式表明:它所提供的模型,就是要讓人下載並在某人已經擁有的硬體上執行。它的提交歷史只有兩筆提交,而且才幾天前而已——這不是事後才硬加在一個已推出九個月的版本上的附帶品。

規格並排顯示,包含包裝列

• 總參數 / 活躍參數 — Hy-Memory-30B-A3B 總計 30B,約 3B 活躍;對比 LFM2.5-24B-A2B 總計 24.0B,2.45B 活躍。

• 層結構——Hy-Memory-30B-A3B 有 48 層,一個稠密區塊,以及 47 個 MoE 區塊,每個 MoE 區塊有 128 個專家、採 top-8 路由,外加一個共享專家;LFM2.5-24B-A2B 則採用 40 層,其中 30 層是雙閘控短卷積區塊,10 層是分組查詢注意力,每個 MoE 區塊有 64 個專家、採 top-4 路由。

• 上下文 — Hy-Memory-30B-A3B 為 262,144 個位置,對比 LFM2.5-24B-A2B 的 131,072,而後者本身已較上一代的 32K 有所提升。

• 權重佔用空間 — 分佈於 51 個 BF16 分片共 60.1 GB,對比 BF16 的 48 GB,另有 14.5 GB 的 Q4_K_M GGUF 與 13.6 GB 的 QAT QAD-Q4_0。

• 授權 — Hy-Memory-30B-A3B 採用 Apache 2.0,而 LFM2.5-24B-A2B 則採用 LFM1.0 授權;後者屬於自訂授權條款,並非 OSI 認可的授權,商業部署前值得仔細閱讀。

• 訓練語料 — 針對 LFM2.5-24B-A2B,涵蓋 16 種語言、共 36T 個 token,詞彙表大小為 128,000 個 token;Hy-Memory 模型卡載明英文與中文,且未公布 Hy-Memory-30B-A3B 的 token 數量。

• 已記錄的用途 — 在 Mem0、MemOS、Hy-Memory 及(留出)EverMemOS 內部的記憶寫入,對比於在真實測試框架中具備推理軌跡、工具呼叫與代理式強化學習的裝置端代理。

• 供應商公佈的量化——無 vs 四種格式。

再注意一次最後一列。Liquid AI 在基礎權重釋出後幾天內,就發布了 LFM2.5-24B-A2B 的 GGUF、FP8、ONNX 與 MLX-4bit 版本,社群還補上了更多。那是一家廠商以現有最具體的方式表明:這個模型就是要讓人下載下來、在本機執行。Hy-Memory 的發布則傳達了相反的訊息,卻從未明說:一種精度、一種格式、60 GB,以及一張指明以 vLLM 0.31.0 作為部署方式的模型卡。

各自受訓要做什麼,以及為什麼那不是同一份工作

LFM2.5-24B-A2B 是一款代理。Liquid 將它定位為快速、私密的執行者,總是先推理再回答,並且擅長呼叫工具——其公布的工具使用與指令遵循數據是整張表中最亮眼的部分,其中 IFEval 達 96.75、IFBench 達 74.69,尤其突出。該公司自家的指引對這項弱點直言不諱:不要單獨拿它來處理知識密集的問題,而應搭配檢索或網路搜尋。這是一個為行動而打造的模型,其知識是刻意外包出去的。

Hy-Memory-30B-A3B 完全不採取行動。它讀取一段對話並寫入記憶。它的輸入是對話往來,輸出則是結構化紀錄——Hy-Memory 快速入門要求它產生一個 JSON 物件,其中包含一連串自足的記憶字串,並在 temperature 0.0、關閉推理的情況下執行。LFM2.5-24B-A2B 的評判標準在於它是否完成了一項任務,而 Hy-Memory-30B-A3B 的評判標準則在於它所寫入的記憶庫日後是否能產生更好的答案。評估位於模型的下游,這正是 Hy-Memory 表格比較的是寫入者而非模型的原因——每一列都更換寫入者,並將答案模型、評審、檢索設定與提示詞固定不變。

證據缺口,而它並非對稱的

這兩組數字都來自供應商本身。但它們並非同樣有用。

Liquid AI 在同一個 vLLM 環境中,將自家模型與基準模型進行對照測試,並公布了那些數據列——LFM2.5-24B-A2B 的模型卡包含與 Qwen3.6-35B-A3B 及其他模型的直接比較,且是在同一套測試框架上進行,這至少讓表格的相對樣貌具有內部一致性。其宣稱在某種意義上是可稽核的:任何擁有該 GGUF 的人本週都能在中階硬體上嘗試重現這些結果。

Hy-Memory 的評估設計方式不同,也更難查核。主要矩陣是在每個基準的固定 20% 子樣本上執行,而非完整資料集——就成本而言這是站得住腳的選擇,但若你想倚重微小差距,就站不住腳了。而這份頭條結論所倚重的正是微小差距:Hy-Memory-30B-A3B 的 55.49 巨集平均,對上 Claude Opus 5 的 54.62,差距是 0.87 分。在 MemOS 測試框架上,差距是 0.01——50.51 對 50.50。同時,這項宣稱的頂點,也就是在留出的 EverMemOS 測試框架上得到的 56.89,是最值得檢驗的單一結果,卻也是沒有人跑過的那一個。

兩家廠商都沒有這兩個模型的獨立分數。{{1}}對 LFM2.5-24B-A2B 來說,這只是個兩天前才出現的不便。{{/1}} {{2}}對 Hy-Memory-30B-A3B 來說,這與硬體問題疊加在一起:你無法像重新執行 14.5 GB GGUF 那樣,輕鬆重現 60 GB BF16 模型的數字。{{/2}}

A screenshot of the Hugging Face file listing for tencent/Hy-Memory-30B-A3B, showing the model card header with the apache-2.0 licence and arxiv:2610.22196 tag, a 60.1 GB repository size, and a file list of 51 safetensors shards with no quantised build published alongside — the packaging contrast with Liquid AI's GGUF repository.

如果你的代理既需要記憶又需要嘴巴

務實的解讀是:這兩者在系統中是互補的,而不是在評比中互為競爭對手,而部署上的分工也就自然形成。

記憶寫入器在每一回合以簡短輸出觸發——一種高頻、低複雜度、必須具確定性的工作負載。裝置端代理執行器則在有任務要執行時被叫用,需要規劃並呼叫工具,且受益於在資料附近執行。一個正在打造私有代理堆疊、不進行任何第三方呼叫的團隊,很可能會希望寫入路徑與行動路徑是兩個不同的小模型,各自執行它被訓練來做的那一件事,且兩者都在本機執行。

這就是路由器問題的落點。OrcaRouter 用一組 API 金鑰就能橫跨200+ 個託管模型,且零加成,其路由 DSL能將多個模型組成單一呼叫——這正是讓本機服務的寫作模型與託管的尖端模型以單一端點回應的機制,並具備自動容錯移轉,當後端效能衰退時。確切說明這裡適用的情況:Hy-Memory-30B-A3B 與 LFM2.5-24B-A2B 都不在我們的目錄中,而這兩者我們也都不託管。 取得兩者的途徑是檢查點與你自己的硬體。路由器涵蓋的是讀取路徑及其相關規劃,以及在不變更呼叫程式碼的情況下,替換由哪個模型填補某個槽位的能力。

值得在真正需要之前就先做。路由表現在寫起來成本很低,但等到某個代理框架已經把端點硬編碼在十個地方之後,再回頭補上就要付出高昂代價。

A screenshot of the Hugging Face model card for LiquidAI/LFM2.5-24B-A2B, showing the Liquid AI org header, 398 likes and 6.07k followers, tags for Text Generation, Transformers, Safetensors, 16 languages and lfm2_moe, the LFM1.0 licence badge, and the opening line describing a 24B-parameter reasoning model with only 2B active parameters built for on-device work.

那張卡是對這個差異的公正總結。Liquid AI 自己的說法是,LFM2.5-24B-A2B 是為了在使用者所在之處運行而打造。Hy-Memory 團隊從未提出同等的主張,而 Hy-Memory-30B-A3B 背後的 60 GB 檔案所做的恰恰相反。

要先拿起哪一個?

如果你想在本週讓一個稀疏中型模型跑在自己的硬體上,LFM2.5-24B-A2B 顯然是第一站——下載大小是 14.5 GB,授權條款得要讀一讀,而工具呼叫的數字,則是它表格中最可能與你切身相關的部分。

如果你的代理程式有記憶問題,而且每經過一次對話就愈發嚴重,Hy-Memory-30B-A3B 正是針對這點而來,而且在開源領域中沒有其他東西能與之相提並論。先編列硬體預算,再編列時間預算。