LFM3-1.7B-Base 对比 LFM2.5-2.6B-Base：更少参数、更少 Token、更多上下文

算术的方向反了。LFM3-1.7B-Base于2026年10月26日发布，比LFM2.5-2.6B-Base小36%，后者由Liquid AI于2026年8月4日推出——1.73亿亿参数对2.69亿亿参数。它的训练token数也更少：22万亿对约34万亿。按照业界通常用来给预训练模型排序的这两个数字，更新的检查点本该更差。Liquid的说法却恰恰相反，至少对在其之上构建的后训练模型而言是如此；而对任何要挑选一个主干模型来微调的人来说，有趣的问题在于：这些差异中哪些是真实的，哪些只是用一套基准测试讲出来的故事。跑这个对比，消耗的应该是算力，而不是第二份合同。0% 加价OrcaRouter以0%的加价转嫁各提供商的标价。

这是一次同一家族内部的比较，因此显得异常清晰。相同的厂商、相同的许可证家族、相同的 128,000 词元词汇表、相同的 2,048 隐藏维度、相同的 base-to-base 角色。这两个检查点在架构、数据量、上下文长度以及固化到主干中的后训练量上有所不同。其他几乎所有因素都保持不变。

差值，逐维度来看

• 参数 — LFM3-1.7B-Base 为 1.73B，而 LFM2.5-2.6B-Base 为 2.69B。减少了 35.7%，这正是 Liquid 发布文章中“参数减少 35%”这一说法的来源。

• 层数——24 对 30。较新的模型不仅更窄，也更浅。

• 层混合——LFM3 采用十三个门控短卷积、五个滑动窗口注意力块和六个全注意力块；LFM2.5 采用二十二个卷积和八个全注意力块，且没有滑动窗口层级。

• 注意力——LFM3 中有十六个查询头和四个键值头，而 LFM2.5 中为三十二个和八个。两者均保持头维度 128 和隐藏大小 2,048。

• 前馈宽度——LFM3 为 7,680，而 LFM2.5 为 10,752。参数缩减的大部分实际上就集中在这里。

• 卷积缓存——LFM3 为七个，LFM2.5 为三个，并新增了 256 个 token 的滑动窗口。

• 上下文 — 262,144 个 token，对比 128,000 个。较新的检查点将其翻倍。

• 预训练 token 数——22 万亿对约 34 万亿，其中较新一次训练的最后 3.5 万亿个 token 专门用于经过整理的 mid-training 数据，包括智能体轨迹与工具调用。

• 产物 — LFM3-1.7B-Base 仅以 BF16 safetensors 形式发布，大小为 3.46 GB。LFM2.5-2.6B-Base 提供 Safetensors 以及 GGUF、ONNX 和 MLX 构建版本，量化后可在低于 2.5 GB 的情况下运行，并获得 Transformers、vLLM、SGLang、llama.cpp 和 MLX 支持。

参数去哪儿了

缩减并非均匀分布，这对任何估算微调成本的人都很重要。两个模型都采用绑定嵌入，词表完全相同，均为 128,000 个 token，因此嵌入矩阵保持不变。隐藏层大小保持 2,048 不变。节省来自三个方面：层数减少六层、注意力头数减半，以及前馈块窄了约 29%。

收窄前馈块是缩小 transformer 成本最低的方式，因为该块承载了每一层中的大部分参数。将注意力头数减半会同时减少键值缓存和权重，这就是为什么一个上下文长度翻倍的模型仍可被描述为在 4 位量化下约 1 GB 内运行。代价是容量：更窄的 MLP 用于存储事实关联的空间更少，而更少的头数使模型可用的独立注意力模式减少。Liquid 的论点是，更好的数据和更好的层组合足以弥补这一点。这个论点是可以检验的，而截至本文发布时，公司外部还没有人检验过它。

上下文来自哪里

将上下文从 128K 翻倍到 256K 而不让注意力开销也翻倍，就需要避免全局注意力。LFM3 的堆栈正是这样做的：它将其二十四层中的五层交给 256 token 的滑动窗口，十三层交给卷积，只留下六层能够看到整个序列。该配置还在全局注意力层上设置了 0.5 的部分旋转因子，对每个头维度的一半应用旋转嵌入，并且这些层的旋转 theta 为一百万，而滑动层则为一万。

Liquid 的发布博文给出了一个具体数字来说明这能带来什么：在 128K tokens 下，文本模型的 KV 缓存为 1.6 GB。对于 LFM2.5-2.6B-Base，没有公布同等数字。因此，这种比较是方向性的，而非精确的——较新的架构旨在以更少内存容纳更长上下文，而厂商自己的数字是唯一可用的测量值。

为什么更少的 token 才是那个有意思的说法

从34万亿个token降至22万亿个，意味着在数据层面将预训练计算量减少了35%，这与大多数模型代际演进的方向相反。通常的叙事是数据更多、参数更多、模型更好。Liquid的叙事则是两者都更少，同时采用新架构和新的数据配比，加入了科学论文、仓库级代码、数学内容以及更广泛的知识来源。

3.5 万亿 token 的中间训练阶段，正是让这个检查点区别于简单预训练的地方。它使用经过筛选的更高质量数据，其中智能体轨迹和工具调用占比更高，并且上下文窗口也是在这一阶段扩展的。这个阶段也是基础模型带有聊天模板的原因：中间训练数据被格式化为对话，既有带思考轨迹的，也有不带思考轨迹的。

这些都无法从外部验证。token 计数是自行报告的，数据混合比例未公开，也没有消融实验表明哪项改动带来了哪项收益。这一说法看似合理——过去两年里，数据质量屡次胜过原始数据量——但“看似合理”并不等于经过测量。

基地对基地的比较能解决什么

它可以确定规格、成本和兼容性，本页也确实做到了这一点。它无法确定质量，因为这两个检查点都没有已发布的基准测试。Liquid 没有为 LFM2.5-2.6B-Base 发布评估，也没有为 LFM3-1.7B-Base 发布任何评估。两张模型卡都推荐将该检查点用于大规模微调，并指引读者到其他地方了解聊天用途。

这个家族中唯一的质量证据是经过后训练的那一对模型。Liquid 报告称，LFM3-1.7B 在其自有测试套件上的平均得分为 49.37，而 LFM2.5-2.6B 为 31.55，且较新的模型使用的参数少了 35%。这是一个很大的差距，但它是厂商数据，是在厂商选定的测试套件上测得的，而且比较的两个模型不仅主干不同，后训练也不同。这能证明 LFM3 的配方能产出更好的 instruct 模型，但不能证明其基础检查点是更好的起点，因为其上的后训练可能解释了全部差异。

面向所有 LFM2.5 用户的迁移说明

这两个检查点共享词表大小、隐藏层大小和分词器系列，这使得迁移看起来比实际更容易。它们并不共享建模代码：LFM2.5 加载为 Lfm2ForCausalLM，LFM3 加载为 Lfm3ForCausalLM，二者都通过带 trust_remote_code=True 的自定义代码加载。为其中一个编写的训练脚本如果不更改模型类，就无法加载另一个，而且聊天模板在处理思考轨迹方面也有所不同。

更大的运维差异在于打包方式。LFM2.5-2.6B-Base 提供 GGUF、ONNX 和 MLX 构建，并可在 llama.cpp、vLLM、SGLang、Transformers 和 MLX 下运行。LFM3-1.7B-Base 以单个 BF16 safetensors 文件的形式发布；量化版本和跨平台构建针对的是经过后训练的 LFM3-1.7B，而不是基础检查点。如果你的流水线依赖 GGUF 制品，你就得自行转换并验证结果。

微调支持则是与之平衡的另一面。LFM3-1.7B-Base 提供了用于监督微调和持续预训练的 TRL notebook 链接，文档也覆盖了从那里继续的路径。更小的检查点、256K 上下文以及智能体中期训练，都正对准这些 notebook 所展示的那类领域适配。

从哪个主干开始

如果你要开始新的微调、你的任务受益于长上下文，并且你能使用 Transformers 在 BF16 下工作或自行转换权重，请从 LFM3-1.7B-Base 开始。参数减少 35% 在单 GPU 训练中能省下真金白银，上下文长度翻倍是实实在在的能力变化，而聊天模板缩短了监督阶段。

如果你已经有可用的流水线、依赖 GGUF 或 ONNX 产物，或需要一个背后有一年社区工具支持的检查点，请继续使用 LFM2.5-2.6B-Base。较新的模型才发布三天。它的 Instruct 同系列模型已有量化构建，并在 vLLM、SGLang、llama.cpp、Ollama、LM Studio、MLX 和 ONNX Runtime 中获得首日支持，但基础检查点还没有；这一差距正是抢先采用带来的实际成本。

如果你不确定，就去做实验，而不是去读营销材料。从你自己的数据中取一小部分，用同一套继续预训练配方对两个主干模型训练相同的步数，并在你开始之前构建的留出集上评估。这只需要几个 GPU 小时，却能回答任何供应商表格都回答不了的问题。当两个微调模型都就绪后，把它们放在同一个端点后面：OrcaRouter 的 路由 DSL 可以在它们之间分流流量，而自动故障转移意味着一次糟糕的实验不会变成糟糕的生产日。该平台以 0% 加价透传供应商标价，因此运行测试的成本就是算力成本，而不是再签一份合同。

值得关注的数字

能为此定论的不是又一个平均值。而是一次基座模型评估——任何基座模型评估——由 Liquid 或第三方发布，在相同的微调配方下比较 LFM3-1.7B-Base 和 LFM2.5-2.6B-Base。在它出现之前，代际差异在架构和配置中有文档记录，在 token 数量上看似合理，但在真正重要的地方尚未得到证明。较新的检查点更小、上下文更长，并且为训练做了更好的打包。它是否更好，是仓库没有回答的问题。