--- layout: post.njk source: https://yage.ai/share/liquid-lfm3-edge-model-specialization-20261031.html web_feed: articleId: cmvx180sl00069eyewiauiz6f feedSourceId: webfeed_yage_ai guid: https://yage.ai/share/liquid-lfm3-edge-model-specialization-20261031.html sourceUrl: https://yage.ai/share/liquid-lfm3-edge-model-specialization-20261031.html speaker: yage.ai title: |- 别再把 2B 小模型训成缩水版通才了：从 Liquid LFM3 看端侧模型的同源偏科新策略 date: '2026-10-31' summary: 文章讨论了在端侧小模型（如2B参数模型）上，不应追求模型成为全能通才，而应采取“同源偏科”的新策略。Liquid AI开源的LFM3家族通过共享同一套预训练数据和基底权重，在模型上进行了工程取舍，将同一棵树干分叉出六个各司其职的偏科零件，分别负责文本生成、多模态执行手和零输出词元的单次前向决策模型。这种策略旨在通过牺牲部分通用能力（如闭卷常识准确率）来换取在特定任务上的高可靠性、低延迟和极小的内存占用，从而使模型更适合在端侧硬件上落地。 area: tech-engineering category: architecture tags: - model-architecture - model-pruning - inference-optimization - llm-strategy - resource-allocation people: - samstevens companies_orgs: - Liquid AI products_models: - LFM3 - LFM3-1.7B-Base - LFM3-VL-2B - LFM3-Audio-2B - LFM3-Omni-2B - d1-2B - d1-Omni-2B - Qwen3.5-9B - Qwen3.5-4B - Whisper-large-v3-turbo media_books: [] draft: true status: evergreen --- 我相信大多数玩本地大模型的同学都有个类似的经历：在电脑上装了一两个 20 亿参数（2B）的轻量级模型。刚开始用 Ollama 拉取权重运行起来，看到终端每秒输出上百个词元，确实很开心。但用上一会儿就会发现，稍微冷门一点的领域知识，它经常会瞎编；几万字的项目文档，它常常找不到里面的关键数据；让它按照指定格式调几个外部接口，它也会漏掉必要参数或弄错括号位置。短短十分钟的新鲜感过去以后，这些模型往往就成了硬盘里的吃灰玩具。 端侧小模型为什么老成玩具，是因为几千亿参数量级的云端旗舰模型把整个行业带偏了。我们下意识以为大模型就应该无所不能，想照搬云端那个能背百科、能吞几十万字的长文档、能看图能听声音的全能聊天机器人，塞到 20 亿参数（2B）的壳子里去。这两年在反复翻车之后，一线工程团队越来越意识到，死磕端侧微小模型的单模型全能是个死胡同。 10 月 27 日，Liquid AI 开源了新一代 LFM3 家族，一口气放出六个 20 亿参数（2B）级别的模型。这套模型真正特别的地方，在于它彻底换了一套端侧生存策略。团队在底层把复用做到了极致，让所有模型共享同一套预训练数据、同一套训练管线和同一个 17.3 亿参数的基底权重。到了上层，他们果断放弃单模型全能幻想，做了三项具体的工程取舍，把同一棵树干改造成六个各司其职的偏科零件。 ## 怎么既复用同一套训练家底，又拆出会说话的手和不说话的眼？ 放弃全能通才、改做专职零件，模型团队撞上的第一道墙是研发成本。如果给写工具代码、看图片、听语音、做快速分类各自从头攒数据、搭管线训一个独立底座，算力和日常维护的账根本算不过来。LFM3 的解法是把九成以上的苦功全砸在唯一的一棵共同树干上，最后一步再做同源分叉。 在 Hugging Face 上查看 LFM3 的模型集合，可以看到首发六个模型都是从同一个 17.3 亿参数的模型 LFM3-1.7B-Base 训练出来的。它先在 18.5 万亿词元的网页、代码和科学文献中打下基础，然后在最后的 3.5 万亿词元中期训练中重点加入高密度的智能体操作轨迹和多样的工具使用数据。甚至未做任何指令微调的基底模型配置里，也预置了 思考框模板。后面的看图、听声和判断模型全都在这个昂贵的工具调用基础上分支出来。 这棵共同的树干向上分出了两个不同的物种。很多开发者第一次看到六个模型名字都会犯迷糊，不知道它到底是逐字生成代码的常见生成模型，还是给选项打分的决策模型。实际上，团队同时提供了两种路线，分为左右两派。 左边的分支是四个标准的生成模型：纯文本的 LFM3-1.7B，接上视觉编码器的 LFM3-VL-2B，接上音频编码器和自研分词器的 LFM3-Audio-2B，以及把视觉和音频都接上的全模态模型 LFM3-Omni-2B。它们像一般的开源大模型那样一个字一个字往外蹦，或者吐语音帧，专门用来当智能体的执行手，看懂当前状态后写个 来调接口或点按钮。 右支则是从 VL-2B 和 Omni-2B 出发，通过强化学习得到的两个决策模型 d1-2B 和 d1-Omni-2B。团队把它们逐字说自然语言的能力直接砍掉，调用时生成的输出词元数永远是零。你把长文本或屏幕截图连同问题塞进输入端，模型只跑一次前向计算，在 H100 上只需 5.7 毫秒，在苹果 M5 Pro 笔记本芯片上也只要 18.6 毫秒，就能直接从网络最后一层读出四类结构化结果。它可以给候选分支打出带校准概率的选择，标出关键字段在原文里的起止字符位置，给未知连续数字估出中位数与八成把握的上下界区间，或者框出图片里目标物体的坐标并数出个数。无需从头另训底座，在多模态树干上挂一套强化学习决策头，就能拿到一个毫秒级响应、零输出词元、不会写坏括号格式的判别眼。 LFM3 在底层共用同一个 17.3 亿参数的训练底座，在上层分叉为逐字写工具指令的生成模型与零输出词元的单次前向决策模型 ## 为什么要拆成六个模型，还把知识题准确率压到 7%？ 理解了同源分叉的树干结构之后，自然会冒出下一个问题。既然家族里已经有了能看图、能听声、能读文字的全模态模型 LFM3-Omni-2B 和 d1-Omni-2B，为什么还要大费周章地把它拆成六个模型？ 在 Hacker News 的发布讨论帖里，工程师 samstevens 直接交了底。在工程实践里，指望不同模态互相促进基本是幻想，在小模型上尤其如此。总参数量卡在 20 亿（2B）的窄空间里，每多塞一种模态，都在挤占原有模态的脑容量。官方自己的评测账单证明了这点：比纯文本和工具调用，专职文本模型明显强于视觉模型，而视觉模型又强于全模态的 Omni-2B，后者甚至还砍掉了 思考框。比看图和语音转写，全能模型同样输给对应的专职模型；到了决策分支，d1-2B 的 70.2 分平均成绩也高于全模态 d1-Omni-2B 的 67.7 分。坦率承认 20 亿参数（2B）撑不起全能大一统，是它能落地的第一道取舍。 比拆模态更狠的是，它在知识记忆和执行训练上做手术。看 LFM3-1.7B 的评测，在浏览器自动化的 AutomationBench 上，它拿了 41.29 分，把大五倍的 Qwen3.5-9B 的 15.10 分远远甩开，可转头做闭卷科学常识，又毫无悬念地大幅输给同场的大模型。 最直观的，是 AA-Omniscience 的幻觉测试里，LFM3-1.7B 拿到了全场唯一正总分 +0.50，隔壁的 Qwen3.5-4B 却打出了 -57.17。细看子项，LFM3-1.7B 对冷门事实的闭卷准确率其实只有 7.07%，垫底全场。它拿正分全靠遇到不会的问题干脆闭嘴，未知拒答率 92.93%。反观 Qwen3.5-4B 的未知拒答率仅 13.64%，剩下八成以上时间都在盲猜胡编。 这其实就是把小模型榨成实用部件的关键招数。团队不指望小模型去背百科全书，转而用强化学习重罚胡猜，逼它没把握时干脆闭嘴或去调外部搜索工具。然后把代码、数学、工具调用等六个专职强化学习教师模型蒸馏进同一个底座，在对话模板里加入按需加载工具说明书开关 defer_loading=True。就算后台挂了几百个工具，初始提示词里一个都不列，等搜到具体工具名，才动态塞进 标签，把注意力全留给眼前的动作。 当然，这项取舍也带来了两个明显副作用。第一个副作用是训练出了工具强迫症。工程师 liquid_richie 确认，只要本地环境默认挂着内置工具列表，哪怕不写系统提示词，随便问一句「什么动物下的蛋最大」，模型也会在 思考框里脑补出必须调用工具的指令，然后强制去调工具。第二个副作用是视觉分支对思考框的重度依赖。第三方核验报告指出，VL-2B 宣称追平 12B 模型的 71.4 分靠的是默认开启思考框 enable_thinking=True。一旦关掉思考框追求低延迟，平均分立刻跌到 62.1 分，数学与逻辑推理更从 68.8 分直接掉到 41.0 分。 LFM3-1.7B 主动放弃内置百科记忆，用 7.07% 的闭卷事实准确率换取 92.93% 的未知拒答率与越级的工具执行表现 ## 砍掉四分之三的全局注意力，换来了什么、又丢掉了什么？ 除了脑容量不够背书以外，小模型在手机和轻薄本上跑多轮智能体还会遭遇另一个鬼门关。每次调取工具返回的长日志都会累加到历史对话缓存中，很快就能把手机内存撑爆，读入提示词的等待时间也会慢得没法用。 为了在端侧硬件上跑出高速度，他们在包括树莓派 5、三星手机、iPhone 17 Pro、苹果 M4/M5 Max、高通 NPU 等 14 种真实硬件上做了一轮架构搜索。查看 LFM3-1.7B-Base 的底层网络配置可以发现，团队对全部 24 层网络都做了大刀阔斧的改动。他们直接砍掉 18 层全局注意力，只留 6 层通览全文，其余 13 层换成只记眼前 7 个词元的局部卷积层，5 层换成只看最近 256 个词元的短窗口层，最后再用大模型手把手蒸馏出仅 1.05 GB 的 4 比特压缩权重包。 这次结构改动直接带来可观的内存与速度红利：四分之三的网络层不随文本变长而累加历史缓存，到了 128K 长度，历史对话缓存仅占 1.6 GB 内存，不到 Qwen3.5-4B 的 4.3 GB 的四成。处理 32K 长度的输入，它在苹果 M5 Max 和 iPhone 17 Pro 上的提示词读入速度比对比模型快了 2.5 倍以上。 但砍掉四分之三的全局注意力、仅用最后 500 亿词元即 0.23% 的训练量来扩充到 256K 窗口，也带来了一个官方宣传里没有明说的代价。它标称的 256K 窗口只是内存装得下，而非检索找得到。在长文找针测试 RULER 128K 里，LFM3-1.7B 只得 65.56 分，落后 Qwen3.5-4B 的 84.63 分近 20 分。官方云端接口也把纯文本模型限到 128K、多模态模型限到 32K，而 d1-2B 文档更明确提醒，超过 64K 词元后状态会开始不可靠。用 64K 之后的长文检索退化，换取短平快任务上的极小内存和秒级响应，正是它在结构上做的明白账。 ## 跳出 LFM3 本身，这套偏科思路给我们训模型和用模型什么启发？ 老实说，LFM3 这些模型本身不一定能成为人手一个的流行爆款，但就算我们不打算用这套模型，它们验证的工程思路依然很有借鉴意义。过去很多团队微调开源模型，不论是 20 亿参数（2B）的小模型还是几百亿参数的大模型，都会陷入一种全能焦虑：既想要模型在垂直业务里拿高分，又担心微调后掉了通用闲聊、闭卷常识和长文阅读的综合排名，最终训出一个两头不靠的平庸模型。LFM3 给出的示范格外干脆：先算清楚研发总账，把底层的数据、训练管线和基底权重复用到极致；到了面向具体任务的那一层，果断抛开面面俱到的包袱，主动接受偏科。 不管黑猫白猫，能便宜又有效地为真实业务抓到老鼠就是好猫。如果一个模型只负责为你的系统写接口调用，就大胆用强化学习重罚瞎猜，哪怕闭卷百科准确率跌到 7.07% 也无所谓，只要遇到盲区肯闭嘴、调用外部工具不写歪参数就行。如果一个节点只需要守住流水线最前排做工单分流、截取原文起止位置或者框选画面按钮，那就连逐字吐自然语言的能力都一起舍弃，直接改成几十毫秒跑完一次前向计算的判别头。如果它平时处理的文本全都不超过几万字，那就少留几层全局注意力，用 64K 之后的长文检索退化去换平时的极小内存和秒级响应。 同样的道理也适用于日常的智能体和自动化流水线。与其等一个既小又快又全能的神仙模型，不如把任务切开交给不同的偏科零件：让不吐字的判别模型守住最前排做毫秒级路由和字段截取，让高拒答率的轻量模型配外部数据库做纯工具执行手，碰到纯语音转写就直接挑更小更准的 8 亿参数专职模型 Whisper-large-v3-turbo，而把真正需要广博知识和超长上下文推理的重担留给云端旗舰大模型。承认模型的物理边界，敢于用非核心能力的牺牲去换取核心动作的高可靠，才是微调模型和落地端侧智能体真正走向实用的开始。