ARTEMIS 对比 Gemma 4 12B：马具和大脑不是同一种采购

谷歌的 ARTEMIS 和 Gemma 4 12B 并不相互竞争，而想浪费一周时间，最快的方法就是把它们放进同一张对比表里，然后选出一个赢家。ARTEMIS 是谷歌于 2026 年 8 月以 Apache 2.0 协议开源的 Android 自动化执行框架：它接收一句话，通过 ADB 驱动一台真机，并报告发生了什么。Gemma 4 12B 是 Google DeepMind 于 2026 年 6 月 3 日发布的稠密 120 亿参数开放权重多模态模型——一个你能在笔记本电脑上运行的大脑，而不是一个能点击屏幕的系统。两者之中，一个若没有另一类东西加持，就无法看见、决策或行动；另一个则根本无法持有一台设备。但这一比较仍值得做，因为它背后的问题是当下每个移动团队都在问的：一个你完全自有的小型开放模型，能否完成 Android 自动化？还是说你需要在像 ARTEMIS 这样的框架背后接一个托管的前沿模型？这个问题有真正的答案，而且它不是任何一家厂商发布公告所暗示的那个答案。

首先，直白地陈述这个范畴错误。

ARTEMIS 本身不包含任何模型。它自己的徽章上写着“多模型 — Gemini | Claude | GPT-4o | Qwen-VL”，而决定你使用哪一个的文件是code>config/artemis.jsonc/code>。它是一个控制回路：一个无障碍优先的定位器，一个在你点击落下之前清除弹窗的安全检查，一个把旧截图压缩成视觉摘要的会话账本，以及两种执行配置——Flash 每步约 3–5 秒，Pro 每步约 15–40 秒，配备一个 Planner、一个 Operator 和一个只读 Checker。它对世界的全部认知，都来自一个并非由它编写的视觉语言模型。

Gemma 4 12B 是形态完全相反的对象。它是一个检查点。它没有设备连接，没有 ADB，没有无障碍服务，也没有“点击”是一种可以执行的操作这种概念。给它一张截图，问它下一步该做什么，它会回答你——也许回答得还不错——但回答就是它能动性的全部范围。从“模型说在 (540, 1180) 处点击”到“手机在 (540, 1180) 处点击了”之间的一切，都是 ARTEMIS 的职责，而这占了大部分工作。

所以，对这场对比最诚实的表述框架并不是 ARTEMIS 对阵 Gemma，而是：一个 12B 的开源模型作为 Android 智能体的推理层，究竟能为你带来什么，以及在什么时候你需要为更大的模型付费？

Gemma 4 12B 究竟带来了什么

对于一款中型模型来说，它的规格出奇地完善，而其中有三项特性对任何移动端场景都至关重要。

• 它在输入层是真正的多模态。 文本、图像、音频和视频均可输入，输出则是文本。它是首个不配备独立多模态编码器的中型 Gemma，也是该系列中首个原生接收音频输入的模型——这并非 UI 自动化功能，但如果你的测试场景涉及语音留言、会说话的通知，或基于音频提示构建的无障碍路径，那它就是一项实打实的能力。

• 这是一个你可以拿在手上的 12B 模型。Artificial Analysis 将其列为采用 Apache 2.0 许可的 12B 总参数模型——没有收入门槛，没有研究条款，是一个你可以直接用来构建产品而无需征求任何人许可的许可证——具有 256K 上下文窗口，启用了推理功能，实测输出速度为每秒 109.2 个 token。社区报告称，其权重在 SFP8 下约为 13.4 GB，在 Q4_0 下约为 6.7 GB，也就是一台拥有 16 GB 内存的笔记本电脑。

• 它很便宜，但并不是同类中最便宜的。Artificial Analysis 将其列为每百万输入 token 0.10 美元、每百万输出 token 0.30 美元——并在同一面板中指出，对于规模相近的开源权重模型而言，这属于偏贵的一档，其中位数是输入 0.05 美元、输出 0.15 美元。缓存读取费用约为 0.03 美元。

基准测试的图景是常见的中型模型的一团乱麻，值得仔细说明，因为追踪网站上的数字彼此并不一致。Artificial Analysis 给推理配置的 Intelligence Index 评分为 14，在其同类 142 个开放权重模型中排名第 21 位——这是一个体面的中游位置，距离前沿还有很长一段路。谷歌自身的定位是，12B 在推理、科学和文档任务上几乎与更大的 Gemma 4 26B-A4B 相当，并胜过上一代的 Gemma 3 27B。第三方聚合器给出的结果是 LiveCodeBench v6 上大约 72%，MMLU-Pro 上 77.2%，而 GPQA Diamond 则在 66% 到 79% 之间，具体取决于你看的是哪个追踪网站以及哪种配置。对 12B 来说，这些数字算得上体面。它们也是未经审计、自行报告的汇总数据；当四个网站相差十三个点时，你应当采信区间，而不是某个具体点位。

ARTEMIS 带来了什么，用一段话来概括，因为它并非此处的主题。

ARTEMIS 带来了模型所不具备的一切：一个动态优先的定位器，在无障碍元素索引存在时使用它们，不存在时则回退到视觉与坐标，这意味着无需维护 XPath，也不会有 ID 在 Compose 或 Flutter 界面上失效。它带来了一张安全网，能够拦截你的点击即将落在其上的系统弹窗；带有四个级别的检查点验证，从code>off/code> to code>strict/code>；自动崩溃堆栈、关键帧截图与诊断报告、一个 Web 控制台、用于 pytest 和 CI 的 Python SDK，以及——这也是它传播得如此之快的原因——一个原生 MCP 服务器，把整套能力以五个工具的形式暴露给 Antigravity、Claude Code、Codex 以及任何其他支持 MCP 的助手。据称，它在 Google Research 的 AndroidWorld 基准测试上取得了 99% 以上的完成率，截至 2026 年 9 月 11 日，在公开排行榜上达到 99.1%，而人类表现为 80%。该数字为自行上报，且排行榜并不核实提交内容，因此请把它视为一份强有力的厂商声明，而非审计结果。

两者真正重叠的唯一之处

存在一种真实的架构：由一个小型 Gemma 包揽全部工作，值得一看，因为它揭示了云端模型实际上在为哪些东西付费。一个名为 Orion 的开源 Android 智能体框架完全在设备端运行：MediaProjection 捕获屏幕，一个量化后的 Gemma-4-E4B-it通过 LiteRT-LM 在高通 Hexagon NPU 上运行并选择下一个动作，而 Android 无障碍服务负责派发点击。没有云 API，没有按 token 计费的账单，屏幕也永远不会离开手机。它已在 Galaxy S25 Ultra 上得到验证，并且据其自身描述，只有在配备 Hexagon NPU 的硬件上才有意义——该模型需要约 3 GB 存储空间，而该框架面向 arm64 上的 QNN HTP v79。

这就是当今小型模型 Android 代理的形态，而且要注意走到这一步的代价。模型经过量化并映射到 NPU。动作空间是像素，因为一个仅依赖截图的模型无法理解“元素索引 12”。整个设计是一套垂直堆栈——模型、运行时、芯片、框架——这正是它为什么是一个框架，而不是能直接塞进你测试套件里的即插即用方案。Gemma 4 12B 的参数量大约是那套堆栈中 E4B 的三倍，而且并未以可在手机上运行的格式发布；一个 12B 模型即便采用四位量化，也只能跑在工作站或服务端端点上，而不是常驻 NPU。

各自实际上胜出之处

• 规模化成本——自托管的 Gemma 4 12B 完全没有按 token 计费的单价，而 ARTEMIS 每运行一步都要调用一次视觉模型。在每晚运行的 500 项测试回归套件上，这种差异的累积速度比任何基准测试的差距都要快。

• 隐私 — 在自己的硬件上运行 Gemma 4 12B 绝不会将截图发送到任何地方；ARTEMIS 的无障碍辅助功能明确在设备端运行，不发送任何内容，但它针对每张截图发起的模型调用会发送到你配置的任意服务商。

• 真实应用中的任务可靠性——ARTEMIS 以明显优势胜出，因为它是一个自带安全网、检查点验证与恢复机制的测试框架。更优秀的模型无法替代这一点。

• 音频与长篇文档 — Gemma 4 12B，技术规格表中标明支持原生音频输入，并拥有 256K token 的上下文窗口。ARTEMIS 对这两点均不置可否。

• 首次通过测试所需时间 — ARTEMIS，优势极为悬殊。克隆，code>./start.sh/code>，连接一台已启用 USB 调试的设备，等待第一个任务安装无障碍辅助程序。用裸检查点构建等效方案是一个耗时数月的项目，而上面的 Orion 示例就是该项目完成后的样子。

• 自由修改推理层 — Gemma 4 12B，其 Apache 2.0 权重让你可以基于自己的 UI 词汇进行微调。ARTEMIS 是 Apache 2.0 代码，但推理能力取决于你的模型所在之处。

这种配对目前实际可用的版本

请明确说明你本周能部署什么。ARTEMIS 经过测试的后端列表是 Gemini、Claude、GPT-4o 和 Qwen-VL——Gemma 4 12B 不在其中，也没有已发布的评估表明 Gemma 4 12B 能驱动 ARTEMIS 会话。配置文件接收的是模型端点，因此这种配对是说得通但未经证实；如果你尝试这样做，你是在做原创工作，而不是遵循文档。值得直说：ARTEMIS 的路线图中有一个“设备端轻量级 VLM”事项，而填补这一项的模型不会是 12B 模型。

Gemma 4 12B 也不在我们的目录中——我们路由的是其他 Gemma 4 规格，即 Gemma 4 26B-A4B 和 Gemma 4 31B，而不是 12B，所以如果那正是你想要的检查点，你只能从供应商自己的分发渠道以及常见的第三方托管方那里获取。路由式目录要解决的是这个问题的另一半：如果你的方案是在托管视觉模型上运行 ARTEMIS，那么该模型就是一项会随每次运行的每一步而增长的成本项，而真正有用的杠杆不是标价，而是缓存价格。一次 Pro 运行会在每一步重新读取不断增长的上下文，因此，缓存读取便宜的模型对这笔账的改变，远大于全新输入便宜的模型。这也是为什么提供商故障转移应放在配置里，而不是你的事故日志里——一次长时间的 Android 会话会把上下文保持在一个端点上，而提供商在第 74 步出个小故障，就会让你这次运行功亏一篑。

哪一个是你下一步的行动

如果你有一个移动应用和一套回归测试套件，你要的是 ARTEMIS，而 Gemma 4 12B 不能替代它的任何部分——它充其量只是你以后可能在无文档记录、占用自己时间的情况下换上的引擎。如果你正在构建一个必须在无网络、无每次调用成本的手持设备上运行的产品，你要的是一个小模型，而 Gemma 4 12B 对你实际拥有的设备形态来说很可能太大；在假设 12B 能装得下之前，先看看 Orion 在 NPU 上用 4B 级 Gemma 做了什么。

这两个决策只在一个地方发生碰撞，而且这是成本问题，不是能力问题：你每天愿意为此购买多少次视觉调用？诚实地回答这个问题——数一数你的测试次数，数一数你的步骤数，数一数你的夜间运行次数——那么，在托管模型上搭建测试框架，还是采用自托管技术栈，这个选择会自己浮出水面。

的用途路由目录正是这个问题的另一半：如果你的方案是在托管视觉模型上运行 ARTEMIS，那么该模型就是一项会随每次运行的每一步而增长的成本项