SubQ Snap 1.1 与 LFM2.5 2.6B Base：购买决策，还是从检查点构建？

在SubQ Snap 1.1与LFM2.5 2.6B Base的对比中，最重要的词是最后一个。Base 意味着预训练。它意味着 Liquid AI 发布该检查点时，已经过约 34 万亿个 token 的训练，但尚未进行任何监督微调、蒸馏或强化学习——正是这些过程让语言模型变成能遵循指令的模型。它不会回答问题。它不会选择标签。让它路由一张支持工单，它会按照训练文本的风格续写你的提示词；这不是缺陷——这正是基础检查点的用途。

SubQ Snap 1.1则相反，是一个成品：Subquadratic 的决策模型，于 2026 年 10 月 22 日发布，可接收最多 384K token 的文本和图像，外加一组固定答案，并返回一个经过校准的选择。把二者放在一起当作可相互替代的选项来对比，是一种范畴错误，而且这种错误很有用，因为这一错误恰恰正是团队在面对“要在自己掌控的硬件上运行分类”时所面临的决策。问题不是“哪个模型更好”，而是“你是直接购买这项决策，还是从一个起点开始自行构建它？”

Liquid AI 实际交付了什么

LFM2.5-2.6B Base 于 2026 年 8 月 4 日发布，与其经过后训练的兄弟型号 LFM2.5-2.6B 一同亮相，同属一个参数量从 2.3 亿一直延伸到 240 亿的混合专家模型家族。其架构采用 Liquid 的 LFM2 设计：共 30 层，其中 22 层为双门控短卷积块，8 层为分组查询注意力层，词表规模为 128,000 个 token，并在中期训练扩展阶段加入了 128K 上下文窗口。它以 26.9 亿参数可容纳于约 2.5 GB 之中，在 Apple M5 Max 上运行速度约为每秒 220 个 token，在 Ryzen AI Max+ 上约为 113 个，在手机上约为 30 个。

Instruct 兄弟版本才是那些有意思数字所在之处，值得一读，用来衡量后训练究竟有多大价值。Liquid 报告称，AIME25 为 51.87，LiveCodeBench v6 为 59.41，IFBench 为 59.17，Multi-IF 为 80.07，BFCLv4 为 56.88，ToolSandbox 为 77.83——这些全都是厂商报告的数据，而且全都来自后训练模型。基础检查点没有可比的指令遵循分数，因为它无法遵循指令。检查点与一个你能向它提问的模型之间的这一差距，来自四个后训练阶段：两轮监督微调、按领域进行教师专业化、多领域同策略蒸馏，以及在真实执行框架内进行的智能体强化学习。

Liquid 也直白说明了该模型不适用于哪些场景：智能体编程和知识密集型工作。这比大多数实验室发布的定位声明都更诚实，值得按字面采信。

规格对比

• 它是什么——LFM2.5 2.6B Base 是一个未经指令微调的预训练检查点；SubQ Snap 1.1 是一个托管式决策模型，提供固定答案 API。

• 上下文 — LFM2.5 2.6B Base 为 128K tokens；Snap 1.1 为 384K tokens。

• 输入 — LFM2.5 2.6B Base 仅支持文本；Snap 1.1 支持文本和图像。

• 输出——自由形式的 token 生成，或你在其上训练的任何 head，适用于 LFM2.5 2.6B Base；对于 Snap 1.1，则是带概率的选择或分数。

• 价格 — 仅限自托管，无按 token 计费，适用于 LFM2.5 2.6B Base；每 100 万输入 token 为 $0.04，输出免费，适用于 Snap 1.1。

• 许可 — LFM Open License v1.0，允许商业使用但设有收入门槛，适用于 Liquid 模型；Snap 则完全不提供权重。

• 占用空间——LFM2.5 2.6B Base 约为 2.5 GB，并可在手机上运行；Snap 1.1 则需通过网络调用。

检查点与分类器之间的差距

要让 LFM2.5 2.6B Base 具备 Snap 1.1 的功能，你需要五样东西，而其中只有一样是模型。

你需要带标签的数据——对于狭窄的路由任务，每个类别有几千个示例是合理的起点；如果类别不平衡或边界很微妙，则需要多得多。你需要一次训练运行：在从未见过指令的基础检查点之上，加一个分类头或 LoRA 适配器，这意味着微调同时完成任务适配和指令遵循工作。你需要校准，因为 softmax 分数不是经过校准的概率，而在未校准分数上设置的路由阈值就是靠猜测设定的阈值。你需要一个由你维护的评估工具链，因为随着流量变化，模型会漂移。你还需要服务基础设施——llama.cpp、MLX、vLLM 或 ONNX，它们都支持该架构。

这些都不算什么稀奇事。所有这些都需要由懂行的人投入数周工作，而且每当任务发生变化，这些工作就会再次出现。实事求是的比较，不是拿每百万 token 0.04 美元去和免费相比，而是拿每百万 token 0.04 美元去和四到八周的工程投入，再加上自持模型的持续成本相比。

该许可证不是 Apache

Liquid 依据 LFM Open License v1.0 发布 LFM2.5。允许商业使用，但年收入超过 1000 万美元的组织需要单独的商业许可证。这与 Granite 的 Apache 2.0 或 Gemma 的 Apache 2.0 有着本质区别，而且这类条款往往是在原型跑通之后，才被法务部门很晚发现。如果你是一家低于该门槛的初创公司，它今天不会让你付出任何成本，但日后可能会让你付出代价。如果你高于该门槛，请在核算 GPU 成本之前，先核算许可证成本。

在基础检查点完全胜出的情况下

气隙部署是最有说服力的场景，而且这一点毫无争议。一个 2.5 GB 的模型，能在手机、笔记本电脑或没有网络路径的容器中运行，对于现场应用、涉密环境或交付给客户的设备来说，是唯一的选择。Snap 1.1 无法进入其中任何一种场景。它是一个 API，而且没有任何版本可以在本地运行。

规模经济是第二种情况，但它们需要真正的规模才能发挥作用。按每月 200 万次决策、每次 20,000 个上下文 token 计算——即 400 亿输入 token——Snap 1.1 每月花费 1,600 美元，也就是略低于每年 20,000 美元。用一个微调过的 2.6B 模型在你已有的硬件上承载这些流量，则没有边际成本。收支平衡点大致在年度 API 账单超过微调工程成本加硬件成本之时；对大多数团队来说，这是一两年后的事，而不是一个月。

完全控制是第三种方式。用你自己的标签训练的模型只会做你训练它去做的事，不会做其他任何事。Snap 1.1 是一个通用决策模型，在 Artificial Analysis Decision Index v1.0 上的准确率为 20%——其 65 的指数得分主要来自对无法回答的内容弃答，据报道其非幻觉率为 86%。针对你的领域微调的 2.6B 模型在你的任务上往往会超过这一准确率，而且除非你训练它弃答，否则它绝不会弃答。

Snap 1.1 完胜之处

首次决策所需的时间以分钟计，而不是以冲刺为单位。无需收集训练数据，无需拟合预测头，也无需绘制校准曲线。你发送一份文档和一个选项列表，就会收到返回的概率，而这个概率就是产品。

第二个差异是长上下文，而且这是架构层面的差异，而非偶然差异。Snap 在单次前向传播中处理 384K 个 token，且每个 token 的计算量恒定。LFM2.5 2.6B Base 拥有 128K 窗口，而作为一款 26 亿参数的模型，其有效检索范围将比标称范围短得多——Liquid 自家的同系列模型报告的 AA-Omniscience 得分为 −29.50，该指标衡量的是小模型知道多少，而不是它阅读得有多好，但它会设定预期。

第三点是，Snap 的输出本身就已经是你需要的东西。无需解析器，无需 schema，也无需针对格式错误回答的重试逻辑。

那么，哪一个呢？

如果决策是对长文档进行路由或分类判断，如果数据可以离开你的网络，并且你想在本季度就获得这项能力，那就购买 Snap 1.1。自建路线确实存在，但对大多数团队来说，第一年并不会更便宜，而且基础检查点（base checkpoint）是这条路径上最难的起点——你通常会从经过后训练的 LFM2.5-2.6B 开始，并在其基础上进行微调，而不是从 Base 开始。

如果你需要让模型部署在网络无法触及的地方，或者打算永久拥有这些权重，并且具备足够的工程能力让这件事物有所值，那就选择 Base 检查点。在这种情况下，除了训练运行的成本，还要把许可问题一并纳入预算。

两者都不在 OrcaRouter 的目录中，也永远不会在：LFM2.5 2.6B Base 是本地检查点，Snap 1.1 仅通过 Subquadratic 的 API 在 console.subq.ai 提供。在围绕任一模型构建的流水线中，OrcaRouter 承担的是将决策转化为行动的那一层——一个密钥背后有 200+ 个生成模型，提供商标价以 0% 加价原样传递，以及自动故障转移，这样当路由调用落到一个暂时不可用的模型上时，就不会变成被丢弃的请求。决策层和写作层有不同的故障模式；最好不要将它们放在同一个依赖上。

值得关注的并不是任一模型在基准测试中的那一行成绩，而是：一个基于数千个领域样本微调而来的 26 亿参数检查点，能否在团队实际拥有的那一项任务上，匹敌一个专用决策模型。在范围狭窄、标注良好的分类任务上，答案历来是肯定的；也正因如此，这里的“购买还是自建”问题才真正悬而未决，而不是一句修辞。