Liquid AI 的 LFM2.5-350M 最近在 Spark Arena https://spark-arena.com/leaderboard 上长期居于速度榜首。这个模型在 Ollama 上可以直接拉取：
ollama pull LiquidAI/lfm2.5-350m
只有 379MB，Q8_0 量化，354.48M 参数，128K 上下文，标注了 tools + thinking + completion 三项能力。
我把之前对其他所有小模型做过的同一套测试——脚本评测（46 用例中英双语）和 BFCL 官方评测（25 抽样）——都对它跑了一遍，下面是结果和对比。
测试环境与模型
MacBook Air M4, 16G 统一内存
推理引擎: Ollama 0.32.9
| 属性 | 值 |
|---|---|
| 模型名 | lfm2.5-350m |
| 架构 | LFM-2.5（Liquid 混合架构） |
| 参数量 | 354.48M |
| 下载大小 | 379 MB |
| 量化 | Q8_0 |
| 上下文 | 128,000 |
| 能力 | completion, tools, thinking |
| Ollama 地址 | https://ollama.com/LiquidAI/lfm2.5-350m |
| Spark Arena | https://spark-arena.com/leaderboard |
脚本评测结果
46 个测试用例（23 用例 × 中英双语），覆盖 simple / parallel / tool_selection / irrelevant / multi_turn / tau_airline / tau_retail / edge 八个维度，使用 Ollama 原生 tools 接口，temperature=0。
| 维度 | 得分 |
|---|---|
| simple | 0.67 |
| parallel | 0.35 |
| tool_selection | 0.38 |
| irrelevant | 0.25 |
| multi_turn | 0.33 |
| tau_airline | 0.00 |
| tau_retail | 0.50 |
| edge | 0.33 |
| 总通过率 | 50.0% |
| 均分 | 0.42 |
| EN 通过率 | 69.6% |
| ZH 通过率 | 30.4% |
| 总耗时 | 74s |
BFCL 官方评测结果
使用 BFCL 官方管线（bfcl generate → bfcl evaluate），25 个抽样测试用例（simple_python 10 + irrelevance 10 + parallel 5），AST 解析 + 类型检查 + 标准化值匹配。
| 类别 | 准确率 |
|---|---|
| irrelevance | 90% |
| simple_python | 50% |
| parallel | 0% |
irrelevance 90% 说明这个模型在"不该调工具的时候能管住自己"这件事上做得不错。simple_python 50% 在同体量模型里也是中上水平。但 parallel 0%——在 BFCL 严格的 AST 格式要求下，它的并行调用输出格式没过关。
与其他模型对比
脚本评测总榜（含 LFM2.5-350M）
| 模型 | 大小 | 通过率 | 均分 | EN | ZH | 耗时 |
|---|---|---|---|---|---|---|
| lfm2.5-thinking | 697 MB | 76.1% | 0.74 | 95.7% | 56.5% | 668s |
| smollm2:1.7b | 1,736 MB | 76.1% | 0.73 | 87.0% | 65.2% | 194s |
| granite4:350m-h | 349 MB | 67.4% | 0.64 | 78.3% | 56.5% | 60s |
| qwen3.5:0.8b | 988 MB | 63.0% | 0.61 | 82.6% | 43.5% | 370s |
| qwen3:0.6b | 498 MB | 56.5% | 0.54 | 78.3% | 34.8% | 220s |
| granite4:350m | 676 MB | 54.3% | 0.54 | 73.9% | 34.8% | 41s |
| lfm2.5-350m | 379 MB | 50.0% | 0.42 | 69.6% | 30.4% | 74s |
| llama3.2:1b | 1,260 MB | 34.8% | 0.30 | 43.5% | 26.1% | 97s |
| functiongemma | 287 MB | 17.4% | 0.17 | 26.1% | 8.7% | 106s |
BFCL 官方评测对比
| 模型 | irrelevance | parallel | simple_python |
|---|---|---|---|
| qwen3:0.6b | 100% | 40% | 40% |
| lfm2.5-thinking | 100% | 60% | 30% |
| functiongemma | 100% | 0% | 20% |
| granite4:350m-h | 80% | 20% | 30% |
| smollm2:1.7b | 80% | 40% | 50% |
| lfm2.5-350m | 90% | 0% | 50% |
| qwen3.5:0.8b | 30% | 40% | 30% |
| llama3.2:1b | 0% | 0% | 0% |
分析
体积效率
379MB 的体积在所有受测模型中排倒数第二（仅比 functiongemma 的 287MB 大），但通过率 50% 远超 functiongemma 的 17.4%。按"每 MB 通过率"来算，LFM2.5-350M 是 0.132%/MB，granite4:350m-h 是 0.193%/MB——granite4:350m-h 仍然是体积效率最高的，LFM2.5-350M 排第二。
英文 vs 中文
英文 69.6% vs 中文 30.4%，差距 39 个百分点。这个差距和 lfm2.5-thinking（95.7% vs 56.5%，差 39pp）以及 qwen3.5:0.8b（82.6% vs 43.5%，差 39pp）几乎一样。说明 LFM 系列的中文工具调用能力和同体量的其他模型处于同一水平——都不太行。
简单调用能力强
simple 维度 0.67，在所有模型中排第三（granite4:350m-h 和 lfm2.5-thinking 并列第一 0.75）。BFCL simple_python 50% 也是所有模型中最高的（与 smollm2:1.7b 并列）。这说明 LFM2.5-350M 在单次工具调用 + 参数填充这件事上做得不错。
并行调用是短板
脚本评测 parallel 0.35，BFCL parallel 0%。在 BFCL 严格的 AST 格式下，它的并行调用输出完全没过关。这和 Spark Arena 的排名形成对比——Spark Arena 评测的可能不是并行工具调用场景，而是单轮推理质量。
与同门 lfm2.5-thinking 的关系
lfm2.5-thinking（697MB，1.2B 参数）通过率 76.1%，lfm2.5-350m（379MB，354M 参数）通过率 50%。同一架构、不同参数规模，通过率差了 26 个百分点。参数量缩到不到三分之一，能力下降了三分之一多一点，这么粗略来看缩放效率还算合理。
速度
实际生成速度（tokens/s）测试结果：
| 模型 | 生成 tokens | 生成时间 | tok/s |
|---|---|---|---|
| lfm2.5-350m | 33 | 0.41s | 80.2 |
| granite4:350m-h | 126 | 3.63s | 34.7 |
| lfm2.5-thinking | 256 | 8.41s | 30.4 |
LFM2.5-350M 以 80.2 tok/s 的生成速度遥遥领先，是 granite4:350m-h 的 2.3 倍、lfm2.5-thinking 的 2.6 倍。这正是它在 Spark Arena 速度榜上排第一的原因——Liquid 的混合架构（SSM + Transformer）在推理效率上有天然优势，350M 参数配合 Q8_0 量化在本地 CPU/Metal 上能跑到 80 tokens/s，这个速度体验已经非常流畅了。
74 秒跑完 46 个工具调用测试，平均每个测试 1.6 秒，也是所有受测模型里第二快的（仅次于 granite4:350m 的 41s）。
代码能力测试
工具调用之外，还用 HumanEval / HumanEval-X 对两个 LFM 模型跑了代码生成 pass@1 测试。每种语言 15 题，覆盖 Python、C++、JavaScript 三种语言，要求模型补全函数代码并通过单元测试。
测试方法：给模型 HumanEval 的 prompt，追加指令"Complete the code. Output ONLY the code, no explanation, no markdown."，temperature=0。从模型输出中提取代码块，编译/运行后检查测试用例是否通过。
| 模型 | 大小 | Python | C++ | JS | 平均 |
|---|---|---|---|---|---|
| lfm2.5-350m | 379 MB | 13% | 0% | 13% | 9% |
| lfm2.5-thinking | 697 MB | 0% | 0% | 0% | 0% |
结果很直白：两个 LFM 模型的代码生成能力都很弱。
lfm2.5-thinking（697MB，1.2B 参数）全挂——三种语言 0%。考虑到它有 thinking 机制，很可能在代码场景下思维链反而干扰了输出格式，导致提取不到有效代码，或者生成的代码虽然"看起来像"但逻辑不对。
lfm2.5-350m（379MB，354M 参数）稍好，Python 和 JS 各对了 2 题（13%），C++ 全挂。9% 的平均 pass@1 在同体量模型里属于较低水平。作为参考，之前测过的 qwen3.5 系列在同样 15 题规模下 Python 普遍在 40-70% 区间。
这说明 LFM 的混合架构（SSM + Transformer）在工具调用场景下有一定竞争力，但在代码生成这个需要精确语法和逻辑推理的任务上，跟同体量的 Dense Transformer 模型还有明显差距。如果你的使用场景需要模型写代码，LFM 系列目前不是合适的选择。
总的来看适合低成本设备
LFM2.5-350M 在 379MB 的体积下做到 50% 工具调用通过率和 50% 的 BFCL simple_python 准确率，单次工具调用能力在同体量模型中领先。但并行调用（BFCL parallel 0%）、中文（30.4%）、以及代码生成（pass@1 平均 9%）是三个明显短板。
Spark Arena 榜首的位置说明它在速度上确实有优势，但工具调用和代码生成场景下的表现跟专门的评测还是有差距。如果需要并行调用、中文工具调用或代码生成，granite4:350m-h（349MB，67.4%，中文 56.5%）仍然是更稳妥的选择。但如果你的使用场景对体积和速度敏感、以单次工具调用为主、以英文为主、不需要写代码，LFM2.5-350M 值得一试。
对于一般的低成本设备来说，LFM2.5-350M 根本不用什么 GPU，就直接用 CPU 应该就可以流畅运行了。