Liquid AI 一次放出 6 个 LFM3 模型：统一骨干与端侧清单

10 月 27 日，Liquid AI 在 Hugging Face 发布 LFM3。它把文本、视觉、音频、全模态与决策模型放到同一套骨干上，并宣称所有模型都能在单张 GPU 上微调。之所以现在值得看，不只是“模型变多”，而是它把多模态模型从“各自训练”改成“共享底座再分叉”，普通开发者可以据此判断：哪些模型适合直接使用，哪些环节仍要自己准备数据和评测。

先看结论：共享骨干改变了什么

LFM3 的核心不是单独增加几个模型，而是重新组织模型家族的生产方式。官方博客介绍，LFM3-1.7B-Base 是共同起点，随后分出六个 2B 级模型，分别处理文本、视觉、音频、全模态和决策任务。

官方给出的主要变化包括：LFM3-1.7B 参数量比 LFM2.5-2.6B 少 35%，但表现超过后者；文本模型支持 256K 上下文；4-bit 精度下占用约 1GB；每个模型都可以在单张 GPU 上微调。这里的“超过”是 Liquid AI 自家比较口径，不能直接等同于所有任务都更强，但它至少说明团队把设计重点放在“每个参数能做什么”以及“能否在本地定制”。

24 层结构，数字可以自己复算

LFM3-1.7B-Base 采用 tri-hybrid 结构。官方正文列出：13 个门控短卷积层、5 个滑动窗口注意力层和 6 个全局注意力层，总共 24 层。

总层数 = 13 个门控短卷积
       + 5 个滑动窗口注意力
       + 6 个全局注意力
       = 24 层

滑动窗口长度 = 256 tokens
卷积核大小 = 7

这个结构不是简单的“把注意力换成卷积”。官方解释，滑动窗口注意力只看有限范围，全局注意力负责更远距离的信息；门控卷积则承担局部特征处理。LFM2 使用的是短卷积与注意力混合，LFM3 进一步用硬件在环的架构搜索覆盖手机、Raspberry Pi 5、笔记本、云端 CPU、GPU 和 Qualcomm Hexagon NPU 等 14 种设备与后端组合。

按官方口径推下来，LFM3 的目标场景更偏向“需要在本地持续运行的智能体”，而不是单纯追求一次性回答质量。官方还称，LFM3-1.7B 与 LFM2-1.2B 在短提示上的每参数表现相当，而上下文达到 8K tokens 时约快 25%。这属于官方基准结果，不是任何设备上的普遍速度保证。

六种模型，按输入输出选分支

官方表格给出的分支如下：

对普通用户来说，选型可以先看输入输出，而不是先看参数量：只需要文本处理，就不必承担视觉或音频模块；需要“听音频并回答”，看 LFM3-Audio-2B；需要同时接收多种输入并输出语音，才有必要看 LFM3-Omni-2B。决策模型 d1 系列也不是普通聊天模型，官方介绍它们会返回一组带概率的校准判断，而不是直接生成一段文本。

Liquid AI 的官方博客还称，LFM3-VL-2B 使用新的视觉编码器，相比前代视觉语言模型中的 SigLIP2 编码器，计算量少 3 倍；在单张 NVIDIA B300 上以 BF16 和 SGLang 运行时，生成速度超过 12,000 tokens per second。后者属于特定硬件和推理栈下的官方测试，不能直接搬到手机或普通显卡上。

微调价值在于“改任务”，不是自动得到专用模型

官方明确把 LFM3 定位为 specialized intelligence 的起点，并给出微调示例：让模型学习按照指定格式行动。用户可以针对自己的数据、术语和部署环境调整模型。

这一步很关键。共享骨干降低了“从零开始训练”的门槛，但不会自动解决三件事：

第一，数据是否覆盖目标任务。图像问答、屏幕理解和语音助手需要的数据形态不同，不能因为模型共享底座，就把一份通用指令数据当作专用训练集。

第二，输出是否可验证。文本模型可以靠人工抽查，决策模型则更需要校准和阈值；概率分数是否适合业务，必须用真实样本评测。

第三，部署链路是否完整。Hugging Face 社区中已有针对 LFM3-Omni-2B 的 Metal 实现尝试。该 GitHub Pull Request 的摘要写明，它支持 macOS 下从 WAV 输入到文本与语音输出，并提供 /v1/audio/chat 和 /health 接口。但该条目仍标为 draft，且摘要说明 Metal 与 CUDA 后端分开处理。因此，它可以作为本地部署线索，不能当成官方支持的完整生产方案。

端侧部署的收益，也有现实边界

LFM3 的 4-bit 文本模型约 1GB，确实适合把部分推理放到设备上。256K 上下文、长上下文下的速度优化，以及视觉和音频编码器的更新，说明 Liquid AI 并不是只面向云端。

但“约 1GB”不能理解为所有模型都只需 1GB。视觉模型还包含视觉编码器，音频模型还包含音频编码器、解码器和 LiquidCodec；Omni 模型同时组合多套组件。实际占用还取决于量化格式、KV cache、上下文长度、推理框架和设备支持。

因此，部署前应把清单写成这样：

model: LFM3-VL-2B
input: [text, image, video]
output: text
quantization: 4-bit
device: edge-or-desktop
runtime: verify-supported-backend
context: test-before-increasing
acceptance:
  - latency
  - memory
  - output-quality

这是一份配置模板，不是官方可直接执行的 YAML 文件。它提醒开发者先固定输入、输出、量化方式和验收指标，再决定使用哪一个模型。Hugging Face 首页目前也把模型、数据集和在线应用放在同一平台中，模型权重可通过 Hugging Face 模型库 获取；具体使用方式仍应以模型仓库和许可证文件为准。

许可证可能比模型大小更先决定能不能用

LFM3 的开放权重不等于没有使用门槛。Liquid AI 的 GitHub 项目摘要明确提到 LFM Open License v1.0，并注明商业使用限制为年营收低于 1000 万美元；同一篇官方博客的中文译本也写明了这条限制。

这是许可证条款层面的信息，不能简单称为“完全开源”。如果你的组织年收入超过这一门槛，或者计划把它嵌入商业产品，应该先逐条检查许可证正文，包括商用、再分发、托管服务和衍生模型的要求。这里的金额门槛是许可证摘要中写明的条件，不是我根据模型规模推算出来的成本。

还要区分“官方事实”和“使用建议”：官方说模型可在单张 GPU 上微调，这是事实；“你的项目就应该微调”则是我的判断。我的经验判断是，只有当固定模型在真实任务上的错误模式稳定、数据量足够、评测集已经准备好时，微调才值得做。否则，先做提示、检索和后处理改造，可能更便宜，也更容易验证。

参考来源

• Liquid AI 发布 LFM3：六个约 20 亿参数的开放权重多模态模型，主打端侧

• Liquid AI：Build specialized multimodal models with LFM3，Hugging Face，2026-10-27

• Liquid AI：Introducing LFM3: Every Modality for Specialized Intelligence，2026-10-26

• Hugging Face 模型库

• TensorFold：LFM3-Omni-2B on Metal 社区实现尝试