指南

作者： Matt Connor 2026-10-18

如何在纯 CPU VPS 上运行 LFM2.5-24B-A2B

Q: 哪个 llama.cpp 版本支持 LFM2.5-24B-A2B？

llama.cpp 在 lfm2moe 架构下支持此模型系列。该架构最早于 2025 年 10 月通过 pull request #16464 添加，并于 2025 年 12 月通过 pull request #18132 修复张量问题。本指南固定使用 v0.7.0 标签，该版本包含这两项变更。v0.7.0 发布版本不提供预构建二进制文件，因此请从该标签构建 llama-server，然后在加载日志中确认架构行。

使用 llama-server 在纯 CPU VPS 上运行 LFM2.5-24B-A2B：按量化表规划 RAM，固定 llama.cpp 版本，采用模型卡采样参数，并将 API 仅监听 localhost。

CPU-only VPS 对 LFM2.5-24B-A2B 的要求

只要 VPS 的 RAM 足以容纳完整模型，就可以使用 llama.cpp 的 llama-server 在 CPU-only VPS 上运行 LFM2.5-24B-A2B。Q4_K_M 文件大小为 14.5 GB。为了获得可用的速度，整个文件都应驻留在内存中。llama.cpp 会对该文件进行内存映射，因此 RAM 较少时也可以启动，但未驻留在 RAM 中的部分必须在需要时从磁盘重新读取。模型完全装入内存后，内存带宽决定运行速度。租用的 CPU 核心数重要性要低得多。本指南将从源代码构建固定版本的 llama.cpp，下载模型，应用 Liquid 推荐的采样设置，并让 API 仅监听 localhost。

LFM2.5-24B-A2B 是 Liquid AI 发布的模型。模型卡将其描述为“具有 24B 个参数、仅激活 2B 个参数的推理模型，面向设备上的快速私有代理”。该模型采用 MoE（专家混合）架构。模型卡的规格列表显示，它有 2.45B 个激活参数和 40 个层，其中 30 个是短卷积块，10 个是 GQA（分组查询注意力）层。每个 MoE 块包含 64 个专家，top-4 路由会为每个 token 选择其中 4 个专家。上下文长度为 131,072 个 token。

为什么混合专家模型在 CPU 上的行为不同

稠密模型会读取它生成的每个 token 所需的全部权重。MoE 模型不会这样做。对于每个 token，每个 MoE 层中的路由器会从 64 个专家中选择 4 个，只有这些专家会执行计算。因此，显卡可能标注总参数量为 24B，但活动参数量约为 2.45B。

这会对 CPU 服务器产生两个影响，而且方向相反。

首先，全部 24B 个参数都必须保持可访问，并且为了获得良好速度，参数应放在 RAM 中。 路由器会为不同 token 选择不同专家，因此无法预先知道下一个 token 需要哪些专家。llama.cpp 默认使用内存映射加载模型，其文档说明，这样系统可以“仅在需要时加载模型的必要部分”。因此，不在 RAM 中的专家不会导致模型停止运行。路由器选中该专家时，系统会从磁盘读取它。不过，在生成 token 的过程中执行磁盘读取，速度远低于从 RAM 读取。因此，应为服务器提供足够的 RAM，使整个文件都能常驻内存。

其次，每个 token 只会读取活动部分。 生成一个 token，意味着将活动权重从 RAM 流式传输到 CPU。对于 CPU，内存流量是速度瓶颈，而不是算术运算。我们的 LLM 能否放入 RAM 的容量计算方法用一句话概括了这一点：“每秒 token 数的上限等于内存带宽除以每个 token 的活动权重字节数。”这里的活动部分约占模型的十分之一（24B 中的 2.45B）。因此，与文件大小相同的稠密 24B 模型相比，CPU 服务器运行此模型时的生成速度要快得多。

实际结果是：应购买容量足以容纳模型的 RAM，并根据内存带宽评估速度。增加 CPU 核心数只能在内存总线达到饱和前提供帮助。超过这一点后，更多核心会和其他核心一样等待数据。

LFM2.5-24B-A2B 需要多少 RAM？

Liquid 在模型卡片中列出了这些 GGUF（llama.cpp 加载的文件格式）文件的大小。由于模型卡片使用十进制单位，因此这里的大小也是十进制 GB。

图表LFM2.5-24B-A2B GGUF file sizes from the model card (GB)

label

size_gb

QAD-Q4_0

13.6

Q4_K_M

14.5

Q5_K_M

Q6_K

19.7

Q8_0

25.5

BF16

F16

此图表背后的数据

[
  {
    "label": "QAD-Q4_0",
    "size_gb": 13.6
  },
  {
    "label": "Q4_K_M",
    "size_gb": 14.5
  },
  {
    "label": "Q5_K_M",
    "size_gb": 17
  },
  {
    "label": "Q6_K",
    "size_gb": 19.7
  },
  {
    "label": "Q8_0",
    "size_gb": 25.5
  },
  {
    "label": "BF16",
    "size_gb": 48
  },
  {
    "label": "F16",
    "size_gb": 48
  }
]

文件大小只是最低需求，不是总需求。除此之外，还需要为以下内容预留内存：

KV cache（保存上下文中每个 token 的注意力键和值）。它会随设置的上下文长度增加。
操作系统和服务器上的其他服务。
预留空间，避免内核必须回收模型页面并从磁盘重新读取。

40 个层中只有 10 个是注意力层，因此与相同深度的纯注意力模型相比，它需要的 KV cache 更小。但 KV cache 仍然不是 0。如果计划使用较长上下文，请使用 RAM 指南中的 KV 公式，并代入模型自身的配置值。

根据表格可以得出一个简单的容量规划规则。Q4_K_M 文件大小为 14.5 GB，因此 16 GB VPS 几乎没有空间留给 KV cache 和操作系统。对于使用中等上下文的 Q4_K_M，建议准备 24 GB 或更多 RAM。Q8_0 文件大小为 25.5 GB，约为 23.7 GiB。因此，32 GiB RAM 的 VPS 大约还剩 8 GiB，可供 KV cache、操作系统和预留空间使用。对于中等上下文，这可能足够，但余量较小。如果希望在 Q8_0 下使用较长上下文，应选择更大的配置。模型卡片还列出了 QAD-Q4_0 文件，大小为 13.6 GB。Liquid 训练该量化格式，以恢复普通 Q4_0 会损失的准确率。如果希望了解这些级别之间的权衡，我们对 Q4、Q8 与 FP16 量化的比较进行了说明，其中介绍了每一步对质量和内存的影响。

下载前，先检查服务器实际拥有的资源：

free -g
df -h ~
nproc

free -g 显示总 RAM 和可用 RAM。df -h ~ 显示主目录所在磁盘的可用空间。你需要为模型文件和 llama.cpp 构建过程预留空间。

固定支持此架构的 llama.cpp 版本

模型的 config.json 将该架构命名为 Lfm2MoeForCausalLM。llama.cpp 使用架构名称 lfm2moe 支持这一系列架构。相关支持最早在拉取请求 #16464（“llama：支持 LiquidAI LFM2-MoE 混合模型”）中加入，该请求于 2025-10-07 合并。随后，拉取请求 #18132 修复了张量缺失问题，并于 2025-12-17 合并。

本指南将 llama.cpp 固定到标签 v0.7.0。该标签于 2026-10-15 发布，对应提交 620d2225cc436ab0b001e3200e590e3b286ef9ab。该标签包含上述两个提交。v0.7.0 版本不提供预构建的服务器二进制文件，因此需要从源代码构建。固定到标签后，上游后续更改不会在不知情的情况下改变服务器。相关原因，以及如何安全迁移到更新的标签，请参阅我们的在服务器上固定 llama.cpp 版本指南。

安装构建工具，然后准确克隆该标签：

sudo apt update
sudo apt install -y build-essential cmake git curl jq libssl-dev
git clone --branch v0.7.0 --depth 1 https://github.com/ggml-org/llama.cpp.git ~/llama.cpp
git -C ~/llama.cpp log -1 --format=%H

最后一条命令应输出 620d2225cc436ab0b001e3200e590e3b286ef9ab。如果输出其他哈希值，则当前版本不是 v0.7.0。

现在仅构建服务器：

cd ~/llama.cpp
cmake -B build
cmake --build build --config Release -j "$(nproc)" --target llama-server
ls -l build/bin/llama-server

在小型 VPS 上，构建需要几分钟。最后一条命令应列出该二进制文件。如果 cmake -B build 报错退出，请查看第一行错误信息。缺少编译器或缺少 cmake，表示 apt install 步骤未完成。

下载 GGUF 文件

直接从 Liquid 的 GGUF 存储库下载 Q4_K_M 文件。普通的 curl 下载方式适用于任何构建版本，并会生成一个普通文件，便于备份或移动。

mkdir -p ~/models
curl -L --fail -o ~/models/LFM2.5-24B-A2B-Q4_K_M.gguf https://huggingface.co/LiquidAI/LFM2.5-24B-A2B-GGUF/resolve/main/LFM2.5-24B-A2B-Q4_K_M.gguf
stat -c %s ~/models/LFM2.5-24B-A2B-Q4_K_M.gguf
sha256sum ~/models/LFM2.5-24B-A2B-Q4_K_M.gguf

stat 应输出 14526258464，即文件的字节数。该文件约为 13.5 GiB，与卡片标注的 14.5 GB（十进制单位）是同一个文件。将 sha256sum 的输出与 Hugging Face 文件页面上显示的 SHA-256 值进行比较。文件大小更小或哈希值不同，表示下载未完成，llama-server 将无法加载该文件。

若要改用 QAD-Q4_0 文件，请将两个文件名都改为 LFM2.5-24B-A2B-QAD-Q4_0.gguf。

在 localhost 上启动 llama-server

先在前台启动服务器，以便查看加载日志：

~/llama.cpp/build/bin/llama-server -m ~/models/LFM2.5-24B-A2B-Q4_K_M.gguf --host 127.0.0.1 --port 9931 -c 16384 --temp 0.1 --top-k 50 --repeat-penalty 1.05

每个标志都有明确用途。

--host 127.0.0.1 让 API 仅监听 loopback 接口。v0.7.0 已默认使用此设置，但显式写出可避免默认值变化带来的影响。
--port 9931 是 v0.7.0 的默认端口。旧版指南使用 8080。显式指定端口，避免脚本依赖版本。
-c 16384 设置上下文大小。默认值 0 表示服务器从模型获取上下文长度；本例中为 131,072 个 token。上下文越大，KV 缓存越大，因此只设置所需的大小。
--temp 0.1 --top-k 50 --repeat-penalty 1.05 是模型卡推荐的采样参数。服务器的通用默认值为 temperature 0.80、top-k 40，且不设置重复惩罚，因此请自行传入这 3 个标志。

模型加载期间，日志会输出模型元数据，包括架构名称。此处应看到 lfm2moe 系列。如果出现未知模型架构错误，说明当前运行的二进制文件不是根据固定 tag 构建的版本。

默认情况下，服务器没有 API key。在 loopback 上这没有问题，因为只有本机进程可以连接。若要从笔记本电脑访问，请使用 SSH 隧道，而不是开放端口：

ssh -L 9931:127.0.0.1:9931 user@your-vps-ip

随后，笔记本电脑可以通过 http://127.0.0.1:9931 访问 API。如果必须将服务器置于反向代理之后，请添加 --api-key，并使用较长的随机值。请注意，/health 按设计是公开的，不会检查 key。我们的《在 VPS 上运行 llama.cpp 的服务器》指南介绍了服务器进程周边的完整配置。

检查模型是否已加载并能够回答

在第二个 SSH 会话中，向健康检查端点请求状态码：

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:9931/health

503 表示模型仍在加载。200 表示服务器已就绪。从网络存储加载 14.5 GB 数据需要一段时间，因此请等待后重试。

然后向 OpenAI 兼容端点发送实际请求：

curl -s http://127.0.0.1:9931/v1/chat/completions -H "Content-Type: application/json" -d '{"messages":[{"role":"user","content":"Reply with the single word: ready"}],"max_tokens":1024}' | jq '.choices[0].message, .timings.predicted_per_second'

模型卡片说明，该模型在回答前始终会进行推理。请预留足够空间，让 max_tokens 包含推理文本和最终答案。限制值过低时，回复会在推理阶段被截断，因此无法看到答案。

测量您自己的每秒 token 数

本指南不会为 VPS 输出每秒 token 数。速度取决于您的套餐内存带宽，因此其他服务器上的数值无法准确反映您的 VPS。Liquid 提供的数值来自桌面级硬件，而不是 VPS：

图表Liquid's published decode speeds, llama.cpp, Q4_K_M, 4K-token input (not a VPS)

label

decode_tok_s

AMD Ryzen AI Max+ 395

114

Apple M5 Max

184

此图表背后的数据

[
  {
    "label": "AMD Ryzen AI Max+ 395",
    "decode_tok_s": 114
  },
  {
    "label": "Apple M5 Max",
    "decode_tok_s": 184
  }
]

Liquid 报告称，AMD Ryzen AI Max+ 395 的速度为 114 token/秒，Apple M5 Max 的速度为 184 token/秒。这两台机器的内存带宽都远高于典型 VPS。请将这些数值视为上限参考，而不是实际预测。

请直接从服务器获取您自己的数值。每个 /v1/chat/completions 响应都包含一个 timings 对象，其中的 predicted_per_second 字段表示该请求的生成速度。上面的 jq 命令已经会输出此字段。使用同一个提示运行 5 次，然后观察数值范围。若要了解更全面的方法，包括租用的 GPU 何时开始比按 token 计费的 API 更划算，请阅读我们的指南：测量本地 LLM 的每秒 token 数】【。

LFM2.5-24B-A2B 的适用场景和工具调用

模型卡片将代理任务和工具使用列为该模型的优势。卡片还指出，模型“不建议单独用于知识密集型任务”，并建议将其与检索或网络搜索结合使用。实际使用时，应为模型提供工具和文档，不要要求它从记忆中回忆事实。类似面向代理的 SearXNG 搜索技能的搜索后端符合这一模式。

默认情况下，模型会将工具调用写成用特殊标记包裹的 Python 风格函数调用，例如 <|tool_call_start|>[get_candidate_status(candidate_id="12345")]<|tool_call_end|>。您也可以在系统提示词中要求它改用 JSON 调用。v0.7.0 服务器通过 Jinja 聊天模板引擎支持 OpenAI 风格的函数调用，该功能默认启用。服务器能否将此模型的格式转换为结构化工具调用，取决于它针对该模板使用的解析器。在依赖这一功能之前，请先进行测试：发送包含 tools 数组的请求，然后查看响应。消息中出现结构化工具调用，表示解析成功。content 中出现原始的 <|tool_call_start|> 文本，表示代理代码必须自行解析该调用。

模型卡片中的 Ollama 命令是否可用？

GGUF 卡片为 Ollama 提供了以下命令：

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

我们检查了下载步骤，没有完成完整加载测试。Hugging Face 提供的 Ollama 风格清单可以无错误地解析 :Q4_K_M 标签。清单列出了一个大小为 14,526,258,464 字节的模型层，其哈希值与 Q4_K_M 文件匹配。因此，pull 应会下载正确的文件。我们没有在 Ollama 中运行该模型，因此无法确认它能否正确加载并生成内容。撰写本文时，Ollama 的最新发行说明未提及 LFM2.5；Ollama 中还有关于解析 LFM2 工具调用的未合并 pull request。如果你依赖工具调用功能，请先在 Ollama 中进行测试，再将其用于生产环境。

不要将其与 Ollama 自有库中的 lfm2:24b 混淆。该条目是较旧的 LFM2-24B-A2B，列出的上下文窗口为 32K。这是不同的模型。关于这两个运行时之间的一般取舍，请参阅 Ollama 与 llama.cpp 的对比。

许可证：投入生产前先检查

该模型依据 LFM Open License v1.0 发布，不采用 Apache 或 MIT 许可证。许可证规定了每年约 1000 万美元的收入“Threshold”。法律实体的商业使用如果超过该阈值，则不在许可范围内。符合条件的非营利组织不受该阈值限制，但仅限于非商业用途或研究用途。对于收入恰好为 1000 万美元的情况，许可证文本并不完全一致。因此，在将该模型用于商业产品前，请自行阅读模型存储库中的 LICENSE 文件。本节仅作摘要，不构成法律建议。

将 llama-server 作为 systemd 服务运行

在 SSH 会话中启动的服务器会在会话结束时停止。将其作为 systemd 服务运行，使其在系统启动时自动启动，并在崩溃后自动重启。创建 /etc/systemd/system/llama-lfm.service，将 youruser 替换为您的登录名：

[Unit]
Description=llama-server with LFM2.5-24B-A2B
After=network.target

[Service]
User=youruser
ExecStart=/home/youruser/llama.cpp/build/bin/llama-server -m /home/youruser/models/LFM2.5-24B-A2B-Q4_K_M.gguf --host 127.0.0.1 --port 9931 -c 16384 --temp 0.1 --top-k 50 --repeat-penalty 1.05
Restart=on-failure

[Install]
WantedBy=multi-user.target

然后加载并启动该服务：

sudo systemctl daemon-reload
sudo systemctl enable --now llama-lfm
systemctl status llama-lfm
journalctl -u llama-lfm -n 50

systemctl status 应显示 active (running)。如果显示 failed 状态，journalctl 会输出加载日志，其中第一条错误行会指出原因。ExecStart 中的路径错误是最常见的原因。然后重复运行健康检查，直到返回 200。

FAQ

在 VPS 上运行 LFM2.5-24B-A2B 需要多少 RAM？

模型卡中的 Q4_K_M 文件大小为 14.5 GB。整个文件应装入 RAM，因为下一个 token 可能选择 64 个专家中的任意一个。llama.cpp 会对模型使用内存映射，因此 RAM 少于文件大小时仍可运行；但未驻留在 RAM 中的专家被选中时，需要从磁盘读取，速度会慢得多。还需为 KV cache、操作系统和预留空间额外分配内存。16 GB VPS 对 Q4_K_M 来说空间过于紧张。建议使用 24 GB 或更多 RAM，并通过 -c 设置适中的上下文长度，以控制 KV cache 大小。

为什么 24B MoE 模型可以在 CPU 上运行？

24B 个参数中，每个 token 只有约 2.45B 个参数处于激活状态，因此 CPU 为每个生成的 token 读取的权重约为总权重的十分之一。在 CPU 上，从 RAM 读取权重是速度瓶颈，因此速度取决于内存带宽除以激活参数所占的字节数。稠密 24B 模型为每个 token 读取全部权重，在同一台机器上的速度会慢得多。

哪个 llama.cpp 版本支持 LFM2.5-24B-A2B？

llama.cpp 在 lfm2moe 架构下支持此模型系列。该架构最早于 2025 年 10 月通过 pull request #16464 添加，并于 2025 年 12 月通过 pull request #18132 修复张量问题。本指南固定使用 v0.7.0 标签，该版本包含这两项变更。v0.7.0 发布版本不提供预构建二进制文件，因此请从该标签构建 llama-server，然后在加载日志中确认架构行。

为什么我向 8080 端口发送的 curl 请求失败？

在 llama.cpp v0.7.0 中，服务器默认端口是 9931，而不是旧指南使用的 8080。8080 上没有进程监听，因此连接被拒绝。启动服务器时显式传入 --port，并在所有客户端中使用相同的端口。

我可以将 LFM2.5-24B-A2B 用于商业用途吗？

LFM Open License v1.0 允许年收入低于约 10000000 美元的商业使用。收入超过该门槛的公司不在许可范围内。非营利组织只有在非商业用途或研究用途下，才可免于该门槛限制。投入生产前，请阅读模型仓库中的 LICENSE 文件；如果您的情况接近该限制，请咨询律师。

#lfm2.5#llama-cpp #local-llm #cpu-inference #ai-agents