LFM3-1.7B-Base：代码仓库透露了什么，以及 Liquid AI 尚未说明什么

Liquid AI 新模型家族中影响最大的检查点，恰恰是可供阅读内容最少的那个。 LFM3-1.7B-Base是一个拥有 17.3 亿参数的纯文本预训练模型；2026 年 10 月 27 日，它成为所有后训练 LFM3 模型构建所基于的主干——文本模型、视觉模型、音频模型、全模态模型，以及两个决策模型。家族发布博文只用了一个分句提到它。它没有独立公告，没有基础模型基准表，也没有针对它的媒体报道。与此同时，代码仓库却异常明确地说明了这个检查点是什么、用途是什么，这使得这次发布很容易描述，却很难被夸大。 模型提供商收取的费用不会附加任何加价。 提供商标价 供应商价格变动当天就会反映到你的账单上。

下文将把这两件事区分开来。前半部分的所有内容都来自模型卡、配置文件、许可证文本或 Liquid 自己的发布帖，今天就可以核查。后半部分则是权重上线三天后仍然真正未知的内容。

两个代码仓库、一篇发布文章，以及十二小时的间隔

时间戳讲述了一次发布的来龙去脉：它先在公开场合发生，之后才出现在营销中。经过后训练的LFM3-1.7B仓库创建于 2026 年 10 月 23 日。基础仓库创建于 10 月 26 日 16:28 UTC，其模型卡最后修改于 10 月 27 日 04:15 UTC——不到十二小时后。博客文章《推出 LFM3：面向专用智能的每一种模态》的日期是 10 月 27 日。等到公司外任何人能读到规格说明时，权重已经在 Hugging Face 上放了一天。

这个顺序值得直白说明，因为它是这里最接近“静默发布”的东西。Liquid 确实发布了该系列，公告中将 LFM3-1.7B-Base 列为其他六个模型所基于训练的检查点。公司没有做的，是以基础检查点自身名义单独发布它——没有单独的帖子，没有针对基础模型的专门评估，除了模型卡中的一段话之外没有任何定位。系列获得了发布，主干得到的只是一个代码仓库和指向该系列的指引。

仓库里有什么？

模型卡片很简洁，而且这一次在基础信息上是完整的。一个 3.46 GB 的 bfloat16 model.safetensors 文件。一个词表规模为 128,000 的 tokenizer。模型代码以自定义 Python 的形式随权重一同提供，需通过 trust_remote_code=True 加载，而不是通过已合并的上游 Transformers 发行版。许可证是 LFM Open License v1.0，与 Liquid 自 LFM2 以来所使用的一系列条款同属一脉。

• 参数 — 1.73B，稠密，每处理一个 token 都会读取全部参数。

• 层 — 24：十三个门控短卷积块、五个滑动窗口注意力块、六个全注意力块。

• 上下文 — 262,144 个 token，输入加输出。

• 注意力几何结构 — 隐藏维度 2,048，十六个查询头，四个键值头，头维度 128。这是四比一的分组查询注意力，而不是 LFM2.5 的八比一。

• 局部窗口——256 个 token，并配有大小为 7 的卷积缓存。这是逐层的注意力设置，而非上下文长度；当该架构在发布前一天首次出现在某个引擎的拉取请求中时，曾引发了一小波误报。

• 词汇表与语言 — 128,000 个 token，列出了十六种语言：英语、阿拉伯语、中文、法语、德语、意大利语、日语、韩语、葡萄牙语、西班牙语、越南语、泰语、印度尼西亚语、印地语、俄语、波兰语。

• 内存——据 Liquid 称，4 位精度下约为 1 GB，出厂时的 BF16 版本为 3.46 GB。

在引用某个规模之前，有一个小不一致值得了解。Hugging Face 的侧边栏将该模型四舍五入为“2B params”，而卡片中的表格写的是 1.73B。文件可以说明问题：3.46 GB 的 bfloat16 按每个参数两字节计算就是 17.3 亿个参数，因此侧边栏标签只是四舍五入的惯例，而不是另一套规格。撰写本文时，该仓库显示过去一个月有 15 次下载和 8 个赞——这是一个已发布、从发布帖获得链接、但尚未被任何人采用的检查点画像。

架构，不含图示

最好把这一设计理解为一种预算权衡。在长上下文下，全注意力是 transformer 中昂贵的部分：每个 token 都要与其他所有 token 进行比较，而成本随序列长度的平方增长。Liquid 的三混合堆栈只把二十四层中的六层用于这一操作。十三层是门控短卷积，以每个 token 固定成本在局部混合信息；五层是滑动窗口注意力块，一次只查看 256 个 token。网络中三分之二的部分完全不执行全局注意力操作。

这就是 Liquid 自 LFM2 以来一直在下、如今更进一步的那同一注。LFM2.5-2.6B-Base 用了三十层，拆成二十二个卷积和八个全注意力块，没有滑动窗口这一层。LFM3 在堆栈的五处用滑动注意力块替换掉一对卷积，把卷积缓存从三提到七，并加入了配置里出现的三明治归一化和部分旋转设置。这一具体取舍是否提升了质量，只有评测能回答，而截至发稿时还没有基座模型评测来回答它。配置能确立的是：256K 上下文不是靠把注意力扩展到 256K 实现的，而是靠让堆栈的大部分保持局部。

基础模型自带聊天模板

这最可能让那些下载该检查点、期待原始文本补全的人感到困惑。LFM3-1.7B-Base 包含完整的聊天模板，而模型卡说明中期训练包含了带和不带思考轨迹的聊天数据，并使用与后训练模型相同的模板进行格式化。调用 apply_chat_template 时，推理默认启用：除非传入 enable_thinking=False，否则响应会从思考块内部开始；传入后会预填一个空轨迹，并要求直接回答。

所以它的行为有点像指令模型，而文档却把它描述成完全不同的东西。模型卡自身的建议毫不含糊：LFM3-1.7B-Base“仅推荐用于需要大量微调的任务，例如特定语言或特定领域的助手、基于专有数据的训练，或试验新颖的后训练方法”。对于聊天、工具调用和智能体，它指向的是 LFM3-1.7B。这个模板之所以存在，是因为中期训练数据按那种格式组织，并且微调会继承它——并不是因为这个检查点曾针对对话进行过调优。任何把该模板当作就绪信号的人都会对输出感到失望，而模型卡在他们开始之前就已经说明了这一点。

人们会引用的数字并不是这个模型的数字。

发布文章包含一个内容详实的基准测试表，但其中几乎没有任何内容适用于本文所讨论的检查点。49.37 的主打平均值属于 LFM3-1.7B，即经过后训练的模型，是在 Liquid 自有套件上测得的。对比行——LFM2.5-2.6B 为 31.55、MiniCPM5-2B 为 39.19、Gemma 4 E4B 为 31.74、Qwen3.5-4B 为 39.27、Qwen3.5-9B 为 47.24——是后训练模型与后训练模型之间的比较。SWE-bench Verified 上的 43.40 和 LiveCodeBench v6 上的 73.46 同样是调优后模型的分数。

在随意阅读中，有两种说法会被附会到这个基础检查点上，但不应如此。第一种是“参数减少35%”——那是LFM3-1.7B优于LFM2.5-2.6B，是关于后训练模型对的陈述，而非基础模型对基础模型的结果。第二种是LFM3“媲美Gemma 4 12B”的说法。那句话针对的是视觉模型LFM3-VL-2B，涵盖62项视觉基准。它完全没有涉及文本基础检查点，而后者根本没有已发布的评估。一个没有基准表的基座模型并不罕见——Liquid也刻意没有为LFM2.5-2.6B-Base发布任何基准表——但这种缺失意味着，目前关于这个检查点的每一项质量主张，实际上都是关于由其产出的模型的主张。

培训，以及真正与众不同的部分

Liquid 表示，该检查点在两个阶段共处理了 22 万亿个 token。主预训练阶段相对于 LFM2 调整了数据配比，增加了更多科学论文、仓库级代码、数学内容，并扩大了知识来源的覆盖面。最后的 3.5 万亿个 token 属于中期训练阶段，使用的是经过筛选的更高质量数据，其中智能体轨迹和工具调用的占比更高；上下文窗口也是在这一阶段扩展到 256K。

不寻常之处不在于 token 数量，而在于智能体数据被放进了基础模型，而不是只用于后训练。大多数厂商会把工具调用轨迹保留到指令微调阶段使用。Liquid 把它们放进了主干，然后在此基础上用 SFT、混合 RL、多领域同策略蒸馏和智能体 RL 后训练了六个不同的模型。对于一个旨在跨模态共享同一个骨干的模型家族来说，这是一套连贯的策略，也正是基础检查点会带有聊天模板的原因。这是一种关于训练方法的说法，无法从外部核实，也不存在独立复现。

如今你可以用它做什么

模型卡片链接了两个 TRL notebook：一个用于监督微调，从杂乱文档中提取结构化 JSON；另一个用于在新语言上继续预训练，并以从原始文本中使用土耳其语为例。两者都基于 LFM3-1.7B 编写，并且只需更改一个 model_id 以指向基础检查点。文档页面涵盖了微调路径的其余部分。instruct 模型有一套完整的运行时变体——用于 vLLM、SGLang 和 Transformers 的 BF16；用于 SGLang 的 FP8 和 NVFP4；用于 llama.cpp、Ollama 和 LM Studio 的 GGUF；用于 Apple silicon 的 MLX；ONNX Runtime。基础检查点只有一个产物：BF16 safetensors 文件。没有 GGUF，没有 MLX 构建，也没有量化发布版本。如果你想在手机上运行它，转换工作得由你自己完成。

如果你靠提供模型服务谋生，这适用于什么场景

预训练的检查点并不是聊天端点，这一点值得具体说明。截至撰写本文时，LFM3-1.7B-Base 并未出现在 OrcaRouter 的目录中，而且基础模型会是一个很奇怪的待路由对象：它没有可供路由的指令遵循能力。路由器真正有用的位置要从下一步开始，也就是在微调版本存在之后。将 200 多个模型置于同一个 API 之后，对提供商标价零加价，具备自动故障转移和路由 DSL，因此经过领域调优的 LFM3 检查点可以与更大的通用模型并列，进行比较或故障转移，而无需第二次集成。当 1.73B 的专用模型擅长一件事而你还需要第二种意见时，模型融合——由一组模型共同作答——是另一个选择。这一切都不要求基础检查点本身被托管在任何地方。

仍未确认的是什么？

• 基础质量。没有基准测试表，没有评估框架输出，也没有在任何任务上与 LFM2.5-2.6B-Base 进行对比。

• 独立验证。 尚无第三方实验室公布基础模型或调优模型的运行结果。发布帖中的每个数字都出自 Liquid 自己。

• 上游 Transformers 支持。该仓库使用自定义建模代码和 trust_remote_code。这在发布初期是正常的，但后期会带来维护成本。

• 基础模型如何提供服务。 发布文章称，基础模型和经过后训练的模型可在 Hugging Face、Liquid Playground 和 Liquid API 上使用。API 如何处理未经调优的基础检查点，文中并未说明，也没有公布其定价。

• 许可证边界情形。 LFM Open License v1.0 在年收入低于 1000 万美元时可免费用于商业用途；超过该门槛则需适用商业许可证。许可证文本是公开的，但它如何处理基于基础模型训练、随后投入商业服务的衍生模型，是律师要回答的问题，而不是模型卡要回答的问题。

看什么

下一个有意义的信号不是又一场发布，而是对后训练模型的首次独立评估，以及首个公开微调——它报告了在基础检查点上训练起来是什么样。Liquid 自己的说法正邀请这种检验：一个 1.73B 主干产出了六个模型，并声称击败 2.69B 的前代，这要么是真正高效的架构，要么是精心挑选的基准测试套件，而只有外部运行才能区分两者。在那之前，仓库就是全部故事：一个 3.46 GB 的文件、一份清晰的规范、一个并非邀请的聊天模板，以及一份在营收线逼近之前值得一读的许可证。