Clef 对比 LFM2.5 2.6B Base：在 H200 上占用 55 GB，在笔记本电脑上仅需 5.4 GB

下面这场对比中，硬件在模型之前就决定了胜负。Cloudflare/clef是一个拥有 270 亿参数的多模态决策模型，基于 Qwen3.8-27B 后训练而成；其仓库由十二个主干分片外加一个小型联合 schema 头组成，大小略超 55 GB。LiquidAI/LFM2.5-2.6B-Base是一个拥有 26.9 亿参数的纯文本检查点，其权重为单个 5.4 GB 文件，由 Liquid AI 于 2026 年 8 月 1 日在 LFM 开放许可证下发布。Cloudflare 自己公布的 Clef 延迟——中位数 209.3 毫秒，p95 为 238.6 毫秒——是在单块 H200 上测得的。Liquid AI 为其 LFM2.5 系列设想的部署环境是笔记本电脑、手机或 Ryzen 掌机。两家厂商都将其模型描述为小巧、快速且高效，而两者说的都是实话，只不过针对的是不同的机器。

在第一个缺口之后还有第二个缺口，而正是这个缺口真正改变了计划。Clef和LFM2.5 2.6B Base都不会以你可能预期的方式开箱即用地回答一个问题。Clef 是为一项它无法偏离的任务而完全训练好的：它回答输入的问题，除此之外什么也不做。Liquid 检查点则完全没有针对任何任务进行训练——它是一个基础模型，刻意没有经过指令微调，而 Liquid AI 自己的模型卡也说明，它只推荐用于大规模微调。所以，真正的问题不是哪一个运行起来更便宜，而是你买到的究竟是一个成品组件，还是一种起始材料——而这两者的答案各不相同。

各自在哪里运行，以及为什么这就是比较的全部

对这两个模型来说，部署形态绝不是旁枝末节。对决策模型而言，它就是架构本身，因为 209 ms 的前向传播和“就在你面前的机器上运行”这一说法，是从不同端点讲述的同一个主张。

• 参数 — Clef 为 27B，保留 Qwen3.8-27B 视觉编码器；LFM2.5 2.6B Base 的纯文本版本为 2.69B。

• Disk — 一个面向 Clef 的 55 GB 仓库；一个 5.4 GB 的 safetensors 文件用于 Liquid 检查点，并同时发布了量化后的 GGUF、ONNX 和 MLX 构建版本。

• 硬件——Cloudflare 在单块 H200 上用 torch 2.11 和 transformers 5.10.2 测试了 Clef，其延迟数据来自那次运行。Liquid AI 基于该检查点后训练出的同系列模型，在 Apple M5 Max 上以每秒 220 个 token 运行，在 AMD Ryzen CPU 上为 113 tok/s，内存占用不到 2.5 GB，厂商指出在手机上可实现 30 tok/s。

• 上下文 — 根据 Workers AI 模型页面和发布文章，Clef 为 65,536 个 token；LFM2.5 2.6B Base 为 131,072 个 token。

• 输入 — Clef 可读取文本、JSON、图像和视频帧，并对其进行联合评分。Liquid 检查点仅支持文本。

• 许可证——Apache-2.0 适用于 Clef。LFM2.5 采用 LFM Open License v1.0，该许可属于源码公开，而非 OSI 定义的开源：商业使用的前提是贵组织年收入低于 1000 万美元，而一旦越过这一门槛，该许可便不再授予商业使用权。这个门槛是采购层面的事实，而不是一句可有可无的脚注。

每次决策的成本与每个token的成本不是同一个问题

这里诱人的做法是把两个价格相除，然后宣布谁赢了。可一旦碰上这两个模型实际做的事，这种算法就站不住脚了。

Clef 在 Cloudflare 的 Workers AI 上每百万输入 token 收费 0.24 美元。它的输出不是自然语言文本，所以通常的输出 token 这一项并不存在；你为状态付费，只需一次，然后拿回一个分布。对于每天做出数百万个小决策的路由层来说，这个数字就是全部运营成本，而且这个数字只能从供应商那里得到，而不是从你自己的电费账单里得到。

LFM2.5 2.6B Base 每次调用零成本，却无法做出决策。要从中得出每次决策成本，你必须先针对自己的任务对它进行微调，这意味着要收集数据、运行训练任务、评估结果，然后才会发现它在 kVA 和工程时间上让你付出多少代价。一个 2.6B 检查点所具备的诱人经济性确实存在，但它们处在尚未发生的工作的下游，而那个比较每 token 价格的人，已经径直跳过了这一点。

诚实的说法是，这是两种不同的购买。Clef 是一个组件，有标价和托管费用。Liquid 检查点是一种原材料，其成本就是你无论如何都要支付的那次训练运行——而它的回报是，之后你完全拥有这个产物，到那时，一次决策的边际成本真的就只是电费。对于一个狭窄、高频、稳定的任务，这笔交易通常是正确的。对于一个你尚未明确规定的任务，它就反了，因为你无法朝着一个你无法描述的目标进行微调。

未经训练的基座模型并非更差的模型，而是一条不同的起跑线。

人们很容易把 Liquid 检查点缺失基准测试表解读为一种隐藏的弱点。事实并非如此。用指令遵循基准来给预训练基础模型打分，衡量的是它缺少微调，而不是基座本身的质量；正因如此，Liquid AI 才会对后训练过的 LFM2.5-2.6B 做基准测试，而让基础模型保持未评估状态。这片空白从你这边就可以验证，而这就是关键所在：下载 5.4 GB，在你自己的任务上运行你自己的评估，在决定部署任何东西之前先知道答案。

Clef 的表格是形态相反的证据，也有相反的问题。Cloudflare 公布了四十多行基准测试数据、一整套工作流评估集以及一个延迟分布，而其中每一项都是 Cloudflare 在自家的 Decision Index 上产出的，没有任何第三方复现过其中任何一项。Clef 那一列比 Liquid 那一列信息量大得多，可其中没有一个数字经过任何他人的核验。这比一片空白是更强的断言，却又比它看上去的要弱。

你能自行衡量的部分也同样一分为二。有了 Liquid 检查点，你可以衡量一切——它就在你自己的磁盘上，占 5.4 GB。对于 Clef，Apache-2.0 权重同样可供你下载和运行，但要匹配 Cloudflare 的 209 毫秒中位数，需要 Cloudflare 所用的那类 GPU，因此在实际中，大多数团队会通过托管端点来衡量它，并在继承其延迟的同时，也一并继承供应商的可用性。

对它们中的每一个而言，路由层所处的位置

Clef 和任何 LFM2.5 变体都不是 OrcaRouter 上的路由，本文也并非可用性声明——目录对两者均返回 404，因此 Clef 来自 Cloudflare 的 Workers AI 或你自己的 GPU，而 Liquid 检查点则来自其自身的分发渠道。

这里路由层真正要发挥的作用，正是这两个模型共同暗示的模式。一个负责决策的小型受限评分器，加上一个依据该决策行动的大型通用模型，从构造上便是一种双模型架构——而 Clef 自身的主干让这后半部分落到实处：Cloudflare 基于其进行后训练的模型 Qwen3.8 27B，是一条已上架的路由：每百万输入 token 为 $0.33，每百万输出 token 为 $2.40，上下文窗口为 262,144 token。一个端点置于 200 多个模型之前，意味着廉价的决策者与能力强大的执行者位于同一个密钥之后，通过路由 DSL 组合为单次调用，而不是手动把它们连接起来；同时具备自动故障转移，因此某个提供商状态不佳的下午不会连带把决策路径拖垮。如果你转而自行托管 Liquid 检查点，并将你的微调结果与它必须击败的模型进行比较，那么同一个端点就能让这项比较变成一次配置更改，而不是一轮采购流程。

TypeSafe 的 Jev 1.13 在自托管这一场景下尤其值得点名：它是 Cloudflare 拿来对标测试的决策模型，并刻意采用与 Clef 相同的 POST /v1/systemone 请求形态，它是一条已列出的路由，在 65,536 token 上下文内，每百万输入 token 定价 0.042 美元，而且这是在为一个可能本不需要存在的基底投入训练运行之前，以低投入方式弄清有界决策模型是否能帮到你的流水线。

哪个，为什么

当任务范围窄、吞吐量高、规范程度足以让你为其编写训练数据，并且受制于路由型 API 无法解决的两项硬性约束之一时，就选择 Liquid 检查点：数据不能离开你的基础设施，或者它必须运行的那台机器就是你桌上的这台。LFM 1.0 的收入门槛是首先要检查的事项，因为它决定了该许可证对你是否可用。

当决策本身已经可枚举、状态能放进 64K、答案需要的是经过校准的概率而非一句话，并且热路径中的 209 ms 正是你要买下的特性时，就选择 Clef。它固定的 schema 就是特性——一种可审计、可复现、无需解析器的输出形态——而 55 GB 的占用则是骨干模型的代价，这使它第一次就能准确，而不是在一次训练运行之后才准确。

你不该做的是按参数量来挑选。一个必须先训练才能作答的 2.69B 模型，并不是一个已经能作答的 27B 模型的缩小版，而标题里的两个数字——55 GB 和 5.4 GB——描述的是两种不同的预算，而不是同一标尺上的两个点。

这个悬而未决的问题，而且对双方来说都是同一个问题。

两家供应商都没有公布经得起独立检验的证据。Cloudflare 的 Decision Index 测试是自行开展的，且未经复现；Liquid AI 的吞吐量数据是厂商在自选硬件上自行测得的。LFM2.5 2.6B Base 按设计完全没有任何基准测试，而 Clef 表格则出于选择包含了大量基准测试。

对于 Liquid 检查点来说，缺失的证据修复起来成本很低，而且完全掌握在你手里——文件足够小，一个下午就能在笔记本电脑上评估完。对 Clef 来说则不然：复现 209 毫秒的中位数需要 Cloudflare 所用的硬件，以及 Cloudflare 之外无人组装过的状态。这种不对称——比两份规范中的任何内容都更重要——应当决定你这个月围绕这两者中的哪一个来做规划。