LFM3上新，专攻垂直多模态

Liquid AI 近日发布 LFM3，并把新一代模型的重点明确放在“专用多模态”上：开发者不必从头训练视觉、文本等不同模态的基础能力，而是可以围绕自己的行业数据、任务边界和部署硬件，构建更小、更快、也更可控的垂直模型。

**LFM3 是 Liquid AI 面向垂直场景推出的新一代多模态基础模型与定制化构建路径。**截至 2026 年 10 月 27 日，官方在 Hugging Face 发布的技术文章 中，讨论重点并不是再造一个覆盖所有任务的聊天机器人，而是如何把基础多模态能力压缩进一个目标明确的专用系统。

这件事值得关注，因为行业模型的问题早已不是“有没有一个更大的模型可用”。真正困难的是：模型能否识别企业自己的产品、理解内部术语、适应摄像头或传感器数据，并在手机、机器人、汽车、工业边缘盒子等受限硬件上稳定运行。

LFM3不想再做一个万能聊天机器人

**LFM3 的产品定位是缩短通用多模态基础能力与行业生产系统之间的距离。**与 GPT、Gemini、Claude 这类云端通用模型相比，LFM3 更强调任务收敛、部署效率和数据控制，而不是用一个模型覆盖写作、编程、搜索、数学与视觉问答等全部场景。

所谓专用多模态模型，是指围绕有限任务集合、特定数据分布和明确输入模态训练或适配的模型。例如，零售巡检模型只需要理解货架图片、商品名称和陈列规则；设备维护模型更关心仪表照片、维修手册与故障代码；车载助手则需要同时处理语音、道路画面、地图状态和车辆信号。

这类模型通常不需要在所有通用基准上拿第一，但必须在自己的业务分布上足够可靠。一个能回答研究生物理题、却经常认错企业零件编号的模型，对工厂没有实际价值；一个视觉问答分数很高、但首个 token 要等数秒的模型，也很难进入机器人控制链路。

**Liquid AI 对 LFM3 的判断，本质上是把“大模型能力”重新拆成可以被业务约束的组件。**模型需要理解哪些模态、输出什么格式、允许多长延迟、占用多少内存以及在哪类芯片上运行，都应该在训练前确定，而不是等模型做好后再想办法塞进产品。

从LFM到LFM3，路线越来越现实

**Liquid AI 一直在尝试用非纯 Transformer 路线降低长序列和端侧推理成本。**公司早期 LFM 系列包括 1B、3B 和 40.3B MoE 等不同规模，其中 40.3B 混合专家模型每次推理激活约 12B 参数；之后的 LFM2、LFM2.5 又进一步覆盖小参数语言模型、视觉语言模型和端侧部署格式。

早期 LFM-3B 曾把较低内存占用作为卖点，在特定测试配置中占用约 16GB，而对照的 Llama 3.2 3B 配置超过 48GB。这个数字不能直接外推到 LFM3，因为量化方式、上下文长度、批量大小和推理框架都会显著影响内存，但它解释了 Liquid AI 为什么一直把“真实硬件约束”放在产品叙事中心。

**LFM3 延续的不是单纯缩小参数规模，而是让模型更容易被改造成行业系统。**从通用模型到专用模型，参数量只是成本的一部分；训练数据是否干净、视觉与文本是否正确对齐、输出能否被业务软件稳定解析，往往比多出几十亿参数更重要。

| 模型阶段 | 已知代表规模或型号 | 主要方向 | 对开发者的意义 | |---|---:|---|---| | 第一代 LFM | 1B、3B、40.3B MoE | 探索高效架构、长上下文与低内存推理 | 证明非纯 Transformer 路线可以兼顾质量与效率 | | LFM2 / LFM2.5 | 350M、700M、1.2B、2.6B，以及 450M、1.6B、3B 视觉语言模型 | 端侧语言与视觉任务，覆盖 GGUF、MLX、ONNX 等部署生态 | 把模型推进手机、电脑和边缘设备 | | LFM3 | 具体型号以官方模型卡为准 | 围绕垂直数据构建专用多模态模型 | 从“下载模型”转向“构建业务模型” |

需要强调的是，**“Liquid”这个品牌不等于所有模型都可以简单概括为传统液态时间常数网络。**Liquid AI 的生成式基础模型采用了为效率重新设计的计算结构和混合式思路，具体算子、注意力比例与训练配置仍应以每个 LFM3 模型卡和技术说明为准。把 LFM3 直接描述成“会流动的神经网络”，听起来直观，但技术上并不严谨。

专用多模态模型难在数据，不在接入界面

**LFM3 能否真正进入企业，首先取决于多模态数据的组织质量。**文本模型可以从连续语料中学习统计关系，但垂直多模态训练还要处理图片与文字错配、时间不同步、标签粒度不一致，以及同一对象在不同设备上成像差异巨大等问题。

以工业质检为例，一张产品图片可能同时对应生产批次、设备参数、缺陷类型和维修记录。如果训练数据只写着“有问题”，模型很难学会划痕、变形、装配偏移和光照反射之间的差别。更有效的数据应该明确目标区域、缺陷类别、判断依据和处理动作，让模型学习一条完整的业务因果链。

**垂直多模态训练的关键不是把所有企业文件一次性喂给模型。**更合理的流程通常包括四层：先确定任务边界，再清洗和对齐数据，随后进行领域适配与指令训练，最后用真实业务分布做评测和回归测试。

1. 任务定义：明确模型需要分类、抽取、描述、定位还是生成操作建议。
2. 模态对齐：确保图片、文本、音频或传感器记录属于同一个事件和时间窗口。
3. 领域适配：让模型掌握行业术语、对象类别和数据风格，而不是只记住少量模板。
4. 行为对齐：约束输出格式、拒答边界、风险提示和工具调用条件。
5. 部署评测：在目标 CPU、GPU 或 NPU 上测试延迟、内存、功耗与持续运行稳定性。

**专用模型的评测也不能只看通用视觉问答分数。**医疗影像模型应该关注病灶召回率、误报率和跨设备一致性；零售模型需要测 SKU 识别率、遮挡条件下的准确率与单张图片处理延迟；机器人模型则必须考虑连续视频输入后的累计延迟和内存是否持续增长。

LFM3 的价值因此不在于让企业跳过数据工程，而在于降低基础模型部分的重复投入。开发团队仍然需要完成数据治理、训练策略、评测集建设和上线监控，只是不必从零训练视觉与语言的底层表征。

与通用闭源模型相比，LFM3赢在哪里

**LFM3 与头部闭源多模态模型不是简单的能力替代关系。**如果需求是开放式问答、复杂推理、联网搜索或快速验证产品，成熟云端模型通常仍然更省事；如果需求涉及本地数据、固定任务、低延迟和批量部署，专用模型才更有吸引力。

| 比较维度 | LFM3专用多模态路线 | 通用闭源多模态模型 | 传统单任务视觉模型 | |---|---|---|---| | 任务范围 | 围绕特定行业和业务收敛 | 覆盖广泛，开放式能力更强 | 通常只完成分类、检测或分割 | | 数据控制 | 可按模型许可与部署方案保留在本地环境 | 数据通常需要进入云端服务 | 可完全本地训练和部署 | | 输出能力 | 可结合视觉理解、文本生成和结构化结果 | 生成与推理能力强 | 输出结构固定，生成能力弱 | | 部署成本 | 前期适配成本较高，规模化后可摊薄 | 接入快，长期成本随调用量增长 | 推理便宜，但新增任务往往要重训 | | 硬件适配 | 强调端侧、边缘和受限设备 | 主要由服务商管理云端算力 | 在固定硬件上通常效率较高 | | 可控性 | 可针对任务做训练、量化和输出约束 | 可调范围受服务接口限制 | 高度可控，但泛化能力有限 | | 最适用场景 | 工业、零售、车载、机器人、私有知识场景 | 通用助手、内容生产、复杂推理 | 成熟且边界稳定的感知任务 |

**LFM3 最有可能替代的不是旗舰通用模型，而是企业内部拼接起来的多模型流水线。**过去，一个质检系统可能需要目标检测模型找出零件、OCR 模型读取编号、分类器判断缺陷，再由语言模型生成说明。专用多模态模型如果能把这些步骤合并，就有机会减少中间数据转换、模型调度和错误传递。

不过，合并模型也会带来新的风险。单任务模型的错误通常容易定位，而端到端多模态模型出现错误时，很难判断是视觉编码、跨模态对齐还是生成环节出了问题。企业不能因为模型输出了一段流畅解释，就默认其视觉判断可靠。

真正的考题是端侧部署

**LFM3 能否兑现差异化，最终要看它在目标硬件上的真实数字。**参数量小并不自动等于推理快，模型结构、内存访问、KV 缓存、图像分辨率、视觉 token 数量和运行时优化都会改变结果。

多模态模型尤其容易被视觉 token 拖慢。输入一张高分辨率图片时，视觉编码器可能生成数百甚至数千个 token；连续视频则会让序列快速膨胀。如果模型只在短文本基准上表现高效，却没有解决视觉输入带来的内存和吞吐问题，它仍然难以进入实时设备。

**开发者评估 LFM3 时至少应该记录六个数字：首 token 延迟、每秒输出 token、峰值内存、视觉输入处理时间、持续运行功耗和目标任务准确率。**这六项数据必须在同一硬件、同一量化精度和同一输入规格下测量，否则不同模型之间的对比没有意义。

截至目前，官方文章的核心是模型构建方法与产品方向，而不是一张覆盖所有竞品的统一排行榜。官方也没有在该文章中给出可以直接横向比较的统一云端价格，因此现阶段不宜用“性能提升多少倍”或“成本降低多少百分比”概括 LFM3。对企业而言，等待模型卡、权重许可、训练配方和设备实测结果，比只看发布文案更重要。

哪些团队值得现在就试

**拥有独有多模态数据的团队最值得优先评估 LFM3。**如果企业只有公开文本，直接使用成熟通用模型或较小语言模型通常更划算；如果企业积累了大量设备图片、维修记录、产品视频、语音工单或传感器日志，专用多模态模型才可能形成数据壁垒。

以下几类场景与 LFM3 的方向较为匹配：

• 工业与机器人：识别设备状态，同时读取面板文字并生成维修建议；
• 零售与物流：理解货架、包装、标签和库存记录，完成巡检与异常解释；
• 车载与移动设备：在本地处理图像、语音和上下文，减少网络依赖；
• 企业文档：联合理解图表、扫描件、表格和专业术语；
• 医疗与生命科学研究：在严格验证和合规前提下，对图像及结构化记录进行辅助分析；
• 消费电子：让手机、可穿戴设备和智能家居获得低延迟视觉语言能力。

**没有稳定评测集的团队不应该急着做端到端微调。**更稳妥的方式是先建立一套覆盖正常样本、边缘样本和高风险样本的离线测试集，再用基础模型验证任务可行性。只有当错误类型可以被清楚归因时，继续做领域训练才有意义。

Liquid AI这次押对了问题，但还要用结果证明

**LFM3 选择了一个比“再做一个通用大模型”更实际的方向。**基础模型能力逐渐商品化后，企业真正愿意付费的部分，不是模型知道多少互联网常识，而是它能否理解专有数据、满足延迟约束，并稳定嵌入现有业务流程。

这个方向也比单纯争夺榜单更符合 Liquid AI 的优势。头部实验室拥有更大的训练集群、数据渠道和应用入口，初创公司很难在通用模型规模战中长期占优；围绕高效率架构、端侧运行和行业定制建立工具链，反而更容易形成差异化。

**LFM3 现在最缺的不是愿景，而是可复现的纵向案例。**行业需要看到同一套模型在真实数据上训练前后的准确率变化、端侧延迟、内存占用、能耗和长期稳定性，也需要明确不同权重的许可证是否允许商业部署与再训练。

如果这些数据经得起验证，LFM3 可能成为企业构建多模态系统的一条新捷径；如果最终仍需要大量私有工程才能跑通，它就更像一套有潜力的基础零件，而不是开箱即用的行业模型平台。

无论结果如何，Liquid AI 这次至少把问题问对了：下一阶段的模型竞争，不只是谁能训练出最聪明的通用助手，而是谁能让模型在具体设备上，以可接受的成本，把一件具体工作做稳定。

参考来源

• Hugging Face：Build specialized multimodal models with LFM3——Liquid AI 发布的 LFM3 官方介绍，重点讨论专用多模态模型的构建思路。
• Hugging Face：LiquidAI 模型主页——Liquid AI 在 Hugging Face 上发布模型卡、权重与相关技术资料的官方页面。