使用 DiffusionGemma 和一个用 Astra 构建的非常轻量级 harness 复制了 Jev。 由于这个 harness，幻觉率也精确为 0%。
在Jev发布的基准测试上达到了他们结果的 2% 以内，与 Jev 达到了 96% 的同意度。
JoshuaSP/open-jev 是一个实验性的推理框架，旨在利用扩散模型（DiffusionGemma）进行类型化 JSON 决策（Typed JSON decisions），并探索开源扩散模型在结构化判断任务上能否接近 TypeSafe AI 的 Jev 系统！
--
一个开源扩散语言模型用两步"擦除噪声"就生成了合法JSON，把闭源商业产品的速度优势撕开了一道口子！
大语言模型输出JSON还在一个字一个字蹦，有人已经换了完全不同的画法！
DiffusionGemma扩散语言模型通过预构建JSON画布冻结固定结构、在变量槽位注入噪声后一次性去噪，用1到2步生成合法typed JSON，在智能客服路由和文档分类任务上逼近TypeSafe Jev闭源方案的准确率，速度提升近5倍，GPU成本降低约八成。
扩散语言模型跨界生成文本的怪事
2026年9月16日，独立开发者JoshuaSP在GitHub上公开了一个叫open-jev的实验仓库，用Google发布的DiffusionGemma-26B-A4B-it扩散语言模型，在一张H100显卡上跑出了让结构化决策领域侧目的数字！
这就怪了，文本明明是一个字接一个字有严格顺序的东西，怎么能像画画一样整张画布同时去噪？
ChatGPT和Claude这类自回归语言模型生成文字的方式跟打字机差不多：自回归语言模型先读完整段提示词，然后预测下一个最可能的token，把这个token拼到末尾，再预测下下个token，如此循环直到输出结束。
这种逐字蹦的方式写散文、写代码、写诗都很自然，因为人类语言本身就是线性展开的，但是一旦任务变成"从三个选项里选一个部门名称"或者"判断这句话是不是在要求退款"，自回归的劣势就暴露出来了：DiffusionGemma的竞品ChatGPT明明只需要输出一个词billing或者一个布尔值true，却不得不先生成左花括号、引号、键名、冒号、空格，再小心翼翼地避免多打一个逗号或者漏掉一个引号。
更麻烦的是格式错误，自回归语言模型在生成JSON时经常犯低级错误：多一个逗号；少一个引号；把true写成True；在字符串里塞进换行符。开发者被迫在自回归语言模型外面套一层语法约束引擎，比如Outlines或者Guidance，每生成一个token就用正则表达式或上下文无关文法检查合法性，把不合法的token概率强行压到零，这种方案确实能保证输出合法JSON，但是每生成一个token都要跑一次约束检查，速度被拖得更慢，而且约束逻辑越复杂，token级别的遮罩计算开销越大。
JoshuaSP直接绕开了这条路，JoshuaSP让DiffusionGemma根本不"生成"JSON的固定骨架，而是提前把骨架焊死！
DiffusionGemma这个名字里藏着两个关键信息：Diffusion是扩散，Gemma是Google的开源语言模型家族。
扩散模型大家熟悉的是Stable Diffusion和Midjourney，它们从一团随机噪点里一步步"擦"出一张清晰图片。DiffusionGemma把同样的思路搬到了文本上：DiffusionGemma面对的不是一张像素画布，而是一串token序列，每个位置初始状态是词汇表里的随机噪声，经过若干步去噪后收敛成有意义的文字。
DiffusionGemma一次处理一整个256个token的“画布”，先给画布上所有位置填上随机垃圾，然后反复去噪，每次只保留模型最确定的那些位置，不确定的扔掉换新的再猜。这个机制跟你手机上用美图秀秀给老照片去噪是一个道理，只不过它去噪的对象是文本。
这种架构的关键区别在哪？自回归模型必须先输出“{”，再输出引号，再输出键名，再输出冒号，再输出值……每一步都依赖上一步的结果。扩散模型没有这种顺序依赖，它同时看到画布上所有位置，同时猜所有位置的内容，然后反复迭代收敛。
但是，这里有一个致命问题。扩散模型的并行去噪机制，天然不遵守语法规则。自回归模型生成JSON的时候，每一步都能被语法解析器卡住，不合法就不让它继续；扩散模型同时猜256个位置，你怎么卡？卡了一个位置，其他255个位置的分布全变了。
JSON画布怎么把结构冻住
open-jev的核心机制叫JSON画布（JSON Canvas），思路非常直觉：既然输出格式是固定的JSON结构，变化的只是几个字段的值，那就先把整个JSON的token序列铺出来，把不变的部分冻住，只让变化的部分参与去噪。
举个具体例子，假设任务是根据一段客户投诉文本判断应该转给哪个部门、是否要求退款，合法输出只有两种可能：{"department": "billing", "refund_requested": true}或者{"department": "technical", "refund_requested": false}。open-jev的json_canvas.py模块会先把这两个候选输出全部tokenize，然后逐位置对比：左花括号、引号、department、冒号、空格这些位置在所有候选里完全一样，直接冻结为固定token；而billing和technical占据的位置不同，这些位置标记为变量槽位，初始化为词汇表均匀随机噪声。
去噪过程只在这些变量槽位上发生，DiffusionGemma跑一步或两步扩散后，变量槽位的token从噪声收敛到某个具体值，最后一步用trie约束（trie constraint）从合法候选路径里挑logit最高的token。trie是一种前缀树数据结构，把所有合法选项的token序列组织成树状分支，DiffusionGemma在最后读出阶段只能沿着树上的合法路径走，这就从数学上保证了输出一定是预定义候选之一，根本不需要事后修补JSON格式！
JSON画布机制跟Outlines那套逐token语法遮罩的本质区别在于：Outlines是在自回归生成的每一步都做一次约束裁剪，open-jev是把约束提前编译进画布结构，去噪过程本身不受约束干扰，只在最后读出时一次性投影到合法空间！
一步去噪和两步去噪的精度账
open-jev在TypeSafe公司公开的Jev评测集上跑了一组对照实验。
Jev是TypeSafe推出的闭源结构化决策模型，专门做文档分类、工单路由、安全事件分级这类任务，TypeSafe官方公开了20个案例共408个决策问题。
JoshuaSP把这408个问题全部用DiffusionGemma重跑了一遍，对比一步去噪和两步去噪的准确率。
一步去噪的结果是86.1%准确率，337个有参考答案的问题里答对290个；两步去噪提升到87.8%，答对296个。作为参照，TypeSafe Jev闭源API在同样问题上的准确率是90.8%，答对306个，也就是说，开源DiffusionGemma用两步去噪跟闭源TypeSafe Jev之间只差3个百分点，而这3个百分点里还有一部分来自Jev独有的独立问题隔离机制和跨画布KV缓存复用，open-jev并没有实现这些功能。
但是速度差距是碾压级的：原始方案一个问题占一个序列，408个问题跑完花了248秒；分组JSON画布方案把同一个文档的多个问题塞进同一张画布并行去噪，两步跑完只要51秒，快了将近5倍；GPU成本从0.27美元降到0.056美元，降幅约八成。一步去噪更快，48.6秒，但准确率再掉1.7个百分点。
这就引出了一个非常实际的权衡：在智能客服路由、发票处理、安全事件分级这类场景里，3%的准确率损失换来5倍速度和80%成本下降，到底值不值？
分组并行把成本打下来
open-jev的parallel_canvas.py模块实现了一个关键优化：把同一个文档上的多个决策问题合并到同一张JSON画布里，让DiffusionGemma一次前向传播同时去噪所有字段的变量槽位。
具体来说，Jev评测集里有一个发票处理案例，一个文档上挂了十几个问题：发票金额是否正确；供应商名称是否匹配；税率是否合规；付款日期是否在期限内。原始方案把每个问题单独发给DiffusionGemma，每个问题都要重新编码一遍文档上下文，408个问题产生了221万个输入token。分组方案把同一文档的问题打包进一张画布，文档上下文只编码一次，输入token骤降到30万，直接砍掉86%。
JoshuaSP在EVERY_LAB.md里还记录了另一个吞吐量实验：用TypeSafe Every实验室的代码检索和客户声音数据集，每张画布包含6个布尔字段，batch size设为16，单张H100跑出了每秒30.41个文档、每秒182.44个判断的吞吐量，按H100每小时3.95美元计算，处理1000个文档的GPU成本只要0.036美元。batch size提到32和64时显存溢出，open-jev的harness会自动把batch减半重试。
但是分组并行有一个副作用：多个问题共享同一张画布的注意力机制，一个问题去噪时的token分布会影响相邻问题的logit，导致准确率跟单独跑略有不同。Jev的闭源架构据说实现了独立问题隔离，每个问题的推理互不干扰，这也是Jev准确率能高出3个百分点的原因之一，open-jev选择牺牲这点隔离性来换取吞吐量和成本优势，这个取舍在批量分类场景里通常是划算的！
open-jev追上闭源Jev还差多远
TypeSafe Jev的官方数据是20个公开案例全流程跑完只要8.87秒、API成本0.00846美元，而open-jev的分组两步方案要51秒、0.056美元。表面上看差距还有6倍速度和6倍成本，但这个对比并不公平：Jev的8.87秒是API端到端延迟，包含了TypeSafe内部的分支选择、工作流编排和结果聚合；open-jev的51秒是裸推理时间，包含了首次请求的画布构建开销和冷启动延迟，而且JoshuaSP明确声明没有实现Jev的自主分支选择逻辑和最终工作流决策。
更值得关注的是准确率曲线：Jev在发票处理任务上达到97.0%，open-jev两步去噪拿到94.0%；Jev在安全事件分级上80.8%，open-jev 73.1%。差距最大的安全事件分级任务恰好是选项最多、语义最模糊的场景，DiffusionGemma在一步去噪里很难把细微的语义差异映射到正确的trie分支上，两步去噪比一步多了一次自条件（self-conditioning）迭代，让DiffusionGemma有机会修正第一步的粗粒度判断，所以准确率回升了1.7个百分点，但继续增加步数的收益会迅速递减，因为扩散语言模型在文本上的去噪轨迹不像图像那样平滑。
JoshuaSP在仓库的RESEARCH_LOG.md里记录了一些被放弃的实验方向，包括用受限softmax分数做概率校准、尝试跨画布KV缓存复用等。受限softmax分数的问题在于DiffusionGemma的logit分布跟自回归语言模型完全不同，直接拿softmax出来的数字当概率用是不可靠的，这些分数只能做候选之间的相对排序，不能当贝叶斯后验概率解读，这意味着open-jev目前能告诉你billing比technical更可能，但不能告诉你billing的概率是87.3%，而TypeSafe Jev的商业卖点之一恰恰是输出校准概率！
一个没有解决的细节是：open-jev在408个问题里排除了54个没有参考答案的问题和17个参考答案并列的问题，实际评分基数是337而非408，而Jev的官方90.8%准确率是否基于同样的排除规则，JoshuaSP没有给出确切的对照说明，这个数字差距里可能藏着统计口径的偏差。