先看证据
统一的是底座，不是一个万能模型
Liquid AI于2026年10月27日发布LFM3，将它定位为面向专用智能的新一代模型家族，覆盖文本、视觉、音频、全模态和决策任务。它要解决的不是如何把一个通用模型继续做大，而是如何让较小模型适配具体输入、数据和部署环境。
这一区别决定了LFM3的组织方式：官方称首批六款模型都从LFM3-1.7B-Base派生，再按任务形成文本、视觉、音频、全模态和决策分支。所谓“共享”，主要发生在训练底座和模型谱系上，并不意味着部署时只需要一个模型包办所有事情。对工程团队来说，选择分支本身就是架构决策，专用化则是后续工作，而不是模型家族名称带来的自动能力。
速度来自层级分工，也来自硬件搜索
LFM3-1.7B-Base有24层：13层门控短卷积、5层滑动窗口注意力和6层全局注意力。短卷积负责局部信息处理，滑动窗口注意力把交互限制在256个token的范围内，全局注意力则保留跨较远位置建立联系的能力。它不是简单地用一种便宜算子替换注意力，而是让不同层承担不同尺度的序列处理。
其他改动也指向推理时的稳定性和效率。短卷积核从LFM2的3增至7，注意力头的门控可以压低不需要的头部输出，部分RoPE只用于全局注意力层每个头频率较高的一半，Sandwich Norm则同时规范化块的输入与输出。Liquid AI还称，其硬件在环架构搜索覆盖14种设备与后端组合，从手机、Raspberry Pi 5到云端设备和Qualcomm Hexagon NPU。官方报告称，LFM3-1.7B在短提示下按参数量计算可匹配LFM2-1.2B，处理8K上下文时约快25%。这些数字说明设计目标与优化方向，但不是脱离硬件、量化和负载条件的通用速度保证。
多模态能力落在各自编码器上
共享语言底座并没有消除视觉和音频处理的差异。LFM3的视觉与音频分支加入Liquid自研编码器，音频生成还配有LiquidCodec；这意味着模型家族的统一不等于所有模态都经过同一套前端。选型时，团队仍要围绕输入类型、时延要求和目标设备看对应分支，而不能只看底座参数量。
官方给出的具体设计能说明这种分工如何影响序列处理。视觉编码器结合卷积与注意力，Liquid AI称其计算量比前代LFM视觉模型使用的SigLIP2编码器少三倍；处理视频时，每两帧合并为一个时间切片，以缩短时间序列。音频编码器是因果结构，官方称模型可以在用户说话时预填充，首token延迟最低约50毫秒。LiquidCodec在Apple M4 Max单CPU线程上据称可按约87倍实时速度解码语音，并支持流式解码。它们分别针对视觉计算、视频序列长度和语音响应延迟，但这些厂商报告仍需在目标应用的输入与设备上验证。
本地部署的关键不是一个1GB数字
LFM3把端侧部署与专用化连在一起：官方称文本模型的4-bit版本约占1GB，文本上下文窗口达到256K，并称每款模型都可以在单张GPU上微调。对需要本地工具调用或长上下文处理的团队，这些指标提供了初筛依据，也让“选一个合适分支，再用自己的数据适配”成为可能的工程路径。
但1GB只描述文本模型在特定量化精度下的占用，不等于包含视觉或音频分支、缓存和应用运行环境后的总内存。256K上下文也不是自动获得长期记忆或稳定工具执行能力：模型仍需依赖周边的工具调用、上下文管理和编排。单GPU微调同样缺少统一的显存、训练时长和质量目标口径。技术负责人应把这些表述当作待落地的约束条件，逐个核对实际分支、推理后端、量化方式和训练任务，而非直接写成部署承诺。
性能主张要回到具体任务里检验
LFM3-1.7B的训练规模为22T tokens，官方称最后约3.5T tokens用于精选数据的中期训练，并扩展了上下文长度。Liquid AI还称它比LFM2.5-2.6B少35%参数、表现更好。这样的比较有助于判断厂商试图解决什么问题，但材料中的速度、能力和微调便利性数据主要来自发布方，不能直接当作独立复测结论。
更稳妥的评估方式，是先选定应用的真实输入和目标设备，再比较端到端延迟、内存占用、任务成功率与专用数据微调后的变化。对多模态应用，还应把编码器、解码器和模型分支一起纳入测试，而不是用文本模型的体积替代整套系统预算。LFM3的主要价值在于提供一条可检验的路线：用共享底座减少从头构建的工作，再通过分支和硬件适配换取任务与设备上的匹配。若团队无法验证这些适配带来的实际收益，那么模型家族的参数效率和长上下文数字，仍只是选型线索。