为 Microsoft-Decision-1 对比 Liquid AI d1-omni-600M 生成的一张标题卡,副标题为“同类中最宽的传感器覆盖面,对最窄的输入列表”,标签写着:具备视觉和音频的 587M 参数、纯文本 Foundry API、30 秒语音对 32,768 个文本 token、双向编码器对后训练解码器,以及双方均未公开校准。
Engineering & Research

Microsoft-Decision-1 vs Liquid AI d1-omni-600M:一个会听的评分器对决一个只会读的评分器

作者

Magnus Corvin

发布日期

最新模型 · 20查看全部模型 →
基准测试:Artificial Analysis · 每日更新
返回全部文章

你在保险理赔台负责分流索赔,而文件以三样东西送达:一份 PDF、一张有凹痕的门的照片,以及一段九十秒的电话通话。 Liquid AI d1-omni-600M 能够阅读该文件、查看照片并聆听通话,然后一次性回答你事先写好的一组问题——这是否在承保范围内、属于哪个类别、严重程度如何(按二到十的等级)——且不生成文本,也无需解析任何内容。 Microsoft-Decision-1 可以阅读该文件。它在 Microsoft Foundry 上于 2026年10月8日 正式全面可用,是一个托管的纯文本评分器,基于 Qwen3.5-9B 后训练,具有 32,768 个 token 的窗口;其输入面到此为止:没有图像、没有音频、没有视频。两者都会针对你提供的选项返回校准后的概率,两者都产生零个输出 token,且两者均未公布校准数值。

最后那句共同的话,是这次比较中令人不安的部分。这两个是本月推出的传感器最宽和传感器最窄的决策模型,而尽管它们在架构上相距甚远,却落到了完全相同的证据位置:真实权重或真实端点、有文档记录的契约,以及当有人问这些概率是否可信时,供应商之外的任何人都指不出一个数字。

两种血统,而非两种尺码

587M 这个数字会让人把 Liquid AI d1-omni-600M 理解成本博客此前介绍过的那些模型的缩小版。事实并非如此。该模型基于LFM2.5-Encoder-350M训练而来,这是一个双向编码器,拥有 381M 的共享主干和决策头、一个取自 LFM2.5-VL-450M 系列的 94M 视觉编码器,以及用于音频的17 层 FastConformer。Microsoft-Decision-1 则完全属于另一条谱系:一个由 Microsoft 进行后训练的 Qwen3.5-9B 解码器,托管在 Foundry 上,权重不对外分发,也不提供微调路径。

双向架构与解码器架构,正是决定二者各自行为方式的架构事实,也正是参数量之所以会分散注意力的原因。双向编码器一次性读取整个状态,这对于在固定输入上作出判断而言是恰当的形状;经过后训练的解码器放弃了生成路径,却保留了分词器、上下文窗口,以及伴随代工厂部署而来的企业级封装。二者都不是对方按比例放大的版本,无论怎样解读基准测试表格,它们都无法彼此替换。

输入列表实际能带来什么

这正是 d1-omni-600M 与同类中其他所有产品分歧最大之处,也是某个说法需要被仔细审视的地方。

• 语音——Liquid AI d1-omni-600M 可接受文本以及最长 30 秒的语音,并据此给出判定,这是任何纯文本评分器无论达到何种准确率都无法做到的。Microsoft-Decision-1 的非文本模态并不存在。

• 互斥性 —— 如果图像和音频出现在同一请求中,d1-omni-600M 会抛出 ValueError。该类别中最宽的传感器覆盖面仍然一次只能处理一种非文本模态,这对那个理赔台而言是一个实实在在的限制。

• 截断——其卡片标明文本、图像和音频位置合计 16,384 个,并补充说明:在有图像的情况下,状态和问题文本会被截断至 896 个 token,以匹配训练设置。你给哪份文档附加了照片,它就要与这一截断争抢空间。Microsoft-Decision-1 的 32,768 个 token 全是文本,且不会被截断。

• 格式 — d1-omni-600M 有三种问题类型:noul,用于二值决策,返回 0 到 1 之间的 P(yes);choice,用于从你指定的标签集合中选出一个标签,并给出置信度以及每个选项的概率;以及 score,用于在二到十级的有序量表上给出一个位置及其分布。多个问题可以挂在同一个状态上,并通过一次读取完成,用量计数器会报告 output_tokens: 0。Microsoft 记录了是/否、多选、评分、分类和评分标准等形式,还记录了一个明确支持的弃权选项,例如在证据不足时选择“无法判断”——这是 Microsoft 页面上唯一一个在此处没有直接对应项的设计细节。

• 运行时 —— d1-omni-600M 附带自定义代码,需要 trust_remote_code=True,其模型卡建议在 GPU 上使用 float16,同时警告 bfloat16 会在部分数据行上改变首选答案。这是厂商记录的推理服务时敏感性问题,而非缺陷。Microsoft-Decision-1 是托管端点,部署形态是你唯一可调的运行时变量;另外值得注意的是,批量推理已被禁用:没有可用于摊薄大规模评分任务开销的离线通道。

A two-column generated scoreboard titled Microsoft-Decision-1 vs Liquid AI d1-omni-600M. Left column Microsoft-Decision-1 rows read: availability Foundry GA, October 8, 2026; base post-trained Qwen3.5-9B decoder; inputs text only; context 32,768 tokens of text, untrimmed; weights not distributed; calibration not published. Right column Liquid AI d1-omni-600M rows read: availability uploaded October 7, 2026; base LFM2.5-Encoder-350M bidirectional encoder with 587M total; inputs text, images, or 30 seconds of speech, one non-text modality at a time; context 16,384 positions with text trimmed to 896 tokens when images are present; weights open under lfm1.0; calibration not published. A footer line reads that neither vendor has published an accuracy or calibration benchmark for these models.

证据缺口,两个方向皆然

Liquid AI 于 2026 年 10 月 7 日发布了开放的 d1 系列,其中包括 d1-omni-600M,并附有一篇发布博文和一套文档。没有发布的是那个能让多模态声明变得具体的数字。没有针对其自身主打能力的准确率基准——也就是支撑 94M 和 112M 编码器的视觉与音频决策质量——而且视觉子集未包含在已发布的评估材料中。延迟数据也未被公布,因此该模型的吞吐量需要你在自己的硬件上自行发现。

Microsoft 的立场在结构上完全相同,并且更进一步。其“基准测试”标签页列出了各项指标——准确率、校准误差、安全召回率、假阳性率、公平性一致性——并说明评估是在公开和社区决策基准以及未用于训练的留出内部测试集上进行的,对选项顺序进行了变化,应用了配对统计检验,还声称该模型“表现与领先的决策模型相当,并优于采用相同方法评估的其他开放决策模型。”但它没有公布任何结果。页面列出了支持的二十五种语言,包括日语、韩语、阿拉伯语、越南语、泰语、土耳其语、印地语、孟加拉语、斯瓦希里语、希伯来语、波斯语和乌克兰语,并坦率警告称,覆盖范围、质量和校准“可能因语言而异”,非英语,尤其是低资源语言,是一个薄弱环节。定价也不在模型页面上;它外链到 Microsoft 的定价页面。

所以,这两者之间的比较并不是证据与证据之间的比较。它是在两种缺失的数字之间做选择。Liquid AI 已经交付了传感器表面,却让该表面的准确性在公开领域处于未测量状态。Microsoft 已经交付了采购路径——Azure 身份验证、治理、一次 Responsible AI 评估、一套有成文记录的方法论——却让一个概率产品的校准未被量化。

A capture of Liquid AI's own blog post 'Open d1: Edge decision models for text, vision, and audio' dated Oct 7, 2026, showing the opening paragraph that announces d1-3B and d1-omni-600M as released that day, d1-3B's 48.57 Decision Index v0.2.1 score, and its 8 ms, 16 ms and 26 ms latencies on an RTX 4090, a Jetson AGX Thor and a Jetson AGX Orin.

他们两人都未回答的那个校准问题

对于决策模型来说,概率就是产物。下游环节则全都是阈值:0.7 触发升级,0.95 自动接受;而划错这条线的代价,不是以 token 计,而是以糟糕的自动化决策计。在这一类别中,至少有一个模型家族会公布这些数字——InternLM 的 Intern-Decision 检查点会在其模型卡上印出 Brier 和期望校准误差数值——而本文中的两个模型都没有公布。这种不对称,正是应当保持选择面足够宽、而不是仅凭架构就下注的实际理由。

好消息是,这个测试成本很低,而且不需要供应商配合。收集几百个看起来像你真实流量的已标注案例,写下你的应用实际会发送的问题模式,让两个模型分别跑一遍,并计算输出上的预期校准误差。这样你就会知道两件目前除了这两家供应商之外无人知晓的事:微软-Decision-1 的概率在你的数据分布上与其准确率匹配得有多好,以及 d1-omni-600M 的音频和图像路径是否值得其所携带的编码器。微软自己记录在文档中的指导也指向同一方向——在具有代表性的数据上进行验证,根据你出错的成本来设定阈值,始终提供一个弃权选项,随机化选项顺序,对影响重大的决策保留人类在环。

各自属于哪里,以及 OrcaRouter 属于哪里

Microsoft-Decision-1 适用于决策材料是文本、而阻碍在于采购环节的任何场景:一份长文档、一段检索到的段落、一个拟议的工具调用、一个正依据评分标准进行评分的生成答案,同时还需要 Azure 身份验证、统一计费,以及在任何内容投入生产之前必须完成的供应商评估。它是范围更窄的工具,也是更容易获批的工具。

Liquid AI d1-omni-600M 适用于起决定作用的材料不是文本的场景——表单附带的照片、简短的通话录音、屏幕截图——也适用于你希望在可控边界内运行并微调 lfm1.0 权重的任何地方。它是覆盖面更广的工具,也是更难验证的工具,因为多模态这一主张恰恰是背后没有已发布基准支撑的部分。

A capture of Liquid AI's documentation site showing the left navigation (Liquid Foundation Models with Text, Vision, Audio, Decision Models and Liquid Nanos entries, plus Fine-tuning, Edge Inference and llama.cpp), the 'New: Open d1' banner, and the opening description of Liquid Foundation Models as a class of multimodal architectures built for fast inference and on-device deployment.

这两者都不在我们的目录中,此处也不构成对其中任何一方的可用性声明。一个返回概率而非文本的模型,并不是你会把聊天补全请求路由过去的东西,而置身评分席之外正是这件工具的全部设计。OrcaRouter 所承载的,是同一闭环中的生成侧:一个与 OpenAI 兼容的密钥背后的 200 多个模型,它们负责撰写你的评分器据以打分的评分标准,在素材变成一个状态之前对其进行转录或摘要,并发出你的评分器在放行之前予以批准的工具调用。供应商的标价按0% 加价透传,因此生成侧一旦降价,我们这边当天即生效。当单个供应商性能下降时,自动故障转移能让这一侧继续存活——而一条对每份检索到的文档都打分的流水线会立刻察觉这一点——如果你希望受评判的是多个撰写者而非一个,路由 DSL 可把它们组合成单次调用,模型融合会把它们的一致性作为一个字段报告出来,你的评分器可以像读取任何其他字段一样读取它。

最重要的一点

Microsoft-Decision-1 于 2026 年 10 月 8 日在 Microsoft Foundry 上正式发布:仅支持文本,32,768 个 token,基于后训练的 Qwen3.5-9B 构建,托管运行但不提供权重,模型页面上没有价格,没有延迟数据,基准测试部分描述了其方法却未给出结果。Liquid AI d1-omni-600M 于 2026 年 10 月 7 日以 lfm1.0 许可证上传,是一个 587M 的双向编码器决策模型,可读取文本、图像或 30 秒语音——一次只处理一种非文本模态,且当存在图像时文本会被裁剪到 896 个 token——其主打能力没有准确率基准,没有视觉拆分,也没有公布延迟。要根据模态与可控性来选择,而不是根据评分,因为这些评分并不存在:如果你的材料是一张照片或一通电话,这两者中只有一个能作出响应;而如果是一份附有采购审查的四十页文档,则只有另一个能部署。

OrcaRouter 承载的,是同一循环中的生成侧:200 多个模型位于同一个兼容 OpenAI 的密钥之后——它们撰写你的评分器据以打分的评分标准,在素材成为状态之前将其转写或摘要,并发出你的评分器在其运行前予以批准的工具调用。