LFM2.5-2.6B-Base：Liquid AI 最低调的一次发布，却是微调者们真正想要的

浏览2026年8月5日Hugging Face上的计数器，差距一目了然：LFM2.5-2.6B，即Liquid AI于8月4日发布的智能体端侧模型，下载量为47,393次。LFM2.5-2.6B-Base，即所有这些权重所源自的预训练检查点，下载量为151。同一组织、同一架构、同一周，比例却是314比1。

基础检查点既未被泄露，也未被隐藏。它在 Liquid 的发布帖子中恰好只出现在一个括号里——"基础模型（LFM2.5-2.6B-Base）和后训练模型（LFM2.5-2.6B）今天已在 Hugging Face 上提供"——这就是关于它的全部公开记述。它没有自己的基准测试、没有专门章节、也没有单独的模型卡。下文所有内容均直接读取自仓库——模型卡、config.json、LICENSE 文件以及 Hugging Face API——再加上我们自己做的计算。凡是来自 Liquid 自身评估的数字，我们都会注明，因为对于这个特定的检查点，最重要的事实是实际被测量的内容少之又少。

这比脚注所暗示的更为重要。经过后训练的模型，你可以通过尝试来评判；而基础检查点则是一项提议：你得先投入两周时间和GPU预算，才能了解任何东西。因此，这项提议的条款——包含什么、许可作何用途、经过了哪些评估——才是决策的全部。

仓库里实际有什么？

九个文件，一个权重分片，没有建模代码。卡片规格列表，对照config.json：

• 共2.69B参数，bfloat16格式，位于单个5.39GB的model.safetensors中。请按该数字规划存储和显存，而不是按"2.6B"规划。

• 30层，混合架构。 卡片显示22个双门控短卷积块和8个GQA注意力层。这个layer_types 数组在 config.json 中，确切地证实了这一点：22个 conv 和8个 full_attention，注意力层大致每隔三或四个块分布，而不是聚集在一起。

• 隐藏宽度 2048，中间维度 10752，32 个注意力头对应 8 个键值头——即 4:1 的 GQA 比率——并使用绑定的输入和输出嵌入及 10,000,000 的 rope theta。

• 包含 128,000 个词元的词表，以及配套的 18 MB 分词器。Liquid 在这一代模型中将词表扩大了一倍，在 2.6B 参数规模下这是一笔可观的成本：采用绑定嵌入时，仅词表一项就占据了约 262M 的参数预算，接近模型的十分之一。

• 34万亿个训练token。 对于这个规模级别来说，这是一次异常长的预训练运行，也是完全值得查看该检查点的唯一最强理由。

• 16 种语言已声明支持：英语、阿拉伯语、中文、法语、德语、印地语、印度尼西亚语、意大利语、日语、韩语、波兰语、葡萄牙语、俄语、西班牙语、泰语和越南语。

对于任何计划进行长上下文工作的人来说，有一个不一致之处：卡片宣传的上下文长度为 131,072 个 token，而 config.json 将 max_position_embeddings 设置为 128,000。Liquid 自己的博客和文档都说是 128K。这 3,072 个 token 的差异对大多数人来说无关紧要，但如果你正在编写一个将序列打包到宣传的最大长度的训练脚本，请相信配置文件，而不是卡片。

架构字符串是实际的要点：model_type为lfm2，类别为Lfm2ForCausalLM——与 LFM2 发布的类别相同。LFM2.5 是在现有架构上进行的扩展预训练和新的后训练，而非全新架构，因此这里无需任何自定义建模代码。这就是为什么 llama.cpp、vLLM、MLX、ONNX Runtime、SGLang 和 LM Studio 在发布当天就全部支持该系列，也是为什么通过 Unsloth 和 TRL 的微调路径无需补丁即可运行。你确实需要transformers>=5.0.0。

你拿到的卡是另一款型号的卡

打开基础仓库，第一个标题是"LFM2.5-2.6B"——这是后训练模型的名字，而不是你现在看的那个。这并非吹毛求疵；整个页面读起来就像把一段基础模型说明拼接进了指令卡里，而其中留下的三处痕迹会实实在在浪费你的时间。

• YAML frontmatter 中写着 base_mode: LiquidAI/LFM2.5-2.6B-Base。同一行有两个问题：该键拼错了 Hugging Face 的base_model，而且它把基础仓库指向了自身。这不会导致任何故障，但不会生成你期望的、由正确声明的谱系所得到的模型树链接。

• 该仓库被标记为对话型，并附带了一个 chat_template.jinja，因此 Hugging Face 会在一个从未经过指令微调的检查点上显示“聊天模板”徽章。模板存在是因为分词器配置是继承来的，而不是因为权重知道该如何使用它。

• Quick-start 代码片段随后会使用该模板。基础卡上的 Python 示例调用tokenizer.apply_chat_template，传入一条{"role": "user"}消息，并询问“What is C. elegans?”——这是让基础模型看起来表现糟糕的经典方式。将原始预训练检查点包装在对话轮次中，会产生漂移、重复、自我延续的文本，人们很容易将其解读为模型质量差，而不是提示格式错误。请把本模型当作文本补全器来使用，采用少样本（few-shot）提示，并使用你可控的停止序列。

• 变体表仅列出后训练产品线—— LFM2.5-2.6B，以及其 GGUF、ONNX 和 MLX 构建。基础检查点完全没有 GGUF 或 MLX 构建，因此如果不自己转换，"今晚就在 LM Studio 中本地运行"是行不通的。

Hugging Face 还报告说，没有任何推理提供商为该仓库提供服务。该基础检查点在任何地方都没有托管的端点；如果你想要它的 logits，就自己租用 GPU。

不存在的基准部分

{{1}}LFM2.5-2.6B-Base 迄今未发布任何一项评估数据。{{/1}}{{2}}没有 MMLU，没有 MMLU-Pro，没有 GPQA，没有 HellaSwag，没有 ARC，没有困惑度数值——什么都没有，在 Liquid 的三个界面（模型卡、发布帖、文档）上均是如此。{{/2}}{{3}}对于一个基础检查点而言，这种缺失格外扎眼，{{/3}}{{4}}因为那些知识与推理评分恰恰是你判断 34T 预训练 token 是否留下值得微调之物的依据。{{/4}}

现存的成果属于后训练的姊妹模型，由Liquid报告，尚未被独立复现。在Liquid自己的评估中，LFM2.5-2.6B在OpenClaw测试框架内，AIME25得分51.87，IFBench得分59.17，Multi-IF得分80.07，BFCLv4得分56.88，ToolSandbox得分77.83，BrowseComp+得分26.89；对比对象为gemma-4-E2B-it（5.1B）、gemma-4-E4B-it（8B）、Qwen3.5-4B（4.7B）和Qwen3.5-9B（9.7B）。Liquid的总结是，它在每个指令遵循基准上都领先，在几乎所有工具使用基准上也领先；而其自己的图表也坦率地指出了例外：Qwen3.5-9B在AIME25上以56.07领先，在BFCLv4上以60.13领先。速度声明遵循同样的规则——在M5 Max上解码速度为220 tokens/s，在Ryzen AI Max+ 395上为113 tokens/s，在手机上约30 tokens/s，内存占用低于2.5 GB，在单张H100上高并发时输出约15K tokens/s——全部为厂商测量，尚未经任何其他人验证。

陷阱在于假设其中任何一项都能迁移。那些分数是四阶段流水线应用于此检查点之上的产物：两轮监督微调、逐领域教师特化、多领域同策略蒸馏，然后在真实测试框架内使用GRPO进行智能体强化学习。工具调用和指令遵循正是该流水线植入的行为。拿走基础权重，你就是在这一切之前起步。你继承的是预训练——语言、世界知识、长上下文能力、高效的混合架构——而你应该假设自己没有继承智能体评分榜上的任何东西。

151次下载不只是偏早——它偏离了该家庭自身的规律

Liquid 定期发布基础检查点，因此此次发布在种类上并无特别之处。可衡量的是这种忽视。将每个 LFM2.5 基础仓库与同日的 instruct 兄弟版本进行比较，就能得出一个明确的内部常态——以及一个明确的离群值。

• LFM2.5-230M — 58,676 次下载，而基础版本为 6,982 次：比例约为 8 比 1。

• LFM2.5-350M——94,526 对 9,397：约 10 比 1。

• LFM2.5-1.2B — Instruct 构建为 583,914，而基础构建为 17,867：约为 33:1。

• LFM2.5-8B-A1B——171,520 对 3,996：约为 43 比 1。

• LFM2.5-2.6B — 47,393 对比 151：约 314 比 1。

其中一部分仅仅是因为时间；基础仓库创建于8月1日，而指令模型提前四天起步，外加一篇发布帖。但该系列中较早的基础检查点最终稳定在8比1到43比1之间，因此比其中最差的情况还要高出一个数量级，这确实是真正的异常，而不是新仓库的舍入误差。

点赞数讲述了一个更微妙的故事。基础仓库有28个点赞，对应151次下载——大约每五次拉取就有一个收藏。指令模型有232个点赞，对应47,393次下载，大约每204次拉取才有一个收藏。人们标记基础检查点是为了日后回来使用，而不是拉取它。其模型树中已经存在两个社区微调版本和七个量化版本，这正是大规模采用到来之前的前沿形态。

“无限制”并不是许可证所说的内容。

Liquid 的发布页面将该版本描述为开放权重：“下载、微调并无限制地部署。” 而仓库中的文件表述则更为狭窄，如果您正在考虑基于这些权重构建产品，这一部分值得仔细阅读两遍。

该许可证为LFM Open License v1.0——不是 Apache-2.0，不是 MIT，也与你可能正在拿来比较的大多数小型开放权重模型的条款不同。直接引用该文件，第 5 条标题为“商业使用限制”，内容如下：“根据本许可证授予的商业使用权，以您或您的法律实体不超过阈值（Threshold）为条件，”随后是“任何超过阈值的法律实体对作品或衍生作品的商业使用，均不受本协议许可。”第 1 条将阈值定义为“年收入达到或超过 1000 万美元（$10,000,000）。”

所以，实际的解读是：

• 年收入低于1000万美元——您拥有广泛、永久、免版税的授权，涵盖复制、衍生作品、分发和再许可，包括商业用途。

• 达到或超过1000万美元——商业使用不受本协议许可。这不是“需要署名”，也不是“需要通知”。你需要联系Liquid，这大概就是卡片末尾附上他们销售团队链接的原因。

• 衍生作品继承该限制。 您对此检查点的微调属于衍生作品，因此您花费一个季度训练的模型将承载相同的基于收入的授权。如果您的公司跨越了该门槛——或被一家已经达到该门槛的公司收购——您产品所依赖的条款将在其下发生变化。

• 符合资格的非营利组织可获豁免：该门槛不适用于以非商业或研究目的使用作品的 501(c)(3) 组织或其外国同等机构。一般义务同样适用——传递许可证、保留署名声明、标记你修改过的文件。

这些都不意味着这次发布很小气；1000万美元的门槛几乎豁免了所有初创企业和每一位研究人员，而且这是发布权重的一种正当方式。但“无限制”是许可证所否认的营销话术，而这种不匹配恰恰在这里咬得最痛。对基础检查点进行微调是采用模型时代价最高、最不可逆的方式。那正是发现收入条款的最糟糕之处。

到底谁应该完成这个检查点

Liquid自己的指导出人意料地狭隘，值得遵循：卡片上说预训练检查点是 "仅推荐用于需要大量微调的任务，例如特定语言（如日语）或特定领域（如医疗）的助手、在专有数据上训练，或尝试新颖的后训练方法。" 那个"仅"字确实起到了实际作用。如果你想要一个能调用工具的端侧代理，后训练的LFM2.5-2.6B绝对是更好的起点，基础检查点会浪费你一个月的时间。

真正适合选择它的场景：

• 一种后训练阶段未充分覆盖的语言。横跨16种语言的34T词元构成了强大的多语言基础，Liquid已通过1.2B系列中的日语构建在内部验证了这一模式。先针对你的语言继续预训练，再进行你自己的指令微调，就无需与以英语为中心的后训练模型特性对抗。

• A regulated vertical with proprietary data. Under 2.5 GB at inference, no cloud dependency, and a permissive-enough license below the revenue threshold is a rare combination for medical, legal or industrial deployments where the data cannot leave the device.

• 后训练研究。Liquid 公开了其配方——SFT、教师特化、MOPD、智能体强化学习——然后将该配方的确切输入与输出一并交出。能够在相同的初始权重上运行你自己的方法，并与一个强大的参考实现进行 diff，是罕见且有价值的。

• 蒸馏目标。在笔记本电脑上以220 tokens/s速度解码的2.6B混合模型，是将更大的教师模型压缩成可发布版本的有吸引力的学生模型。

最后那一对才是成本真正所在，而且不是GPU小时——是数据。Liquid 的流水线依靠教师特化和在策略蒸馏，这意味着要复现类似成果，真正的先决条件是从更强模型生成的大量数据，再加上偏好对和可验证奖励的 rollout。这首先是一项多模型工作，然后才是训练工作：你要在自己的领域里比较候选教师，然后从胜出的那个进行大规模生成。这正是我们产品所针对的工作——OrcaRouter 以 0% 加价将 200+ 模型放在同一个 API 密钥后面，因此你为合成 SFT 数据集支付的是供应商的标价，而不是路由溢价（当供应商降价时，我们这边当天就会同步）；自动故障转移让二十小时的生成任务不会因为某家供应商的坏时段而中断；路由 DSL 则让你能把同一条提示词扇出到多个教师模型并保留最佳答案。需要明确我们不提供什么：LFM2.5-2.6B-Base 不在 OrcaRouter 上，也没有任何推理提供商托管它——你需要自己运行这些权重。我们对教师模型有用，而不是对学生模型。

无论你交付什么，都值得记住同样的划分。Liquid 的文章认为本地智能体让推理变得免费，并消除了按 token 计费这一成本约束，但这只对边际 token 成立，对总账单并不成立——你已经通过硬件预付了这笔费用，而且 2.6B 模型仍有其上限。Liquid 自己也这么表示，建议不要将这一系列模型用于编码密集型或知识密集型的智能体工作。持久有效的模式是：让微调的本地模型在设备端处理高流量的常见路径，并将困难的小部分任务通过 API 升级到前沿模型，这样既能在关键之处保留隐私和延迟优势，又不必假装 2.6B 参数能胜任一切。

从这些权重到可用成果的路径

启动公告对此只字未提，但基础模型卡默默承载了整个仓库中最实用的东西：七个可直接运行的 Colab 笔记本，精确覆盖了基础检查点所需的流水线阶段。其中两个是继续预训练——一个用于文本补全，一个用于翻译——这是只有从基础权重出发才有意义的步骤，也是没人写过教程的步骤。其余涵盖通过 Unsloth 和 TRL 进行的监督微调、通过 TRL 进行的 DPO，以及通过这两者进行的 GRPO。如果你不想自己组装训练栈，Liquid 还提供了 LEAP Finetune 作为其自有的训练栈。

对照这个模型的形态来阅读Liquid的微调文档，实际的流程是这样的：

• 在训练任何东西之前，先把它当作补全器来提示。忽略卡片上的聊天模板。使用少样本（few-shot）、原始文本和你自己的停止序列。这样你就能发现预训练是否已经覆盖了你的领域和语言，从而决定你到底需不需要继续预训练，还是可以直接跳到SFT。

• 只有在添加知识或语言时才继续进行预训练。 这是成本高昂的分支——语料库规模，而非示例规模——也是后训练同类模型真正无法为您提供的东西。

• 然后使用LoRA进行SFT，基于500到5,000个示例。Liquid自身的指导是，质量和分布胜过数量，示例应与生产输入相匹配。在2.6B规模下，一次LoRA训练过程很短：文档指出，1.2B的运行在单块现代GPU上只需几分钟到几十分钟，因此这个规模仍然可以在一个下午内完成循环。

• 在训练前冻结一个留出集。 这话直白，但对这个检查点来说尤其值得重申：因为没有已发布的基线可作对比——你的评估集就是仅有的数字。

• 偏好或 RL 阶段应放在最后，并且仅在行为本身成为问题时才进行。 DPO 和 GRPO 方案已适用于该系列，但它们是对已能回答问题的模型的精化；在 SFT 落地之前就求助于它们，正是基础检查点项目停滞的原因。

注意这个列表里没有什么：这里不需要自定义内核、打过补丁的训练器或建模文件。因为 LFM2.5 复用了 LFM2 架构，基础检查点可以直接放入标准技术栈，整个项目的成本仅仅在于你为它构建的语料库和评估集。

什么会改变这个局面？

有三件事值得关注，对Liquid来说解决起来成本都很低，但今天没有一件得到解决。

第一项是基础评估。在预训练检查点上，一个单独的 MMLU-Pro 或 GPQA 分数能告诉微调者的信息，比发布帖中所有智能体基准加起来还要多；而 34T token 投入训练的事实，让这一缺失更加令人费解，而非更不令人费解。第二项是模型卡本身——一个基础仓库，其标题指向的是另一个模型，其快速入门指南将聊天模板应用于非聊天模型，其 frontmatter 拼错了 base_model 是一个十分钟就能修复的问题，能防止人们在指令出错时误以为权重坏了。第三项是 LFM2.5 技术报告。引用块指向 arXiv 2511.23404，即 LFM2 于 2025 年 11 月发布的技术报告；2.5 代自己的论文尚未发布，因此这 34T token 背后的预训练数据配比仍未公开。

在此之前，诚实的总结是：这是一个规格明确、训练充分、架构高效的2.6B基础模型，目标受众异常清晰，发布时未附带任何评测数据，并采用收入上限许可协议；到目前为止，几乎没有人真正把它拿出来用过。如果你属于模型卡片所描述的目标受众，那么它值得你投入GPU时间去尝试——而且你将成为全世界最早知道它实际表现如何的人之一。

值得回答的问题

这是 LFM2.5-2.6B 进行后训练所用的同一个检查点，还是一个独立的预训练运行？

模型卡说明 LFM2.5-2.6B-Base {{1}}是预训练纯文本检查点，用于创建所有 LFM2.5-2.6B 变体{{/1}}，{{2}}因此它是已发布流水线的实际输入，而不是并行的或精简的版本{{/2}}。{{3}}这正是它对训练后研究有价值的原因：你的方法和 Liquid 的四个阶段从相同的权重出发，因此它们之间的比较是有意义的{{/3}}。{{4}}值得注意的是，基础仓库创建于 8 月 1 日，最后一次修改是在 8 月 4 日，即发布当天{{/4}}——{{5}}在假设你早期下载的文件就是发布时的文件之前，请检查提交历史{{/5}}。

我可以对它进行微调并出售结果吗？

如果贵法律实体的年收入低于1,000万美元，那么可以——LFM1.0授权涵盖衍生作品的商业使用，前提是完整保留许可证和署名声明，并标注修改过的文件。达到或超过该门槛时，对模型或其任何衍生内容的商业使用不在许可证范围内，需要与Liquid另行安排。该门槛基于贵实体的收入，而非基于模型或其产生的收入，因此同一个微调模型可以授权给一家公司而不授权给另一家，而跨越该门槛增长的公司不再保留其原有授权。

为什么不直接对后训练的LFM2.5-2.6B进行微调呢？

对于大多数项目，你应该从基础检查点开始，Liquid 的模型卡实际上也是这么说的。之所以要从基础检查点起步，是因为当后训练对你不利而非有利时：在新语言或专业语料库上大规模继续预训练，本身往往就会损害指令微调的行为，而且通过 SFT 和 RL 固化下来的拒答模式、工具调用约定和回复风格，既难以去除，又容易相互冲突。如果你是在添加知识或语言，那就从基础模型开始。如果你只是要在边缘调整行为，那就从后训练模型开始，并保留别人已经付费完成的四个阶段工作。