Microsoft-Decision-1 对比 Liquid AI d1-3B：同样的 32K 窗口，两种不同的解读

难得规格对得上。Microsoft-Decision-1自 2026 年 10 月 8 日起在 Microsoft Foundry 上正式可用，上下文长度为 32,768 个 token。Liquid AI d1-3B也是如此——它于 2026 年 10 月 5 日上传至 Hugging Face，两天后由 Liquid AI 发布。两者都接受一个状态加上一组带类型的问题——是/否、从具名选项中做选择、在有序量表上给出位置——并且都在单次前向传播中作答，给出的是概率分布而非生成文本；Laya、Intern-Decision-4B、Kev 以及这一细分领域的其他模型在上下文长度上各执一词，所以这是唯一一组该维度被排除在外的配对，比较只能从别的方面来论证。

原来那个“别的东西”就是输入通道。微软的模型明确是纯文本的：它“不接受也不生成图像、音频或视频内容”。Liquid AI 的模型则在 26 亿参数的语言主干上搭载了一个 4 亿参数的 SigLIP2 NaFlex 视觉编码器，总参数量达到 31.2 亿，而它恰恰是为微软排除掉的那件事而打造的——用固定的问题去评分一张截图、一份扫描表单或一帧摄像头画面。这一分野，再加上一个与能力无关的许可差异，就构成了这场对比的全部。

在两者一致的地方，这比你预想的要多

• 上下文窗口 — Microsoft-Decision-1 为 32,768 个 token，Liquid AI d1-3B 也为 32,768 个 token。

• 输出形态 — 在所提供的选项上给出经过校准的概率；两者均不生成文本，Liquid AI 的用量计数器以 output_tokens: 0 如实说明了这一点。

• 问题类型——既包括文档选择，也包括有序评分和二元是/否，而且它们都允许你按请求定义选项集，而无需重新训练词表头。

• 弃权 — 微软记录了诸如"无法判断"之类的明确弃权选项；Liquid AI 的 Decision Index 架构通过其选项集提供了同样的支持。

• 单遍推理——双方每次决策仅需一次调用，这正是其中任一方案能在流水线规模下可行的原因。

在这个细分领域，两个模型对最难的两项约束不谋而合，这一点值得停下来想想。32K 窗口是让决策评分器能用于完整合同、多页政策或长支持线程的关键；而 512-token 的英语 Laya 检查点以及 Intern-Decision-4B 的每次调用问题限制则不行。如果你的输入很短，这个领域里大多数方案都可以互换，决策只关乎托管。如果你的输入很长，选择范围就缩小到这两个。

那种只有他们中的一个才有的感觉

Liquid AI d1-3B 是多模态的，而模型树把它的谱系交代得一清二楚：先是 LFM2.5-2.6B-Base，然后是 LFM2.5-VL-3B，再到经过后训练、用于单遍校准决策的 d1-3B。图像通过 SigLIP2 NaFlex 编码器进入，模型卡报告在十一项公开图像基准上平均为 74.1，而基础视觉模型为 73.9——因此决策调优并未牺牲其视觉质量。它还报告了反向实验：把图像去掉后，同样的问题得分降至 45.1，这是你能得到的最干净利落的证据，说明感知通道是承重结构，而非装饰。

Microsoft-Decision-1 没有对应项，而且这一缺失是刻意为之，而非尚未完成。微软的模型卡将超出范围的使用场景列为文本生成、开放式问答、对话、翻译和摘要，并另行说明该模型仅支持文本。对于需要依据评分标准为表单截图打分，或判断摄像头画面中是否包含安全事件的流水线而言，这就是一道硬性阻碍——无论怎样进行提示工程，都无法找回模型从未被赋予的模态。

语言数量统计的方向则相反，这也是第二个真正的分歧点。Microsoft-Decision-1 列出 25 种受支持的语言，而微软也坦诚表示，覆盖率、质量和校准“可能因语言而异”，并将非英语、尤其是低资源语言列为表现欠佳的领域。Liquid AI d1-3B 则声称支持 16 种语言。论覆盖广度，微软在纸面上领先；但论及对“广度”究竟意味着什么的坦率程度，两家厂商的说法大同小异，而且双方都没有公布按语言细分的校准数据。

又是基准测试选项卡

Microsoft-Decision-1 的 Foundry 页面带有一个 Benchmarks 标签页，其中包含方法说明部分，但没有图表：公共和社区决策基准以及留出的内部数据集，指标涵盖准确率和校准误差，选项顺序有变化，采用配对统计检验，并声称该模型“与领先的决策模型表现相当，并且领先于用相同方法评估的其他开放决策模型”。没有可核对的内容，也没有可复现的内容。

Liquid AI d1-3B 在 Decision Index 0.2.1 上公布了 48.57 分——而限定条件比这个数字更重要，因为 Decision Index 是 Liquid AI 自家的指数，d1-3B 也是 Liquid AI 自家的模型。这是厂商在自家编写的基准上自行打分得出的结果，公司将其定位为 10B 以下决策模型中的最佳，并在同一量表上领先于一个 35B 模型。应把 48.57 视为一种方向性的说法，而非经过审计的数字。与此同时，模型卡还列出了内部决策格式评测平均 77.1、SQuAD 2.0 为 85.3、PAWS-X 为 76.9 以及 DecisionBench 为 71.8——全部为自报数据；而“10B 以下”的说法是真实的限定条件，而非回避之词，因为该模型为 3.12B。

所以，校准问题的解决方式在整个领域里都一样：Liquid AI 给出的是一个按其自有尺度产生的数字，微软给出的是一套方法论而非数字，而两者都不会提供独立的第三方测量。对你的部署而言，唯一重要的校准数值，就是你在自己的标注数据上计算出的那个。

服务、许可证，以及你实际购买的到底是什么

d1-3B 的延迟是公开的，而这正是该模型存在的原因。在 RTX 4090 上每次决策 8 毫秒，在 AMD MI325X 上为 9 毫秒，在 64 个状态下的打包吞吐量分别为每秒 475 次和 1,106 次。在边缘硬件上：Apple M5 Pro 上为 30 毫秒，Jetson AGX Thor 上为 16 毫秒，Jetson AGX Orin 64 GB 上为 26 毫秒，Orin Nano 上为 50 毫秒。Microsoft-Decision-1 完全没有公布任何延迟数字，而其设计内置的选项——按需付费或预留预配吞吐量的托管式 Foundry API，且批处理推理被禁用——意味着你得通过自己的部署来测量。对于一个其全部用途就是每检索到一个文档或每提出一个动作就被调用一次的模型来说，这不是一个小差距。

许可证问题正是两者以令人意外的方式产生分歧之处。Liquid AI d1-3B 被标记为 lfm1.0，而不是 Apache 2.0——这与 Liquid 的 LFM 系列其他模型采用同一家族许可，该许可带有宽松许可证所没有的使用条件。如果你的法务审查将其解读为“兼容 OpenAI 且无附加约束”，那它并非如此；这件事值得在模型发布前而不是发布后再看。Microsoft-Decision-1 则完全没有权重：它是 Direct from Azure 产品组合下的托管端点，具备 Azure 身份验证、统一计费、无需下载，许可问题也被服务协议所取代。这两个模型都无法通过供应商文档所述的路径进行微调，这对决策模型来说是最尖锐的限制——一个你无法用自己的标签去适配的评分器，其错误模式你无法修正，只能绕过。

绕开它们来路由，正是 OrcaRouter 在这一模式中的位置所在，而且只在这一模式的其中一侧。我们既不托管 Microsoft-Decision-1，也不托管 Liquid AI d1-3B：两者都不返回文本，都不在我们的目录里，而概率评分端点也并非聊天补全的调用目标。我们承载的是这一循环中负责生成的那一半——即草拟你的评分器将要打分的答案、抽取你的评分器将要评判的字段，或提出你的评分器将要批准的动作的那个模型。这意味着超过 200 个模型共用一个 OpenAI 兼容密钥，按供应商标价透传、零加价，因此供应商的价格一旦变动，当天就会在我们这边生效，而自动故障转移则会覆盖这一循环中的生成调用——这个循环根本没有多余的延迟可供重试一次。

两个漂亮的选择，而另一个则毫无悬念

就选Liquid AI d1-3B，只要你的管线里有任何东西是图像。屏幕截图分诊、表单提取、视觉 QA 路由、审核员为摄像头画面打分——Microsoft-Decision-1 没法被要求做这些，而 d1-3B 正是为此打造，并公布了视觉基准成绩来支撑这一说法。如果你需要的是在 Jetson 或笔记本电脑上以数十毫秒计量的边缘推理，如果你想把模型放在自己的硬件上，或者如果你的法务顾问觉得一份你读得懂的许可证就够了，那也应当选它。

选择 Microsoft-Decision-1，如果你的输入是文本、你的文档很长、你的决策关口是采购——Azure 身份验证、统一账单、负责任 AI 评估、有一个可以升级求助的供应商——或者你的流量所覆盖的语言超过了 d1-3B 列出的 16 种。那就接受这一点：它缺少延迟数据和基准测试表，意味着你使用它的头两周是在做测量，而不是集成。

唯一一个并不接近的情况是多模态工作：在那里，当微软在模型卡中写入“text-only”时，选择就已经做出了。