Microsoft-Decision-1 与 Laya：API 背后是 25 种语言，322MB 下载背后是 100+ 种语言

数一数支持的语言，这场对比似乎就已分出胜负。Microsoft-Decision-1自 2026 年 10 月 8 日起在 Microsoft Foundry 上正式可用，列出 25 种受支持的语言，并直言其覆盖范围、质量和校准"可能因语言而异"，还点名非英语、尤其是低资源语言是表现欠佳的领域。Laya由 Convai Innovations 于 2026 年 9 月 18 日以 Apache 2.0 许可发布，自称覆盖 100 多种语言，并称在 51 种受测语言中有 45 种在路由下仍可正常使用，而其仅支持英语的同门模型只有 51 种中的 23 种。前者是部署在 Azure 端点之后、上下文长度为 32,768 个 token 的 9B 模型；后者是拥有 4.21 亿参数的分类器，在单块 Tesla T4 上即可免费运行，每次决策耗时 32.8 毫秒。两者都不生成任何 token，也都返回你所定义的各个选项上的概率。

但完整读完这两份模型卡后，语言数量就不再是那个有意思的数字了。真正有意思的是它背后的校准故事，而这两个项目以相反的方向讲述着这个故事。

Laya 公布了那个令自家营销颇为尴尬的数字

Laya 模型卡在其自身的局限性部分指出，基础检查点在 typed-decisions 基准上的零样本得分为 0.362——低于 0.461 的多数类基线。这相当于一张卡片在告诉你，其模型在该测试上比猜“最常见的答案”还差。它还指出，基础检查点在零样本下接近随机水平，头条的 0.766 typed-decisions 数字需要在该基准自身的划分上进行微调，有序评分问题是最薄弱的原语（SST-5 0.372），高基数选择题表现不佳，因为 77 个选项平均每个只剩大约三到四个 token，noul 能遵循自己的标签，并且 action.act_probability 字段“尚未携带可用信号”，AUROC 为 0.30。Convai 自己的总结句才是任何评估中都该记住的：Laya 是一个可快速专门化的基础模型，而不是零样本决策引擎。

这份坦率比听起来更有价值，因为它明确告诉你 Laya 的用途。它是一个你可以用自己的标签进行微调的编码器——整个架构的设计使得新的 schema 无需重新训练，但要在某项任务上表现出色则离不开它。这样使用时，公布的数据很亮眼：微调后在带类型决策上为 0.766，而 Jev 为 0.727；AG News 为 0.950，而对比 0.910；DAIR Emotion 为 0.595，而对比 0.480；ECE 为 0.081，而 Jev 为 0.246——并诚实地指出，它发布时过度自信，需要重新拟合温度，这使平均 ECE 从 0.466 变为 0.081。

微软公布方法论，却隐瞒结果。

Microsoft-Decision-1 的 Foundry 页面则以相反方向进行了同样的演练。它详细描述了该评估——包括公开和社区决策基准以及留出的内部数据集、包括准确率和校准误差在内的指标、选项顺序变化、配对统计检验、被比较模型使用相同的测试框架——并报告称，该模型“表现与领先的决策模型不相上下，并领先于采用相同方法评估的其他开放决策模型。”它列出了其强项（推理、规则应用、对提示格式的稳健性）和弱项（专业领域知识、非英语）。

然后它什么都不输出。没有准确率数字，没有校准误差，没有按基准分列的表。自我报告的局限性是真实且有用的——分数会随措辞和选项顺序变化，一个表述不佳的问题仍会返回分数，校准在熟悉的任务类型上最强，不会产生任何解释——但一份局限性清单并不是一种测量。所以这笔取舍异常清晰：Laya 给你一些数字，你可以在自己的数据上尝试证伪，而 Microsoft 给你一种合规姿态和一个 32K 的上下文，你可以把一份长文档放进去。

尺寸差异究竟能换来什么

Laya 的小巧在这里不是妥协，而是设计本身。因为每个选项都会在各自的 [MASK] token 上打分，并针对该问题的各个选项做 softmax，答案空间是在请求时组装出来的，而不是预先烘焙进词表头——这就是为什么你今天下午才设计出的 schema 不需要重新训练，也是为什么该模型能容纳在 3.22 亿到 4.21 亿个参数之内。多语言检查点的运行速度约为英语检查点的 2.2 倍，路由器在不到半毫秒内检测文字体系，而在单块 T4 上，批处理吞吐量可达每秒 103 到 332 个问题。对于要为每张工单、每份检索到的文档或每个提议操作打分的负载而言，吞吐量才是关键特性，而不是参数量。

这种设计的代价同样具体，值得与微软的方案对照说明。英语检查点采用 512 个 token 的窗口；多语言检查点则为 1,024，可扩展至 8K。Microsoft-Decision-1 采用 32,768。一条冗长的支持会话线程、一份完整合同或一份多页政策文档，根本无法纳入 Laya 的窗口，而再快的速度也无法弥补截断造成的损失。Laya 每次前向传递回答一组问题，并为每个选项记录 token 预算；微软则记录单次调用最多可处理 32K 个 token，且没有按问题设定的上限。此外，Laya 作为分类器的竞争短板也值得了解：它在 Banking77 上的得分为 0.425，而 Jev 为 0.870——这正是那种细粒度、高基数的意图问题，最需要专门化处理。

不是按 token 计算的成本比较

Laya 在使用点上是免费的——可自托管，Apache 2.0，其自托管成本标注为"$0"——而它真正的代价，是在它能胜任你的任务之前你必须为它付出的那次微调运行。Microsoft-Decision-1 是一个托管的 Foundry API，按 token 计费的价格并未印在模型页面上，没有可下载的权重，没有微调路径，批量推理也被禁用。一个是需要前期投入的数据标注项目，另一个是按量计费的调用。哪个更便宜完全取决于用量，而且交叉点很高：一个 421M 的编码器在租来的 T4 上每秒为 300 个条目打分，一旦训练完成，按每次决策计算，它很难被超越。

正是在这里，OrcaRouter 在基于这两种模型中任一模型构建的流水线中赢得了一席之地，而且它仅限生成侧。我们既不托管 Microsoft-Decision-1，也不托管 Laya：两者返回的是概率而非文本，两者都不在我们的目录中，而且评分端点不是聊天补全目标。我们实际提供的是生成被评分对象的模型——即 Laya 的微调头随后评判的草拟回复、拟议工具调用和候选答案。那就是 200 多个模型，只需一个 OpenAI 兼容密钥即可访问，按提供商目录价透传，0% 加价，当某条服务路径降级时自动故障转移。在对其生成的一切进行评分的循环中，生成调用正是可能出故障的部分，而故障转移正是让评分队列持续有输入的关键。

该选哪一个

选择 Laya，如果你的决策来自多种语言，如果你的调用量足够大、以至于按 token 计费变得重要，如果你有标注数据并有一周时间进行微调，或者如果你需要在自有边界内的硬件上运行评分。接受 512 到 1,024 个 token 的窗口，以及在你对其做专门化之前基础检查点性能接近随机水平这一事实，那么你得到的决策模型会坦诚地承认自己只是一个起点。

选择 Microsoft-Decision-1，如果：你的输入是长文档而不是工单；你的部署关卡是 Azure 身份验证、统一计费和一套负责任 AI 方案，而不是一次下载；25 种语言就能覆盖你的流量；或者你压根不想自己拥有这个模型。请接受这一点：它的第一条校准曲线得由你自己来画，并为此在一份带标签的样本上留出一个下午的时间——因为与 Laya 不同，这个不会直接递给你一个可以拿来争论的 ECE 数字。