Liquid AI发布LFM3：端侧多模态模型落地，要先算清哪些部署条件
Liquid AI于10月27日发布LFM3开放权重模型家族。结合模型文档与许可，解析本地助手的任务选择、完整内存预算、中文验收和商业使用条件。
2026年10月27日，Liquid AI发布LFM3模型家族，把文本、视觉、音频、全模态和决策模型放到同一代基础架构之上。对开发者而言，这条消息的价值在于：本地助手的方案多了一个可按任务选择、再做专门训练的候选，而最终是否值得部署，需要同时检查模型能力、设备资源和业务流程。
背景：设备上的AI需要完成具体任务
整理一段会议记录、从相机画面提取信息、把一句话转成结构化工具调用，对系统的要求并不相同。把所有输入都送给同一个远程模型，容易掩盖本地处理可以承担的部分。LFM3此次以约20亿参数级别的多种模型作为首批产品，反映出厂商希望让开发者先选合适的输入输出方式，再围绕窄任务优化。
这次发布有哪些可核对的变化
根据发布公告，LFM3采用新的混合架构，基础模型和后训练模型开放权重。官方文本模型文档进一步列出：LFM3-1.7B约有17.3亿参数，支持256K token的输入与输出总上下文，语言列表包含中文，面向本地代理、工具调用和结构化输出。官方同时给出了视觉、音频及Omni等分支的说明。
这些信息说明开发者可以按任务下载和运行模型，但不代表同一个文本模型就能直接处理所有模态。以Omni为例，仍应按对应文档配置输入、推理后端和输出方式；将文本版替换成多模态版，还会改变数据处理链路。
约1GB的权重，不等于完整应用只用1GB
官方介绍文本模型在4位精度下约占1GB内存。这里适合用来判断模型本体是否有望放进设备，不能直接当成整套应用的资源预算。实际部署还要给上下文缓存、推理引擎、输入编码、工具执行和应用本身留出空间。
本站建议把验收拆成短指令、长文档和并发调用三组场景，分别记录峰值内存、首字延迟、完成时间及温度或耗电变化。256K是模型文档中的上下文上限；是否应在某台手机上处理这么长的输入，是另一个需要测试的问题。
能力边界与许可，都会影响是否能上线
文本模型文档明确指出，由于模型较小，不建议把它作为复杂多步推理或代理编程的首选，知识密集任务宜结合检索。厂商公布的基准成绩可以帮助确定测试方向，不能替代中文业务样本上的验证，本文也未进行独立跑分。
开放权重同样不等于没有商业条件。模型文档标注LFM Open License v1.0；官方许可包含商业使用收入门槛、保留声明等要求。企业评估时应将具体模型随附许可与组织情况一起核对，达到条款门槛后需另行取得相应商业授权。
影响：先把稳定的小任务从完整流程里拆出来
我们更看好一种循序推进的用法：先让本地模型完成字段提取、意图分类或工具参数草拟，再由业务规则校验输出；遇到超出能力的内容，转交人工或其他模型。这样可以分别观察模型节省了多少等待，以及校验和回退又增加了多少成本。
例如客服系统可以先试验把中文请求整理为工单字段，再比较漏项率与人工修订时间。这里的判断标准应是工单是否可用，而非单看生成速度。本地执行也不会自动保证隐私，联网工具、日志与同步链路仍需单独检查。
适合哪些人关注
移动应用、AI PC、物联网及企业内部工具团队，适合把LFM3列入本地模型候选；研究者则可以关注统一架构下不同模态的适配方式。如果主要需求是高难度代码修改、复杂长链推理或广泛事实问答，宜先验证小模型能承担的子任务，再决定是否接入完整业务。
来源参考
本文依据以下公开资料交叉整理，并加入本站的部署或工作流分析。公告日期为2026年10月27日，资料核验日期为2026年10月28日；动态榜单与预览入口可能变化。
