Liquid AI 的 LFM2.5 家族现已进入 Ertas 目录,共三种规模:230M、350M 和 1.2B。三者均为开放权重,均支持 32,768 token 的上下文窗口,运行内存都不到 1GB,并且都能在我们的入门 GPU 层级上、于免费套餐范围内完成训练。
它们都能用。真正有意思的问题是你应该选哪一个,而这件事的答案比大多数模型对比都更干 净。
简短版本: 如果模型需要维持对话,选 1.2B。如果每次请求彼此独立,选 350M 或 230M。它们之间的分界线是对话连贯性,而这条线比基准分数所暗示的要清晰得多。
| 如果你的模型需要 | 选择 | Q4_K_M 下载体积 |
|---|---|---|
| 维持多轮对话、运行智能体循环 | LFM2.5 1.2B | 731 MB |
| 调用工具、抽取字段、输出 JSON,每次一个请求 | LFM2.5 350M | 229 MB |
| 在浏览器标签页或树莓派里完成上述这些 | LFM2.5 230M | 153 MB |
| 知道很多世界知识 | 更大的模型 | 不适用 |

这个架构只有一部分是 Transformer
LFM2.5 将双门控短程卷积块与分组查询注意力块交错排列。1.2B 与 350M 均为 16 层,按 10 个卷积块比 6 个注意力块划分。230M 为 14 层,按 8 比 6 划分。
这种划分就是整个设计的核心。注意力相对序列长度是平方开 销,卷积是线性开销。把两者混合,就能让长提示词在小参数量下依然划算,而同等规模的纯 Transformer 此时已经开始为自身的注意力矩阵付出代价。这也是为什么一个 230M 的模型能承载 32,768 token 的上下文,以及为什么这些模型在 CPU 上仍能保持吞吐,而同等规模的 Transformer 会明显吃力。
整个家族的词表为 65,536 token,仅为 Gemma 3 的 256K 词表的四分之一。在这个参数量级上,嵌入表在文件体积中占比很大,因此紧凑的词表几乎完全解释了为什么一个 1.17B 的模型导出后比 Gemma 3 1B 还小。
三种规模并排对比
| LFM2.5 230M | LFM2.5 350M | LFM2.5 1.2B | |
|---|---|---|---|
| 参数量 | 230M | 350M | 1.17B |
| 层数 | 14(8 卷积 + 6 GQA) | 16(10 卷积 + 6 GQA) | 16(10 卷积 + 6 GQA) |
| 预训练预算 | 19T token | 28T token | 28T token |
| 上下文长度 | 32,768 | 32,768 | 32,768 |
| 语言数 | 10 | 9 | 8 |
| 发布日期 | 2026 年 6 月 25 日 | 2026 年 3 月 31 日 | 2026 年 1 月 5 日 |
| Ertas GPU 层级 | T4 | T4 | T4 |
| 免费套餐 | 是 | 是 | 是 |
这张表里有两件事值得停下来看看。
350M 拿到了与 1.2B 相同的 28 万亿 token 训练预算。小模型通常相对其容量而言训练不足,因为算力预算往往跟着参数量走。把一次完整规模的训练投在 350M 参数上是一个刻意的选择,而这在分数上体现了出来。
230M 是从 350M 蒸馏而来的,而不是在那个规模上从零训练,随后又经过直接偏好优化和多领域强化学习精调。它覆盖的语言也是三者中最多的,多出了意大利语。
基准数据
以下所有数字均为 Liquid AI 公布的结果,来自 LFM2.5 发布文章、350M 文章 和 230M 文章。1.2B 的对比对象与两个更小的型号不同,因此两张表分开呈现。
LFM2.5-1.2B-Instruct 对比 1B 至 1.7B 区间:

