Decision 3.0 对比 Microsoft-Decision-1：一个是下载，另一个是 SKU

9B 档位的Decision 3.0与Microsoft-Decision-1在纸面上是同一款产品。两者都把Qwen3.5-9B后训练成一个评分器：对一组固定的候选答案分别给出一个经过校准的概率，而全程不生成任何 token。两者面向的也是同样的活儿——为请求选择路由、依据评分标准给输出打分、为智能体的动作把关、对队列进行分诊。两者问世的时间相隔不到一周：Microsoft-Decision-1 于 2026 年 10 月 8 日在 Microsoft Foundry 正式可用，次日正式发布；而d3-flash则于 2026 年 10 月 10 日 17:23 UTC 被推送到 Hugging Face。

差别不在模型本身，而在于你能用它做什么。d3-flash 是一个 83.9 亿参数、Apache-2.0 许可的检查点，你可以下载并运行；它在一个从 5.9 亿参数起步、最高到 260.9 亿参数的家族中位列第三。Microsoft-Decision-1 是 Foundry 上的一个托管端点，其权重完全不对外分发；微软表示，这一产品线之后将迁移到其自家的 MAI 模型之上。这两者中，一个是制品，另一个是服务。关于这对模型的几乎所有实际问题，都源于这一单一事实，包括那些看起来是在问基准测试的问题。

关于决策模型用途的两项决定

微软的博文对适用范围的说明十分明确，而模型卡很少能做到这一点。所支持的问题形式包括是/否、多选、评分、分类以及基于量规的评分。排除项也同样直白地列出：并非为文本生成、开放式问答、对话、翻译或摘要而设计，也不适用于需要输入中未包含的知识的任务。它对最多 32,768 个 token 运行一次前向计算，并且不产生任何输出 token，因为没有解码循环。微软还支持在所提供的证据不足时选择弃权（例如“无法判断”），正是这一细节才使对输出进行阈值判定真正有意义。

d3-flash 处于同一个概念框架之内——Choice、Noul（是/否）和 Score 类问题，每个问题一次前向传递，每个选项对应一个概率，不进行生成——随后它拓宽了输入端。Microsoft-Decision-1 在设计上仅支持文本，而 d3-flash 则接受文本或 JSON，每次请求可包含多张图像（每张最高 1.6 百万像素），以及多段视频（以每秒 2 帧读取）。请求中的每个问题都能看到随附的每一张图像和每一段视频。它是一个更小的模型，却能对所获得的输入做更多的事。

这是第一个真正的分水岭，而且它不是品味问题。如果你需要做出的判断涉及截图、收据、图表或摄像头拍下的一段视频，那么 Microsoft-Decision-1 做不了。这是能力边界，而不是质量差距，再多的准确率工作也无法弥合。

各自发布什么，以及如何发布

这里两个版本做的是真正不同类型的验证，值得将它们分开来看，而不是把数字并列比较。

微软开展了一项覆盖近 150,000 个问题的 36 项基准比较，这些题目在训练中被设为盲测，涵盖路由、排序、长上下文、多语言和分布外任务、推理与安全，并称其模型在所有这些测试集上表现最佳。它报告延迟时使用比值而非数字——p50 比 GPT-6 Sol 快约 35 倍，比 H2O-Lightning-4B v1.1 快 2.5 倍，并称后者为第二名。它把稳健性记录为一套流程：同一请求以八种方式扰动，平均决策翻转率为 1.3%，而当选项描述被改写，或选项被反转或打乱时，翻转率为零。它在 11 项基准的 5,250 个请求上测试了安全性，这些基准涵盖有害内容、越狱和提示注入。它陈述了自我要求的校准标准——在代表性案例上，一个 90% 的预测应在大约十次中正确九次。

vLLM-SR 发布了一个指数。Jev Decision Index 0.3.1 将 d3 排在 64.7，其中 d3-flash 在公开套件上为 57.79，并声称相较 Decision 2.0 的 9B 模型（46.76）提升了 11.0。它还声称 140,178 个公开请求全部得到回答，且无一未获支持，这属于覆盖度声明，而非准确率声明。该模型卡披露，d3 自身的行是内部评估，而与其并列的对比行——Perplexity Decider v1.1、Fastino GLiDE、Jev、Torchcast Decision 27B——是实时榜单数据。而在多模态方面，d3 系列模型报告了全部 19,140 个验证问题上的 Perception Test 分数，其中 d3-flash 为 73.3，而三选一随机下限为 33.3。

所以：Microsoft 发布了一项广度声明，附有有记录的方法和一个稳健性数值，却没有逐检查点的校准数值。vLLM-SR 发布了一个排行榜名次，并明确说明其自身那一行与其他行之间存在溯源差距，还附带了一个视频结果，同样没有校准数值。这两张卡片都没有为其所描述的模型提供 Brier 分数或预期校准误差数值。对于两款全部价值主张就在于所返回的数字有意义的产​​品而言，这就是它们共同的漏洞，也是这两家厂商接下来能推出的最有用的东西。

分发的决定作用比规格表更大

这就是比较不再关乎模型的地方。

使用 d3-flash，你会获得权重、一个decision_config.json，它固定了基础修订版本，包含逐文件 SHA-256 清单、自定义建模代码、读出头，以及一套有文档记录的依赖集，其中包括transformers==5.17.0，以及一个用于线性注意力层的可选 CUDA 内核包。你可以在自己的硬件上运行它、微调它、量化它、将它气隙隔离。你还要承担运维工作：Python 类并不是一个端点，而且模型卡没有说明状态、问题加候选描述所需的 token 预算——max_length 是 null，在随附配置中就是这样，所以那个上限得由你自己去发现。

使用 Microsoft-Decision-1，你可以在现有云账户内获得一个端点，随之而来的还有身份验证、区域可用性和预配控制，而运营工作则完全不用你操心。当然，控制权也完全不归你。没有可下载的代码仓库，没有微调路径，也没有自托管选项；模型的生命周期由 Microsoft 掌控，而不是你，无论是弃用通知，还是换用不同骨干模型重新构建，你都只能被动接受，而无法主动安排。Microsoft 表示，将其迁移到自家 MAI 模型的工作即将到来——对于一个核心价值就在于快速单遍评分的模型来说，这是合理的路线图，但这也意味着，你现在做基准测试的那个具体检查点，未必就是你一年后实际调用的那一个。

关于延迟的说法也需要仔细解读。微软的主打数字是相对于一个规模大得多的通用模型得出的比率，这对它的论点而言是正确的比较方式——决策模型的职责，就是用一次廉价的评分调用替代一次昂贵的生成式调用，而在 p50 下相较 GPT-6 Sol 达到 35 倍，正是这一论点落到实处时的样子。vLLM-SR 的数字是绝对值，基于单请求和单 GPU，它们清楚地展示了模态税：在一块 AMD Instinct MI325X 上，向 d3-flash 发出的文本请求中位耗时 19.1 毫秒，同一请求附带一张图像时耗时 149.4 毫秒，附带一段十秒视频时则耗时 407.6 毫秒。两组数据均由厂商报告，基于不同硬件，且都未在产出它们的实验室之外得到复现。

如何选择

决策规则很短，这是一个好迹象，说明这两个产品实际上并不是在争夺同一个位置。

在以下情况下采用 Microsoft-Decision-1：决策仅涉及文本、你已经在 Foundry 上运行，并且关键就在于它是调用而非部署——无需购买 GPU、无需运维容器、无需自己承担模型的生命周期管理。对平台团队而言，微软的配套材料也是两者中更实用的：扰动测试、安全测试计数，以及明确说明支持弃权选项，这些正是你编写阈值策略所需要的内容；而 32,768 token 的上限是明确写出的，而非留空。

选择Decision 3.0——现实中就是 d3-flash 或 d3-mini——如果决策的任何部分依赖于图像或片段，如果你需要在托管 API 无法触及的地方运行它，或者如果你想用自己标注的案例对评分器进行微调。Apache-2.0 许可证和文件级哈希清单使这成为一个真正可行的选项，而非理论上的选项。作为交换，你接受的是未说明的输入预算、没有已发布的校准，以及该系列才发布几天、背后基本没有外部使用这一事实。

如果你两者都需要——一条常规文本路径用托管式评分器，多模态或气隙隔离场景用自托管评分器，并且两者都通过同一个接口调用——那么实话实说，目前没有任何厂商能提供这样的方案，而这两种请求格式虽然足够接近、可以统一，却并不完全相同。

OrcaRouter 所处的位置，以及它不在的位置

typesafe/jev-1.13 是我们目录中的决策模型，通过 POST /v1/systemone 提供服务，采用上面两个模型都实现的相同状态与命名问题契约：文本输入，结构化 JSON 输出，最多约 64K 输入 token，非流式，每百万输入 token $0.042，且无补全费用，因为它从不生成补全。值得注意的是，上面两张卡片都未完整回答的 Android 风格 token 预算问题，在这里得到了回答。

本次对比中的这两个模型我们都不提供。Decision 3.0 的检查点以 Hugging Face 仓库中的本地推理路径形式发布，而非可路由的端点；Microsoft-Decision-1 则通过微软自有平台及多个第三方平台分发——并非通过我们。本文中的任何内容都不应被理解为对两者中任一模型可用性的声明。

在这个决策中，路由层真正值钱的地方在于这条回路的另一半。评分器从构造上就很便宜；而依据它的输出采取行动的模型则不便宜，把决策模型与生成模型配对，通常意味着两套集成、两份计费关系和两种故障模式。用一个密钥同时调用 200 多个模型——当某家供应商出现波动时自动故障转移，并以 0% 加价透传供应商的标价，因此厂商价格一变，当天就能生效——这意味着你可以在不改动调用点的情况下换掉评分器。这一点在这里比平时更重要，因为这两个模型都还处在足够早期的阶段，你这周做出的决定，应该到下个月就能推翻。

六个月后决定此事的那个问题

两个团队在同一周把同一个基础检查点后训练成了同一形态的产品，却就它应如何触达客户得出了相反的结论。与其说是时间上的巧合，不如说是这个品类销售方式上的分岔：作为权重还是作为服务，作为你拥有的东西还是你调用的东西。

关注三个信号。其一，微软将底座迁回 MAI 或其自有模型，是否会改变它当前所推销的准确率与延迟表现——以及客户能提前多久收到通知。其二，vLLM-SR 是否会为 Decision 3.0 公布输入预算和校准数值，从而填补使其指数无法付诸行动的那道缺口。其三，两家实验室之外是否有人会在已发布的 d3 权重上运行公开测试套件，因为眼下一个能真正定论这场比较的数字，正是两家厂商都尚未给出的那个。