TwIL-LM3-Pro 对比 LFM2.5 2.6B Base：一个是成品，一个是起点

关于已发布的 TwIL-LM3-Pro 与 LFM2.5 2.6B Base 之间的比较，最能说明问题的一点是：webAI 根本没有发布过与 2.6B 的对比。webAI 的 Track A 和 Track B 表格将其 3.66B 形式逻辑专用模型与一系列对手进行比较——包括自家的 Granite 基础模型、VibeThinker-3B、Qwen3-8B、Qwen3.5-4B、Llama-3.2-3B、gpt-oss-120b——而他们选择的 Liquid AI 条目是 LFM2.5-8B-A1B，而不是 2.6B。表中确实出现的 2.6B 是 `LFM2-2.6B`，即上一代模型，其预训练运行不同，是另一个模型。这一省略并非疏忽。LFM2.5 2.6B Base 是一个未经指令微调的预训练检查点，而指令遵循基准测试并不是它被构建来参加的测试。

所以，这个页面是在把一件成品与一种原材料进行对比。Aion 式的框架——一个模型有评分，另一个没有——是说得通的，但原因更具体，也更有趣：其中一个是经过后训练并合并的，另一个则有意在后训练之前停下，而描述它们的两份文档是在有意回答不同的问题。

两个并非同一度量的参数计数

TwIL-LM3-Pro 拥有 3.66B 参数，为稠密模型，每个 token 上全部参数都会激活。它源自 `ibm-granite/granite-4.2-3b`，历经 LoRA 微调、多路径蒸馏、检查点融合、向基座模型回并的 WiSE-FT 合并，以及一个熵加权 GRPO 阶段——而 webAI 发布的产物是合并后的策略，并非 LoRA 适配器，因此可独立运行。

LFM2.5 2.6B Base 拥有 2.69B 参数，共 30 层：22 个双门控短卷积块与 8 个分组查询注意力层交错排列。这种卷积/注意力混合设计是 Liquid 的端侧架构，也正是该系列吞吐量数据之所以如此的原因，而非仅由参数数量决定的函数。它在 34 万亿个 token 上训练，词表规模为 128,000 个 token，并拥有 131,072 个 token 的上下文窗口。

这两个计数彼此相差约36%，且是通过完全不同的架构得出的，因此无论是“3.66B 胜过 2.69B”还是反过来，作为质量论断都毫无意义。webAI 自己的模型卡以一种迂回的方式表明了这一点：它拒绝跨分词器比较语料困惑度——TwIL-LM3-Pro 的词表大小为 100,352，LFM2.5-2.6B 的为 128,000，而困惑度是按 token 计算的。

“Base”移除了什么，以及它为何会改变记分牌

Liquid AI 以两种形式发布 LFM2.5 2.6B：经过后训练的检查点，针对流行智能体运行环境中的智能体工作负载进行了调优；以及 Base，其在自己的模型卡中被描述为“仅文本的预训练检查点，用于创建所有 LFM2.5-2.6B 变体”。Base 是微调的输入，而非产品。它没有指令微调，没有像样的对话模板，也没有公开发布的评估——因为在指令遵循任务上评估基础模型，衡量的是错误的东西。

TwIL-LM3-Pro 的立场正好相反。它的全部价值就在于后训练技术栈：webAI 报告称，在其自有测试框架上，该流水线将域内宏平均门控指标从其基座的 0.4313 提升至 0.5539，而留出的 10 个数据集的宏平均指标则保持平稳（0.7942 至 0.7901），并未出现崩塌。留出集上的保持能力正是专家型后训练的难点所在，也正是 Base 无法回答的部分。

这也正是 webAI 表格中的规模对比体现价值之处。据报道，TwIL-LM3-Pro 在两个留出宏平均上均领先于 LFM2.5-8B-A1B——在十个数据集集合上为 0.7901 对 0.7884，在十四个数据集上为 0.7425 对 0.7378——而参数量不到那个 MoE 模型的一半。这是一个真正的同类对比结果，而它之所以可得，正是因为 LFM2.5-8B-A1B 是一个经过后训练的模型，可以通过指令测试框架来运行。Base 做不到，这就是 2.6B 始终没能拥有单独一列的原因。

值得对齐的维度

• 参数 — TwIL-LM3-Pro 3.66B 稠密 vs LFM2.5 2.6B Base 2.69B（30 层：22 个卷积 + 8 个 GQA）。

• 后训练——LoRA SFT、蒸馏、WiSE-FT 合并，以及在 2580 步的 GRPO 与无（后训练）的对比；Base 按设计即为预训练输出。

• 上下文窗口——两者均为 131,072 个 token，继承自各自的基座模型。

• 词汇量——100,352 个标记 对比 128,000 个，这就是它们的困惑度不可比的原因。

• 语言 — 仅英语 vs 十七种，包括阿拉伯语、中文、日语、韩语、西班牙语和泰语。

• 思维格式 — TwIL-LM3-Pro 默认会输出一个 `<think>` 块并进行长篇推理（域内平均 1,902 个 token，24.2% 的生成结果触及长度上限），而一个完全没有指令格式的基础检查点则不会如此。

• 许可 — webAI Non-Commercial License ver. 1.0 与 Liquid 的 LFM Open License v1.0 对比。

• 它的用途——形式逻辑推理端点与微调起点。

上下文行值得加一条两家模型都提供的脚注：二者各自都从预训练阶段保留了 131,072 个 token，而且两家厂商均未验证长上下文行为——TwIL-LM3-Pro 的模型卡指出，所有已公布的分数都是在 8,192 个 token 的窗口内测得的。这里相互吻合的数字是继承而来的，并非经实证展示的。

许可证，以及每种许可证在法律上的用途

TwIL-LM3-Pro 的 webAI 非商业许可证允许研究和个人使用，并要求若进行创收型部署，需与 webAI 另行签订协议。LFM2.5 2.6B Base 依据 Liquid 自有的 LFM Open License v1.0 发布，而 Hugging Face API 将其报告为 `license: other`，而非标准 SPDX 标识符——在围绕它做规划前请先阅读许可证文件，因为其条款是 Liquid 自有的，而不是公认的模板。

这两个许可证都不是 Apache 2.0，将“开放权重”视为“商业上允许”的同义词是错误的。两者之间的实际区别在于许可证所保护的内容：非商业研究人员可以使用两者，构建产品的公司需要检查两者，而 Base 的全部目的——被微调进别人的产品中——使得其确切条款比看起来更重要。

每个在堆栈中的归属位置

如果你打算进行训练，Base 就是正确的选择。如果你的问题是范围狭窄的标注任务、领域专用的分类头，或是在几千个有标注样本上进行微调，那么从一个 2.69B 的预训练检查点出发——它拥有广泛的多语言词表和为吞吐量设计的混合卷积架构——是一个合理的工程决策，而你跳过的后训练成本，正是你转而有意付出的成本。

当你并不打算进行训练，且任务本身已经是形式逻辑时，TwIL-LM3-Pro 就是正确的选择。蕴含标签、Lean 陈述形式化、语义解析和证明评审正是其整个流程所针对的任务，而从已经历过合并与强化阶段的检查点出发，可以为你省去这件事中真正难以复现的那一环——在获得域内提升的同时保持留出测试集的水平。

把“3.66B 后训练专家模型”解读为严格优于“2.69B 基础检查点”是种误解。它们处于同一条生产线上的不同阶段。

服务于他们，还是绕过他们服务

今天，OrcaRouter 目录中并不包含这两款模型的路由，且原因各不相同。TwIL-LM3-Pro 采用非商业许可，且没有托管端点；LFM2.5 2.6B Base 是一个微调产物，没有人会特意将其作为推理端点提供服务。路由器的价值体现在更高一层，即围绕专用模型的工作：生成并筛选用于微调 Base 的训练数据、扩展要输入形式逻辑模型的提示词，以及对输出进行评分。这些都是文本调用，它们通过一个与 OpenAI 兼容的端点运行，覆盖 200 多个模型，按提供商标价且加价 0%，因此提供商降价当天即可生效，从一个数据生成模型切换到另一个也只是修改配置，而无需再建立第二个供应商关系。

在微调流水线中，自动故障转移比平时更为重要，因为一个在 80% 处中断的批处理作业会浪费整个运行。一把密钥通行于各生成模型，再加上在提供商报错时重新发起请求的回退机制，这比三套 API 集成所涉及的基础设施要小。

哪一个，由你的意图决定

如果你在进行训练，就选 Base。如果你在对形式逻辑进行推理，且许可证允许你的使用，就选 TwIL-LM3-Pro。如果你今天就需要一个遵循指令的小模型，而这两种限制都不适合你的情况，就用 LFM2.5 2.6B 的后训练版同门模型——Liquid 实际为此目的发布的那款模型——并把 Base 留给你本来就计划要做的微调。