Perceptron Mk1.5 对比 Gemma 4 12B：一个用句子作答，另一个用坐标作答

先看这个应该首先让你停下来的数字：Perceptron Mk1.5 是一款为视频和具身智能体打造的模型，它的上下文窗口是 36,864 个 token。Gemma 4 12B 是一个 12B 的开放权重通用模型，窗口为 256K。在大多数人用来比较视觉模型的维度上——我能交给它多少视频素材——这个更小、闭源、专用打造的模型，以七倍的差距输给了那个可下载的模型。这种反转不是任一产品的缺陷。它告诉你两者实际上各是为什么而造的，而这两项任务之间的距离，比它们规格表上共有的“多模态输入”那一行所暗示的要远得多。

Perceptron Mk1.5 是 Perceptron 于 2026 年 9 月 25 日发布的具身推理模型，是 5 月推出的 Perceptron Mk1 的继任者，可接收文本、图像、视频和音频，并输出文本以及机器可解析的几何数据。Gemma 4 12B 是 Google DeepMind 的 11.96B 无编码器多模态开放权重模型，于 2026 年 6 月 3 日在 Apache 2.0 下发布，可接收文本、图像、音频和视频，并返回文本。两者都很便宜，都能读取摄像头画面，而只有其中一个能无需第二解析阶段，就把边界框交给你的控制器。它们之间的选择，取决于必须返回什么。

每一个被构建用来返回什么

把两者并排放在一起，差别并不在于准确率，而在于输出类型。问 Gemma 4 12B 叉车在哪里，你得到的是一句话，而在大多数应用里，这句话本身就是产品——一段描述、一份摘要、对某个关于照片的问题的回答。问 Perceptron Mk1.5，除了它的文字叙述之外，你还可以要求一个点、一个边界框、一个多边形、一个片段，或一个<track>元素，它承载着一次空间观测以及该观测所属的时间戳。一段 60 秒的片段返回的是随时间变化的一系列位置，而不是对场景的某一个平均猜测。

这就是 Mk1.5 存在的全部理由，而它为何重要，值得说清楚。对场景的描述是一件成品。而坐标是其他东西的输入——抓取规划器、缺陷检查、带时间戳的审计追踪。如果你的下游代码必须去读一段文字、再从里面推断位置，那你就是在两个模型之间造了一个解析器，而这个解析器如今就成了你的故障面。Mk1.5 的主张是：几何信息是以带类型的形式送达的。

Gemma 4 12B 的反驳论点并不是它也这样做。而是你可以拥有这些权重。Apache 2.0，11.96B 参数，以预训练和指令微调两种变体发布，运行在你控制的硬件上，并配有已发布的评估卡和背后的第三方指数。这些是不同类型的资产，二者不能相互替代。

在两者真正吻合之处

比"多模态 2026"这一标签所暗示的适用范围要少，但共同点确实存在，值得明确指出，因为这正是买家核对清单通常的起点。

• 输入模态——两者都是真正的四模态。Perceptron Mk1.5 接受文本、图像、视频和音频（WAV、MP3、FLAC）。Gemma 4 12B 通过一条无编码器的统一路径接受文本、图像、音频和视频。

• 输出模态——两者都不生成音频或图像。两者都是文本输出。区别在于 Mk1.5 的文本可以携带结构化的空间标注，而 Gemma 4 12B 的则不能。

• 函数调用——两者都支持。Mk1.5 在聊天补全中提供函数调用，并可通过 JSON Schema 和正则表达式接受受约束的响应。Gemma 4 12B 在其指令微调版本中内置函数调用，并提供可配置的思考模式。

• 推理控制 — Mk1.5 取代了旧的 vision_config.enable_thinking布尔值，改用 reasoning_effort字段，可取值 high、medium、low、minimal 或 none，默认为 high。Gemma 4 12B 提供思考型与非推理型两种变体，它们在同一个测试框架上得分不同，因为二者完成的工作量不同。

• 上下文 — Mk1.5 为 36,864 个 token，而 Gemma 4 12B 为 256K。这是列表中最大的差距，下一节将对此进行讨论。

• 权重与许可 —— Mk1.5 是附带 SDK 的闭源托管模型，而非可供下载的模型。Gemma 4 12B 采用 Apache 2.0 许可，因此托管价格只是若干选择之一，而不是运行它的唯一途径。

36K 窗口是一项设计决策，而非缺陷。

一个拥有 36,864 token 窗口的具身模型听起来像是个错误，直到你看到 Perceptron 同时构建了什么。Mk1.5 接受一个asset_idx字段，因此一个请求可以引用多张图像或视频，并分别对它们进行处理。它将音频限制为每个条目 16,384 个 token——Perceptron 的文档称，按每分钟约 750 个 token 计算，这大约相当于 21.8 分钟的语音。而窗口之所以能保持较小，是因为任务很窄：在帧中查找并跟踪特定对象，就它们回答问题，然后停止。

这与 Gemma 4 12B 的工作形态不同。256K 窗口是为了容纳一份文档、一个代码仓库或一段长对话，并对其整体进行推理。Mk1.5 的窗口则是为一项带结构化答案的感知任务所设的预算，Perceptron 是按这项任务、而非按排行榜来划定其规模的。两者差异真正显现的时刻，是当你的任务变成"看完这段 40 分钟的检查视频，然后把一切都告诉我"——36K 的窗口无法同时容纳转录文本、画面帧和答案，而 Gemma 4 12B 的窗口加上其长上下文召回得分，才是应对这一任务的诚实工具。

这种取舍的另一半是速度。Perceptron 报告称，在单块 H100 上，根据三次运行的中位数，端到端最高快 4.7 倍，但需说明的是，4.7 倍是三次测量中的最好结果，并非典型情况：聊天回答从 5.2 秒降至 1.1 秒，图像问答从 1.7 秒降至 0.51 秒（约 3.3 倍），而一段 60 秒视频在八路并发下从 19 秒降至 9.1 秒（约 2.1 倍）。在具身智能体实际运行的视频工作负载上，实打实的倍数大约是 2 倍。

这些东西中有一个已经被别人测量过了。

这是整场对决中最悬殊的差距，而且差距很大。

Gemma 4 12B 有一张厂商评测卡和一项第三方指数。该评测卡载有厂商报告的数据——MMLU Pro 77.2、GPQA Diamond 78.8、MMMU Pro 69.1、LiveCodeBench v6 72.0、AIME 2026 无工具 77.5、Tau2 三次运行平均 69.0——以及 MRCR v2 8-needle 在 128k 处一个诚实的弱项：43.4，这是在假设 256K 窗口在远端表现相当前需要先看的那一行。在此之上还有一项独立测量：Artificial Analysis 将 Gemma 4 12B 的 Intelligence Index 定为 14，在其类别 142 个模型中排名第 22，输出速度为每秒 113.7 个 token——速度在 142 个中排第 20——标价为每百万 token 输入 $0.10、输出 $0.30。

Perceptron Mk1.5 则完全没有这类东西。既没有 Artificial Analysis 指数条目，也没有 Mk1.5 或 Mk1 的竞技场评分，因此这个模型现有的每一项能力数据，都是由销售它的公司自己产出的。这组数据具体而不含糊，值得一读：0.9433（自我中心hand_box），而 Gemini 3.1 Pro 为 0.4467，Perceptron 自家测试中最好的 Gemini 为 0.6179；EgoSchema 为 80.40，同一竞争对手为 81.20，在广义理解基准上落后 0.80 分，同时声称在 EgoSchema-hard 子集上以 63.75 的得分领先 12%；Molmo2-Track 上 centre-F1 为 0.647，point-HOTA 为 0.628；音频方面 DailyOmni 为 74.67，AVHBench 为 80.56。这些数字呈现的规律——在细粒度几何上具有决定性优势，在通用视频理解上大致持平或略逊一筹——是连贯一致的，也与产品叙事相符。但厂商对自家模型的基准测试只是一种主张，而本文中的两个模型并非以同等的证据标准来描述。

那张表里有一行值得特别提醒。Perceptron 的追踪对比中列出了 Qwen3-VL-8B 的 0.180 centre-F1，并注明源自该模型的论文，而旁边却是其自家模型实测的数字，还把它与 Qwen3.5-27B 在 0.530 和 0.476 这两个来自不同检查点和评测设置的数字并列。在一列实测数字里混入一个论文数值，并不是同类可比的一行，而这正是那种会被引用却不注明出处的条目。同样的提醒反过来也适用于 LiveVQA-W 上启用工具时的 56.0 Mk1.5 成绩——该数字来自四样本多数投票，而与之对比的 Gemini 3.8 Flash 在搜索接地下的 53.2 则不是，而四样本多数投票本身是一种合理的技术，只是相对于单次贪心推理会美化分数。

计算实际工作负载的成本

价目表之间的差距比产品之间的差距更小。Perceptron Mk1.5 每百万输入 token 收费 0.15 美元，每百万输出 token 收费 1.50 美元，缓存输入为 0.0375 美元——恰好是标准输入费率的四分之一，且每个缓存 token 的价格比 Gemma 4 12B 的 0.10 美元标准输入更便宜。Gemma 4 12B 在对其进行测量的第三方测试框架上标价为 0.10 美元和 0.30 美元，而且它采用 Apache 2.0 许可，因此如果你有硬件，自托管可以完全消除边际成本。

有两件事会让直接比较变复杂，而且它们指向相反的方向。第一，Mk1.5 的 reasoning_effort默认是 high，这意味着你每一次未做配置的调用，都在购买该模型所能提供的最昂贵的推理路径；降到 medium 或 low 只需改一行代码，却能直接反映在账单上，这是本次发布中最省钱的实验。第二，Gemma 4 12B 让你可以完全关闭思考步骤，这会同时改变账单和延迟，而在像帧级分类这样固定的任务上，不做推理的那一次运行往往才是正确的选择。

用真实场景来算一算：一条视觉流水线每天处理 40,000 帧，每帧大约一千个图像输入 token。也就是每天 4000 万个输入 token。按 Mk1.5 每百万输入 token 0.15 美元的费率，在相同场景反复出现时可缓存帧的情况下，输入成本每天也就是个位数美元的低端——按任何标准都算便宜。Gemma 4 12B 每百万输入 token 0.10 美元，还要更便宜；如果自托管，边际成本甚至为零。这两个模型都不贵。这里要做的决定不是预算决定，而是你是否需要坐标、256K 窗口，还是两者都需要的问题。

无需第二次集成即可调用这两者

进行这项比较的实际障碍不在于价格——而在于 Perceptron Mk1.5 和 Gemma 4 12B 并不在同一个目录中。如今 OrcaRouter 上也没有为这两者中的任何一个配置路由：我们提供的 Gemma 4 条目是 31B Instruct 和 26B-A4B 变体，而 Mk1.5 则完全没有路由，所以最诚实的建议是通过厂商自己的 API 访问 Mk1.5，地址为 api.perceptron.inc —— pip install "perceptron>=0.4.0"，密钥放在 PERCEPTRON_API_KEY —— 而 Gemma 4 12B 则可以通过第三方托管方，或者自行部署 Apache-2.0 权重来使用。

在这种情况下，路由层真正的作用，是那个你尚未做出的决定。如果 Mk1.5 的结构化输出正是你的应用所需要的，而 Gemma 4 12B 的上下文窗口正是你另一项工作负载所需要的，那么这就是两套集成、两个故障域；把它们放在一个与 OpenAI 兼容的端点之后并启用自动故障转移，意味着任意一侧的供应商抖动都只会退化为一次回退，而不是一个失败的任务；路由规则还可以把几何计算的工作和长上下文的工作分派给不同的模型，而你的应用完全不必知道哪个是哪个。当供应商调整价目表时，直通式路由器按提供商的标价计费，每 token 不额外加价，因此这一变化当天就会生效，而不是等到你的下一个计费周期。路由 DSL 也是你安排对比测试的方式——把一部分真实流量分给各个模型，在你自己的帧上衡量，而不是靠一场基准测试的争论。

你到底想要哪一个？

如果答案必须机器可读，就选 Perceptron Mk1.5。如果你要驱动某个东西，或者记录以位置和时间为关键的信息，那么再多的额外上下文窗口也替代不了一个明确键入的坐标，而 Mk1.5 是这一配对中唯一能产生坐标的模型。对以下三件事要保持清醒：36,864 token 的预算、推理默认值为高，以及附着于它的每一项能力数值都出自供应商自己这一事实。

解决这个问题最便宜的方法，是把一部分真实流量分别路由到双方，并用自己的帧来测量；两者都位于同一个 OpenAI 兼容端点之后，该端点在 OrcaRouter 上，而这正是让并排测试只需一行配置、而不需要第二次集成的原因。

如果你需要容纳大量材料、需要权重，或者需要向不轻信厂商基准测试的人证明这个选择，那就选 Gemma 4 12B。它有独立指数、已发布的评估卡、Apache 2.0 许可，以及大七倍的窗口——而且它会描述一个场景，而不是测量它。最后这一句就是整个决定的关键。这些模型中，一个是你可以拥有并审计的通用模型；另一个是你租用的专用模型，因为它返回几何数据，而专用模型窗口更小、没有第三方评分，这并不矛盾。从外部看，这就是一个专精构建的工具的样子。