ARTEMIS 与 LFM2.5-2.6B-Base：无法胜任任务的检查点，与需要它胜任的评测框架

Google 的 ARTEMIS 路线图上有四个项目，其中恰好有一个需要一种目前显然尚不存在的模型：用于低延迟、隐私优先自动化的端侧轻量级视觉语言模型。对于这样的任务，显而易见的候选者是 LFM2.5-2.6B-Base 这种规模级别的东西——Liquid AI 的 26.9 亿参数预训练检查点，以开放权重发布，拥有 131,072 token 的上下文，且占用空间小到足以放进手机。而它按发布状态也无法填补这个位置，在任何人把两者放进对比表之前，这些原因值得理解。Google 的 ARTEMIS 是一个自然语言 Android 自动化框架，于 2026 年 8 月以 Apache 2.0 开源，通过 ADB 驱动真实手机，并声称在 Google Research 的 AndroidWorld 基准上达到 99%+ 的完成率。LFM2.5-2.6B-Base 是原始预训练材料，没有指令微调，没有聊天模板，而且——有意为之——没有已发布的基准测试，面向的是将自行进行后训练的团队。一个是成品软件，却带着未解决的模型问题。另一个是未完成的权重，却带着已解决的许可证问题。两者都不能替代对方，而它们真正交汇的地方并不是你会猜到的那个地方。

LFM2.5-2.6B-Base究竟是什么

剥去品牌包装，它就是为端侧工作精心打造的基础，其规格参数读起来像是有人针对内存带宽而非排行榜名次进行了优化。

• 规模 — 单个约 5.39 GB 的分片中包含 2.69B 个 bfloat16 参数，却宣传为“2.6B”。

• 架构 — 混合拆分共 30 层：22 个双门控短卷积块叠加在 8 个分组查询注意力层之上，隐藏宽度 2048，32 个注意力头对应 8 个 KV 头，嵌入权重共享。与上一代使用相同的 code>Lfm2ForCausalLM/code> 类，因此无需自定义建模代码。

• 训练 — 约 34 万亿 token，并设有专门的上下文扩展中期训练阶段。

• 词汇表 — 128,000 个 token，这一代翻倍，以更好地处理非拉丁文字。约 262M 参数，约占模型的十分之一，位于绑定嵌入中。

• 上下文 — 模型卡与配置在此处不一致，这点值得注意：文档宣称支持 131,072 个 token，而 code>config.json/code> 将 code>max_position_embeddings/code> 设为 128,000。请按 128K 来做规划，并将任何超出该值的部分视为未经核实。

• 语言——十六种：英语、阿拉伯语、中文、法语、德语、印地语、印度尼西亚语、意大利语、日语、韩语、波兰语、葡萄牙语、俄语、西班牙语、泰语、越南语。

• 基准测试——无。Liquid 未发布基础检查点的任何评估结果，而模型卡将这一省略表述为有意为之：该产物的存在意义在于接受后训练，而非在其原始状态下被衡量。

最后那句话正是本次发布的核心所在，也正是“X vs LFM2.5-2.6B-Base”这一比较必须谨慎对待的原因。基础检查点对任何事情都没有自己的看法。让它规划一个 Android 工作流，它会以概率方式续写你的文本，因为它从未被教过如何回答。模型卡仅建议将其用于需要大量微调的场景：特定语言的助手、受监管垂直领域中的特定领域助手、在专有数据上训练，或作为蒸馏学生模型。对于任何开箱即用的用途，包括工具调用，Liquid 会转而推荐经过后训练的 LFM2.5-2.6B。

ARTEMIS 需要模型提供什么，而这并不是基础检查点所能提供的

ARTEMIS 是一个具有两种模式的控制循环。Flash 是一个反应式的观察-行动循环，每一步大约 3–5 秒。Pro 是一个多智能体图，每一步大约 15–40 秒；其中 Planner 持有一份动态 Markdown 计划，Operator 拥有完整工具集，还有一个只读 Checker 在四个层级上验证检查点，从 code>off/code> 到 code>strict/code>。两种模式都要求底层模型做同一件事：查看截图，从固定工具集中选择一个动作，然后在一两秒内再做一遍，重复上百次，同时不丢失线索。

这是一个要求很高的任务——在严格的模式约束下遵循指令、有依据的视觉理解，以及长时程连贯性——而这恰恰是基础检查点从未被赋予的那组技能。ARTEMIS 自己测试过的后端都是托管模型：Gemini、Claude、GPT-4o、Qwen-VL。它们每一个都针对工具使用做过指令微调，而且每一个规模都很大。

所以差距不在于规模。一个 2.6B 的后训练模型就能撑起一个工具调用循环——Liquid 自家的后训练同门模型声称，在其全部指令遵循评测以及几乎所有工具使用评测中都优于 Gemma 4 E2B-it 和 E4B-it，不过这些是厂商自报的数字，没有经过独立验证。差距在于，基础检查点完全没有经过那类训练，因此根本无法直接接入任何运行框架。

许可证才是更显著的区别

这才是真正决定对决胜负的地方，也是大多数对比所忽略的部分。

• ARTEMIS — Apache 2.0。可将其用于商业用途、分叉，或随产品一起发布，没有收入条件。唯一的义务是保留声明并说明你的更改；而该项目本身在 2026 年 9 月不得不公开补救这一义务，此前 Minitap 指控 ARTEMIS 的 229 个文件中有 228 个与其自己的 Apache-2.0 code>mobile-use/code> 项目匹配，并且作者姓名已通过强制推送被抹去。该仓库现在带有 Minitap 的署名行。

• LFM2.5-2.6B-Base——LFM Open License，一种自定义许可证，而非 Apache 或 MIT。年收入低于 1000 万美元时，授权范围广泛、永久且免版税。达到或超过该门槛时，该许可证完全不涵盖商业使用，并且你必须联系 Liquid。对于任何基于它构建的人来说，关键细节是：衍生作品继承相同条款。你进行后训练得到的检查点并不是你完全拥有的新东西——它会延续这项以收入为条件的许可证，并为符合条件的非营利组织设有例外。

把这两件事放在一起看，决策就会因人而异地翻转。一家已获融资的公司想要交付一个手机端代理，它有一套可以自由使用的 Apache-2.0 框架，还有一个可能完全无法用于商业用途的检查点。个人开发者或未达到该门槛的初创公司则两者兼得，许可证不过是脚注。两家厂商都算不上不讲道理——Liquid 是在保护自己的商业层级，Google 是在将测试工具开源——但“开放权重”和“开放权重”并不是同一种许可，而一场止步于参数量对比的比较，不会告诉你手里拿到的究竟是哪一种。

这个家族，因为基础检查点是进入它的错误入口

如果目标是端侧 Android 智能体，那么有三款同门型号比基础款更重要，而 ARTEMIS 路线图真正需要的那个，并不是最显而易见的那个。

• LFM2.5-2.6B——经过后训练的智能体同门模型。厂商报告的吞吐量在手机级硬件上约为每秒 30 个 token，在 Ryzen AI Max+ 395 上为 113，在 Apple M5 Max 上为 220，运行时占用不到 2.5 GB。

• LFM2.5-VL-3B——视觉语言端侧模型，构建在同一基础模型之上，配备 SigLIP2 400M NaFlex 编码器；厂商报告称，其在 RefCOCO 上的 grounding precision@1 从 57.1 提升至 87.9，并且据 Liquid 称，其在屏幕 UI 元素上的表现超越了大得多的 Gemma 模型，与 4.7B Qwen 3.5 的差距在 0.7% 以内。尚未验证，但它是该系列中唯一能看见屏幕的成员。

• LFM2.5-230M —— 抽取与分类层级，明确不建议用于推理密集型任务。

在这场对比中，对于基础检查点而言，令人不安的结论是：ARTEMIS 的路线图项目是一项 视觉需求，基础模型是纯文本的，而填补这一空缺的家族成员是已经同时应用了视觉编码器和后训练的 VL 变体。基础检查点在 Android 自动化栈中的角色并不是驱动手机，而是充当最终真正驱动手机的那个小模型底下的原材料。

它们真正交汇之处：那个尚无人建成的飞轮

这里有一个真实存在而非修辞上的关联，而且它与通常的方向相反。ARTEMIS 最被低估的功能不是智能体——而是它的“尾气”。每次运行都会捕获崩溃堆栈、关键帧截图、一份压缩步骤的会话台账以及一份诊断报告，而每当某个动作失败时，Pro 都会开启一个“执行事件”，并将其保留在上下文中，直到后续某次成功将其解决。那是一个带标注的语料库，记录的正是 UI 智能体感知出错的那些时刻。

把一个用途完全在于后训练的检查点与之搭配，就会得到一个显而易见的闭环：在托管模型上运行测试框架，收集它在你的应用上受挫的轨迹，然后专门针对这些帧微调一个 2.6B 模型。这正是 Liquid 自己的模型卡所援引的那类专有数据集，用以说明发布基础检查点本身的正当性——“在你自己的数据上训练”——而按收入设限的许可证意味着，对于低于该门槛的团队来说，这是一条合理的路径，对于高于该门槛的团队，则需要进行一次洽谈。

要明确说明那个想法的性质：没有人发表过这个循环，两家供应商都没有提出它，也没有证据表明任何一方测试过它。它是一项提议，而不是一项结果，也应当被当作提议来解读。但只有在这样一种框架下，这两件人工产物才是协作者，而不是一个范畴错误。

如果你已经走到微调这一步，那么对照集就是问题的另一半。LFM2.5-2.6B-Base 不在我们的目录里——任何 LFM2.5 变体都不在——所以那个检查点来自 Liquid 自己的分发渠道以及常见的第三方托管方。路由目录真正能体现价值的地方，在于把你微调后的模型与它在工具使用上必须击败的模型进行基准对比：用一个密钥、一份账单，并具备故障转移，这样某个提供商的一个糟糕下午就不会变成你评估的糟糕下午。当整个练习的重点是你打算据此采取行动的正面对决时，这确实是一件非常有用的东西。

那么，哪一个才是你的问题？

如果你有一个 Android 应用，并且想在本季度对它进行自动化测试，那么你需要的是 ARTEMIS，而 LFM2.5-2.6B-Base 并不是答案的一部分——你将针对托管的视觉模型运行 ARTEMIS，按步付费，而关于端侧 VLM 的路线图事项终将到来，并解决一个你尚未衡量的成本问题。

如果你正在打造一款必须在无网络的手持设备上运行的产品，那你要走的就是小模型路线，而 LFM2.5-2.6B-Base 是这个项目的起点，而不是其解决方案的任何一部分：你会对它进行后训练，你会在写下第一个训练脚本之前，对照你的收入预测来审读 LFM Open License，而如果你的智能体需要看到屏幕，你最终会转而使用 VL 变体。

最不该做的一件事，就是把这两者并排放在一起，宣称这个测试框架更强，然后就此翻篇。真正有用的比较，是在两个完整技术栈之间——托管模型加测试框架，对比微调小模型加你自己搭建的框架——而这两者中只有一个在公开基准上公布过成功率，这跟另一个压根没有云账单这件事，价值完全一样。

路由型目录真正体现价值之处，在于让您的微调模型与它必须超越的模型在工具使用上一较高下，只需一个密钥、一份账单，并具备故障转移能力，这样某家供应商的糟糕下午就不会变成您评测工作的糟糕下午。

LFM2.5-2.6B-Base 不在我们的目录中——没有任何 LFM2.5 变体在其中——所以该检查点来自 Liquid 自己的分发渠道以及常见的第三方托管方。