
Hy-Memory-30B-A3B vs LFM2.5-24B-A2B:两个稀疏专家,但只有一个能在你的机器上运行
- Orca新Orca: OrcaCyber Zero 1.52026-10-10$3.00 / $7.50 每百万 tokens · 73 tok/s
- openaiOpenAI: GPT-6.1 Sol2026-09-2952智能
- anthropicAnthropic: Claude Sonnet 5.52026-09-2856智能
- typesafeTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 每百万 tokens · 725 tok/s
- OpenAIOpenAI: GPT-6 Luna2026-09-2238智能
- OpenAIOpenAI: GPT-6 Sol2026-09-2248智能
- AnthropicAnthropic: Claude Opus 5.52026-09-2258智能
- xAIGrok 4.72026-09-2146智能
- OrcaOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $7.50 每百万 tokens · 35 tok/s
- OrcaOrca: OrcaVerify Text 1.02026-09-16$2.00 / $0.00 每百万 tokens · 821 tok/s
- DeepSeekDeepSeek: DeepSeek V4.1 Flash2026-09-1040智能
- OpenAIOpenAI: GPT-6 Astra2026-09-0453智能77代码
- GoogleGoogle: Gemini 3.8 Flash2026-09-0241智能76代码
- AlibabaQwen: Qwen3.8 Max (0902)2026-09-0245智能76代码
- AnthropicAnthropic: Claude Fable 5.12026-09-0153智能82代码
- TencentTencent: Hy4 preview2026-08-28$0.83 / $2.50 每百万 tokens · 52 tok/s
- AlibabaQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 每百万 tokens · 108 tok/s
- z-aiZ.ai: GLM 5.3 Flash2026-08-2642智能72代码
- DeepSeekDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.22 / $0.66 每百万 tokens · 185 tok/s
- z-aiZ.ai: GLM 5.32026-08-1845智能75代码
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 事件档案库中,其中每一条记录都附有各自的信息来源、严重程度、置信度评级和有争议标记。
这种打包方式上的差异并非排期上的偶然,而正确解读它,能让你对这两个模型的了解超过任何一张基准测试表。它也恰好是这两个模型通常被以错误理由进行比较的原因——人们看到两张卡片上都写着“小型稀疏 {{1}}MoE{{/1}}”,就想当然地认为它们在争夺同一个部署位置。事实并非如此。一个想待在笔记本电脑上的智能体框架里。另一个想待在你服务器上的记忆流水线里,而这两项工作几乎没有重叠。
他们唯一真正共有的东西
两者都是稀疏的。两者都常驻大量参数,并在每个 token 只读取其中一小部分。这就是架构上的全部重叠,而值得说明稀疏性带来了什么、又没有带来什么,因为这是这一规模类别中最常被误解的特性。
24B-A2B 检查点装不进相当于 24.5 亿参数的显存里。文件中的每个参数都必须可加载;激活参数数量换来的是每 token 吞吐量,而不是占用空间。Liquid 自己的模型卡对此说得很直白——该模型是一个 240 亿参数的检查点,运行它就意味着要在某处承载 240 亿个参数。谁要是读到“2.45B 激活”就去找一台小机器,下午准没好果子吃。Hy-Memory-30B-A3B 的 3B 激活数字相对于其 60 GB BF16 文件也同样如此。
除了这一共同属性外,两者在几乎所有重要方面都各不相同。

注意那个仓库是什么。一个厂商专门发布一个独立的 GGUF 仓库,就是在以现有最具体的方式表明:它所提供的模型,就是供人下载并运行在自己已经拥有的硬件上的。它的提交历史只有两次提交,而且才几天前——这可不是事后随手加到某个九个月前的版本上的附属品。
规格,并排对比,包含包装信息行
• 总参数 / 激活参数 — Hy-Memory-30B-A3B 总计 30B,约 3B 激活,对比 LFM2.5-24B-A2B 总计 24.0B,2.45B 激活。
• 层结构 —— Hy-Memory-30B-A3B 共 48 层,其中 1 个稠密块和 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 有所提升。
• 权重占用 — 60.1 GB,分布于 51 个 BF16 分片,而 BF16 格式下为 48 GB;其中 Q4_K_M GGUF 为 14.5 GB,QAT QAD-Q4_0 为 13.6 GB。
• 许可证 — Hy-Memory-30B-A3B 使用 Apache 2.0,而 LFM2.5-24B-A2B 使用 LFM1.0 许可证;后者是自定义授权,而非经 OSI 批准的许可证,在商业部署前值得一读。
• 训练语料——LFM2.5-24B-A2B 使用 128,000 个 token 的词表,涵盖 16 种语言的 36T tokens;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 对象,其中包含一组自包含的记忆字符串,运行温度为 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——是最值得检验的结果,也是无人运行过的那个。
两家厂商都没有为这两个模型提供独立评分。对 LFM2.5-24B-A2B 来说,这只是个已经存在两天的小麻烦。对 Hy-Memory-30B-A3B 来说,这还与硬件问题叠加在一起:你没法像重新运行一个 14.5 GB 的 GGUF 那样,随随便便就复现一个 60 GB BF16 模型的数值。

如果你的智能体既需要记忆,又需要一张嘴
实际的理解是,这两者在系统中是互补的,而非在某场比拼中互为对手,部署上的分工也就自然而然地形成了。
记忆写入器在每一轮都会触发,并且输出很短——这是一种高频、低复杂度、必须确定性的工作负载。当有任务要做时,会调用端侧智能体执行器,它需要规划和调用工具,并且受益于在数据附近运行。一个构建私有智能体技术栈、不进行任何第三方调用的团队,很可能会希望写入路径和行动路径是两个不同的小模型,各自只做自己被训练来做的那一件事,并且都在本地运行。
路由器的问题就落在这一点上。OrcaRouter 是一个 API key,覆盖200+ 个托管模型,0% 加价,并且其路由 DSL将多个模型组合成一次调用——正是这种机制,使本地部署的写作模型和托管的前沿模型能作为一个端点来作答,并带有自动故障转移,在后端性能下降时触发。 确切地说,就这里适用的情况而言:Hy-Memory-30B-A3B 和 LFM2.5-24B-A2B 都不在我们的目录中,我们也不托管其中任何一个。要得到这两者,途径是检查点和你自己的硬件。路由器所覆盖的是读取路径及其相关规划,以及在不改动调用代码的情况下更换由哪个模型来填充某个槽位的能力。
值得在你需要它之前就动手。路由表现在写起来成本很低,可一旦某个智能体框架在十处地方硬编码了端点,事后改造的代价就很高了。

{{1}}那张卡片是对这一差异的公允总结。{{/1}} {{2}}Liquid AI 自己的说法是,LFM2.5-24B-A2B 旨在在用户所在之处运行。{{/2}} {{3}}Hy-Memory 团队从未提出同等的主张,而 Hy-Memory-30B-A3B 背后的 60 GB 文件则恰恰相反。{{/3}}
先拿起哪一个
如果你想本周在自己的硬件上运行一个稀疏的中等规模模型,LFM2.5-24B-A2B 显然是第一站——下载大小为 14.5 GB,许可证需要仔细阅读,而工具调用指标是其表格中最有可能对你有用的部分。
如果你的 agent 存在一个随着每次对话而不断增长的内存问题,Hy-Memory-30B-A3B 正是针对它而来,而且在开源领域没有其他类似的东西。先为硬件做预算,再为时间做预算。
