LFM2.5-24B-A2B本地部署：2B激活仍需14.5GB内存

Liquid AI 的 LFM2.5-24B-A2B 是一个总参数 24B、每 token 仅激活 2.45B 的混合专家模型。官方宣称在 Apple M5 Max 上解码速度达到 184 tokens/s，但你依然需要把全部 24B 权重装进内存——Q4_K_M 量化文件就有 14.5 GB。速度与内存的这笔账，值得在下载之前算清楚。

LFM2.5-24B-A2B 到底是什么

Liquid 于 2026 年 10 月 13 日发布该模型，称其为 LFM2.5 系列中最大、也是最后一个成员。根据模型卡，核心规格如下：

• 总参数 24.0B，激活参数 2.45B
• 40 层：30 个双门控短卷积块 + 10 个 GQA 注意力层
• 每个 MoE 块 64 个专家，top-4 路由
• 131,072 token 上下文，128K 词表
• 约 33T 预训练 token，之后经过 2T token 的 32K 上下文中期训练和 300B token 的 131K 长上下文训练
• 纯文本模型，且是一个始终以 <think> 块开头的推理模型

纯文本这一点已经引发了不少讨论。GGUF 仓库里有人发帖抱怨"模型很好，但没有 mmproj 对我没用"。问题是根本没有 mmproj 可发——这个模型没有视觉塔。需要图像能力的话，LFM2.5 VL 系列最高只到 LFM2.5-VL-3B。

混合专家（MoE）与激活参数：MoE 架构把前馈层拆成多个并行"专家"，每个 token 只路由到其中少数几个，因此总参数与单 token 计算量脱钩。LFM2.5-24B-A2B 每个 MoE 块有 64 个专家、top-4 路由，即每个 token 只调用 4 个专家，理论激活比例约 1/16，叠加共享层与注意力层后实际激活 2.45B。这解释了它最大的认知陷阱：激活参数决定算力与速度，总参数决定内存。权重必须全部常驻内存以备任意 token 路由命中，所以 2B 的激活量不会让 14.5 GB 的 Q4_K_M 文件变小。

双门控短卷积 + GQA 混合：40 层里 30 层是双门控短卷积块，只有 10 层是分组查询注意力（GQA）。短卷积擅长以极低复杂度捕捉局部序列模式，注意力层负责全局信息交换。这种稀疏的注意力布局正是后文 KV 缓存增长缓慢的原因——缓存只为 10 层而非全部 40 层服务，长上下文的内存开销显著低于同深度纯 Transformer。

相比上一代 LFM2-24B-A2B 改了什么

如果你用过上一代 LFM2-24B-A2B（Ollama 里的 lfm2:24b），架构其实没变：同样是 40 层、64 专家、top-4、卷积/GQA 混合。主要升级在训练规模和推理能力上：

项目	LFM2-24B-A2B	LFM2.5-24B-A2B
上下文	32,768	131,072
词表	65K	128K
预训练 token	17T	33T
推理能力	无	始终开启（思维链）
后训练	未对比	5 个阶段，以 agentic RL 收尾

LFM2.5 文本系列的其他成员都很小：230M、350M、1.2B（含 Instruct、Thinking、JP 版本）、2.6B，以及 128K 上下文的 LFM2.5-8B-A1B MoE。这个 24B 是唯一试图进入 30B 级 MoE 赛道的选手。

基准测试：哪些能打，哪些不能

Liquid 把它对标 Qwen3.6-35B-A3B、Gemma-4-26B-A4B-it 和 Nemotron-3.5-Lightning（30B-A3B）。从模型卡摘录的关键数据：

基准	LFM2.5-24B-A2B	Qwen3.6-35B-A3B	Gemma-4-26B-A4B	Nemotron-3.5 30B-A3B
AutomationBench	27.69	8.72	5.46	2.61
BFCLv4	65.01	65.00	57.09	53.78
ToolSandbox	80.71	75.02	72.09	75.13
IFBench	74.69	64.21	47.44	71.67
GPQA Diamond	74.42	83.69	74.90	72.42
AA-Omniscience	-24.90	-24.35	-59.39	-3.58
SWE-Bench Verified	51.00	66.20	25.80	53.40
SciCode	32.71	37.35	35.42	27.78

结论比较清晰：这是一个工具调用和指令遵循模型。它赢下了全部三个指令遵循基准（IFEval 96.75、IFBench、Multi-IF），以及七个 agentic 基准中的五个，包括 LiveClaw 48.09 vs Qwen 的 38.19。但它在 PinchBench 和 WebArena Verified 上输给了 Qwen。BFCLv4 的 65.01 vs 65.00 更像是平局而非胜利。

劣势项目差距不小：Qwen3.6-35B-A3B 在 SWE-Bench Verified 上领先 15 分，GPQA Diamond 上领先 9 分。AA-Omniscience 得分 -24.90（该基准惩罚自信的错误回答）与 Qwen 大致持平，但远落后于 Nemotron 的 -3.58。如果你期待"2B 速度包裹中等规模知识"，实验室自己的表格说明知识正是短板。用它来遵循 schema 和调用函数才是正确姿势。

需注意这些都是实验室发布的数字，带有逐基准测试的配置（多为 temperature 0.6、vLLM、特定轮次上限），目前尚未见到独立复现。

各量化等级的内存需求

这是社区最关心的问题，GGUF 仓库里已有专门的 VRAM 讨论帖。以下是各量化文件大小（来自 GGUF 仓库），实际使用还需为 KV 缓存、操作系统和其他程序留出余量：

量化	文件大小	现实中的适配设备
Q4_0 (QAD)	13.6 GB	16 GB 紧张；24 GB Mac 或 16 GB GPU + 系统内存较舒适
Q4_K_M	14.5 GB	同上
Q5_K_M	17 GB	24 GB 设备
Q6_K	19.7 GB	24 GB 紧张，32 GB 合适
Q8_0	25.5 GB	32 GB+
BF16 / F16	48 GB	64 GB Mac 或工作站

"适配设备"一列是基于文件大小的经验判断，并非 Liquid 官方发布。官方博客仅称其在对比的边缘硬件 MoE 中"内存占用最小"，未给出具体 GB 数值。

KV 缓存方面有一点利好：40 层中只有 10 层是注意力层，因此缓存随上下文增长的速度远低于同深度纯 Transformer，长上下文成本比预期低。但在 16 GB 笔记本上设置 131K 上下文仍然不现实。

关于 Q4_0 文件：这是一个量化感知蒸馏（QAD）检查点，仓库称其经过训练"以恢复 Q4_0 量化损失的精度"。思路不错，但已有讨论帖要求提供实际精度数据，Liquid 尚未公布。在此之前，建议将 Q4_K_M 作为默认选择，QAD 文件用于 A/B 测试。

GGUF 与量化命名：GGUF 是 llama.cpp 生态的模型文件格式，把权重、词表和元数据打包在单一文件中。量化则用更少比特表示每个权重，从而压缩体积、降低内存带宽压力。常见后缀中，Q4_0、Q8_0 是较早期的均匀量化方案，K_M（如 Q4_K_M、Q5_K_M）采用混合精度块量化，对敏感权重分配更多比特，同等体积下精度通常更好。这也是为什么 Q4_K_M（14.5 GB）比 Q4_0（13.6 GB）大一点却更常被推荐作默认选择。

量化感知蒸馏（QAD）：普通量化是训练后压缩，精度损失不可逆；QAD 让模型在训练阶段就"感知"到将被压到 Q4_0，用蒸馏方式让权重适应这种低精度表示，力求恢复损失。代价是它是针对特定量化格式定制的，不能随意换算到其他量化等级，且实际精度增益需要评测数据支撑——这也是社区催促 Liquid 公布 QAD 对比数字的原因。

KV 缓存：自回归生成时，已生成 token 的 Key/Value 张量会被缓存复用，避免重复计算。缓存大小正比于层数、上下文长度和 KV 头数，因此长上下文时它可能与权重文件同量级，是评估"能否跑 131K 上下文"时不能忽略的第二笔内存账。

如何用 llama.cpp、Ollama 或 LM Studio 运行

以下命令来自 GGUF README 及 Hugging Face 标准片段。

llama.cpp OpenAI 兼容服务器：

llama-server -hf LiquidAI/LFM2.5-24B-A2B-GGUF:Q4_K_M

llama.cpp 终端推理：

llama-cli -hf LiquidAI/LFM2.5-24B-A2B-GGUF \
    --temp 0.1 --top-k 50 --repeat-penalty 1.05

在仓库名后加 :Q4_K_M（或其他量化标签）即可指定文件。

Ollama：

ollama run hf.co/LiquidAI/LFM2.5-24B-A2B-GGUF:Q4_K_M

**LM Studio：**打开 lmstudio://open_from_hf?model=LiquidAI/LFM2.5-24B-A2B-GGUF 或在模型浏览器中搜索仓库名。

GPU 机器上使用完整权重：vllm serve "LiquidAI/LFM2.5-24B-A2B"，端点位于 http://localhost:8000/v1/chat/completions。Transformers 需要 transformers>=5.0.0。

在归咎于模型之前，先检查两个设置：

1. 采样参数。 模型卡推荐 temperature 0.1、top_k 50、repetition_penalty 1.05。GGUF 将其存储为 general.sampling.* 元数据，llama.cpp 会自动应用。但不少前端会用自带的采样参数覆盖默认值。如果输出看起来混乱，先查这里。
2. 更新运行时。 架构（lfm2moe）自 LFM2-24B-A2B 起已获支持，但词表翻倍至 128K。早于本次发布的旧版本可能无法正确处理。目前未见相关报告，但更新 llama.cpp 或 Ollama 只需两分钟。

针对 agent 框架（Hermes、OpenClaw^广告、Pi），模型卡中的示例配置将其指向本地端点 http://localhost:8080/v1，Hermes 和 OpenClaw 的配置将上下文长度设为 131,072。

184 tokens/s 背后的细节

模型卡说明边缘速度数据是在 llama.cpp、Q4_K_M 和 4K token 输入上下文下测得的。M5 Max 上为 184 tokens/s，AMD Ryzen AI Max+ 395 上为 114 tokens/s。两者都是拥有大容量统一内存带宽的高端设备。16 GB 笔记本将权重溢出到慢速内存则是另一回事。

更大的问题在于这是一个纯推理模型。每个回答都以思维链开头。一个 2B 激活的 MoE 在回答"是"之前写了 600 个思考 token，端到端体验可能比一个直接回答的 8B 稠密模型还慢。Liquid 将 DSpark 草稿模型列为"即将推出"用于推测解码，社区已在讨论区询问此事。

统一内存与内存带宽：Apple M5 Max 和 AMD Ryzen AI Max+ 395 都属于统一内存架构，CPU 与 GPU 共享同一块高带宽内存池，模型权重无需在设备间拷贝即可被加速器直接读取。大模型推理在 batch size 为 1 时通常是内存带宽受限而非算力受限——每生成一个 token 都要把激活到的权重从内存读一遍。因此这类设备的优势不在浮点算力，而在 256 bit 乃至更宽的内存总线带来的高带宽。16 GB 笔记本一旦权重溢出到 SSD 或慢速内存，带宽骤降，解码速度会从三位数跌到个位数。

推测解码：用一个极小的"草稿"模型先快速猜出若干 token，再由主模型一次性并行验证，接受的部分直接采纳，从而把主模型的前向次数摊薄。它不改变输出分布，只在草稿命中率高时加速。Liquid 列出的 DSpark 草稿模型正是这一用途，对"纯推理模型先写几百 token 思维链"的场景尤其有吸引力。

纯推理模型的开销：始终输出 <think> 块意味着每个回答都先付出固定长度的思考 token 成本。端到端时延 =（思维链长度 + 回答长度）/ 解码速度，所以 184 tokens/s 的峰值吞吐不等于同等的主观响应速度。

LFM 开放许可证与 1000 万美元营收门槛

模型采用 LFM Open License v1.0。商业使用仅限年营收低于"阈值"（即 1000 万美元）的实体。"法律实体"包括控制你、被你控制或与你共同受控的关联公司——大公司的小子公司不能只算自己的营收。超过阈值后，商业使用根本不在许可范围内，需要与 Liquid 单独协商。

对独立开发者和多数初创公司来说这不是问题。但对中型企业的从业者而言，这意味着它不是 Apache 2.0，法务询问时不能当作 Qwen 来对待。

应该用它替换你的 8B 模型吗

如果你的日常主力是 8B 稠密模型，用于工具调用、JSON 提取或 agent 循环，LFM2.5-24B-A2B 值得花一个周末试试。指令遵循和工具使用数据是模型卡中最强的部分，激活参数不到你现在运行的三分之一。但如果你主要用它写代码或回答知识性问题，Liquid 自己的表格建议 Qwen3.6-35B-A3B 是更好的选择，而 8B 也不会太丢脸。

两个值得思考的问题：一个需要 14.5 GB 内存的 2B 激活 MoE，真能替代你的 8B 稠密日常主力吗？还是内存成本就是不可逾越的障碍？如果你已经加载了 GGUF，在什么硬件、什么量化下拿到了多少 tokens/s？那个 184 需要有人验证一下。

参考来源

• LiquidAI/LFM2.5-24B-A2B 模型卡
• LiquidAI/LFM2.5-24B-A2B-GGUF
• Liquid AI 发布博客
• LFM Open License v1.0
• Liquid AI 模型库
• GGUF 仓库讨论区