Liquid AI open d1：一次前向计算做分类，端侧应用该怎样验收

事实与来源

Liquid AI于2026年10月7日发布开放权重的d1-3B和实验版d1-omni-600M。前者处理文字与图片，后者支持文字搭配图片或音频。它们面向判断、分类与评分：给定输入和问题，直接返回结构化结果，适合放在应用的分流环节。

这类模型的价值在于减少为了得到一个标签而生成长答案的过程。本文依据发布原文和两份模型卡分析接口与部署边界，未下载或运行模型；公开权重使用LFM许可证，接入前仍需核对适用条款。

技术机制

官方把输入称为state，可以是文本、JSON或媒体；问题另行描述要判断什么，以及可选答案。接口支持是非判断、命名选项和有序等级。模型在一次前向计算中读取输入及多个问题，从选项分布给出结果，不逐个生成输出token，也就省去了从自然语言回答里解析标签的步骤。

这里的“零输出token”不代表零计算量。读取长文本、编码图片和处理多个问题仍有开销。d1-3B基于解码器式视觉语言模型，omni版本基于双向编码器并接入视觉、音频编码器。后者的接口规定单次请求使用图片或音频，不能把两种媒体同时传入；应用的数据组织必须遵守这一约束。

例子与用途

假设做一个本地笔记收件箱，用户放入一段文字或一张截图，希望自动归到“待办、参考资料、暂不分类”。可以定义一个分类问题，再定义“是否含明确时间”和“是否需要人工确认”两个判断，让同一输入一次返回三项结果。这里的场景是本文构造的设计示例，并非实测效果。

应用收到结果后，只给笔记添加可撤销标签；日期仍需另外提取和校验。若用户输入的是“也许下周再考虑”，系统不应仅凭分类概率就建立确定日程。把内容理解、字段校验和执行动作分开，既便于换模型，也能把分类错误限制在较低成本的范围内。

限制与不确定性

d1-3B模型卡的速度表使用预热后的请求。发布方报告Apple M5 Pro上单问题约30毫秒，3.4千token输入约640毫秒；这说明最短样例的数字不能直接作为整个应用的响应时间。加载权重、首次编译、媒体预处理以及业务逻辑，还需要在目标设备上单独测量。

omni版本仍属早期研究发布，官方没有提供它的推理速度数字。其音频训练面向英语用户与助手之间的请求，片段截到30秒，因此不能据语言列表就认定中文语音意图已经验证可靠。模型卡还区分文字答案的温度校准与图像、音频的原始softmax输出，不能把所有模态的置信度当成同一种质量保证。

开发者启示

先为具体功能准备人工标注的小型验证集，覆盖否定句、含糊表达、多个意图和不属于任何选项的输入。比较准确率之外，还应记录错误标签会触发什么后果；“暂不分类”应成为可接受结果，而不是为了覆盖率强行选择。概率阈值应由本项目的数据确定，并保留独立测试集，避免反复调到只适合样例。

部署验收则分开记录冷启动、预热延迟、长输入和内存峰值，固定模型版本、问题描述及选项顺序。官方示例需加载模型仓库自带代码，运行前应审查并固定版本，不把开放权重等同于任意代码可信。以上是工程建议；是否能替代现有分类器，仍需用目标语言、设备和真实工作流验证。