Liquid AI发布LFM3：6款2B级开源多模态模型

Liquid AI再推小模型矩阵：LFM3一次放出6款2B级开源权重模型

Liquid AI发布了LFM3系列，一次性推出6款开源权重模型，均定位在2B参数级别，覆盖文本、视觉、音频、全模态（omni）和决策（decisions）等方向。这一动作延续了该公司押注「小尺寸、高可用性」模型的路线。

一次发布，覆盖五种模态

从官方披露的信息看，LFM3并非单一模型，而是一个模型家族：6款模型分别对应不同的输入输出形态。文本、视觉、音频是当前多模态产品最常组合的三条能力线，而「omni」意味着单模型同时处理多种模态，「decisions」则指向决策类任务——后者在开源小模型中相对少见，值得关注其具体任务定义与评测方式。

把多模态能力下放到2B级别，是这组模型最核心的产品逻辑。参数量小意味着推理成本低、部署门槛低，适合端侧或边缘场景；但多模态能力在小参数下往往伴随能力折损，实际表现需要等独立评测验证。

「开源权重」（open weights）与「开源软件」并非同一概念：前者通常只公开训练完成的模型参数，不公开训练数据、训练代码或完整配方。因此使用者的权利完全取决于许可证条款——是否允许商用、是否允许再分发微调后的模型、是否要求署名或开放衍生模型。对于计划将模型嵌入产品的团队，许可证往往比基准分数更具决定性。

「全模态模型」（omni）指用单一模型同时接受并生成文本、图像、音频等多种模态，而非由多个专用模型拼接成流水线。其优势是跨模态信息可在同一参数空间内交互，劣势是各模态能力可能互相挤占，且难以针对单一模态做精细化优化。这正是判断 omni 与专用文本/视觉/音频模型如何取舍的关键。

LFM3-1.7B：三混合骨干与256K上下文

官方重点介绍了LFM3-1.7B这一型号。它采用tri-hybrid（三混合）骨干结构，支持256K上下文窗口，并且在4-bit量化下体积约为1GB。

这三点组合起来指向同一个目标：在极小体积内保留长上下文能力。256K上下文在2B级模型中并不常见，而「约1GB@4-bit」意味着它可以放进内存受限的设备。tri-hybrid骨干是Liquid AI的技术标签，其具体混合了哪几类层、各自承担什么角色，官方素材未展开，但从命名看应是对不同序列建模机制的组合，用以在效率与表达能力之间取得平衡。

混合骨干（hybrid backbone）是近年序列建模的一个活跃方向，其基本思路是在同一网络中组合不同类型的层——常见组合包括标准注意力层、线性注意力/状态空间模型（SSM）层以及卷积或门控线性单元层。纯 Transformer 的注意力计算随序列长度呈二次增长，长上下文代价高昂；而线性注意力或 SSM 层能以接近线性的复杂度处理长序列，但在精确召回与复杂推理上往往弱于全注意力。混合架构通过让多数层走廉价路径、少量层保留全注意力，在效率与表达能力之间做权衡。业界已有 Mamba-2/Transformer 混合、Jamba 等实践。

4-bit 量化指将模型权重从 16 位浮点压缩到 4 位整数或低比特浮点表示，可将显存占用降至约四分之一，是端侧部署的关键手段。但量化会引入精度损失，尤其在长上下文与多模态任务中可能放大误差，因此「1GB@4-bit」只是体积指标，并不等同于该精度下的质量保证。

对开源小模型赛道的意义

开源权重+小参数+多模态，这三个条件叠加，直接对标的是一批正在把多模态能力压缩到端侧的团队。对开发者而言，真正有价值的不只是「能跑」，而是许可证条款、微调友好度、以及各模态下的实际质量。

目前可获得的信息集中在模型规格层面：6款模型、2B级、1.7B型号的骨干结构、上下文长度与量化体积。至于训练数据构成、基准测试成绩、许可证细节，原始素材均未涉及，这些恰恰是决定模型能否被生产环境采用的关键。

端侧（on-device）部署指模型直接运行在手机、笔记本、嵌入式设备或边缘服务器上，而非调用云端 API。其约束不只是内存：还包括功耗预算、首 token 延迟、持续推理时的发热，以及隐私合规要求。2B 级模型在 4-bit 量化后约 1GB，理论上可装入中高端移动设备的内存，但 256K 上下文所需的 KV 缓存会随序列长度线性增长，长上下文场景下的实际内存占用远高于权重体积，这是评估「能否真正端侧长上下文」时容易被忽略的一点。

待观察的问题

第一，6款模型的能力边界是否清晰——尤其是「omni」与单独文本/视觉/音频模型之间是否存在能力重叠与取舍。第二，决策类模型的任务范畴需要明确定义，否则难以评估其实用价值。第三，256K上下文在1.7B模型上的实际有效长度，通常与标称值存在差距。

LFM3的发布说明小模型的多模态竞赛仍在加速。规格已经摆上台面，接下来要看的是评测数据与真实部署反馈。