Microsoft-Decision-1 与 Intern-Decision-2B 对比：快九毫秒，但校准明显更差

InternLM 自己的表格里有一个本不该存在的数字，而正是它让这次对比比规格表更有价值。Intern-Decision-2B——2,213,241,664 个参数，从 Qwen/Qwen3.5-2B 微调而来，于 2026 年 9 月 26 日 05:36:19 UTC 在没有任何公告的情况下上传至 Hugging Face——其每查询平均延迟为33.28 ms（单张 RTX 4090），比自家 8.52 亿参数的同门兄弟模型的 33.98 ms 还略快一点。它同时也录得了其家族中最差的校准：期望校准误差为 0.100，而 0.8B 为 0.066；拟合温度为 2.100509348278，而 0.8B 为 2.747760550703。与此同时，Microsoft-Decision-1，自2026 年 10 月 8 日起在 Microsoft Foundry 正式可用，却既没有公布延迟数字，也完全没有公布校准误差——只有一段描述二者测量方式的方法论说明。所以这场对决真正要问的，并不是两者哪个更好，而是：当你买任何东西的中间那一档尺寸时，你究竟买到了什么。

两个模型都是决策评分器：输入状态，输入有界问题集，输出校准后的概率，不生成文本，也没有需要解析的 token。正是这一共同约定，让差异变得清晰可辨。Microsoft-Decision-1 是一个托管的、仅文本的 Foundry API，基于 Qwen3.5-9B，具有 32,768 个 token 的窗口，不提供分布式权重，也没有微调路径。Intern-Decision-2B 是一个 Apache-2.0 检查点，将上游 Qwen 许可证保留为 LICENSE-QWEN，仓库约 4.46 GB，包含自定义推理代码，并且在任何地方都没有托管端点。

中等尺寸实际上是用来做什么的

InternLM 在四十秒内推送了三个检查点：0.8B 在 05:35:57，这一个在 05:36:19，4B 在 05:36:37。在厂商自己的七套评测平均值上，这个系列按你希望看到的顺序攀升——79.38、84.68、90.02——这是 2B 唯一看起来像是一笔明智购买的地方。而在其他所有地方，它看上去都是那种没人会故意选择的尺寸。

提示处理在一次决策调用中占主导地位，这才是延迟倒置的机械性解释，而不是什么谜团。评分器对提示只做恰好一次前向传播，而提示长度由状态、模式和选项描述决定——绝不由模型写出的任何内容决定，因为模型什么都不写。在这种情况下，参数量只是次要成本，因此通常选择最小检查点的理由并不适用：你省下的不是时间，而是内存。0.8B 的整个仓库约为 1.73 GB，而该模型为 4.46 GB，这才是更偏好前者的诚实理由。2B 唯一真正可称道之处，是它恰好是快速档里最快的那个，而领先幅度小到可以视作噪声。

与 Microsoft-Decision-1 相比，那种说法几乎无关紧要，因为这两个模型并不处于同一延迟区间。托管端点的速度首先是你的部署形态的函数——同一标准 SKU 上的无服务器与预置吞吐量——其次才是模型的函数，而 Microsoft 没有公布任何可供比较的每调用数据。Microsoft 确实公布的是一个朝相反方向起作用的硬性运营约束：批量推理被禁用。没有离线通道可以用来摊销批量评分运行，因此 Microsoft-Decision-1 流水线要为每一次决策支付交互成本，而自托管检查点无论是否在进行评分，都要付出 GPU 小时成本。

校准柱，中间落败之处

把三张 Intern-Decision 卡片放在一起读，这个系列就不再表现得可预测。准确率随规模单调变化；校准则不是。2B 的 ECE 为 0.100——三者中最差——拟合温度为 2.100509348278，远低于 0.8B 的 2.747760550703。卡片指示你使用随你所下载规模一同提供的推理模块，因为默认校准是按检查点分别设定的；任何把一个同级模型的封装复制到另一个同级模型的人，都会在不知不觉中应用错误的温度。

在把这个 0.100 当作对权重的判决之前，这个变换本身值得理解。它是在该字段的候选 logits 上做 softmax，随后再对该分布取对数并除以温度后做第二次 softmax。由于它在第一次 softmax 之后运行并保持排序，它完全无法改变 argmax。它会改变置信度、yes 概率以及评分题的期望值，但标签保持不变。如果你的流程读取标签，温度参数就是空操作，ECE 则只是个无关紧要的趣闻。如果你的流程读取概率——对它们设阈值、按它们排序、把它们送入期望值计算——那么 0.100 的 ECE 就是“阈值符合你所写含义”与“阈值不符合”之间的差别。正确的应对方式是在你自己的已标注案例上拟合你自己的温度，而不是断定权重有问题。

Microsoft-Decision-1 要求完成完全相同的工作，但可用的起点信息更少。其 Benchmarks 标签页称，准确率、校准误差、安全召回率、假阳性率和公平一致性是在公共和社区决策基准以及留出的内部测试集上测量的，选项顺序经过了变化，并且应用了配对统计检验，还说该模型“表现与领先的决策模型相当，并领先于以相同方法评估的其他开放决策模型”。没有 ECE。没有 Brier。没有温度。没有准确率表。其全部价值主张就是一个可信概率的模型，恰恰是这次比较中完全没有公布任何校准数值的那一个。

契约边界：托管模型不会做的四件事

这两个模型所做的调用看起来如出一辙，而分歧恰恰藏在其边缘之处。

• 模态 — Microsoft-Decision-1 明确仅限文本，不接受任何图像、音频或视频。Intern-Decision-2B 在状态之外还可接受多达八张图像，这使其成为截图分诊和布局检查的候选方案，而托管 API 无法以任何准确度提供这些功能。

• 输入上限与失效模式——Microsoft-Decision-1 单次调用最多处理 32,768 个 token。Intern-Decision-2B 声明 DecisionEngine(max_length=8192)，并直接拒绝超长输入而非将其截断，这对评分器而言是正确行为，同时也是一堵硬墙，因为状态、schema 和 skeleton 必须全部在一次传递中到齐；没有任何分块策略能保住这一契约。

• 问题形态 — InternLM 记录每次调用可包含一至十六个问题，每个问题最多 62 个选项，涵盖三种字段类型（choice、score、noul），其中 noul 是二元的是/否，返回一个概率，而 score 则在由你命名的量表上返回经概率加权的期望值。Microsoft 记录了这些格式——是/否、多选题、评级、分类、评分量规——外加一个受明确支持的弃权选项，例如证据不足时的“无法判断”，对于任何编写升级逻辑的人来说，这是该页面上最有用的一句话。

• 价格 — Microsoft-Decision-1 模型页面并未标出费率；定价链接指向 Microsoft 的定价页面，因此每次决策的成本需要从 Azure 或账单上读取，其中 0% 可归因于输出 token，因为根本没有输出 token。Intern-Decision-2B 每次调用不花钱，成本全在 GPU 时间上，而且它没有托管提供商。其存储占用约为 4.46 GB，分布在一个 3.76 GB 的语言分片、一个 612.5 MB 的视觉塔和一个 50.3 MB 的投影器上。

哪些是已确认的，哪些只是厂商的一面之词？

把这两个类别区分开，就是这个系列的全部纪律所在。这些可由文件列表或 HTTP 响应确认：参数量、分片映射、许可证对、基础模型、底层架构——一个 Qwen3_5ForConditionalGeneration，具有 24 层、2,048 的隐藏大小、8 个查询头对 2 个键值头、256 的头维度、每三层线性注意力层对一层全注意力层的重复模式、一个保留的多 token 预测层，以及 262,144 位置的嵌入上限，而 8,192 token 的引擎上限让这个上限实际上无关紧要。

供应商报告且未经复现：每一个准确率数字、每一项延迟指标，以及温度。没有论文，没有 arXiv 条目，没有发布帖，没有更新日志，也没有独立评估。那个演示 Space 返回 401，这意味着它并非公开，而不是坏掉了。模型发布之后出现的那个 GitHub 仓库——三次提交、训练代码、两个推理后端、一个包含 10,751 行测试数据的评估包、一个 96 个用例的校准基准以及一份复现指南——比大多数悄无声息的发布所获得的文档还要多，而且它没有附带权重、训练数据和代码许可证。微软处于一个不同但相邻的位置：其方法论是真实的，其主张是定性的，而目前两家公司都处于这样一种境地——其核心数字除你之外无人能够核查。

OrcaRouter 在这样的流水线中处于什么位置

这两个模型都不在我们的目录中，此处任何内容都不应被解读为可用性声明。返回概率而非文本的模型，并不是你会把聊天补全路由过去的那类对象，这两个模型都是如此。我们真正提供的，是那些评分器所服务的循环中的生成侧：通过一个 OpenAI 兼容密钥即可调用的 200 多个模型，它们负责撰写评分标准、起草候选答案，并发出工具调用，随后由评分器在执行前对其评分。供应商目录价按 0% 加价原样传递，因此生成侧的供应商降价当天就会在我们的价格上生效；如果你不愿把自己的阈值押在单一评判者身上，路由 DSL 可将多个模型组合成单次调用，模型融合会将其一致性作为一个可评分的字段报告出来。当某个提供商出现性能下降时，自动故障转移能让这一侧保持存活——在一个对自己看到的一切都进行评分的循环里，这比在一个偶尔回答用户一次的循环里更为重要。

最重要的一点

Microsoft-Decision-1 自 2026 年 10 月 8 日起已在 Microsoft Foundry 上正式可用：托管式、纯文本、32,768 个 token，基于 Qwen3.5-9B，由 Microsoft 进行后训练，不提供分布式权重，并且其基准测试部分记录了方法论却没有给出任何数字——连延迟也没有，且批量推理处于关闭状态。Intern-Decision-2B 是 2026 年 9 月 26 日发布的一个 2,213,241,664 参数的 Apache-2.0 检查点，在其三个同门型号中速度最快，在 4090 上为 33.28 ms，但校准最差，ECE 为 0.100，拟合温度为 2.100509348278，它无法改变标签，却会改变你用来设阈值的每一个置信度。如果你想要中间尺寸，支持它的理由其实很薄弱：要么多花 2.7 GB 换取 4B 的准确率，要么接受 0.8B 的占用；而无论哪种情况，在阈值接近生产环境之前，都要先拟合你自己的校准。

我们承载的，是那些评分器所服务循环中的生成性一半：超过200个模型，位于一个兼容 OpenAI 的密钥背后，它们编写评分标准、起草候选答案，并发出工具调用，随后由评分器在它执行之前进行评分。