vLLM d3-ultra：26.09B 答完 255 题，SR-Text 87.2 分

一句话结论：vLLM Semantic Router 在 2026 年 10 月 26 日放出了 Decision 3.0 家族里体量最大的决策模型 d3-ultra，26.09B 参数、一次读取答完 255 个问题、SR-Text 拿到 87.2 分，但它的定位不是聊天，而是替你的系统做判断。

过去两年大模型的叙事几乎都围绕生成展开，多写几个字、多想一步、多调一次工具。但真实业务系统里最耗钱的一环往往不是生成，而是判断。一段用户请求进来，该转给哪个团队、这段文字里有没有隐私信息、截图里那个按钮在不在、这段视频里目标物有没有出现——这些问题传统做法是再调一次大模型，让它读一遍输入、写出答案、再解析答案。d3-ultra 想把这个环节换掉。

它不生成一个字的自然语言，只输出概率。给它一段文本或一段 JSON 状态，可以再挂上图片和视频，然后一次性提交一批问题：选择题给一个选项，是否题给出 yes 的置信度，评分题给分，Box 题在图像里框出位置，Track 题在整段视频里跟踪一个目标。模型读一遍输入，所有问题的答案都从这一次读取里出来，每个答案都带概率。

d3-ultra 是什么：一个只输出概率的多模态决策模型

它出自 vLLM Semantic Router 这个项目，仓库名叫 semantic-router，GitHub 上 6277 星、1082 个 fork，Apache-2.0 许可。d3-ultra 属于它的 Decision 3.0 家族，模型卡上的正式说法是 26.09B 参数，其中 0.46B 是视觉编码器，其余是文本骨干。上下文按每个问题计算，最多 131,072 个 token，超出直接报 max_length_exceeded，不做静默截断。

骨干不是自研结构。config.json 里 architectures 写的是 Qwen3_5Model，model_type 是 qwen3_5，64 层、隐藏维度 5120、SwiGLU 中间维度 17408、24 个查询头对 4 个 KV 头、head_dim 256。层类型排布是每 4 层一个全注意力层，其余是线性注意力层，也就是 16 层全注意力加 48 层线性注意力。vocab_size 248320，max_position_embeddings 262144。团队给 d3 家族换掉了传统因果掩码，改用 prefix_bidir 的双向注意力，让每个问题都能看到完整的状态。

它的答案不是从词表里采样出来的，而是走一套单 token 答案码。decision_config.json 里 format_id 是 d3-code-readout-v1，选项被编号成 A、B、C 一直到几百，读出层在最后一个位置对答案码的 logits 排序。选项可以给得很长，比如「点积主义，用纯色小点构成」这种描述，答案依然是那个短码。这套设计让概率是可比的、可校准的，也让路由器能把置信度直接接到下游规则上。

把它放进系统里意味着一件事：判断和生成解耦。判断这一步交给便宜的小模型或者一次专用推理，生成那一步仍然可以走最贵的大模型。类似把检索和阅读拆开、把分类和写作拆开的思路，在 Drex for Search 的路由实测 里已经能看到收益的形状。

一次读取答完 255 题：延迟实测

这是 d3-ultra 最值得看的地方。官方在单张 AMD Instinct MI325X 上用 AutoModel 跑了从 1 题到 255 题的阶梯测试，结果是每多一个问题只多花 7.3 毫秒左右。

换算下来很直观：一次判断 304 毫秒，255 个判断 2.16 秒。如果这些判断拆成 255 次独立调用，光模型前向就是 255 乘 304 毫秒，约 77 秒，差 36 倍。当然拆开调用还能并行，实际差距没有这么大，但读一遍省下来的那部分输入编码开销是实打实的。

问题数量本身也有代价，主要是提示词变长。官方记录里，同一个请求的输入 token 从 1 题的 380 个涨到 255 题的 16764 个，增幅 13% 到 33%。这意味着问题写得像散文一样长会明显拖慢速度，选项描述要尽量精炼。

SR-Text 87.2 分：六个决策模型的横向对比

官方自建了两套测试，都不公开。SR-Text 是文本决策集，含 10411 个请求、73495 个问题。绝大部分题目重造了 34 个公开基准的技能，换成新题，分在知识与推理、语言理解、检索与分类、工具与自动化、艺术与审美五个能力域；另外 4896 个问题来自 43 个专门为这套测试写的任务族，比如评估 SQL 查询和表格公式、匹配发票、按用量计费、给客服工单分派。计分方式是六部分的均值，每部分是随机基线校正后的准确率乘 100，0 分等于瞎猜，100 分等于全对。

领先幅度不算碾压，2.1 分对 GLiDE V1.2、4.1 分对同门 d3-turbo。但分布有信息量：d3-ultra 在五个能力域里四个第一，唯一落后的是艺术与审美，d1-ultra 90.8 对它 89.6，官方说在测试误差范围内。新任务域那一列差距拉得最开，67.4 对 60.0 对 58.5，说明它在这批专门设计的任务族上确实更有优势，而不是靠刷公开基准的题。

测试方法上有一处值得留意：GLiDE V1.2 用公开模型文件在官方自有硬件上实测，测的是 2026 年 10 月 23 日；Jev 1.14 走 TypeSafe 的 API，版本锁定在 jev-1.14.0；d1-ultra 走 Liquid AI 的 API，没有版本锁定，测的是 10 月 26 日。Jev 的 10411 个请求里有 86 个返回无效答案，SR-Box 的 5678 个问题里有 816 张图被 API 以尺寸原因拒绝，这些一律算错。

SR-Box 落后 1.8 个点：图表强，自然图像弱

SR-Box 是视觉定位测试，5678 个 Box 问题对应 4984 张图。4778 个问题问的是图中确实存在的东西，分在照片、艺术、指示表达、票据、文档、界面截图、图表等十个域；另外 900 个问题问的是图里没有的东西，这部分不计入分数。框与参考框的 IoU 达到 0.5 才算对，最后取十个域的正确率均值。

这里有个反直觉的地方。去掉图表之后，d3-ultra 掉到 54.6%，和 d3-turbo 的 59.6% 差 5 个点。十域均值只差 1.8 点，说明图表这个域它是领先的，自然图像域它反而落后。官方的解释是 d3-turbo 在自然图像上更强，而 d3-ultra 在图表上更强。

结论很直接：如果你要做的是界面元素、图表里的柱子、票据上的字段定位，d3-ultra 更合适；如果要做的是自然照片里的物体框选，同门的 d3-turbo 仍然更强。另外注意 GLiDE V1.2、d1-ultra、d3 这三个模型不支持 Box，是能力缺失，不是零分，别把表格里的空位读成落后。

家族全尺寸与显存账

Decision 3.0 是一个家族，不止一个尺寸。vllm-project/semantic-router 的内置模型注册表里列了全部八个成员的加载参数量与最低设备显存要求，这张表比任何跑分都更能说明选型边界。

三个 26.09B 成员的加载参数量完全一样，都是 260.87 亿，最低显存都是 72 GiB。差别在训练与数据分布上，而不是规模。d3-ultra 的权重 revision 是 2f9a5e5e，d3-turbo 是 689b3af1，d3 是 cbff3a3c，三个包各自固定到具体的提交哈希，模型文件的 SHA-256 也逐个记录在注册表里。

如果 72 GiB 显存的门槛吃不消，d3-mini 以下的尺寸是更现实的选择。官方在 2026 年 10 月 11 日的一篇博客里详细写过 d3-lite、d3-nano、d3-mini 转 Core ML 之后在 M5 Pro 上的表现，JevBench 公开套件的准确率转换前后基本持平（d3-lite 73.2% 到 74.0%，d3-nano 75.3% 到 75.8%，d3-mini 81.8% 到 81.8%），单请求中位耗时从 204 毫秒降到 53 毫秒、173 毫秒降到 69 毫秒、438 毫秒降到 169 毫秒。代价是下载体积，3.7 GB、10.5 GB、19.6 GB。

部署方式、定价与官方复现记录

四条路。Transformers 侧用 AutoModel.from_pretrained 加载，需要 transformers 5.17.0，配套可选的 flash-linear-attention 加速包。vLLM 语义路由引擎的 vllm-sr serve -e 命令在 10 月 25 日的 PR 5449 里加入。官方还提供免费 API 和一个 Hugging Face Space 演示。定价上 d3-ultra 与 d3-turbo 都是免费 API 加自建，GLiDE V1.2 与 Jev 1.14 按每百万输入 token 0.04 美元收费。

官方在 2026 年 10 月 25 日留了一份运行记录文件，专门核对路由运行时给出的输入和包自带运行时给出的输入是否完全一致。结果是 1575 个问题，token 差异 0、状态长度差异 0、温度差异 0。答案是按包运行时作为基准逐题比对，d3-ultra 单独跑的一致率 99.69%，16 个并发在飞时 99.94%，d3-turbo 是 99.88%。

这里出现一个和宣传口径不完全一致的点。官方模型卡给的延迟是针对图片的，1 题 304 毫秒、255 题 2.16 秒；而这份记录里的纯文本请求 1 题只要 58 毫秒，255 题 1.675 秒。也就是说图片才是重的那一项，纯文本判断便宜得多。用同一份记录横向比，d3-ultra 的文本延迟比 d3-turbo 高，除以 token 比之后落在 0.87 到 1.06 之间，也就是两者每 token 的成本基本持平，d3-ultra 慢主要因为它吃进去的 token 更多。

还有一个工程细节。d3-ultra 的 decision_config.json 比同类多声明了两个字段：prompt_layout 是 header-v1，会把纯文本请求的问题列表排在状态前面；temperature_by_questions 规定单题请求用 1.046 的温度，多题请求用 1.0。官方记录显示单题请求在 1.046 下的平均差距是 0.0026，而包运行时统一用 1.0 时是 0.0057，差距更小说明更确定。另外，一个请求自己的前向计算受内核上限约束而不是受 max_num_batched_tokens 约束，所以在 32768 的批 token 上，上述延迟变化不超过 6%，长状态不需要更大的批预算。

常见问题

d3-ultra 和直接调一个大模型问答，差在哪

差在三处。速度上，判断被压缩成一次读取加一次读出，不需要自回归生成，几十毫秒到几百毫秒就能出概率。成本上，输出只有答案码的 logits，不生成文本，token 消耗接近于零。工程上，概率可以直接接进规则系统做阈值判断，这一点和 AI 网关基准里测到的路由收益 是同一类账。

72 GiB 显存是不是太高了

对多数团队确实高，这是 d3-ultra 的实际门槛。家族里 d3-mini 只要 16 GiB、d3-flash 32 GiB、d3-lite 和 d3-edge 只要 4 GiB，而 d3-lite 已经转成 Core ML 可以在 Mac 本地跑。更省的路是先用小尺寸跑通逻辑，把最难的判断再路由到 26.09B 那一档。

这些评测分数能直接横向比吗

不能直接当成公共榜单。SR-Text 和 SR-Box 都是团队自建且不公开的测试，同一个模型在别的评测集上表现会不同。可比的部分是同一套测试内部的横向对比，因为所有模型用的是相同题目和相同打分器。跨模型比的时候还要看接入方式，GLiDE V1.2 是本地跑文件，Jev 1.14 和 d1-ultra 走的是别人的 API，后两者连版本都没完全锁定。

小结

d3-ultra 的价值不在于它比谁聪明，而在于它把判断这件事从生成流程里拆了出来，并且拆得足够干净。一次读取，255 个问题，2.16 秒，每个答案带概率，这套接口形状对做路由、做审核、做分流的后端系统是直接可用的。

选型上的取舍也很清楚。文本决策能力最强是它，72 GiB 显存是它，自然图像定位不如同门 d3-turbo 也是它。工具与自动化这个能力域 97.8 分、检索与分类 97.7 分，说明它最擅长的恰好是工程系统里最常见的那两类判断。

相关阅读

• Drex for Search 深度：6 基准省 62% 步数，搜索前先决策
• Keln 网关基准实测，缓存命中 93.9%，四家 AI 网关跑 3360 轮
• Cohere Rerank 5：BRIGHT 82.2 分，token 省 35%
• Cloudflare 发布 Clairic：文档提取 AI 让代理链路快 3 倍