原始来源：Liquid AI 发布与方法说明
发现渠道：Hacker News · AI
本地模型不仅要回答得对，还要在设备能承担的内存和延迟内完成工作。Liquid AI 发布 LFM3 系列，文本、视觉、音频、全模态及两个 Decisions 模型共用约 17 亿参数的骨干，组成六个约 20 亿参数的模型。它把不少全局注意力换成门控短卷积与滑动窗口注意力：前者处理局部序列，后者只查看附近位置，保留的全局层再承担长距离联系，从而减轻长上下文的缓存负担。
这不是单纯把大模型缩小。Decisions 版本面向一批明确问题，在一次模型计算中并行输出选择、范围、位置框或文本片段，适合分类、提取等任务，减少生成长解释的成本。团队还把真实设备上的测量用于架构选择，说明模型结构与部署后端需要一起考虑。
厂商报告四比特权重约 1GB；这不包括全部运行内存。其 128K 上下文测试中，用于复用先前 token 计算结果的 KV 缓存约 1.6GB。速度比较则限定在 llama.cpp、特定量化、32K 输入和短输出等条件，不能直接代表手机应用的端到端体验。模型卡也明确不推荐复杂多步推理或 Agent 编程；可下载权重采用 LFM Open License 1.0，使用前仍需读具体许可。
可信度 65 · 重要性 82 · 新颖度 82
技术与主题
系统与效率 · 基础模型 · 多模态 · small language model · hybrid architecture · on-device inference · structured output
colingauvin
在 LFM3 发布讨论中介绍自己的 LFM2.6 邮件处理；明确是旧模型经验。
忠实转述（非原句）：他用 RTX A4500 运行 LFM2.6，对邮件元数据做初步分流，并把把握不足的项目交给更大模型。他说约四成标注已能信任；仍在等待 LocalAI 支持 LFM3，才准备替换试用。这里可借鉴的是分工方式，不是新版本性能结果。
dchuk
尝试 LFM3 的 Omni 和文本模型后报告加载问题；为单个用户环境。
忠实转述（非原句）：他尝试在 LM Studio、omlx 和 rapid mlx 中运行新模型，遇到 safetensors 无法读取的问题，尚未成功启动。回复者建议尝试 mlx-vlm 与原生 MLX 导出；讨论中这项建议不等于已经确认修复。
编辑评读
LFM3 最有启发的地方是把“回答问题”拆成不同的产品动作。邮件分流只需要标签与置信线索，图片审查可能需要位置框；强迫每一步先写自然语言，再从文字中解析结构，增加了延迟和出错面。专用输出因此可能比聊天榜上的总分更值得测试，但前提是业务能清楚定义输出与失败处理。
早期讨论也把这件事拉回部署现实。一位用户的旧版 LFM2.6 邮件流程把困难样本交给较大模型，这是分层使用的经验，不能替 LFM3 背书；另一位用户报告新模型在几个 MLX 工具里无法加载。模型权重够小，只是起点，转换格式、算子支持和服务框架能否接上同样决定可用性。
对准备试用的团队，最直接的比较对象是现有任务流水线：在同一批真实输入上，统计能独立完成的比例、需要升级处理的比例以及整条链的延迟。这样才能判断省下的推理资源是否被重试与转交吃掉。本期没有做本地跑分，发布页的数字仍是厂商测量。
需要留意
- 厂商基准未独立复现；早期运行支持反馈因后端而异。