Liquid LFM3 提出了一个更好的本地人工智能问题：哪个小模型可以完成这项工作？

读取收据的本地助理不一定需要与回答口头问题的助理相同的模型。在三个允许的操作中进行选择的程序又有不同的工作。将它们视为一项任务可能会使小型应用程序变得不必要的复杂化。

Liquid AI 发布 LFM3 于 2026 年 10 月 27 日：六个大约 2B 级模型，从共享的 1.7B 基础分支出来，涵盖文本、视觉、音频、全向和两个决策变体。该公司提供开放权重、在线体验平台和 API 访问权限。 LFM3公告。

有趣的决定是哪种角色适合你的应用。本指南通过实际选择解释了该系列，将紧凑的权重文件与工作内存预算分开，并提供了第一次评估，可以揭示专用模型是否对您自己的硬件有用。

Raspberry Pi 5 硬件；说明性边缘计算环境，不是我们的 LFM3 测试。图片：RetroEditor、CC BY 4.0；已缩放并添加留白。 图片来源 · 许可与图片说明. 官方产品参考。

一系列专用模型从您需要的输出开始

错误选择的最快方法是从最大的支持输入列表开始。从应用程序必须产生的输出开始。段落、转录文本、结构化字段和允许的操作之间的选择是不同的输出约定，即使相同的源材料可以帮助生成所有四个接口约定。

Liquid 10 月 27 日的公告确定了四个模态分支和两个决策分支：LFM3-1.7B、LFM3-VL-2B、LFM3-Audio-2B、LFM3-Omni-2B、d1-2B 和 d1-Omni-2B。下表将这些角色转化为应用程序选择问题。它是一个选型指南，而不是一个独立的质量排名。 系列描述。

我们的看法：本地AI的有用单位是 最小的完整任务。模型应该具有足够的能力来满足明确的应用契约，以及处理不确定性的方法。除此之外的一切都需要运行时、测试和集成成本才能赢得一席之地。

把这一模型系列看作工具包。对于某些工作来说，携带所有工具是明智的。对于重复调整，选择合适的工具会更简单。这个类比是关于应用程序设计的，而不是声称一种模型总是击败另一种模型。

以下公告所列角色的原创说明图： Liquid AI 的 LFM3 公告。它将应用程序选择分组并省略内部实现细节。

开放权重带来部署选择，也带来阅读许可条款的责任

下载权重为开发人员提供了具体的打包、评估和调整的信息。它可以支持本地部署，其中应用程序的数据路径处于开发人员的控制之下。这很有用，但可下载文件的存在并不能解决其商业条款。

Liquid 的 模型目录，11 月 2 日检查，描述免费商业用途，直到企业达到 年收入 1000 万美元。LFM3-1.7B 模型卡 标识 LFM Open License v1.0。阅读检查点附带的许可证以及 当前许可页面 用于预期的部署、分发和收入情况。

这是一个实际的采购步骤。一个小型的内部原型、一个可下载的消费者应用程序以及向其他企业提供的服务可能会引发有关分发与义务的不同问题。将模型标识符、修订版和许可证与应用程序一起记录下来，以便在项目发展时决策仍然可追溯。

运行时软件和模型权重也有单独的版本。当模型可能已经发布，而设备上的运行时尚未提供兼容支持。应检查文档支持的组合，而不是假设每个能够加载早期系列的应用程序都可以正确加载新系列。

对于团队，此记录应包括检查点期望的提示或模板。如果输入格式不正确，兼容的加载器仍然会产生不良行为。再现性首先要了解实际加载的内容以及应用程序如何与之对话。

大约 1 GB 的权重是内存预算的开始

Liquid 在 10 月 27 日的发布材料中表示，文本模型采用 4 位量化时的占用约为 1 GB。文本模型卡 列出的规格为 1.73B 参数，以及输入与输出合计 256K 令牌的上下文。这些是模型规格；应用的峰值内存还取决于工作负载和运行时。

权重文件只是运行过程的一部分。 运行时需要工作内存；上下文处理需要状态；多媒体输入可能需要额外的缓冲区和编码器。设备上的其他程序竞争相同的资源。权重大小的宣传数字无法告诉您整个应用程序在负载下是否会保持舒适。

因此，说明性预算应从测量的进程内存占用开始。记录应用程序的空闲状态、处理代表性请求时的峰值以及重复请求后的状态。测试用户实际提供的上下文长度和输入大小，而不是选择一个很小的提示，因为它容易装入内存。

同样的规则也适用于时间。启动、提示处理和响应生成是单独的等待。在长时间延迟后快速生成令牌的模型在交互式应用程序中可能会感觉很慢；批处理任务可能更关心每小时完成的项目。选择与交互相匹配的度量。

对于音频功能，包括从输入到可用结果的整个路径。对于图像功能，包括图像处理。对于决策功能，包括验证和操作交接。这些是您定义的评估要求，而不是版本提供的性能数据。

原创内存预算图。线段宽度是说明性的，没有测量比例；大约 1 GB 数字是指 Liquid 发布的 4-bit 文本模型占用空间，而不是总应用程序内存。 来源。

三个示例性应用揭示了不同的权衡

文档助手可以将阅读与决定分开

想象一个接收拍照收据的小型企业应用程序。其中一项工作是读取可见的商家、日期和金额。另一个是确定文档是否足够完整以供人员审阅。即使一个模型对这两种输出都有贡献，这些输出也值得单独验证。

视觉语言路径可以支持有关图像的问题；可以评估决策路径以进行范围明确的完整性检查。应用程序应保留源图像并将提取的字段与接受的簿记数据区分开来。缺失的日期应该一直缺失，直到有人解决为止。

构建一个示例评估集，纳入清晰图像、模糊图像、不常见的版式，以及使用实际工作语言的收据。衡量字段错误并复核工作量。高整体成功率可以隐藏对业务最重要的领域中反复出现的错误。

有用的产品结果是更短、更清晰的审核队列。模型是否能产生优雅的解释并不重要，重要的是审阅者是否可以查看原始材料并修正字段。该优先级有助于在开放式语言输出和更具约束性的决策界面之间进行选择。

语音界面可以从一组有限的允许操作开始

考虑一个用于本地应用程序的说明性免提助手。用户可以要求查找项目、读取其状态或准备草稿操作。当说话比打字更容易时，音频功能就变得很有用，但应用程序仍然需要知道允许更改哪些请求。

从一个小的动作词汇和一个可见的确认路径开始。例如，定位记录的请求可以在授权数据内立即运行，而更改记录的请求可以提出建议的操作以供审查。该策略属于应用程序，而不属于模型碰巧产生的任何措辞。

测试实际声学条件。背景对话、简短的话语和相似的名字可能会从干净的录制句子中产生不同的失败模式。包括正确结果是再次询问用户的情况。流利的口头回答不如正确的、可恢复的互动有用。

当请求取决于可见内容和所说内容时，全模态候选模型就变得相关。如果每项任务都只使用语音，那么添加视觉处理就需要一个理由。这就是模型系列的设计可以帮助保持功能与工作相称的地方。

本地支持工具可以在保留升级处理路径的同时为工作分流

说明性的支持应用程序可能会使用工单和附加的屏幕截图在三个队列之间进行选择。范围明确的决策输出比应用程序必须解释的长答案更直接地适合该任务。有用的问题是所选择的路线是否足够可靠且复核率可接受。

保留明确的“需要复核”结果。测试与任何允许的队列都不匹配的工单、相互矛盾的屏幕截图以及上下文不足的情况。应用程序不应仅仅因为结构定义要求给出有效类别而让模型发明一条有效路径。

将模型与简单的基线（例如现有规则和人工路由）进行比较。如果基线已经可靠地处理某个类别，则模型需要改进工作流程的不同部分。新颖性不是接受标准。

对于每个错误，保留足够的授权上下文以了解其发生的原因。将输入问题、类别定义不清和模型错误分开。这种区别告诉您是否要改进模型、更改队列定义或要求更好的源材料。

基准表是您自己的工作负载的起点

官方 LFM3-1.7B模型卡，于 11 月 2 日检查，建议检索或搜索知识密集型工作，并警告不要在这种规模下进行智能体编程和复杂的多步骤推理。即使供应商基准表显示了进展，这对于将模型放置在更大的系统中也是有用的指导。

基准测试结果回答特定设置下的特定问题。您的应用程序添加了自己的数据、工具、语言分布和故障成本。模型可以在公开综合评测上进行改进，同时仍然需要对用户每天遇到的少数类别进行仔细的工作。

在试点中分开三个比较。首先，将任务质量与当前工作流程进行比较。其次，比较目标设备上的完整资源成本。第三，比较从故障中恢复所需的工作。这些比较可能会导致不同的赢家。

例如，当本地专用模型拒绝时，云端通用模型可以作为升级路径。这种安排需要明确的数据政策和用户体验。本地操作是您在整个应用程序中验证的部署选择，包括日志记录和回退请求。

应根据已证实的差距进行微调。如果失败是由于缺少源材料或不清楚的输出定义，更多训练可能会强化错误的任务。在决定定制是下一个有用的步骤之前，定义接口约定并检查错误。

首次试点应能形成一页清楚的决策记录

官方 文本模型卡 链接检查点格式和运行时指令。从此处开始获取确切的模型/运行时组合；使用官方 Playground 进行初始交互检查是否适合您的数据政策。这两种方法都不能替代测试您计划发布的部署。

1. 编写输入输出约定。 说明允许的材料、预期结果和明确的审查结果。选择一项任务而不是一般助理角色。
2. 选择候选和修订。 匹配模态和输出角色，然后记录检查点、许可证和兼容运行时。请阅读特定于模型的限制。
3. 创建代表性评估集。 包括普通情况、困难情况、不支持的请求以及实际用户语言的示例。将留出的材料与定制数据分开。
4. 在隔离环境中运行记录的快速入门。 遵循模型卡的当前依赖性和格式化说明。在比较输出之前确认返回的模型身份。
5. 测量完整的应用路径。 捕获实际输入大小的正确性、审核率、延迟和峰值内存。记录硬件和运行时设置以及数字。
6. 练习不确定性路径。 确认缺失信息、无效输出和运行时故障导致可理解的审核或重试状态。
7. 决定下一步应优化什么。 使用重复出现的错误类别在更好的输入、更清晰的规则、检索、微调或不同的模型之间进行选择。

对于第一遍，书面决定可以很简单：在具有这些审核条件的情况下，该候选模型对于该设备上的此任务很有用。一个狭隘的、可重复的结论比一般性的声称本地人工智能已经准备好应对一切更有价值。

小模型通过完成规定的工作赢得一席之地

LFM3 为需要在应用程序附近进行文本、视觉、声音或有限决策的开发人员提供了更多选择。它的实际意义在于能够在这些角色中进行选择并将它们作为产品的一部分进行评估。

下一步是使一项工作足够精确，以便可以测量质量、内存和恢复情况。当整个应用程序可以依赖其接口约定并知道在无法回答时该怎么做时，专用模型才真正有用。

来源

• Liquid AI：介绍LFM3，2026 年 10 月 27 日； 2026 年 11 月 2 日检查。
• Liquid AI 模型目录 和 定价和许可，2026 年 11 月 2 日检查。
• 官方 LFM3-1.7B 模型卡，2026 年 11 月 2 日检查。
• 官方d1-2B模型卡，2026 年 11 月 2 日检查。

保留决策背后的材料

Telli.sh 是一个选择，可将获准保存的原始资料与审阅后的笔记放在一起。 创建笔记工作区。