LFM3 把小模型分成六种工种，本地 Agent 要先选对任务
LFM3 用六种小模型分别处理文本、视觉、语音和结构化决策。读懂它适合接哪些 Agent 工作、约 1GB 为何不是总内存，以及 LFM Open License 的商用边界。
Liquid AI 在 10 月 27 日发布的 LFM3，值得关注的是六种小模型分别接手具体工作：读工单、看票据、听指令，或直接给出结构化判断。它们来自同一个底座，但不是一个可以包办所有 Agent 任务的通用大脑。宣传中的约 1GB 是文本模型在 4-bit 精度下的模型占用口径，不是整套应用的总内存承诺；开放权重也不等于无条件商用。
想开始资料型评估，可以先看已公开的 LFM3-1.7B 文本模型与权重入口。其他变体和量化格式仍需逐项核对对应模型卡、下载状态与运行框架，不能把家族公告当成全部版本已验证可运行。
把这些区别拆开，才能看出这次发布真正改变了什么：开发者多了一组可以贴近应用部署、再用自己的数据训练的候选，而不是又多一个参数更小的聊天窗口。
同一封客服工单，可能需要两种完全不同的模型
假设一封工单写着：“我被扣了两次钱，包裹也一直没到，请退回其中一笔。”如果你需要起草一段解释，工作是生成文本；如果你只想知道是否涉及退款、该交给哪个部门、有哪些主题，工作是做判断。
LFM3 把这两条路线放进了同一家族。文本模型 LFM3-1.7B 面向本地 Agent、工具调用和结构化输出；d1 决策分支则接收一段情境和一组问题，在单次前向计算中返回答案及对应概率。官方给出的工单示例，正是同时判断退款意图、责任团队、主题和紧急程度。（LFM3 官方技术文章：d1 与工单示例）
这不是说生成模型不能分类，而是输出合同不同：一边可以组织解释、调用工具、继续对话；另一边把问题预先规定好，直接把判断交给业务流程。概率便于设置转人工门槛，却不能直接当成你自己工单上的准确率保证。
按这个思路，六种变体比一张参数排行榜好理解得多：
| 模型 | 适合先试的工作 |
|---|---|
| LFM3-1.7B | 文本助手、工具调用、按格式抽取信息 |
| LFM3-VL-2B | 理解图片、文档和视频，输出文字 |
| LFM3-Audio-2B | 语音对话、转写、语音合成，把口头请求转成工具调用 |
| LFM3-Omni-2B | 同时结合看见和听见的内容，输出文字或语音 |
| d1-2B | 对文字、图片或视频作预定义的结构化判断 |
| d1-omni-2B | 在决策输入中加入音频 |
共同的 LFM3-1.7B-Base 是继续训练的底座，不是第七种已经完成任务适配的模型。也不用因为 Omni 输入最全就默认选它：只处理文字工单，先测试文本模型或 d1；只有任务必须同时理解画面与声音时，全模态才有明确理由。这是从输入和输出选模型，不是从名字选旗舰。（LFM3 发布公告：模型家族）
LFM3-1.7B 适合接工具，不等于接管整个代码库
沿着工单往下走，助手可能还需要查订单、取退款规则、生成处理建议。文本模型的价值在这里：把用户请求转成工具调用，再根据返回结果继续工作。
但模型不是执行系统。模型卡明确要求应用解析并执行调用，再把结果放回对话。它还支持工具搜索：先不把整个工具目录塞进提示词，等应用的搜索工具返回名称后，再加载对应定义。这给较大的工具目录提供了一条接入路径，不等于下载权重就已经连好了公司的业务系统。（LFM3-1.7B 模型卡：工具调用与工具搜索）
应用仍要决定哪些工具可用、哪些动作必须确认。模型能提出退款调用，与它应该被允许自动退款，是两件事。
厂商基准解释了为什么这个小模型值得试。在 Liquid AI 公布的 WebArena-Verified 测试中，LFM3-1.7B 得分为 38.42，前代 LFM2.5-2.6B 为 3.02。不过模型卡披露，这组能力评测使用 vLLM、BF16，WebArena 最多运行 40 步。它不是本站的亲测结果，更不是手机上 4-bit 模型能原样复现的成绩。
更有决策价值的一句，反而藏在模型用途说明里：由于体量小，官方不推荐将它用于 agentic coding 或复杂多步推理；知识密集型任务应使用检索或搜索。会调用工具，不等于适合自主拆解大型代码改造。让它先完成规则明确的一步，比直接把整个仓库交过去更符合当前证据。
真正的专用化，是让模型学会你的票据和术语
小模型的另一条路线，是缩小任务范围之后继续训练。
LFM3 的共享底座有 24 层：13 层门控短卷积、5 层滑动窗口注意力、6 层全局注意力。它不是简单把大型模型等比例缩小，而是在不同计算方式之间寻找能力与端侧效率的组合。结构本身不能证明业务效果，但解释了这组模型为什么同时强调小体积、长上下文和后续适配。
官方发布的单 GPU 微调笔记，给出的工作比“训练一个行业专家”具体得多：从凌乱文档抽取 JSON、依据检索资料回答或拒答、从票据照片读出字段、把智能家居语音指令映射到函数调用。开发者可以沿着数据准备和评估继续试，而不是只换一段系统提示词。（LFM3 官方技术文章：微调任务与笔记）
“单 GPU”也不是任意消费显卡都能完成所有训练的保证。实际预算仍取决于变体、训练方法、样本与序列长度。
发布公告里的风机叶片案例展示了这个思路，也展示了它的边界。厂商用约 3000 张公开照片，在一张 A100 上训练数小时，再用约 1400 张留出照片比较，报告微调后分类准确率达到 67%。对有固定缺陷类别的任务，这比泛泛讨论模型懂不懂工业知识更有用。
但同一案例披露的检测 F1 是 0.11。分类是在判断图像类别，检测还要定位缺陷；F1 综合衡量查准与查全，越接近 1 越好。两者不是同一指标，不能只摘出 67%，就宣布小模型已经能可靠接管巡检。它说明值得围绕一个窄任务建立训练与评估闭环，不说明训练一次便可放心上线。（LFM3 发布公告：风机叶片微调案例）
约 1GB 装的是模型，不是整套长上下文 Agent
任务选对以后，才轮到设备预算。
文本模型的实际参数量是 1.73B，上下文窗口为 256K tokens，输入和输出合计。约 1GB 的宣传口径与 4-bit 模型有关；运行时还需要上下文状态、计算缓冲区，以及 Agent 应用本身的资源。
一个足够直观的提醒来自厂商自己的公告：文本模型在完整 128K 上下文下，保存上下文中间状态的 KV cache（键值缓存）需要 1.6GB。仅这一项就说明，不能把“模型约 1GB”改写成“1GB RAM 可以跑满长上下文”。也不能简单把两项相加，便得出所有后端通用的最低内存配置。
模型卡的端侧性能测试使用的是另一组条件：llama.cpp、Q4_0、32K 上下文、批量大小 1、生成 100 tokens，并启用 GPU offload。看到速度图时，要把这些条件一起读；前面 BF16 的任务分数与这里的量化速度，并不是同一场实验。
最省事的试点不是先塞满 256K，而是固定一类输入，检查输出是否合格式、结论是否正确、峰值内存和首字延迟是否可接受，再逐渐增加文档长度。要接语音或图像，就测对应变体，不能沿用纯文本模型的预算。
本地部署提供了控制推理位置的选择，不自动保证全部数据都留在设备上：搜索、业务工具和日志仍可能联网。省不省钱，也要把硬件、运行和维护算进去，而不是把没有逐 token API 账单理解成没有成本。
LFM3 开放权重，商用还要读 LFM Open License
把试点变成产品前，还有一项不能从模型大小推出来：授权。
文本模型采用的是 LFM Open License v1.0，不是 Apache 或 MIT。其“Commercial Use”定义包括直接或间接的商业利益与金钱报酬，不只是在外面卖模型服务。（LFM Open License v1.0：定义与商业使用限制）
许可涉及1000万美元年营收门槛。定义与限制的原文值得保留，而不是简化成一句“免费商用”：
“Threshold” shall mean annual revenue of 10 million United States dollars ($10,000,000) or more.
第 5(a) 条使用的措辞是：
The rights granted under this License for Commercial Use are conditioned upon You or Your Legal Entity not exceeding the Threshold.
第 5(b) 条紧接着写道：
Any Commercial Use of the Work or a Derivative Work by a Legal Entity that exceeds the Threshold is not licensed under this Agreement.
简而言之，超过门槛的主体不能依据这份协议获得商用授权，需向许可方确认授权路径。这里保留定义与条款的原句，不替临界营收情形作等号推断。Legal Entity 的定义还包含控制、被控制或共同控制的实体，不能只看承接项目的小团队收入。自己的主体如何适用，尤其接近门槛时，应向许可方和法律顾问确认。
再分发还涉及附带许可证、标明修改、保留相关声明等义务。能下载、能微调、能在本机运行，和可以按自己的商业模式分发，是不同的检查项。
LFM3 最值得拿来试的，是你能清楚写出成功标准的一小块工作：工单该分给谁、票据字段有没有读对、语音是否触发了正确工具。先证明这块工作在目标设备和授权条件下成立，再扩大范围。对本地 Agent 来说，选对工作，比找到一个最低内存数字更接近真正可用。