StartLux登顶决策模型榜：中国挑战者入局Jev赛道
作者｜林绮蓓编辑｜蔡芳芳Jev 此前的走红，让一类专门为 AI 系统提供判断结果的决策模型进入开发者视野。与通常生成一段文字回答问题的大语言模型不同，决策模型接收当前状态和候选选项，直接给出各个选项的概率，供 Agent 或其他程序决定下一步行动。如今，这个赛道迎来了一位中国挑战者。10 月 16 日更新的 Huggi
Jev 之前火起来，让一类专门给 AI 系统提供判断结果的决策模型走进了开发者视野。这类模型和常见的大语言模型不一样——后者是生成一段文字来回答问题，而决策模型接收当前状态和候选选项，直接输出各个选项的概率，交给 Agent 或其他程序去决定下一步怎么走。
现在，这条赛道上多了一个中国挑战者。
Hugging Face Decision Index 0.3.2 榜单 10 月 16 日更新，中国团队 StartLux 的 27B Instant 模型以 69.12 分排在 174 个参评条目第一。公开基准、同类能力私有测试、新领域私有测试这三部分，它都是第一。
团队此前公布的 Decision Index 0.3 公开评测里，StartLux-Decision-27B-AutoThink 拿到 73.37 分；Jev 托管版是 57.96 分，前者相对领先约 27%。
这次发布还带来另一个变化：模型开始学着自己判断，什么时候该多想一想。
StartLux 给出了 Instant 和 AutoThink 两条路线。Instant 靠一次计算就快速输出概率；AutoThink 则看初始判断的置信度，再决定要不要启动额外推理。
至于推理何时启动、又该怎么及时收尾，StartLux 提出了 RLCD² 强化学习方法。按团队的说法，目的是提升决策概率的质量，同时压住不必要的推理开销。
这次更新也引出一个更值得聊的问题：AI 系统越来越频繁地调用模型去做任务路由、权限判断和工具选择，那模型给出的概率到底靠不靠谱？多加推理，又能把最终决策改善到什么程度？
最新榜单进一步验证了 StartLux 的领先位置。10 月 16 日的 Decision Index 0.3.2 榜单上，27B Instant 综合得分 69.12，排在其余 173 个参评条目之前。拆开看，公开基准测试 72.88 分，同类能力私有测试 64.82 分，新领域私有测试 61.41 分，三部分都是第一。
团队公布的评测里，StartLux-Decision-27B-AutoThink 以 73.37 分超过 Jev 托管版的 57.96 分，相对高出约 27%。不过把成绩拆细了看，StartLux 和 Jev 的差距，并不完全来自新增的推理能力。
同样是 27B 规模的 Instant 版本，不生成显式推理过程，在 DI 0.3 公开子集上就拿到 72.83 分，跟 AutoThink 只差 0.54 分。也就是说，在这套综合测试里，StartLux 走直接判断这条路，成绩已经高过 Jev。
这种优势在小模型上同样存在。2B Instant 得 59.14 分，略高于 Jev 托管版的 57.96 分；4B 和 9B Instant 分别是 67.88 分和 69.96 分。从 0.8B 到 27B 五个规模，StartLux Instant 都超过了参评的同规模最强第三方决策模型，分数优势大约在 7.4 至 16.9 分之间。
Instant 已经拿到这样的分数，AutoThink 多加的推理能力又带来了什么？团队提出的另一项基准 DecisionPivot 给了更具体的观察角度：一道题的关键条件变了，模型能不能看出变化，并跟着调整答案。
在这类任务上，Instant 和 AutoThink 的差距明显拉大。27B Instant 的成对准确率是 75.4%，AutoThink 达到 86.9%，高出 11.5 个百分点。作为对照，Jev 托管版为 31.0%，Decision 3.0 d3 为 71.3%，Perplexity Decider v1.1 为 70.1%，低推理强度的 GLM-5.3 为 82.2%。这些结果说明，在需要识别和处理关键条件的任务里，额外推理带来的收益更明显。
这次 StartLux 提供了 Instant 和 AutoThink 两条不同的决策路线。开发者把当前状态、问题和候选选项输入模型，模型返回各选项的概率。任务路由、工具调用、权限判断这些场景里，程序就能依据这些概率挑下一步动作。两条路线的关键差别，在于模型要不要生成额外的推理过程。
Instant 有 0.8B、2B、4B、9B、27B 五种规模，一次前向计算就输出选项概率，不会先生成一段推理文字。为了把完整输入用足，Instant 在全注意力层采用双向注意力，让前面的内容也能结合后面的问题和选项一起算，从而提高单次决策的准确率。
这样的设计也让它适合高频决策场景。团队公布的推理测试显示，在单张 NVIDIA H200 GPU 上，用 vLLM、单个并发请求，0.8B 至 27B Instant 模型的单次请求中位延迟约为 25 至 52 毫秒。这组数字来自特定硬件和测试配置，实际延迟还会随输入长度、部署环境和并发负载变化。
AutoThink 覆盖 4B、9B 和 27B，保留了生成推理所需的因果注意力。它先算出各选项的初始概率：最高概率达到阈值，模型就直接返回；没达到，才生成推理过程，再算一次概率。系统最后把两次结果融合，默认推理后的结果占 75% 权重，初始结果占 25% 权重。
启动推理的阈值由开发者自行调整，这是该机制的关键所在。目前服务默认取0.6，而论文里公布的主要AutoThink成绩用的是0.9。阈值定得越高，初始判断就越难直接过关，模型进入推理流程的可能性也就越大。仓库里有一组对照实验：27B AutoThink的阈值从0.9降到0.6后，DI 0.3得分从73.22掉到72.85，DecisionPivot成对准确率则从88.1%跌至68.4%。
这组数据点出了按需推理的一个取舍：少推理对综合评测分数的影响或许不大，可一旦任务需要识别复杂条件，性能下滑就会更明显。所以开发者选阈值时不能光看总体榜单，还得掂量实际任务的复杂度，以及漏掉一次必要推理会带来什么后果。
团队还统计了模型在DecisionPivot核心任务上的实际决策过程。7800个样本中，27B AutoThink直接作答的占39%，这部分准确率96%；剩下61%进入推理流程，准确率从初始判断的57%升到融合后的93%。在这些触发推理的问题里，系统改对了1783个初始错误，也新添了94个错误。这里说的“思考”专指生成额外的显式推理过程，并不代表Instant完全不做计算或判断。更关键的是，触发条件依赖模型自身的初始置信度——如果它一开始就对错误答案信心很足，照样可能跳过推理。按需推理因此无法从机制上根除过度自信。
为展示决策模型怎么用，StartLux公布了几个演示。一段国际象棋演示里，初代StartLux-Decision-v1-27B执白对Jev 1.13，第19回合完成将杀，双方都没用搜索。团队还把它用于《星际争霸Ⅱ》人族机器人的战略决策，并展示了战胜内置Hard AI的结果。
连续视觉决策演示比游戏任务更能体现这类模型在动态环境中的用法。火箭发射演示中，模型依据连续画面识别尾焰、烟雾、发射塔和飞行阶段的变化，逐帧回答九个决策问题。洪灾救援演示则要求模型持续跟踪救援人员、幸存者、吊索和救援篮的位置与状态，据此更新对救援进度和任务优先级的判断。
模型判定某题需要额外推理之后，还有一道难题：该生成多少推理内容，又该在何时收手？推理过程越拖越长，答案即便更准，快速决策的意义也可能被消磨掉。
为此，StartLux团队提出了RLCD²强化学习方法，全称Reinforcement Learning for Calibrated Deliberative Decisions。它不只奖励正确答案，更看重生成的推理能否提升决策概率的质量，同时对超出软长度预算的推理加以惩罚。
RLCD²排在训练流程的最后。在此之前，团队先用监督微调和决策样本训练打下基础判断能力，再用推理监督样本教AutoThink生成并结束推理，最后才用强化学习打磨推理质量和生成长度。论文披露，基础训练涉及不同规模的百万级样本，AutoThink的推理监督阶段用了约4000至21000条样本。
具体训练时，团队留一个参数冻结的模型副本充当评分者，比较推理前后的选项概率，用概率评分规则衡量推理带来的改善。生成推理的模型则不断更新参数，学着分辨哪些推理真能改善判断，同时压掉不必要的生成长度。评分者固定不动，训练过程就能以相对稳定的标准衡量推理收益。
团队在2986个留出样本上测试了强化学习前后的模型，每题都启用推理。9B模型在生成限制内正常结束推理的比例从45.9%升到93.9%，平均推理长度从2494个Token降到868个，减少约65%；最终答案准确率从80.38%变为80.48%，基本没动。
可见在这组实验里，RLCD²的主要收益来自推理效率，准确率并未大幅提升。不同规模模型的效果也不一致：27B模型在DecisionPivot上的成对准确率由强化学习前的87.2%变为86.9%，略有下滑；9B模型则从53.3%升到59.9%。更准确的说法是，这项方法能改善推理长度和结束行为，总体上维持决策性能，但不保证每个模型的准确率都往上走。把比较范围扩到“完全关闭推理”和“按需启动推理”，额外计算的价值就更清楚了。团队保持AutoThink模型不变做对照：9B模型在DecisionPivot上的成对准确率从22.3%升至59.9%，平均每题多出1365个推理Token；27B模型从48.0%升至86.9%，平均每题生成304个推理Token。平均值包含未触发推理的题目，反映的是整个测试集上的平均生成开销。
有个现象挺有意思：27B模型参数规模更大，这组实验里却用更少的平均推理Token拿到更高的成对准确率。看来推理Token数量不能单独代表模型的决策能力。不过Token少也不直接等于运行成本低——27B模型每个Token的计算开销更高，实际成本还得看硬件、推理吞吐量和部署方式。
评测成绩之外，StartLux团队还盯着两个问题：条件一变，模型能不能跟着改判断？程序依据模型给出的概率筛答案、派任务时，这些概率还可靠吗？
StartLux 这次推出的 DecisionPivot 基准，头一件事就是看模型对关键条件变不变敏感。基准的核心由 13 类程序生成任务组成，样本共 7800 个，权限判断、调度冲突、工具调用有效性、目标状态验证这些场景都覆盖在内。它不满足于只查一道题答得对不对，而是改动问题里的关键条件，再看模型会不会跟着调整判断。
具体做法是成对准确率：一组对照题里所有案例都答对，这组才算正确。举例说，两道题只差一个关键条件，正确答案一个是“是”、一个是“否”。模型两次都答“是”，其中一道确实对了，整组照样不得分。这种设计能看出模型是不是偏爱某个固定答案，压根没随条件变化改判断。
为了让基准能被复核，团队把题目生成器、独立求解器、评分程序和数据哈希都公开了。核心任务的答案先由生成程序算出来，再交给独立求解器验证。
判断对错之外，还有个更贴近实际应用的问题：模型给出的置信度，真能对上它答对的概率吗？打个比方，Agent 系统拿模型置信度筛候选答案时，还能不能相信“90% 的把握”大致就是 90% 的正确率？
论文里有一项实验：团队用 9B 模型验证回答，独立回答场景下，置信度落在 80% 至 90% 区间的部分实际正确率有 92%；可系统从 32 个候选里挑出最高分回答后，同一置信区间的正确率掉到 78%。底层模型没变，筛选一过，置信度和实际正确率的关系就可能变样。
筛选答案并不必然拉低系统总体正确率。问题出在开发者身上：若还沿用单独回答时定的置信度阈值，就可能把筛选结果的可靠性估错。比如原先规定“置信度超过 90% 就自动执行”，经过候选筛选或多模型路由之后，这条规则未必还对应原来预期的错误风险。
对此，StartLux 给出策略感知校准。研究人员的做法是让带标签的校准样本先走一遍实际采用的筛选和路由流程，再依据返回结果的置信度及相关分数，拟合出新的概率校准映射。候选答案筛选这一环，过程里还会把候选数量、平均分等因素算进去，底层模型的参数不用动。
团队报告，在覆盖候选筛选、推理门控、级联调用等四类流程的 184 组设置中，校准后置信度与正确率之间的有符号偏差落在−2.7 至 +2.1 个百分点之间。但校准映射用到没见过的数据集上时，仍出现最高 6.1 个百分点的过度自信。可见策略感知校准能改善已评估流程里的概率可靠性，效果却不一定在新数据分布下保住。
目前 StartLux 已公开模型权重及推理代码，vLLM、llama.cpp 和 MLX 都能部署，还提供不同规模的量化版本。许可证限制得留意：推理代码走 Apache 2.0，模型权重用 CC BY-NC 4.0，只许非商业使用；商业部署要另外拿授权。
Agent 系统越来越多地接手工具调用、任务分配和权限判断，模型要交的不光是一个答案，还有这答案有多大把握、值不值得再投算力确认。StartLux 这轮围绕快速决策、按需推理和概率校准的研究，想解决的正是这些。
不过眼下的领先成绩，主要还是来自特定评测环境。DecisionPivot 给出了可验证的复杂决策任务，可程序生成的测试题和真实生产系统之间仍有距离。换到不同业务数据、调用负载和推理阈值下，模型的延迟、成本与错误率如何，还得靠更多实际部署来验证。对正在搭 Agent 系统的开发者来说，这类模型多了一种技术选择：让专门模型接下一部分高频决策，必要时再追加推理计算。它能不能真把系统可靠性提上去，说到底要看具体工作流里的表现。
代码、模型及论文链接：
- GitHub（推理引擎及评测）
https://github.com/StartLuxLabs/StartLux-Decision
https://github.com/StartLuxLabs/DecisionPivot
- Hugging Face 模型合集
https://huggingface.co/collections/startlux-models/startlux-decision-v11-autothink
- 论文：https://arxiv.org/abs/2610.1730
