LFM3-1.7B edge inference at 32K context: prefill throughput, decode throughput, and host plus GPU memory on AMD Ryzen AI Max+ 395, Apple M5 Max, and iPhone 17 Pro, compared with MiniCPM5-2B, Qwen3.5-4B, Qwen3.5-9B, and Gemma 4 E4B.
LFM3-1.7B edge inference at 32K context: prefill throughput, decode throughput, and host plus GPU memory on AMD Ryzen AI Max+ 395, Apple M5 Max, and iPhone 17 P 查看原始材料 ↗
LFM3-1.7B GPU inference: output throughput versus concurrent requests on one NVIDIA B300, compared with MiniCPM5-2B, Gemma 4 E4B, Qwen3.5-4B, and Qwen3.5-9B.
LFM3-1.7B GPU inference: output throughput versus concurrent requests on one NVIDIA B300, compared with MiniCPM5-2B, Gemma 4 E4B, Qwen3.5-4B, and Qwen3.5-9B. 查看原始材料 ↗

先看证据

1.73B参数，256K上下文文本模型
13卷积、5滑窗、6全局24层
滑窗256 tokens；卷积核7关键事实
官方称22T tokens基础训练
3.5T tokens末段agent-heavy训练
4-bit权重约1GB；128K KV缓存约1.6GB关键事实

把机制串起来

输入先把素材压到可处理的规模

自注意力能让任意位置直接交互，但序列越长，计算与缓存开销通常增长得很快。卷积擅长低成本地处理邻近信息；滑窗注意力只看附近一段，全局注意力则负责跨远距离建立联系。长上下文窗口只是模型允许输入的长度，不等于模型能在整段文本里稳定找回信息，也不等于运行时只需存下量化后的权重。

机制再把计算集中到关键步骤

文本骨干共24层：13层门控短卷积、5层256-token滑窗注意力、6层全局注意力；三者分工分别偏向低成本局部混合、中程交互和远距离信息传递。卷积核为7，局部卷积能以较低开销处理邻近上下文，但无法单独替代跨长距离的注意力，因此仍保留全局层；全局层带来更强交互能力，也重新引入长上下文计算与KV缓存成本。门控让卷积或注意力输出可按内容调节，注意力头另用sigmoid门控；全局层采用部分RoPE，区块使用sandwich norm，官方将这些设计与表达能力、训练稳定性及长上下文成

结果最后落到可验证的工作结果

['适合本地工具调用、轻量agent与单GPU微调', '视频输入按2fps采样，需评估快速动作遗漏', '量化权重约1GB不代表总运行内存仅1GB', '长文档检索、重知识问答和复杂编码先做实测']

六个模型，瞄准的不是同一种任务

Liquid AI于2026年10月27日发布LFM3，这是一个由共同基础模型分出的六款开权重模型家族，面向文本、视觉、音频、全模态和决策任务。成员包括LFM3-1.7B文本模型、视觉模型LFM3-VL-2B、音频模型LFM3-Audio-2B、全模态LFM3-Omni-2B，以及d1-2B和d1-Omni-2B两个决策模型。它们不是一款模型换六个名字：不同成员加入相应的视觉或音频组件，决策模型也分别从视觉和全模态模型专门化而来。

这套发布最值得技术负责人留意的变化，是小模型竞争的目标从“参数更少”转向“能否在限定设备上完成一类工作”。Liquid AI称这些模型可以在单张GPU上微调，并部署到手机、笔记本、私有服务器或云端；这描述的是一条部署路径，不是所有模型都能在所有设备上同样运行。文本模型主打本地 agent，视觉模型支持视频输入，全模态模型可用文字或语音回答，决策模型则试图用一次前向计算处理多个问题。选型的起点因此应是输入、输出和任务，而不是家族名称里的参数规模。

混合架构是在分配计算，不是消灭注意力

LFM3-1.7B的文本骨干有24层，但并非每层都做同一种注意力计算：其中13层使用门控短卷积，5层使用256-token滑动窗口注意力，另有6层全局注意力。卷积核从前代的3扩大到7，注意力头增加sigmoid门控，全局层采用部分RoPE，并使用sandwich norm。直观上，短卷积和局部注意力承担较近距离的信息处理，少数全局层则为跨较长距离的信息交互保留通道；这是计算的分配方式，不是长上下文能力自动免费的证明。

Liquid AI称，这种组合由硬件在环的架构搜索选出：LFM2阶段在一部手机和一台笔记本上调优，LFM3则覆盖14种设备与后端组合，包括Raspberry Pi 5和Qualcomm Hexagon NPU。这个差异说明设计目标不只是抽象的模型分数，也包括算子在具体硬件上的表现。不过，公开材料没有给出每种设备上的统一延迟、吞吐或功耗结果，不能仅凭搜索覆盖面推断某个部署点一定更快或更省电。对工程团队来说，这种方法的价值在于把硬件约束提前纳入架构选择，而不是等模型训练完再寻找运行时补救。

长上下文和小权重之间，仍隔着缓存

LFM3-1.7B有256K-token上下文窗口，官方称其4-bit权重约占1GB。这是一个容易被误读的数字：它描述的是量化后的权重规模，不是模型运行时的总内存。Liquid AI还给出另一项成本：文本模型在完整128K上下文下，KV cache需要1.6GB。权重和缓存是两笔不同的账，而实际运行还要看所用运行时、输入长度和设备条件。

家族内部的上下文规格也不统一。公开模型卡给出的LFM3-VL-2B窗口为128K，LFM3-Audio-2B为32K，不能把文本模型的256K推广到所有成员。发布提供GGUF、MLX、ONNX、FP8和NVFP4等格式，扩大了可尝试的运行路径，却不意味着每种格式在每种硬件上都具备相同能力。对于端侧方案，先用目标设备、目标量化格式和预期上下文长度测峰值内存，比把“1GB”直接写进资源预算更可靠。

基准成绩显示的是取舍，不是全面胜出

Liquid AI报告的LFM3-1.7B 29项基准平均分为49.37，并称高于Qwen3.5-9B的47.24；这些是发布方自己的评测结果，不是独立复核。拆开看，agent相关任务更能解释它的定位：WebArena-Verified得分38.42，对比Qwen3.5-9B的28.94；BFCL V4为71.39，对比62.83。与此同时，知识和编码任务并未呈现同样优势：GPQA Diamond为63.37，对比80.40，SWE-bench Verified为43.40，对比51.20。平均分把不同能力压成一个数，部署判断却不能这样压缩。

长上下文结果也提醒团队不要把窗口大小和有效检索能力画等号。LFM3-1.7B在RULER 128K上得分65.56，低于材料所列Qwen3.5-9B的87.11；在Humanity’s Last Exam上，未用工具得分7.17，启用搜索后升至13.90。后一个变化说明工具可以补足一部分能力，但不会把模型本身变成更强的知识推理器。若应用依赖长文档召回、复杂编码或高难度知识问答，就应分别测量检索、工具调用和模型回答，而不是仅凭256K上下文或29项平均分做上线决策。

真正的部署问题还包括训练和许可

LFM3-1.7B的基础模型据称使用22T tokens训练，最后3.5T tokens侧重agent轨迹和工具调用数据，并扩展上下文。公开材料中的分段数字存在口径差异：模型卡图示的各阶段相加约为21.55T，文字则写22T和最后3.5T。它们可能涉及四舍五入或阶段划分不同，但现有材料没有解释清楚，不能把数字差异当成已核实的精确训练账本。对技术负责人而言，更直接的问题是这些训练取向是否匹配自己的任务分布，而非单看训练token总量。

“开权重”也不足以直接回答商业部署能否使用。发布材料列出的许可为LFM Open License v1.0，来源摘要提到与1000万美元收入门槛相关，但具体限制和适用条件需要以许可证文本为准。因而，LFM3适合被当作一套值得做针对性试验的本地模型方案：先选定具体任务和设备，核算权重、缓存与运行时，再复测关键基准，并在接入产品前审查许可证。它提供的是架构与部署选择，不是已经兑现的端侧性能保证。