Decision 3.0 与 Intern-Decision-4B：两个团队微调了同一个模型，却在其他所有方面意见相左

把 d3-mini，即 Decision 3.0 的 4B 成员，放在 Intern-Decision-4B 旁边，你首先注意到的并不是差异。两者都是同一个基础检查点 Qwen3.5-4B 的微调版本。两者都列明为 45.4 亿参数。两者都接收一个状态、一个由具名问题构成的模式以及一组候选答案，并为每个候选返回一个校准后的概率，而无需生成任何 token。两者均为 Apache-2.0。两者都是在没有任何公告的情况下发布的：InternLM 于 2026 年 9 月 26 日在四十秒内上传了三个检查点，而 vLLM-SR 的 Decision 3.0 系列于 2026 年 10 月 10 日登陆 Hugging Face，相关消息仅由 vLLM 项目的 X 账号传播。

在那之后，剩下的就全是分歧了。他们在如何从模型中读出一个概率、视频是否算作输入、一个请求可以有多长，以及——最尖锐的是——团队是否愿意公布那个表明其自身置信度值得信赖的数字上，都存在分歧。本文讨论的是这四个分歧，以及每一个会让你付出什么代价，而不是哪个模型“更好”，因为两者并非在同一尺度上衡量，如果不做两家供应商都未曾做过的工作，就无法将它们相互排名。

首先值得理解的巧合

两个实验室在两周内选择同一个 4B 主干，并不完全令人意外——Qwen3.5-4B 是结构化输出模型的合理基础，而两个团队显然都选择了它，因为它足够小，可以低成本运行，又足够强，能够读懂指令。真正令人意外的是，他们得到的参数量在四位有效数字上都完全相同。这说明微调保留了原有架构，也说明两者都没有额外加入一个大到足以改变总参数量的独立视觉塔。两者都将自己的多模态能力融入同一套权重之中。

有趣的部分在于读出。这两个模型在原理上以相同方式回答问题——对候选答案进行评分，而不是生成它们——但在机制上则完全不同：

• Intern-Decision-4B — 将每个选项映射为单个 token 符号（A–Z，然后是 a–z，再是 0–9），把 JSON 骨架连同每个字段对应的占位符渲染进提示词中，并执行一次因果前向传播，读取每个占位符紧前位置的 logits。该机制已在其模型卡上逐步记录，包括精确的 softmax 与 temperature 步骤。

• d3-mini — 在 modeling_d3.py 中自带一套自定义架构，其独立的读出头存放在单独的 readout.safetensors 中，还有一个 decision_config.json，其中声明了 noncausal_full_attention和末位 token 池化，并且以 token 到代码的映射直接在配置中定义，而非用文字描述。

两种方法都没有明显更优。InternLM 路线的好处是，它运行在标准的 Hugging Face 模型类上，并带有文档记录的数值序列——你可以检查它的工作过程。vLLM-SR 路线的好处是，读出是一个经过训练的 head，而不是现有 token 嵌入的投影，因此拟合更自由；代价是你必须 trust_remote_code=True并运行他们的代码才能做任何事。

各自发布的上限

这才是真正的偏好开始形成的地方，因为一张卡在何处停止工作这一点上，远比另一张具体得多。

• 输入上限——Intern-Decision-4B：默认 8,192 个 token，超过该值的请求会被直接拒绝，绝不会被截断，上限由构造函数参数设定。d3-mini：max_length为null，随附配置中没有任何 token 预算出现在模型卡上。

• 每次请求的问题数 — Intern-Decision-4B：1 至 16，并声明任一问题的选项数上限为 62 个。d3-mini：未声明限制；卡片仅说明这些问题会一并作答，每个问题各来自其自身的前向传播。

• 图像 — Intern-Decision-4B：每次请求最多支持八张，按你提供的列表排序，由检查点处理器负责尺寸调整和 token 扩展。d3-mini：每次请求可传入多张，支持路径、URL、PIL 图像或 base64 数据 URL，每张最高以 1.6 百万像素读取，每个问题都能看到每一张图像。

• 视频 — Intern-Decision-4B：无。d3-mini：多个视频，以每秒 2 帧读取，上限为整个片段分布 32 帧、每帧 0.2 兆像素。

输入上限才是对大多数人来说起决定作用的那条线。8,192 token 的预算要在状态、问题指令和候选描述之间共享，这对这些模型所宣称的文档评分和长上下文路由工作来说是一个实实在在的约束，InternLM 值得称赞，因为它坦率地说明了这一点，而不是留待别人去发现。vLLM-SR 对此不予说明则恰恰相反：不是隐藏的限制，而是未知的限制，无论怎么读仓库都无法确定。

校准才是真正的分野

每个决策模型都许下同样的承诺：它返回的数字是一个概率，据此设定的阈值有其意义。但几乎没有哪个模型能证明这一点。这正是两个版本分歧最大的地方，而这一分歧的方向，与你从发布日期所能猜到的恰好相反。

Intern-Decision-4B 在其自己的模型卡上发布：在其七项基准平均值上，Brier 分数为 0.347，期望校准误差为 0.065；通过在 1,728 个指定校准案例与 1,693 个单独验证案例上进行 NLL 最小化得出的拟合温度为 1.99241824；明确声明未使用测试套件标签来选择该温度；以及一项 96 个案例的诊断，显示其校准从温度缩放前的 0.628 Brier / 0.213 ECE 变为缩放后的 0.550 / 0.089。它还说明了默认值，并表示校准是按检查点进行的，因此将其他尺寸与此模块一起使用将不匹配。

Decision 3.0 发布了一个准确率指数和一项覆盖率声明——140,178 个公开请求全部得到回答，无一无据可依——却完全没有给出任何校准数值。在六个检查点中的任何一个上，都没有 Brier 分数，没有 ECE，也没有说明温度设置。温度在 d3 交付的 decision_config.json中为 1.0，即恒等变换，它可能是、也可能不是拟合得到的取值；文件并未说明。

将两条指数头条并排阅读，这种不对称性只会更加严重。d3-mini 的卡片报告 Jev Decision Index 0.3 public-suite 得分为 54.90，并描述为使用官方工具包在已发布权重上测得，而同一榜单上的对比行则被描述为实时榜单数据。Intern-Decision-4B 报告其自身七个基准的平均值为 90.02。这两个数字不在同一尺度上，使用的任务也不相同，把它们放进同一句话里作比较会是不诚实的。可比较的是披露：一张卡片告诉你它的置信度错得有多离谱，而另一张则不知道，或者不愿说。

延迟，以及为什么这两组毫秒数同样不可比较

两张卡都公布了每请求延迟，但就和准确率数据不可比一样，仅凭表面数值加以采信同样是错误的。

• Intern-Decision-4B —— 平均 44.16 ms，中位数 44.03 ms，p95 44.60 ms，在单张 RTX 4090 上通过本地 Hugging Face 路径测得，据称取决于工作负载和硬件。

• d3-mini — 文本的中位延迟为 17.5 毫秒，带图像时为 96.2 毫秒，带十秒视频时为 371.5 毫秒，测试环境为单块 AMD Instinct MI325X，每次仅处理一个请求。

有两件事使这些结果无法直接比较。其一是硬件与软件路径：一边是 4090 对 MI325X，一边是原版 Hugging Face 前向传播对通过flash-linear-attention可获得掩码层内核的自定义注意力实现。其二是工作负载：InternLM 的数字被描述为在未说明的混合负载上的每查询端到端时延，而 vLLM-SR 的数字则按输入模态分列，因此纯文本对比是唯一同类可比的条目，而即便这一项也跨越了两家 GPU 厂商。

从这两张卡片上要看的数字不是排名，而是形态。在一个工作流内部，决策模型会被反复调用——一条支持记录可能需要一个目的地、一次退款核查、一个升级决策和一个优先级评分，也就是四个问题，而一批 128 条记录就会把这一切变成 512 次决策。在这种量级下，与下游生成模型的成本相比，17 毫秒和 44 毫秒都微不足道。真正需要留意的是那些取决于模态的数字，因为按照 d3-mini 自身的数据，一次图像或视频请求的成本是文本请求的五到二十倍；而如果你的决策是基于一张截图做出的，那你已经引入了一种大多数决策模型部署都不具备的成本特征。

到底该选哪一个？

如果你需要做出的决策取决于视频，那毫无悬念，也无需分析：Decision 3.0 能读取视频，而 Intern-Decision-4B 不能。对于任何涉及屏幕录制、摄像机片段或帧序列的情况，这就是全部答案，而这个差距本身就足以证明较新系列存在的合理性。

如果你的输入内容是文本和偶尔出现的图像，那么选择取决于两件事，而这两件事都不是排行榜。

当你需要围绕阈值进行推理时，选择 Intern-Decision-4B。在两者之中，只有它会告诉你一个 0.9 是否意味着十次中有九次，它会指明自己的温度参数，会说明该温度是在哪些案例上拟合得到的，并把它自己的推理记录成一段简短的编号流程，让你可以基于一个现成的模型类重新实现。对于一个处在自动化动作前端的评分器来说，那才是真正重要的特性，而且它比准确率分数更少见。

当你需要覆盖范围或多模态能力时，就选 Decision 3.0。从 0.59B 到 26.09B 的六个检查点意味着，同一请求格式既能由 6.7 ms 的边缘模型来服务，也能由 27B 的模型来服务；而且该系列共享同一个接口，因此在层级之间迁移只是配置更改，而不是重写。问题在于，你是在信任一个未说明的输入预算和一个未经审计的校准声明，而且该系列中最大的模型，正是供应商在其自有测试框架上测出索引数值的那个模型。

如今两者都不是安全的默认选择。d3 下载量最高的 checkpoint 在 Hugging Face 上才上线了大约一天；Intern-Decision-4B 已上线两周，获得了约 3,200 次下载和 83 个赞，这算是关注度，但不是生产流量。两者都足够便宜，可以测试，而且都没有第三方评估背书。如果你要把评分器放在一个会花钱的环节前面，正确的做法是让两者都在你自己标注的案例上跑一遍，并比较校准曲线，而不是榜单上的行。

路由器何处适得其所，实话实说

这两款模型 OrcaRouter 都不提供。Decision 3.0 的检查点是 Hugging Face 仓库中的一条本地 Python 推理路径，未发布任何 HTTP 端点；而 Intern-Decision-4B 是以 DecisionEngine 类的形式提供的，需要你自己实例化。两者都不是我们今天能够路由的模型，本文的任何内容都不应被理解为可用性声明。

我们确实提供的是同一系列的托管端。typesafe/jev-1.13已收录在我们的目录中，通过POST /v1/systemone提供服务——与上述两个开源模型所实现的相同状态与命名问题契约——定价为每百万输入 token 0.042 美元，且不收取补全费用，因为它从不生成补全。它与另外 200 多个模型并列，而对任何想要比较这两者的人来说，这才是真正的关键：打分器是循环中便宜的那一环，而依据决策采取行动的模型才是昂贵的那一环。通过一个密钥同时路由两者，在提供商出现波动时自动故障转移，并按 0% 加价透传提供商标价，这意味着评估一个决策模型无需签署第二份合同，也无需在切换后端时重写调用点。如果你正处于评估中途——这两个模型今天都处于这个阶段——那么在决定采用其中任何一个之前，这一部分值得先搭建好。

悬而未决的问题

两张卡片对模型作者对读者负有什么义务存在分歧，而这种分歧比模型本身更有意思。InternLM 公布了一个温度值及其拟合所依据的案例，随后又公布了显示校准改善了多少的诊断结果。vLLM-SR 公布了文件哈希、固定的基础修订版本、声明的硬件目标、覆盖范围声明——实打实的溯源工作——却完全没有给出校准数值。

判断哪个版本会成熟的标准，不是哪一个能在榜单上胜出，而是下一个 Decision checkpoint 发布时是否带有 Brier 分数，以及 InternLM 的下一次上传能否达到视频。这两者都能从外部看到，核查起来成本都很低，而且目前都还没有发生。