LFM3：六个 20 亿级模型，为什么要共用一个底座
Liquid AI 在 2026 年 10 月 27 日发布了 LFM3：先训练一个 1.7B 参数的语言底座，再从它分化出文本、视觉、音频、全模态和决策模型。六个可直接使用的模型都在 20 亿参数量级，权重和多种本地部署格式已经公开。
这次更新值得关注，不是因为“又有一个小模型”，而是因为它给出了另一种端侧多模态路线：不让一个大模型勉强处理所有输入，而是让一组小模型共享语言核心，各自在外面接适合图像或声音的部件。你可以只下载任务真正需要的那一支，也可以在相同底座上继续微调。
不过，“开放权重”“256K 上下文”和“约 1 GB”都容易被读得过头。本文会把架构、使用路径和限制分开讲；性能数字均来自 Liquid AI 的模型卡与发布资料，不视为独立测评。为确认最基本的部署链路，我还在纯 CPU 环境中运行了官方 Q4_K_M GGUF，结果放在后文。
六个模型，不是一个模型的六种名字
LFM3-1.7B-Base 是共同起点。发布页面列出的六个成品模型如下：
| 模型 | 输入 | 输出 | 额外部件或训练目标 |
|---|---|---|---|
| LFM3-1.7B | 文本 | 文本 | 对话、工具调用和 Agent 场景的后训练 |
| LFM3-VL-2B | 文本、图像、视频 | 文本 | 视觉编码器 |
| LFM3-Audio-2B | 文本、音频 | 文本、语音 | 音频编码器、解码器与 LiquidCodec |
| LFM3-Omni-2B | 文本、图像、视频、音频 | 文本、语音 | 视觉与音频部件同时接入 |
| d1-2B | 文本、图像、视频 | 校准后的判断 | 基于 LFM3-VL-2B 的决策训练 |
| d1-omni-2B | 文本、图像、视频、音频 | 校准后的判断 | 基于 LFM3-Omni-2B 的决策训练 |
这里的“一个底座”更像同一款底盘，而不是同一辆车。视觉模型仍要安装摄像头对应的视觉编码器，音频模型也需要把波形转换成 token、再把 token 还原成语音的组件。共享底座能降低分别从零训练的成本，却不会让文本权重凭空获得看图和听声音的能力。
这个区别会直接影响下载和部署：只做结构化文本抽取，用 LFM3-1.7B 就够了；既要看图又要听语音，才有理由承担 Omni 分支的额外依赖。六个模型也不是一次加载后随时切换的“模式”，而是不同检查点。
三种层各做什么
LFM3-1.7B 有 24 层，Liquid AI 称其为 tri-hybrid，也就是三种计算层混排：
- 13 层 gated short convolution，卷积核大小为 7；
- 5 层 sliding-window attention，窗口为 256 个 token；
- 6 层 global attention。
可以把它想成读一份很长的维修记录。
短卷积像不断扫过相邻几行的值班员，擅长发现局部组合，成本不会随全文长度急剧增加；滑动窗口注意力像每次查看当前页前后的内容，能连接一段范围内的信息；全局注意力则像少数几次翻阅整本档案，负责远距离关联。
纯全局注意力让每个 token 都与其他 token 比较，长文本的计算和缓存代价很高。LFM3 用较多局部层处理日常信息，把更昂贵的全局观察留给少数层。这不保证它一定比同规模 Transformer 更准确，但解释了它为什么把长上下文和端侧推理放在同一套设计里。
架构还有三个细节：
- 逐头门控注意力：每个注意力头的输出先经过 sigmoid 门。某个头没有贡献时，可以降低自己的输出；Liquid AI 还认为这有助于抑制不利于量化的异常激活。
- Partial RoPE：全局注意力只给每个头中高频的一半维度施加旋转位置编码，另一半更偏向按内容匹配；滑动窗口层仍使用完整 RoPE。
- Sandwich norm：每个块在输入与输出两侧都做归一化，控制激活尺度。
这些机制共同服务于“用较小模型处理较长任务”，但不要把结构上的节省直接等同于端到端效果。模型卡写明，LFM3-1.7B 有 1.73B 参数、128K 词表和 256K token 的输入输出总窗口；这说明接口容量，不说明任意放入 256K token 都能被可靠记住和利用。
22T token 训练了什么
据 Liquid AI 披露，Base 模型的预训练总量为 22T token，最后 3.5T token 属于中期训练，增加了 Agent 轨迹与工具调用数据，并把上下文扩展到 256K。文本成品模型随后经历监督微调、混合强化学习、多领域在线蒸馏和 Agent 强化学习。
这解释了为什么模型卡把它定位为本地 Agent、工具调用、结构化输出和领域微调，而不只是聊天模型。它的 chat template 也直接支持工具 schema，并设计了延迟加载工具定义的格式，避免把庞大的工具目录全部塞进每次提示词。
但训练量不是质量证明。Liquid AI 给出了 WebArena-Verified、BFCL、SWE-bench 等大量结果，也列出了采样参数、最大步骤和推理后端；这些仍然是模型开发方自己的评测。尤其是 Agent 基准会受到脚手架、工具描述、最大步数和重试策略影响，不能仅凭表格断言 1.7B 模型普遍胜过更大的模型。
本地烟雾测试：Q4_K_M 能否真的跑起来
官方提供 BF16、FP8、NVFP4、GGUF、MLX 和 ONNX 等变体。为了验证最容易复现的 CPU 路径，我使用 LFM3-1.7B 的 Q4_K_M GGUF，并从源码构建支持 LFM3 的 llama.cpp。
测试环境与版本如下：
| 项目 | 本次环境 |
|---|---|
| 系统架构 | Linux x86_64 |
| 处理器后端 | llama.cpp CPU，未启用 GPU |
| 可用内存 | 约 9.7 GiB |
| llama.cpp | commit 338fce6511c744893cc0d3d958b275f40552c7a4 |
| 模型文件 | LFM3-1.7B-Q4_K_M.gguf |
| 文件大小 | 1,099,627,808 字节 |
下面的命令按本次测试版本固定了 llama.cpp commit，并使用 Hugging Face 的直链下载模型：
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
git checkout 338fce6511c744893cc0d3d958b275f40552c7a4
cmake -B build
cmake --build build -j --target llama-cli
curl -L -o LFM3-1.7B-Q4_K_M.gguf \
https://huggingface.co/LiquidAI/LFM3-1.7B-GGUF/resolve/main/LFM3-1.7B-Q4_K_M.gguf
./build/bin/llama-cli \
-m LFM3-1.7B-Q4_K_M.gguf \
-p '只用两句话解释滑动窗口注意力和全局注意力的区别，不要使用比喻。' \
-st \
-n 128 \
--temp 0.1 \
--top-k 50 \
--repeat-penalty 1.1 \
--reasoning off2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
我给模型的中文问题是：
只用两句话解释滑动窗口注意力和全局注意力的区别，不要使用比喻。
模型在 CPU 上成功载入并按要求输出两句中文，说明模型文件、聊天模板和该版本 llama.cpp 的基本兼容链路可用。这里刻意只把它称作烟雾测试：一个问题不能衡量事实性、中文水平、工具调用、256K 长上下文，更不能复现厂商的速度或 Agent 基准。关闭思考轨迹是为了让短输出约束更稳定，不代表所有任务都应这样设置。
“4-bit 约 1 GB”说的是量化权重的大致占用，不是应用运行时的总内存。上下文缓存、执行图、程序本身以及更长提示词都会继续消耗内存；实际产品还要在目标手机、树莓派或笔记本上测峰值，而不是只看下载文件大小。
该选哪一支
如果目标明确，选择可以从输入和输出倒推：
| 任务 | 优先尝试 | 理由 |
|---|---|---|
| 离线文本抽取、JSON 生成、简单工具路由 | LFM3-1.7B | 依赖最少，GGUF 与 ONNX 路径齐全 |
| 设备端看图问答或短视频理解 | LFM3-VL-2B | 不必加载音频组件 |
| 语音转文字、语音回答或边说边生成 | LFM3-Audio-2B | 支持因果音频编码与流式语音生成 |
| 图像与语音需要同时进入同一次对话 | LFM3-Omni-2B | 同时接入视觉与音频部件 |
| 需要输出带置信度取舍的视觉判断 | d1-2B / d1-omni-2B | 训练目标针对决策校准，不等同于通用聊天 |
最现实的起点通常不是 Omni，而是能覆盖需求的最小分支。多一个模态就多一套预处理、依赖、延迟和测试面；“以后可能用到”不足以抵消当前的工程成本。
三条必须保留的边界
1. 小模型适合窄任务，不是廉价替代所有大模型
模型卡明确建议：知识密集型任务应配合检索或搜索；由于规模较小，不推荐把 LFM3-1.7B 用于 Agent 编程或复杂多步推理。它更适合流程受控、输出格式明确、失败可以检测的任务。
把模型装进工具框架，也不会自动得到可靠 Agent。应用仍要验证参数、限制权限、设置超时和重试上限，并为外部动作保留审计记录。
2. 六个分支的上下文和能力并不完全相同
文本模型标注 256K 上下文，音频模型卡则标注 32K 输入输出总窗口。语音还涉及 16 kHz 输入、24 kHz 输出及编解码开销。不能把文本分支的规格复制到整个家族，也不能用文本 GGUF 的运行结果替多模态分支背书。
3. 开放权重不等于无限制的开源许可证
LFM3 使用 LFM Open License v1.0。许可证允许研究、修改和再分发，也允许年收入低于 1000 万美元的主体进行商业使用；达到或超过这一门槛的法律实体，其商业使用不在该协议授权范围内。再分发还要保留许可证、修改说明和归属信息。
因此，个人研究和小团队试用的门槛较低，但大型公司不能只因为模型文件可下载，就把它当作 Apache-2.0 或 MIT 权重。真正进入产品前，应让法务按主体收入、使用方式和衍生分发路径核对许可证。
值不值得上手
LFM3 最值得试的，不是“20 亿参数挑战大模型”，而是同一语言底座能否让一组专用小模型更容易训练、部署和维护。如果你的任务需要离线运行、数据不宜离开设备、输出结构明确，或者要在单一模态上做领域微调，它提供了较完整的起点。
如果需求是复杂编程、开放式研究、强事实问答，或者只想找一个模型包打全部，LFM3-1.7B 的体量和模型卡自己的警告都说明它不是稳妥替代品。更合理的做法是先用真实数据做一个窄评测：准确率、拒答、工具参数、峰值内存和延迟都过线，再决定是否扩到视觉、音频或 Omni 分支。
💬 评论