AREX Feed Article
Google Gemma 称 vLLM 单步去噪可把 DiffusionGemma 变成 Jev-like 模型，读出置信度与概率分布
北京时间 9 月 30 日凌晨，Google Gemma 的称，可以用 vLLM 把 DiffusionGemma 变成一种「Jev-like」模型：在画布（canvas）里预置响应模板，vLLM 就能在单次去噪（denoising）步骤内，为 yes/no 问题、多选题和打分题提取置信度分数与概率分布。帖文称这「为结构化任务带来新一档的精度」，并称其「快速、高效、可以规模化」。紧随其后的一条致谢 vLLM 项目账号 @vllm_project 与 @mmastrac，并附上 vLLM 的 GitHub 链接。
被致谢的 PR #57250 由 mmastrac 提交，9 月 16 日创建，9 月 22 日合入 vLLM 主仓库；帖文介绍的机制已有合入主仓库的实现。这条帖文没有附任何基准数字，「精度」「快速」「可扩展」都是 Google 一方口径；可核查的测试数字则来自 PR 作者自测，以及 Google 账号和 Google Cloud 文章此前的发布。Gemma 账号此前也发过相关帖文，例如 ，以及 。
（图：vLLM 博客，自回归生成与 DiffusionGemma 画布去噪的对比：图中画布为 4 个 token 示例，真实模型一次处理 256 个。）
预置画布、单步去噪，再逐槽读出概率
DiffusionGemma 的生成方式与自回归模型不同。自回归模型每做一次前向只产出一个 token；DiffusionGemma 一次前向处理一整块画布，默认 256 个 token 位，用多轮去噪把随机占位符逐步收敛成文本（）。Jev-like 读取把这套流程反过来用：不让画布从噪声开始，而是预置成一份回答模板。
模板里放好固定文本（问题标签、格式符号），只把要作答的槽位留成噪声；请求再被限制为只跑一步去噪，并在步数上限到达时立即提交。这两件事对应 diffusion_max_steps=1 与 diffusion_read_only=true 两个请求参数。由于去噪阶段使用双向注意力，画布上每个位置都能同时看到完整上下文和其他所有槽位，因此一次前向就能给出每个槽位的分布（）。
（图：vLLM 博客，固定 256 位的画布上，每个去噪步骤重新采样全部位置，低熵位置保留模型的采样，其余位置重新加噪。）
读出的结果有两层：每个答案槽位返回 temperature 为 1 的 logprobs（对数概率），取最大值就是模型最可能的答案；该位置分布的熵被当作不确定度使用，熵高于阈值时可以追加若干次带噪声的读取，看多次结果是否一致，并给出标准误差（PR 说明与 vLLM 文档）。
约束同样明确：候选标签必须能编码成单个 token，否则画布会错位；多 token 的选项可以事先映射成单 token，例如把 moderation_spam 映射成 B。服务端会用分词器（tokenizer）校验模板里的每个标签。问题类型包括 noul（yes/no）、多选题 choice 与打分题 score，一个请求里可以同时问多道题。客户端不必自己拼画布：文档里的示例服务器会把问题 schema（问题定义）转成种子画布等字段。
被致谢的 PR：种子画布、只读请求，以及一次并发修复
PR #57250 的标题是「DiffusionGemma 模型的结构化生成模式（Jev-like）」。作者在说明里写道，DiffusionGemma「包含了构建 Jev-like 模型所需的全部组件」。这个改动往 vLLM 核心里加了三样东西：用固定 token 预置画布（diffusion_seed_canvas）、让只读请求在步数上限到达时直接输出按最大概率取定的画布并跳过额外的 commit（提交）前向（diffusion_read_only）、限制去噪步数（diffusion_max_steps）；顺带修掉一个 bug：两条并行请求的 logprobs 互相覆盖，会以 HTTP 500 收场。
它还接入了既有的 logprob_token_ids 校验：读取时可以点名要候选标签 id 的精确 logprobs，而不必等它们排进 top-k。按 PR 说明，26 个选项的场景里只有 1～8 个能进 top-k。
作者给出的自测数字是：单台 DGX Spark、32 行画布、每请求 3 个决策，单并发 8.7 req/s、延迟 0.12 秒；32 并发 54 req/s、延迟 0.58 秒，约合每秒 162 个决策。他在 PR 评论中补充说，跳过不扩散阶段的多余计算，可把决策耗时再降约 20%～40%。
（图：vLLM 博客，DiffusionGemma 的推理流程：编码器预填充、画布去噪循环、整块提交。）
另外，/v1/systemone（Jev 决策 API 的兼容端点）是 PR 附带的示例服务器，不是 vLLM 标准端点。9 月 23 日，vLLM 项目账号发帖宣布，并感谢 mmastrac 把工作推向上游。
DiffusionGemma：把整块画布一次算完的开放权重模型
DiffusionGemma 于 2026 年 6 月 10 日发布，是 Google 基于 Gemma 4 骨干构建的离散扩散语言模型：26B 总参数的 MoE（Mixture of Experts，混合专家），推理时激活 3.8B 参数（）。按 vLLM 博客的说法，它是 vLLM 原生支持的第一个扩散语言模型；按 Google 的说法，它把推理瓶颈从显存带宽转向计算，token 生成最高快 4 倍：RTX 5090 上 700+ tokens/s、单张 H100 上 1,000+ tokens/s，量化后可塞进 18GB 显存。
它同时是开放权重（open-weights）模型（把 DiffusionGemma 归入开放权重文本扩散模型的代表）。vLLM 博客提到，FP8、NVFP4 等量化检查点已发布在 RedHatAI 的仓库里。
这种「整块并行 + 双向注意力」的架构，是 Jev-like 读取成立的前提。Google Cloud 那篇文章说得直接：把扩散模型当聊天机器人用，就会错过它真正的能力，即在一个前向里评估整个输出结构。
「Jev-like」里的 Jev：只做决策的托管 API
Jev 是旧金山创业公司 TypeSafe AI 的第一个模型，这样介绍它：不聊天、不写文章，把非结构化的状态映射成带类型的概率决策，像一次由前沿模型支撑的函数调用。TypeSafe 把这类模型称为「System One」，取自丹尼尔·卡尼曼《思考，快与慢》里那种快速直觉的思考方式。它的 API 只有三种问题：Choice（从选项里选一个）、Score（放到有序刻度上）、Noul（是/否，名字来自伯努利分布），每个答案都附带一个可供代码分支的概率。
Jev 本身是托管 API，处于早期访问；截至 Red Hat 9 月 28 日文章发稿时，TypeSafe 没有公布权重、参数量或自托管方案。对受监管行业、气隙环境和主权部署来说，把每一次路由决策发往第三方端点并不可行；按 Red Hat 的总结，「他们需要的是模式，而不是依赖」。
开源社区此前在自回归模型上复刻过类似效果。Qwen 3.5 上的 Kev 项目需要自定义块状因果注意力掩码、专门的 <decide> 指针读出头，还要跑 LoRA（Low-Rank Adaptation）微调；而按 Google Cloud 文章的说法，如果模型本身就是离散扩散模型，就不必训练自定义读出头，也不必改写注意力掩码。
接口层面，vLLM 的示例服务器实现了 Jev 决策 API 的 /v1/systemone 端点，现有的 Jev 客户端代码可以直接指过来（Red Hat 文章与 vLLM 文档）。
数字、限制，以及被追问的校准问题
Google 自己给出的部署数字出现在 9 月 22 日的那条帖文里：Cloud Run 上单步延迟约 35～60 毫秒，batch@32 约 100～123 req/s；运行成本约 3 美元/小时，闲置时降到 0。Google Cloud 的实操文章另给了一组数据：把模型量化到 INT4 后（权重从 52GB 压到 16.1GB），部署在一张 24GB 显存的 L4 上，对 8 条运维告警做三题分类（要不要叫醒值班、归哪个团队、严重程度如何）；明确案例约 180 毫秒返回，含糊案例在触发补采样后仍低于 500 毫秒。
还有几处限制：决策模式目前需要 vLLM 的 nightly 构建，/v1/systemone 只是示例端点，请求格式仍在收敛（Red Hat）。文档还明确：FlashInfer 不能服务 DiffusionGemma，因为一个批次里会混合因果预填充与双向去噪，指定 FLASHINFER 会被拒绝。配套的两个后续 PR 里，约束读取（constrained reads） 已于 9 月 24 日合入，把种子画布扇出为多次噪声采样的 截至发稿仍未合并。Red Hat 一侧，DiffusionGemma 已是其验证过的模型，决策模式可在预览构建上评估，正式支持的端点与时间未定。
还剩一个统计问题。在这条新帖文下面，开发者 Abhishek Kothari（@thenightshipper）说，「单步读取很聪明」，但对真实的路由决策，他想知道置信度是否在留出样本上校准过：「当它说 0.8 时，它是不是在 80% 的情况下是对的？」如他自己所说，在用熵来决定哪些案例需要追加采样之前，这个答案很重要。