继 JEV 之后又一起量AutoTrust 一周连出两款霸榜模型GEV-26B-Decide 凭什么刷屏【免费下载链接】GEV-26B-Decide项目地址: https://ai.gitcode.com/hf_mirrors/autotrust/GEV-26B-Decide10 月初CSDN 上接连出现了十余篇围绕同一个模型的技术拆解文章从「50GB 到 17GB 的 NVFP4 量化奇迹」到「MTP 投机解码让思考提速 1.8 倍」再到「System 1/2 双系统架构深度解析」几乎把部署、量化、推理加速、架构原理全部讲了个遍。这个被社区当作「决策大模型样板间」来研究的主角就是 AutoTrust 继 JEV 之后推出的GEV-26B-Decide。它到底凭什么在短短一周内从发布走到刷屏本文不打算重复社区教程里的「跑起来」步骤而是沿着仓库源码与评测报告回答三个问题它和 JEV 的两次起量在数据上是什么关系为什么 AutoTrust 连续押注「决策」这个赛道以及这套打法对开源模型生态意味着什么。从 JEV 到 GEV一周内的两次起量数据说明了什么先把「起量」这件事落到数据上。仓库 README.md 里有一张家族对比表把 GEV-26B-Decide 与同一批任务、同一套场景下的 JEV-27B-VL、JEV-9B 放在一起任务GEV-26B-DecideJEV-27B-VLJEV-9Bcomputer use编号框 元素文本60 个任务95%95%95%每次点击耗时≈ 85 ms≈ 260 ms≈ 200 msrobot arm抓取与放置20 个场景40%75%50%每次机械臂决策耗时61 ms239 ms163 ms关键信息藏在细节里在 computer use 上GEV-26B-Decide 用85 ms/次点击达到了与 JEV-27B-VL 完全相同的 95% 成功率速度快了约 3 倍在机械臂上61 ms 的决策延迟让「看一眼、抓一下、放到托盘」的完整闭环只要 4–8 秒模型时间。也就是说这次的「起量」不是靠更高的分数而是靠同样的分数、接近一个数量级的延迟压缩——把决策延迟从几百毫秒压进几十毫秒是社区教程愿意逐篇拆解的根本原因。另一条线索藏在模型血缘里。README 明确写着GEV-26B-Decide 此前以autotrust/JEV-Gemma4-26B-A4B的名字发布权重完全一致。也就是说GEV 不是从零新训的模型而是 AutoTrust 把 JEV 的决策头方法论从 Qwen 系底座迁移到 Gemma-4-26B-A4B 底座上、完成系统化评测与工程化的产物。这种「换底座、通吃架构」的节奏让 AutoTrust 能在 JEV-27B-VL 热度未散时一周内无缝衔接推出第二款可用模型。时间线也印证了社区侧的两波爆发10 月 3 日仓库更新 computer use 与机械臂演示见 videos/computer_use_shop.mp4 与 videos/robot_arm_pick_place.mp4单步决策 60–85 ms 的数据首次放出10 月 7 日CSDN 开始出现第一波实操文章锦标赛策略处理 256 个选项、noul/score/choice三种决策类型、校准概率原理、自适应思考指南、视觉决策、机器人控制、256K 长文本10 月 8 日第二波爆发集中在 NVFP4 量化版本50GB → 17.1 GiB、24GB 单卡可跑、vLLM 一行命令部署、lm_head LoRA 补丁剖析、MTP 投机解码。一周之内从架构科普到量化原理、从部署教程到延迟优化全部齐了这本身就是一个项目「起量」的信号社区教程的密度通常与项目的工程完备度成正比——教程写得出来是因为源码里真的有那么些东西可以写。双系统决策为什么 AutoTrust 连续押注「决策」赛道回答这个问题之前得先看懂 GEV-26B-Decide 的核心架构。仓库把它做成一张清晰的表格它做什么输出System 1类型化决策yes/no · 2–256 选项单选 · 0–5 评分支持文本与图像提示最长 256K一次前向传播给出每个选项的校准概率自适应思考可选thinking: auto先跑 System 1置信度低于 0.8 时 System 2 介入校准概率System 2未修改的google/gemma-4-26B-A4B-it可选逐步推理文本 / 推理这套设计的精髓是**「只在需要时思考」**。serve_decide.py 中的调度逻辑可以直观地看到它的实现p1 await s1_dist(ctx, req.kind, parts, has_img, req.question, opts, strategy) probs, think p1, None if thinking on or (thinking auto and max(p1) tau): p2, think await s2_dist(ctx, req.kind, parts, has_img, req.question, opts, req.think_budget, req.return_reasoning, tmpl) probs _fold(p1, p2, prof[mix])System 1 先给出一版概率分布默认阈值tau 0.8只有领先选项的置信度低于阈值时才让同一个基座进入 Gemma-4 思考模式做推理思考结束后把 System 2 的答案分布与 System 1 的原始分布按p ½p1 ½p2折回。为什么要各占一半README 的解释很直白System 2 单独给出的分布接近 one-hot、过度自信等权混合才能在「保留 System 1 的校准度」和「获得 System 2 的准确率」之间取得平衡。这套机制的效果仓库用两组数据交叉验证。一组来自 reports/adaptive_validation_summary.json在 1,754 道非 Decision Index 题上数据集System 1自适应触发思考比例AQuA-RAT数学应用题68.189.053.9%LogiQA逻辑推理55.380.363.7%StrategyQA多跳问答68.078.771.0%MedMCQA医学66.771.752.3%OpenBookQA科学94.396.314.7%全部 1,754 题73.383.447.8%自适应模式只用 47.8% 的题量就拿到了「永远思考」方案 96% 的增益——这就是「思考是手段、不是目的」的工程化表达。另一组来自 reports/decision_index_adaptive.jsonKnowledge Reasoning 领域技能从 0.429 提升到0.602其中 GPQA Diamond 从 42.9% 涨到 78.6%CRUXEval 从 67.5% 涨到 90.7%MMLU-Pro 从 65.0% 涨到 84.6%BBH 从 75.0% 涨到 92.0%。决策指数balanced skill从 58.02 上升到62.48超过了对标竞品 TypeSafe Jev 1.13 榜单条目57.91。但更值得注意的是仓库把「思考不适用」的场景也测了一遍并如实写入报告。在分类、检索、工具路由领域思考几乎没有帮助甚至有害BANKING77 的 macro-F1 从 88.0 掉到 85.0System 2 经常用过度自信的错误答案推翻正确的 System 1ToolRet 的 nDCG10 只从 66.8 升到 66.9围棋类 ChessBench 的思考大多撞上 8,192 token 预算、读出的答案并不更好。连同 reports/thinking_games.json 里 Flappy Bird、2048、整局 Connect Four 的负反馈这些数据共同构成了一个诚实的结论思考只对「能按显式规则逐步校验」的问题逻辑谜题、数学、约束求解有效。这种「把坏消息也写进 README」的做法是它区别于多数营销式发布的另一个信号。双系统背后的工程单引擎部署、lm_head LoRA 与 NVFP4 量化架构再漂亮如果社区跑不起来「刷屏」也无从谈起。GEV-26B-Decide 的工程化设计恰好把传播的燃料备齐了。首先是单引擎双系统。serve.sh 只用一条命令拉起 vLLMexec python3 $MODEL_DIR/serve_decide.py --model $MODEL_DIR --served-model-name autotrust/GEV-26B-Decide \ --enable-lora --max-lora-rank 32 --lora-modules jev-decision$MODEL_DIR/adapter_vllm \ --logprobs-mode processed_logprobs --max-logprobs 256 --max-model-len ${MAX_MODEL_LEN:-65536} --enable-prefix-cachingSystem 2 就是未修改的基座走标准 OpenAI 接口System 1 是挂在jev-decisionLoRA 模块上的「决策头 骨干 LoRA」通过新增的POST /v1/decide路由提供。一个引擎、一套权重同时服务两种系统文本图像通吃。难点在于决策头被实现成lm_head 上的 LoRA而 vLLM 原本不允许 vocab 超过 258,048 的模型挂 lm_head LoRA——Gemma-4 的词典是 262,144。仓库的解法是直接给 vLLM 打补丁见 patches/vllm-gemma4-lm-head-lora.patch把 LoRA vocab 上限从 258,048 抬到 262,144并把 PEFT 的lm_head目标映射到 vLLM 的 logits processor LoRA 包装器上同时修复了别名模块去重问题对应上游 PR 的后移。这套补丁就是社区文章「打补丁让 vLLM 支持 lm_head LoRA」的出处——它让「决策头」和「思考大脑」能共享同一个推理引擎是单引擎部署成立的前提。其次是为跑得动而生的底子。config.json 显示基座是 30 层 × 128 专家的 MoE 结构每 token 激活 top-8总参数 26B、每 token 激活约 4B原生上下文 262,144 token256K决策头是一个 2,816 → 24 槽的 fp32 线性头soft-cap 30掩码掉未激活槽位后除以各类型温度再 softmax见 judge_config.json 与 calibration.json。System 1 在 B200 上单请求中位延迟约45 ms64 并发下每秒 257 次决策——这是社区 NVFP4 教程里「45ms 秒回」数字的源头。然后是社区 10 月 8 日集体发力的量化与加速。NVFP4 量化版把 3,840 个路由专家压到 4-bit50GB 权重降到 17.1 GiB让 24GB 单卡成为可能——这是「显存奇迹」类的传播点。而真正解决「思考太慢」痛点的是 MTP 投机解码serve.sh 里通过MTP1环境变量挂上google/gemma-4-26B-A4B-it-assistant草稿模型System 2 的单请求吞吐从 247 提到 438 token/s约 1.8–1.9×128 并发下从 7,072 提到 13,505 token/s。仓库的延迟报告 reports/adaptive_latency_summary.json 给出了量化收益Knowledge Reasoning 十项基准上思考中位延迟从13.4 秒降到 7.7 秒P90 从 32.9 秒降到 18.8 秒。思考模式仍然是延迟大户System 1 的 45 ms 在思考面前可以忽略不计但「能跑到」和「跑不动」之间被这套组合拳拉开了一条清晰的界线。刷屏背后的生态信号决策模型的边界被重新定义回到开头的问题这波刷屏对开源生态意味着什么有三点值得单独拎出来。第一开源模型第一次把「决策」做成了可消费的产品形态而不是推理的副产品。传统 LLM 的答案是文本你要自己去解析GEV-26B-Decide 的答案是一个校准过的概率向量——System 1 的 ECE 只有 0.035calibration.json 的校准拆分 ECE 约 0.002这意味着「80% 置信度」在统计意义上真的接近 80% 正确。仓库还专门提供了 calibration_gold.json按 ground-truth 答案校准的温度 1.214/1.098/1.000并建议「用置信度门槛confidence gating来闸控自动动作」时使用。概率输出 置信度闸控是智能体、机器人、自动化流水线能真正信任模型的前提——这也是 AutoTrust 连续押注该赛道的逻辑Chatbot 赛道拼的是文笔决策赛道拼的是可校验的输出协议。第二「决策头 底座 LoRA 量化 投机解码」证明了一条可复制的开源玩法。这套栈的每个环节都留下了可审查的源码证据决策头 24 槽布局与 verbalizer 都在 judge_config.jsonSystem 1 的 LoRA 配置r32、alpha64、目标模块正则在 adapter/adapter_config.json单引擎服务在 serve_decide.pyvLLM 补丁在 patches/vllm-gemma4-lm-head-lora.patch全部逐 episode 的演示结果沉淀在 reports/demos/cu_results.json 与 reports/demos/arm_direct.json。任何一个团队都可以把这套「底座不换、决策头另训」的配方搬到自己选的基座上。JEV 的 Qwen 底座版本、GEV 的 Gemma-4 版本已经先行验证了可迁移性——这比一个孤立的 SOTA 数字更有生态价值。第三也是容易被忽略的一点诚实披露正在成为开源模型竞争力的组成部分。README 的 Limitations 一节列得很具体HLE 上 System 1 低于随机水平8.4% vs 16.4% 随机基线且自信答错的题只有 1.6% 正确思考不改善分类与检索128K 以上上下文未测图像决策是零样本决策头只在文本上训练英语中心化不适合无置信度闸控的高风险决策。训练数据披露同样到位System 1 使用了部分测试基准的训练集拆分如 BANKING77、CLINC150因此明确声明「MMMU / MMMU-Pro 不是该模型的有效评测」。这种「自曝短板的 benchmark 报告」在刷屏时代恰恰是最稀缺的信任资产——它让 62.48 这个数字在读者眼里从「宣传材料」变成了「可复核的实验记录」。回到题目本身一周之内AutoTrust 用 JEV 与 GEV 两次起量靠的不是两个孤立的「霸榜数字」而是一套可迁移的决策架构System 1 秒答 System 2 按需思考、一套完整的工程化配套单引擎、lm_head LoRA 补丁、NVFP4 量化、MTP 投机解码以及一份敢把边界写清楚的技术文档。社区刷屏拆解的每一篇文章几乎都能在仓库里找到对应的源码行——这种「热度能追溯到代码」的项目才是真正值得跟进的起量。【免费下载链接】GEV-26B-Decide项目地址: https://ai.gitcode.com/hf_mirrors/autotrust/GEV-26B-Decide创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考