Perceptron Mk1.5 vs LFM2.5-2.6B-Base：租用感知，还是拥有检查点并自行完成？

这两款模型的目标都是你可以单手拿起的硬件。Perceptron Mk1.5 是一款面向具身智能体的感知模型，其厂商称它可落地于无人机、四足机器人、智能眼镜和手机。LFM2.5-2.6B-Base 是 Liquid AI 专为端侧部署打造的 2.69B 开放权重检查点——小到可在不到 2.5GB 内存中运行。这种共同的物理野心是它们唯一的共同点，而对任何想在规格表上比较二者的人来说，这都是一个陷阱。Perceptron Mk1.5 是一个按 token 租用的成品：输入文本、图像、视频和音频，输出文本以及机器可读的几何信息，自 2026 年 9 月 25 日起上线。LFM2.5-2.6B-Base 则是一个未经指令微调、没有聊天模板、也没有基准测试声明的原始预训练基础模型——一个发布出来供他人完成的检查点。其中一个今天就能回答问题；另一个则是未来某个模型得以问世的原材料。

只有指明阶段，比较才有效。

把一个已经上线的 API 和一个基础检查点放在一起，并不是正面对比；硬要假装是，就会做出一张荒唐的表格：其中一方每一行都“赢”，因为供应商已经把它做完了，而另一方还没开工。真正有用的问题是：你现在处在工作的哪个阶段。

Liquid AI 以一组检查点的形式发布了 LFM2.5 系列，基座模型是其中的第一个。其模型卡列出 30 层共计 26.9 亿参数——22 个双门控短卷积块和 8 个分组查询注意力块——在约 34 万亿个 token 上训练，拥有 128,000 token 的词表、131,072 token 的上下文长度，并支持包括英语、中文、日语、韩语和阿拉伯语在内的 16 种语言。它仅支持文本，是一个因果语言模型，仅此而已，而 Liquid 自己的建议也直截了当：该检查点适用于需要大量微调的任务，例如特定语言或特定领域的助手、在专有数据上训练，或试验新颖的后训练方法。将其变成能够承载该系列已公布分数的工具调用智能体的，是 Liquid 的四阶段后训练流水线，而基座模型并不包含这一流水线。

Perceptron Mk1.5 位于那条弧线的另一端。Perceptron 已经完成了后训练，确定了输出格式，并为结果定价——每百万输入 token 0.15 美元，每百万输出 token 1.50 美元，缓存输入为 0.0375 美元。它的规格具体到基础检查点所不具备的程度：36,864 token 的上下文、8,192 token 的最大输出、四种输入模态，以及一个 reasoning_effort 控制项，默认为 high，支持 chat completions 上的函数调用，以及通过 JSON Schema 和正则表达式实现的受约束响应。

之所以要把两者放在一起看，是因为总拥有成本朝着相反的方向走。Mk1.5 每 token 都很贵，但启动是免费的。LFM2.5-2.6B-Base 在边际上是免费的，却要在唯一真正重要的货币上付出高昂代价——而这对基础检查点而言，就是你的工程时间。

逐维度进行，并保持各角色清晰分明。

• 它是什么 — Perceptron Mk1.5 是一个托管的感知 API，可提供结构化的空间输出。LFM2.5-2.6B-Base 是一个可下载的 26.9 亿参数预训练因果语言模型。

• 输入 —— Mk1.5 接受文本、图像、视频和音频（WAV、MP3、FLAC）。LFM2.5-2.6B-Base 接受文本，且仅限文本。

• 输出 — Mk1.5 返回文本，以及可选的点、框、多边形、片段和带时间戳的 <track> 元素，或受 JSON Schema 约束的响应。基础版会返回下一个 token 的 token 概率，且没有任何调优使其变得有用。

• 独立使用——Mk1.5 在你拿到密钥的当天就能用。LFM2.5-2.6B-Base 在任何产品意义上都不能回答问题；它需要经过微调，通常还需要一个聊天模板，才能成为一款可以交付的模型。

• 上下文 — Mk1.5 为 36,864 个 token，而基础模型为 131,072 个。端侧检查点所容纳的文本量，几乎是服务端感知模型所容纳任何内容的四倍。

• Footprint — Mk1.5 能在 Perceptron 运行它的任何地方运行，其已公布的延迟工作是在单块 H100 上完成的。基础版设计为在内存低于 2.5GB 的情况下，在笔记本电脑、手机或边缘设备上运行。

• 证据——Mk1.5 的每一项能力数据都出自 Perceptron 自己，且没有针对它的独立指标。基座则完全没有基准测试声明：Liquid 公布的是后训练版 LFM2.5-2.6B 的分数，而非此检查点。

• 许可证 — Mk1.5 是闭源的，按 token 租用。LFM2.5-2.6B-Base 在 LFM Open License v1.0 下发布，权重可下载并保留。

权重路线，诚实核算成本

如果说 LFM2.5-2.6B-Base 的吸引力在于权重免费，那么这句话更诚实的版本是：权重只是整个项目中最便宜的部分。基于专有数据进行微调，意味着需要数据集、一次训练运行、一套用来判断微调是否奏效的评估工具链，以及一条服务路径——Transformers、vLLM 或 SGLang，或者 Liquid 发布的 GGUF、ONNX 和 MLX 构建版本之一，分别用于 CPU、跨平台和 Apple Silicon 部署。这些都不算稀奇，而且在 2.69B 规模下，它能适配 70B 微调根本触及不到的硬件。但基础检查点只是一个起点，而进度风险完全落在你这笔交易的一方。

你换来的是控制权。16 种语言的分词器和 131K 上下文意味着，领域微调不必与预训练争夺空间。低于 2.5GB 的占用意味着部署目标是设备而非数据中心，而这正是该系列的全部意义所在。并且，LFM Open License 让你能留下成果——一个竞争对手无法从你能使用的同一 API 租到的专家模型。

在押注这一谱系之前，有一项第三方证据值得了解，也有一个空白。Liquid 经后训练的 LFM2.5-2.6B 确实有一项独立测量：Artificial Analysis 将其智能指数列为 8，在其同类 49 个模型中排名第 9。基础检查点则没有——它没有对应页面，这对预训练基础模型来说很正常，值得直说，而不应把它当作定论。后训练模型的指数告诉你的是，在指数区间的低端，从这一起点出发，该流水线能产出什么，而不是你的微调将会产出什么。

API 路线，以及对于托管模型而言，“设备端”意味着什么

Perceptron Mk1.5 的部署情况比其目标清单所暗示的要复杂，值得精确说明。供应商的公告将无人机、四足机器人、智能眼镜和手机列为部署目标。该模型本身由 api.perceptron.inc 提供服务，并需通过 API 密钥访问，而 Perceptron 公布的延迟证据是在单张 H100 上三次运行结果的中位数。单张 H100 并不是无人机。更现实的解读是，Mk1.5 是为具备网络链路或配套计算盒的机器人提供感知层，而不是运行在机体内部的模型——任何围绕它规划离线设备的人，都应在设计硬件之前检验这一假设。

如果网络假设成立，API 路线能换来的，是基础检查点无论出多少钱都给不了的东西：坐标。Mk1.5 的 <track> 输出携带一条空间观测及其时间戳，因此一段片段返回的是随时间变化的物体位置，而不是对场景的描述。再加上 asset_idx 字段——它让一次请求可以分别寻址多张图像或多段视频——请求的形态就与一个控制回路相吻合：参考帧输入，几何信息输出，模型与真正驱动动作的代码之间没有解析阶段。

成本就是已经列出的那些：36,864 个上下文 token，每项音频 16,384 token 的上限——Perceptron 的文档按约每分钟 750 token 折算，将其定为大约 21.8 分钟；一个 reasoning_effort 的默认值为 high，这会在你未配置的每次调用中按最昂贵的推理路径向你计费；以及由销售该模型的公司给出的一组基准测试声明。手部跟踪数字是那个应该用你自己的素材来检验的数字：0.9433 在自我中心视角的 hand_box 上，对比 Gemini 3.1 Pro 在 Perceptron 自己的运行中的 0.4467，是一个很大的差距，而厂商评估中的大差距恰恰值得复现。

这两者都不在我们的目录中，这会改变决定。

目前，Perceptron Mk1.5 和 LFM2.5-2.6B-Base 都没有在 OrcaRouter 上配置路由。Mk1.5 完全没有路由，因此要访问它，只能使用厂商自己的 API——pip install "perceptron>=0.4.0" 和 PERCEPTRON_API_KEY——而我们的目录中没有任何规模的 Liquid AI 模型，因此该基础检查点需要从 Liquid 的 Hugging Face 下载，而不是通过调用获取。

这一点没有听起来那么重要，因为两者并非可以互换的端点，任何定价上的理由都无法让它们变成那样。路由层在这里所贡献的，是决策中仍然开放的那部分。如果你在 Mk1.5 上构建一项感知服务，并在微调过的 LFM2.5-2.6B-Base 上构建一个文本专家，那你就是在跑两套集成、面对两种故障模式；在它们前面放一个兼容 OpenAI 的网关，就能把任一侧的供应商故障变成一次回退，而不是一个失败的任务，而一条路由规则可以把视觉流量和文本流量发往不同的模型，应用甚至无需知道哪个是哪个。一个覆盖200 多个模型、供应商列表价按 0% 加价透传的 API，就是这种做法的版本：供应商调价当天就能落地，而不必等到你下次续约——不过就这两个模型而言，今天这个网关是一个规划层面的考量，而不是一条现成可用的捷径。

你应该做什么，以及应该衡量什么

如果你的任务是“在这一帧里找到这个物体并返回它所在的位置”，那就先租用 Mk1.5，在你自己的视频上验证 hand-box 这一说法，然后再决定是否把生产路径押在它上面。要为网络假设预留预算，刻意设置 reasoning_effort，而不是直接接受 high，并把 36,864 token 的窗口当作它本就是的硬性约束来对待。结构化输出才是产品，而如果你的下游代码无需解析阶段就能直接消费一个坐标，那就在大多数视觉管线悄然损失精度的地方带来了实打实的节省。

如果你的任务是“我需要一个用别人都没有的数据调过的 2.6B 模型，还要在没有 GPU 的地方跑”，那就下载 LFM2.5-2.6B-Base，并在开始之前诚实地估算微调的成本。检查点是免费的，工程不是；而这个系列自己的教训——经过后训练的同门模型在独立指数上得分 8——提醒人们，基座模型和成品模型之间的差距，才是真正的工作所在。这两者都不是错误答案。它们是不同的购买选择，唯一真正的错误，是把一个还得由你完成的基础模型，当成已经做好的产品。

两个模型、两套集成、两种故障模式，这种处境比表面看上去更糟。在 OrcaRouter 上，你可以设置自动故障转移，这样任意一侧的服务商故障都会降级为回退，而不是导致任务失败。