Liquid AI 推出小参数多模态模型家族

Liquid AI 这次发布 LFM3，重点是用同一个基础模型，衍生出文本、视觉、音频和决策等多种产品。按公司的说法，其中的文本模型参数比上代少了 35%，性能却更好，还提供了 256K 上下文窗口。

对程序员来说，值得关注的是小模型能否承接更多任务。但这篇消息提供的证据很有限：架构细节、评测项目和部署成本都没有展开。可以把它当作一个模型选型线索，还不能直接当作替换现有方案的依据。

六款产品共用底座，发布重点在哪里

据 IT之家 10 月 28 日报道，Liquid AI 于当地时间 27 日发布 LFM3 模型家族。首批产品均基于 LFM3-1.7B-Base，覆盖六个方向：

产品	原文标注的方向
LFM-1.7B	文本
LFM3-VL-2B	视觉
d1-2B	决策
LFM3-Audio	音频
LFM3-Omni-2B	全能
d1-Omni-2B	全能决策

理解这次发布，要区分基础模型与衍生产品。LFM3-1.7B-Base 是它们共同的底座，但共用底座，不代表六款产品拥有相同的输入方式、接口或部署要求。

原文没有解释「决策」「全能决策」具体对应什么任务，也没有给出调用示例。仅凭名称，不能认定它们具备工具调用、自动执行操作或完整 Agent 工作流的能力。

另一个容易看混的地方是命名：原文把文本产品写作 LFM-1.7B，把基础模型写作 LFM3-1.7B-Base。这里保留原文写法，不能自行认定两者是同一个可下载或可调用的型号。

参数少了 35%，为什么还不能直接判断更划算

LFM3 的技术信息集中在两点：采用全新的三混合层架构，并在 22T 词元上完成预训练。词元是模型处理文本时使用的切分单位，22T 描述的是训练规模，不是上下文长度。

至于「三混合层」究竟混合了哪些结构，各自负责什么，原文没有说明。因此，我们只能确认公司强调了架构变化，无法据此解释它为什么更快、更省或更准确。

更直接的比较来自 Liquid AI 的表述：LFM-1.7B 提供 256K 上下文窗口，在使用的参数减少 35% 的同时，性能优于上代 LFM2.5-2.6B。

参数更少、性能更好，目前是厂商结论，原文没有给出可复核的评测结果。

这里至少缺少两个判断条件。第一，「性能」指哪些任务，是知识问答、代码生成，还是其他测试？第二，比较是否采用相同的推理设置？这些信息不齐，就不能把总体表述套到自己的业务上。

256K 也需要单独看。上下文窗口表示一次能够容纳的信息规模，并不自动保证模型能准确利用其中每一段内容。原文没有提供长文本检索、跨段推理或长代码输入的测试，也没有说明接近窗口上限时的资源消耗。

我的判断

我认为，这次发布最有价值的信号，是 Liquid AI 继续尝试用较小的共同底座覆盖多种任务。如果后续评测能够支持其性能主张，这类模型值得进入选型名单。

但现有消息还不足以支撑工程决策。它没有给出实测过程，谈不上独立验证；也没有披露延迟、吞吐量、内存占用、价格或部署条件。参数量只是成本判断中的一个因素，不能直接折算成实际节省。

与继续使用现有模型相比，切换方案还要考虑任务准确率和接入成本。对前端、全栈团队尤其如此：这篇消息没有代码能力数据，不能因为它是新一代模型，就推断它更适合改组件、排查 Node 问题或理解整个仓库。

能拿来做什么

• 把 LFM-1.7B 加入候选模型清单，等明确可用方式后，用团队已有的真实任务与当前模型做同题比较，记录正确率、响应时间和资源消耗。
• 如果关注 256K 上下文，可以准备一份长文档测试，检查模型能否找到分散的信息并正确关联；不要只验证输入是否能成功提交。
• 按实际输入类型筛选产品。处理文本先关注文本型号，涉及图片或音频再核实对应产品的能力、接口与部署要求，避免仅凭「全能」名称做选择。