Microsoft-Decision-1 与 Kev：购买评分，还是拥有能产出评分的配方

贾里德·帕尔默（Jared Palmer）给自己的模型附上了一份“收据”。Kev 系列——Kev-0.8B、Kev-4B 和 Kev-9B——基于冻结的开放权重基础检查点构建，配有 rank-16 LoRA 适配器和一个小型指针头，于 2026 年 9 月 24 日发布，其训练配方、逐阶段数据量和评估数字均已公布；对于任何将其与 Microsoft-Decision-1进行比较的人来说，诚实的头条结论是：Kev 告诉你的关于如何复现它自身的信息要多得多。微软的评分器于 2026 年 10 月 8 日在 Microsoft Foundry 上正式可用：一个由微软后训练的 Qwen3.5-9B 基座模型，32,768 token 上下文，仅支持文本，权重未分发，评估方法已公布，但没有公布结果。两者都接收一个状态和一组类型化问题，并返回校准后的分布，而不是生成的文本。一个是服务，另一个是你今晚就能在 notebook 里运行的方法。

这一区别而非能力决定这场对决的原因在于：Kev-4B 在其域外锁定测试上报告 ECE 0.017，而 Microsoft-Decision-1 什么都没报告，因此，通常能裁定评分器对评分器比较的校准论证，只有一方陈述了立场。

Kev 实际上发布的内容

Kev-4B 的模型卡异常具体，而具体性正是关键。主干是 Qwen3.5-4B-Base，冻结在指定修订版本，具有 24 个 Gated DeltaNet 线性注意力层和 8 个全注意力层，隐藏大小为 2,560。在其之上是一个秩为 16 的 LoRA 适配器——3380 万个可训练参数，应用于注意力、MLP 和 DeltaNet 投影——以及一个指针头，它将每个选项的结束标记与问题的最后一个标记进行评分并做 softmax。一个温度 T = 2.41 存储在头文件中并在加载时应用，模型卡给出了拟合值和文件哈希。训练分阶段进行，并公布了记录数量：基础配方有 12,576 条记录，1,425 条用于日期和缺失证据，5,219 条真实的 CFPB 投诉叙述，6,000 条技能记录和 5,320 条开发者工具记录，后续阶段重放了早期阶段的数据。模型卡还说明了未使用的内容：“未使用 Jev（TypeSafe 的托管决策模型）的任何输出。”

基准表就列在同一页上，而且还附带了失败案例，这种情况比成功案例更为少见。Transfer-v4 锁定域外测试：准确率 0.838，Brier 0.224，ECE 0.017。Breadth-v1 在 14 个留出数据集、3,089 个问题上：准确率 0.690，ECE 0.029。Hard-v1 测试：0.803。Documents-v1 测试：0.903。十选项的 MMLU-Pro：0.565。日期运算：0.65，被作者称为最薄弱的领域，并提供了一个预处理器标志作为部分修复方案，同时明确注明该项未重新测量。局限性部分还补充说，校准采用的是单一分布内温度，因此覆盖能力在域外会下降；选项顺序可能使答案翻转；超过 8,192 个 token 的长度虽可服务但未经验证。服务性能数据也已公布：在 H100 上，短状态下六个问题耗时 18.1 毫秒，缓存后为 12.9 毫秒，常驻 GPU 内存 14.3 GB。

微软反而发布的内容

Microsoft-Decision-1 以不同的姿态覆盖了大部分相同的内容。它可对是/否、多项选择、评分、分类和量规类问题进行打分，支持"无法判断"等明确的弃权选项，返回 JSON 概率值，并可在单次调用中处理最多 32K 个 token——是 Kev 所验证上下文的四倍。它以托管 API 的形式在 Microsoft Foundry 中的 Direct from Azure 产品组合下分发，支持无服务器和统一终结点部署、标准 SKU、Azure 身份验证以及统一计费路径。批量推理已禁用，且不提供权重下载和微调途径。

评估部分描述了公开和社区决策基准以及留出的内部数据集，指标包括准确率和校准误差，选项顺序有变化，配对统计检验，并声称该模型“表现与领先的决策模型相当，并领先于用相同方法评估的其他开放决策模型”。没有表格。模型卡诚实地列出了自身的局限——分数会随措辞和选项顺序而变化，校准在熟悉的任务类型上最强，不生成解释，非英语覆盖最弱——但局限列表并不是校准测量。任何人在 Microsoft-Decision-1 上设置 0.9 的自动接受阈值，都是在凭信念设置，并在生产中调整它。

比较中需要花钱的那部分

Kev 的经济性才是这场对决真正势均力敌的原因。方案是一个冻结的基础模型加上一个 33.8M 的适配器，这意味着你训练的边际模型消耗的是适配器级别的算力，而不是基础模型级别的算力。你可以把基础模型在内存中常驻一次，然后加载多个适配器——每个决策域一个——这是 Microsoft 的托管 API 完全无法表达的部署形态。如果你的路由规则与通用评审器不同，Kev 让你把这种差异训练进去；Microsoft-Decision-1 则让你写一个更好的提示词，然后祈祷。

相比之下，托管 API 不附带任何运维面。没有需要跟踪的适配器，没有需要保持热度的服务栈，没有需要权衡的“验证时上下文与线上服务上下文之间的差距”，也不存在在某个数据集上拟合出的温度在你的数据上表现不同的风险。对于决策量不大的团队来说，即便 token 需要花钱，这项服务在工程工时上仍是更便宜的产物；而对于每天要为数百万条数据打分的团队，一旦 GPU 的成本收回，自托管适配器便会在单位成本上胜出。

还有第三条路径：在最薄弱的环节上不依赖这两个模型中的任何一个，而这正是 OrcaRouter 所处的位置。我们不托管 Microsoft-Decision-1 或 Kev——返回概率的评分器并不是一个 chat-completions 目标，而且这两个模型都不在我们的目录中。我们承载的是决策流水线中生成的那一半：负责起草候选答案、编写评分标准，或发出会被评分的工具调用的模型。所有这一切都在一个兼容 OpenAI 的密钥之后，上面有 200 多个模型 按提供商标价透传，0% 加价，因此供应商的价格变动当天就会在我们这边生效。如果你正在构建评分或分诊循环，写作调用是可路由的，而评分调用则不是，保持这条边界清晰，才能防止评分流水线悄悄变成聊天流水线。

如何决定

选择Kev的场合包括：你需要在上线前拿到数字，你想用自己的决策标签进行微调，你想在自有边界内以零边际成本运行评分，或者你想让多个决策领域共用同一个常驻基础模型。它公布的 ECE 数值仍然是作者在自己搭建的评测框架上测得的自有结果——请把它们视为可信的自我评估，而非经过审计的第三方结论——但它们至少是一个你可以尝试复现的明确量级，而且复现的方法就摆在那里。

选择 Microsoft-Decision-1——当决策关口是采购或上下文长度时：一个带统一计费和负责任 AI 套件的托管式 Azure 端点，针对长文档提供 32K 输入，并且有供应商可供升级求助。它缺少基准测试表并非丑闻——许多托管模型发布时都没有——但这确实意味着该模型的第一个校准曲线将由其用户绘制，而在你把生产阈值指向它之前，你应当计划成为其中之一，并使用你自己标注的数据。