Liquid AI 推出六款轻量多模态开放权重模型

小模型能不能承担 Agent 的实际工作？Liquid AI 发布的 LFM3 给出的答案是：工具调用、网页操作等任务可以优先尝试，但知识问答和代码修复仍有明显短板。这一系列包含 6 个开放权重、约 2B 参数的模型，覆盖文本、视觉、音频和决策任务。

对前端和全栈开发者，值得看的是它怎样把模型做小，以及省下的资源能换来什么。原文同时留下两个需要核对的地方：成绩主要来自 Liquid 自评，「约 1 GB 内存」也不能当成完整应用的运行预算。

6 个模型共用底座，重点放在本地任务

LFM3 的 6 个模型都从 LFM3-1.7B-Base 出发，共用一套骨干网络，再面向不同任务训练：

• LFM3-1.7B 面向文本和本地 Agent，针对 Hermes Agent、Pi、OpenClaw 等运行框架做了后训练。
• LFM3-VL-2B 接收图像和视频，视频按 2 fps 采样。
• LFM3-Audio-2B 支持 18 种语言的语音输入、输出和工具调用。
• LFM3-Omni-2B 结合视觉、音频和语言，可以用文字或语音回答。
• d1-2B、d1-Omni-2B 面向决策任务，一次前向计算回答多个问题。

这里的「一次前向计算」，可以理解为模型执行一轮计算就产生多项判断，区别于逐个问题分别调用。原文没有展开它的输入格式和使用限制。

「2B 级」也不是精确参数量：文本模型为 1.73B，视觉模型为 1.92B，Omni 为 2.2B；前两者的上下文窗口分别是 256K、128K。报道说每个模型都能在单张 GPU 上微调，但没有给出各型号对应的显存、训练配置和耗时，不能据此推断普通消费级显卡都能轻松训练。

小模型靠什么把 Agent 成绩拉起来

LFM3 没有让所有层都执行同一种计算。它的 24 层混合了三种算子：13 层门控短卷积、5 层滑动窗口注意力、6 层全局注意力。滑动窗口为 256 tokens，卷积核从 3 扩大到 7。

这种安排让局部处理和全局关联分工：部分层只处理邻近信息，部分层负责更大范围的联系。具体组合来自把真实设备纳入测试的架构搜索。LFM2 只针对 1 部手机和 1 台笔记本调优，LFM3 扩大到 14 种设备与后端组合，包含 Raspberry Pi 5 和 Qualcomm Hexagon NPU。

其他改动包括按注意力头设置 sigmoid 门、全局层使用 partial RoPE，以及 sandwich norm。不过，原文没有拆分这些改动各自贡献了多少收益。

训练方向同样偏向 Agent。底座训练使用 22T tokens，最后 3.5T 是 Agent 数据占比较高的中期训练，同时把上下文扩展至 256K。后训练分四步：先进行 1.75T tokens 的监督微调（SFT），接着是混合强化学习，再把 6 个专长教师模型蒸馏进一个模型，最后进行 Agent 强化学习。

这些投入对应到 Liquid 自评，优势确实集中在指令遵循和执行任务上：

测试	LFM3-1.7B	Qwen3.5-9B
AutomationBench	41.29	15.10
WebArena-Verified	38.42	28.94
BFCL V4	71.39	62.83
GPQA Diamond	63.37	80.40
SWE-bench Verified	43.40	51.20
RULER 128K	65.56	87.11

LFM3-1.7B 的 IFEval 为 96.66，29 项基准均分为 49.37，高于 Qwen3.5-9B 的 47.24。但表格后半段也表明，知识、代码修复和长上下文使用能力仍有差距。Humanity’s Last Exam 无工具时只有 7.17，加入工具后升到 13.90。

更长的上下文窗口，不等于模型能可靠利用窗口里的全部信息。

约 1 GB 能装下权重，运行还要算另一笔账

原文称模型采用 4-bit 量化后约占 1 GB 内存，并提供 GGUF、MLX、ONNX、FP8、NVFP4 检查点。部署运行时包括 llama.cpp、MLX、vLLM、SGLang、Ollama 和 Transformers；其中，文档明确列出文本和视觉模型的 GGUF、MLX、ONNX 支持。

但不能把「约 1 GB」和「256K 上下文」直接拼成最低运行要求。Liquid 的端侧测试使用 llama.cpp、Q4_0 量化和 32K 上下文；完整 128K 上下文仅 KV cache 就需要 1.6 GB，Qwen3.5-4B 对应为 4.3 GB。KV cache 是推理时保存历史计算结果的缓存，也会消耗内存。

服务端则是另一种测试条件：在单张 NVIDIA B300 上使用 SGLang，1,024 个并发请求下，LFM3-1.7B 每天生成 3.6B tokens。原文没有交代请求长度、首 token 延迟等细节，这个吞吐量不能直接换算成自己的服务容量。

多模态成绩也要按任务看。LFM3-VL-2B 在 62 项视觉基准上平均为 71.4，接近 Gemma 4 12B 的 71.7；视觉定位为 77.3、GUI 理解为 83.1，但视频为 61.2、Agent 任务为 42.5，仍落后于更大的 API 模型。Audio 的英语词错误率 WER 为 6.2，语音合成 UTMOSv2 为 3.8；Omni 在 Daily-Omni 上为 70.1，对照 Qwen2.5-Omni-7B 为 61.3。这些分数各自有测试范围，不能合成一句「多模态全面领先」。

我的判断

我认可这条路线：先明确任务，再针对设备和训练数据优化，小模型有机会成为本地工具调用、界面理解和固定流程自动化的候选。它也没有证明自己能普遍替代大模型。代码修复和知识测试中的差距，已经给出了边界。

所有主要对比都来自 Liquid 自评，原文没有提供独立复现，也没有证明架构、数据和后训练分别贡献多少。官方报告它比 LFM2.5-2.6B 少 35% 参数且成绩更好，可以作为选型线索，不能直接当成生产效果保证。

专用微调同样需要保留判断：他们在单张 A100 上做了几小时 SFT 和 GRPO，把风机缺陷分类提升到 67%，但缺少初始成绩、数据规模和对照方案。d1-2B 比 d1-3B 少三分之一参数，Decision Bench 从 83.6 升到 85.2，也仍需具体业务验证。

另外，开放权重不等于 Apache 2.0。LFM3 使用 LFM Open License v1.0，免费商业使用有年营收 $10M 门槛；原文没有讲清超过门槛后的完整授权条件。

能拿来做什么

• 做 Node Agent 时，可以先选工具参数生成、网页操作等明确任务，用现有调用样本对比 LFM3-1.7B 和当前模型，记录成功率、延迟及重试次数。
• 评估本地部署时，把量化权重、目标上下文的 KV cache 和应用开销分别计算，先按实际输入长度测试，再考虑是否需要 128K 或 256K。
• 做截图理解或 GUI 自动化时，可以把 LFM3-VL-2B 列入候选；涉及视频时，要检查 2 fps 采样能否覆盖任务中的关键变化。
• 用于商业产品前，核对 LFM Open License v1.0 的营收门槛，并把授权条件纳入与 Apache 2.0 模型的选型比较。