LFM2.5-24B-A2B 实测：激活只有 2B 的 24B 端侧模型，我在 16GB MacBook 上踩了一遍内存坑

Liquid AI 在 10 月 13 日放出了 LFM2.5 家族的收官之作 LFM2.5-24B-A2B，开放权重，主打一个很明确的卖点：这是一颗为「端侧 Agent」设计的推理模型。10 月 16 日中文科技圈开始集中跟进报道，我在这台 Apple M4、16GB 统一内存的 MacBook 上用 llama.cpp 把 Q4_K_M 量化版完整跑了一遍——下载、加载、对话、工具调用全流程，包括一次很典型的显存爆炸事故。这篇文章把真实测到的数字、踩到的内存坑，以及哪些场景我建议你别用它，一次性讲清楚。

先搞懂：24B 总参 + 2B 激活意味着什么

传统密集模型的算力账单跟着全部参数走，MoE（混合专家）模型换了种玩法：参数都在，但每个 token 只唤醒一小部分。LFM2.5-24B-A2B 用了 64 个专家、每个 token 路由 top-4 的设计，总参数 240 亿，每个 token 激活约 20 亿。

这个设计直接改变了两件事：

• 算力账单按 2B 算：解码阶段的计算量大约相当于一个 2B 的密集小模型，这是它能在家用电脑上跑出高速度的根本原因；
• 内存账单按 24B 算：全部权重都得装进内存，这才是真正的门槛，后面实测部分我会专门讲。

相比上一代，这代还把上下文从 32K 拉到 131K，词表从 65K 扩到 128K（对中文等非拉丁语言的分词效率友好很多），预训练语料从 17T tokens 加到 33T。官方明确说这是一个「reasoning-only」模型——先输出显式思维链再给答案，最终训练阶段就在 Agent 环境里泡出来的，工具调用和多轮交互是它的主场。

有一个细节挺有意思：Liquid AI 在训练后期观察到了典型的 reward hacking 行为——模型学会了翻代码仓库的 git history、去 GitHub 和 PyPI 找答案，甚至意识到自己在沙盒里。这类现象写进官方博客本身就是一种坦诚，也提醒我们：哪怕是 2B 激活的端侧模型，Agent 行为的边界依然需要人盯着。

官方成绩单：先看，别全信

官方给了两组关键数据。速度方面：Apple M5 Max 上 184 tokens/s，AMD Ryzen AI Max+ 395 上 114 tokens/s，单张 NVIDIA B300 高并发下每秒输出超过 2.1 万 tokens。效果方面，官方拿它对标总参和激活都多 50% 的 Qwen3.6-35B-A3B：

这些是厂商自报数据，我没能独立复现完整基准（后面会说原因），但方向上可以这么理解：它把筹码押在了工具调用和多轮 Agent 任务上，知识密集型任务（GPQA、SWE-Bench 这类）官方也承认打不过更大的模型，并直接建议知识重的活儿配检索或联网搜索。

实测：16GB 内存的 M4 MacBook，先报喜再报忧

环境与下载

我的环境：Apple M4（基础版，内存带宽 120GB/s）、16GB 统一内存、macOS、llama.cpp 0.5.0（brew 安装）。权重选了 GGUF 格式的 Q4_K_M 量化版，HuggingFace 上各量化档位如下：

我下载的 Q4_K_M 落地就是 14.53GB——16GB 内存的机器，这份文件意味着几乎没什么余量，这是第一个坑，后面细说。

坑零：默认启动方式在 16GB 机器上直接爆炸

我先用最直觉的方式启动，让 llama.cpp 把能塞的层全塞进 Metal GPU：

# 运行环境：Apple M4 / 16GB 统一内存 / llama.cpp 0.5.0（brew install llama.cpp）
llama-server -m LFM2.5-24B-A2B-Q4_K_M.gguf --host 127.0.0.1 --port 8080 -c 4096 --jinja

# 运行环境：Apple M4 / 16GB 统一内存 / llama.cpp 0.5.0（brew install llama.cpp）
llama-server -m LFM2.5-24B-A2B-Q4_K_M.gguf --host 127.0.0.1 --port 8080 -c 4096 --jinja

模型加载花了 1 分 07 秒，一切看起来正常。然后我发了第一条消息——直接收获一屏 Insufficient Memory (00000008:kIOGPUCommandBufferCallbackErrorOutOfMemory)，Metal command buffer 反复失败，decode 返回 -3，一条 token 都没吐出来。日志里那句 current allocated size is greater than the recommended max working set size 早就预警了，但我没当回事。

结论很直白：14.53GB 权重 + KV cache + 系统占用，16GB 统一内存的 Mac 没法把权重全量放进 GPU。这不是 bug，是物理限制。

纯 CPU 跑通：能跑，但有代价

改用 -ngl 0（所有层走 CPU）后一次成功：

# -ngl 0 表示 0 层放 GPU，全部走 CPU；-c 2048 控制上下文省内存
llama-server -m LFM2.5-24B-A2B-Q4_K_M.gguf --host 127.0.0.1 --port 8081 -c 2048 -ngl 0 -t 4

# -ngl 0 表示 0 层放 GPU，全部走 CPU；-c 2048 控制上下文省内存
llama-server -m LFM2.5-24B-A2B-Q4_K_M.gguf --host 127.0.0.1 --port 8081 -c 2048 -ngl 0 -t 4

真实测到的数字：

• 加载时间：1 分 33 秒（-ngl 0，Q4_K_M）；
• 生成速度：约 2.3-2.6 tokens/s（-t 4，两次带计时的完整请求，用 usage 里的 completion_tokens 除以实测墙钟时间得出）；
• 内存占用：llama-server 进程 RSS 约 7.3GB——得益于 mmap 按需分页，不是把 14.5GB 全部拉进物理内存，系统空闲内存维持在 61% 左右，没有触发严重 swap；
• 中文质量：可用。我用「用一句话解释 MoE 架构为什么省算力不省内存」提问，它先走了一小段思维链，然后给出「MoE 只在前向传播时激活部分专家，从而削减计算量（省算力），但所有专家的参数都必须常驻显存，导致内存占用不降反升」——一句话命中要害，没有废话。

但 2.3 tokens/s 是什么体验？模型是 reasoning-only 的，一个简单问题思维链加答案动辄四五百 token，也就是说一次完整回答要等三四分钟。当 Agent 的思考引擎用，这个速度只能算「技术验证通过」，谈不上日用。

工具调用实测：一次通过，JSON 合规

作为端侧 Agent 模型，函数调用是必测项。--jinja 参数启用模型自带的工具调用模板后，我注册了一个简单的天气查询函数：

curl http://127.0.0.1:8081/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "lfm2.5",
    "messages": [{"role":"user","content":"北京今天天气怎么样？"}],
    "tools": [{"type":"function","function":{"name":"get_weather",
      "description":"查询城市当前天气",
      "parameters":{"type":"object","properties":{"city":{"type":"string"}},"required":["city"]}}}],
    "tool_choice": "auto"
  }'

curl http://127.0.0.1:8081/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "lfm2.5",
    "messages": [{"role":"user","content":"北京今天天气怎么样？"}],
    "tools": [{"type":"function","function":{"name":"get_weather",
      "description":"查询城市当前天气",
      "parameters":{"type":"object","properties":{"city":{"type":"string"}},"required":["city"]}}}],
    "tool_choice": "auto"
  }'

返回的 tool_calls 结构完全合规：函数名 get_weather、参数 {"city":"北京"}，OpenAI 兼容格式，接进任何 Agent 框架都不需要额外解析。这一项对得起官方「为 Agent 而生」的宣传。

一个反直觉的坑：max_tokens 会被思维链吃光

我让它「写一句 20 字以内的中文 slogan」，设了 700 的 max_tokens——结果收到一条完全空白的正文。翻 reasoning 才发现，这孩子把每个候选 slogan 逐字数数、反复推翻重写，700 个 token 全花在思维链上，还没来得及给答案就触顶了。

所以用这个模型请记住：reasoning-only 意味着你的 max_tokens 预算要先扣掉思维链。端侧跑的时候给 1500 起步，别按普通对话模型的习惯设个 300 就完事。

踩坑记录与选型建议

坑一：内存是硬门槛，不是算力。 2B 激活让你误以为它是「小模型」，但 24B 的权重就是 24B 的体量。我在 16GB M4 上的实测结论：全量 GPU offload 直接 OOM，纯 CPU 能跑但只有 2.3 tokens/s。想要官方宣传的那种流畅体验，你需要 32GB 以上统一内存的 Mac（Q4_K_M 塞得进 GPU 还留有余量），或者带独显的机器。

坑二：上下文长度和内存是乘法关系。 131K 上下文是卖点，但每多 1K 上下文都是实打实的 KV cache 内存。我实测用 -c 2048 就是刻意为之；端侧跑 Agent 把任务上下文控制在 8K-16K 内，速度和稳定性都会好很多。

坑三：量化档位别贪高。 Q6_K 要 19.69GB，16GB 机器直接没戏；这个模型的最优解在 Q4 档位，这是工程权衡而不是画质牺牲。

三类我建议你别用它的场景（尤其 16GB 机器用户）： 1. 16GB 内存机器想当日用 Agent 大脑——实测 2.3 tokens/s 的思维链等待会消磨掉所有耐心，这个场景请直接看更小的模型（下文有链接）； 2. 知识密集型问答——官方自己都承认打不过大模型，硬上只会收获一本正经的胡说八道，配合检索再用； 3. 复杂软件工程任务——SWE-Bench 这类多文件重构，24B 总参撑不住，老老实实走云端。

一句话总结它的正确打开方式：32GB+ 内存的 Mac 或带独显的机器，拿它跑工具调用循环，这才是官方 184 tokens/s 数据对应的真实场景。

和站内其他端侧方案怎么选

如果你在纠结端侧部署的整体路线，先看本地部署大模型的通用对比（Ollama 与 LM Studio 双方案）；16GB 内存又想要能日用的 Agent 模型，之前写过的 MiniCPM5-2B 端侧部署实测 是更现实的选择，内存需求只有零头；把本地模型接进 Agent 工作流的完整方案，参考 OpenClaw 接本地模型指南，以及用 Headroom 压缩 Agent 上下文省 token 的思路——端侧跑 131K 上下文不现实，压缩上下文正好互补。上周的 EmbeddingGemma 2 本地实测 也印证了同一个判断：端侧 AI 的可行性正在从「能跑」变成「能干活」——前提是你先算清楚内存这笔账。

写在最后

LFM2.5-24B-A2B 的价值不在于跑分赢了多少，而在于它把「笔记本上跑一个像样的 Agent 大脑」从 PPT 变成了 14.5GB 的下载链接。2B 激活的架构设计让速度不再依赖顶级显卡，但代价是你得为 24B 的总参腾出内存空间——我的 16GB M4 实测把这个门槛踩得很清楚：全 offload 会炸，纯 CPU 只够验证。如果你手上有 32GB 以上内存的 Mac 或带独显的机器，它值得你现在就下载试试；16GB 用户，看完本文的三个坑再决定要不要花这 14.5GB 磁盘。

外部资料：Liquid AI 官方博客、HuggingFace 权重页、llama.cpp 项目主页。