OpenJev 生态全景解析：当社区用 151M 参数在浏览器里复刻 Jev 的「System One」范式

admin@yesmiracle.net (万戈) — Mon, 21 Sep 2026 00:00:00 +0000

如果你看了上一篇 Jev 的深度解析，应该已经理解了 TypeSafe AI 为什么放弃文本生成——并行采样、RLCD 训练、数学保证的类型安全——这些让 Jev 在结构化决策任务上比 LLM 快 200 倍、便宜 400 倍。

然后有趣的事情发生了。

Jev 发布不到一周，开源社区里至少涌现出 8 个独立项目，试图用不同的技术路线复刻 Jev 的「System One」范式。 有人用 ModernBERT + GLiClass 搭了个 151M 参数的纯编码器决策引擎，在公开 Benchmark 上宣称超越了 Jev 本身。有人往浏览器里灌了个 Qwen3-0.6B，让任何人免费在本地 GPU 上对比直接 Logit 读取和逐 token 生成的差距。还有人用 Google 的 DiffusionGemma 做并行决策，单步推理达成 90.8% 的 Jev 一致率。

这不是开源社区在「山寨」一个 API。这是在用不同的技术栈验证同一个洞见：「AI 不需要会说话，会判断就够了。」

这篇文章系统地梳理 OpenJev 生态——从技术路线、性能数据到工程启示。

1. 全景图：八个项目，三条技术路线

OpenJev 不是一个项目，而是一个快速扩散的生态系统。我按底层技术路线把它们分为三类：

分类	项目	核心模型	参数	路线
编码器路线	OpenJev Verdict 1.4	ModernBERT-base + GLiClass	151M	双向编码器 + 分类头
	openJev-verdict-2.0	ModernBERT-base + 双通道	149.6M	编码器 + 双校准通道
	Laya（参考）	ModernBERT-large	421M	更大的编码器基线
扩散路线	JoshuaSP/open-jev	DiffusionGemma 26B-A4B	26B	扩散去噪 + Logit 约束
	razorback16/openjev	DiffusionGemma 26B-A4B	26B	同上的决策服务封装
LLM 路线	SemIf (workszop/openjev)	Qwen3-0.6B (GGUF)	0.6B	Browser WebGPU + Logit 读取
	zhihz/openjev	Qwen3-4B-Instruct	4B	本地 MLX 推理
	TheoLeeCJ/openjev	多种开放模型	可变	LLM 分类头读取
商业	openjev.sh	N/A	N/A	付费代理 + $JEV 代币

三条路线的哲学完全不同。下面逐一拆解。

2. 编码器路线：OpenJev Verdict——151M 的纯判断引擎

架构

Verdict 是当前最「认真」的 OpenJev 项目。它不是把 LLM 拿来改 Prompt，而是从零用编码器搭了一个纯判断模型。

核心组件：

ModernBERT-base（149.6M 参数）：Answer.AI 和 LightOn 联合研发的高效编码器，支持 8192 token 上下文，原生 unpadding，训练效率比旧版 BERT 高 4 倍
GLiClass 分类头：bi-encoder 架构，将文档和候选标签联合编码后计算相似度
RLCD 风格训练：用 Brier Score 等校准指标做优化信号

推理过程是非自回归的：输入文档 + 候选标签列表 → ModernBERT 单次前向传播 → 分类头计算所有候选的 Logit → Softmax 归一化 → 直接输出概率分布。整个过程 20–35 毫秒完成。

Verdict 1.4 的修复故事

V1.0 有几个低级但关键的工程缺陷：

Calibrator 没加载：推理引擎在独立运行时忘了加载 calibrator.json，实际上在用未校准的 temperature 1.0 瞎蒙
候选标签格式不匹配：GLiClass 基座来自自然语言推理（NLI），期望标签写成假设句（“It is {description}"），但引擎直接送裸名词短语
上下文窗口过大：训练数据的上下文平均 71 tokens，推理时却允许 1024，导致分布外漂移

V1.4 修复后，Standard 难度准确率从 62.5% → 69.4%（+6.9%），Hard 难度校准误差从 0.298 → 0.118（-60.4%）。这是一个很好的案例：即使架构对了，粗心的推理工程也能毁掉一切。

Verdict 2.0：151M 击败 421M

Verdict 2.0 在 LocalLLaMA/typed-decisions 这个企业级决策 Benchmark（2000 条金融/安全/客服/Agent Trace 数据）上交出了令人侧目的成绩：

模型	参数量	Top-1 准确率	Brier Loss	ECE	延迟
Verdict 2.0	149.6M	77.10%	0.0636	1.44%	~20-25ms
Laya	421.3M	76.60%	0.0660	—	~31ms
TypeSafe Jev 1.13	~150M	72.70%	0.1480	14.4%	~140ms
TF-IDF + LR	0	66.10%	0.1520	2.07%	~8ms
Verdict 1.0 基线	149.6M	26.10%	0.5851	42.09%	~35ms

几个值得注意的点：

Verdict 2.0 的准确率（77.10%）超过了 Jev 本身（72.70%）。但要注意：Benchmark 数据集是 LocalLLaMA/typed-decisions，不是 Jev 的 workflow evals。TypeSafe 明确拒绝在公开 Benchmark 上评测，所以这不是 apples-to-apples 对比。
TF-IDF + Logistic Regression 拿到 66.10%，说明这个数据集里相当一部分决策可以通过简单词频特征解决。Verdict 2.0 多出的 11% 来自需要深层语义判断的边界样本。
Verdict 2.0 的双通道校准（Correctness Head + Distribution Channel）把 ECE 降到了 1.44%，这是数学上比 Jev 更好的校准度。Jev 的文档里承认 ECE 约 14.4%。

但是：Verdict 2.0 目前只支持最多 25 个候选选项（24 + 1 弃权槽），而 Jev 支持 255。Verdict 的上下文窗口也受限于 ModernBERT 的 8192 token 位置编码。

编码器路线的根本局限

编码器方案的优势是快且便宜——一次前向传播决定所有事情。但它的上限也很清楚：

没有推理能力：遇到需要多步推导的决策（「如果 A 且 B 则 C」），编码器要依赖训练数据中的模式覆盖
不支持开放式输出：只能从预定义的候选中选择，不能动态生成新选项
语言能力受限：相比在数十亿 token 上训练的 LLM，编码器的语言理解有限
候选数量上限：25 vs Jev 的 255，差距明显

但如果结构化决策是它唯一的任务，这些局限可能根本不成问题。

3. 扩散路线：DiffusionGemma 做并行决策

JoshuaSP/open-jev 走了一条完全不同的路：用 Google 的 DiffusionGemma 26B-A4B（一种非自回归扩散语言模型）来做并行决策。

为什么用扩散模型？

DiffusionGemma 不是逐 token 生成文本，而是从一个随机噪声向量开始，通过多步去噪直接「涌现」出完整输出。这意味着它能在单步去噪后就读取 Logit 做出决策，而不需要走完整个扩散序列。

对比 Jev 的并行采样与 DiffusionGemma 的扩散采样：

	Jev	DiffusionGemma (1-step)
采样策略	专用并行架构	扩散去噪 + Logit 约束
单次决策速度	70-500ms	~150ms（含 H100 推理）
一致性	数学保证（原始 Jev）	90.8%（复刻 337 题）
类型安全	架构保证	约束解码保证
模型来源	私有训练	开放权重 26B

实测结果

项目作者在 20 个 Jev 公开用例的 337 个问题上做了对比：

Workflow	原始 1-step	分组 1-step	分组 2-step	原始 Jev
Agent 跟踪	78.8%	78.8%	80.8%	78.8%
客服	91.3%	82.6%	84.8%	89.1%
发票处理	92.8%	92.2%	94.0%	97.0%
安全事件	69.2%	73.1%	73.1%	80.8%
全部	88.4%	86.1%	87.8%	90.8%

分组 2-step 推理比原始方法快 4.85 倍、便宜 79%，正确判断只少了 2 个（337 题中从 298 → 296）。

关键发现：所有 408/408 输出都是有效的 typed answer，零格式错误。通过约束解码直接在 Logit 层拦截非法 token，格式合法性同样可以数学保证。

扩散路线的成本估算：$0.0361/千文档（H100 上），与 Jev 的 $0.042/M tokens 定价在不同维度上。

路线的意义

DiffusionGemma 方案证明了非自回归语言模型天然适合 System One 范式。扩散模型不需要逐 token 解码，可以在任意去噪步骤后读取已稳定的 Logit。这意味着：

如果你需要更高的判断质量，就多走几步去噪
如果你只需要快速决策，就 1-step 截断
同一个模型可以同时提供 System One 和传统的 System 2 生成能力

4. LLM 路线：SemIf——浏览器里的 Logit 读取实验

SemIf（原名 OpenJev，由 workszop 开发）是这个生态里最出圈的项目。它登上 Hacker News 首页拿到 556 票，245 条讨论。

核心思想

在浏览器加载一个 Qwen3-0.6B 的 GGUF 量化版本（~639MB），然后用两种方式比较同一个模型做决策：

Direct Readout：从模型的最后一层 Logit 中直接读取候选标签的归一化概率——单 token 读取，不生成任何额外文本
Generation：让模型自回归地生成一个 JSON 格式的概率分布——完全标准的 LLM 调用

结果一目了然：

指标	Direct Readout	Generation
延迟（RTX 3090）	0.704 s	3-5x 更慢
格式错误率	0%（数学保证）	需解析 JSON
是否需要 LLM 生成	❌ 单 token 读取	✅ 完整解码
是否需 GPU	是（WebGPU）	是（WebGPU）

SemIf 的页面设计了非常直观的交互：左边是 Direct Readout 的条形图显示每个选项的概率，右边是 Generation 的输出和计时。你可以自己添加/删除选项，实时体验差距。

关键发现：不是模型的问题，是范式的问题

SemIf 最深刻的洞察是：同一个模型（Qwen3-0.6B），通过 Direct Readout 和 Generation 输出的概率分布可以完全不同。因为生成路径需要模型「自我报告」概率——模型需要先想好答案，再把它写成 JSON——这个过程引入了额外的偏差和格式压力。

Direct Readout 则绕过所有中间表示，直接从最后一层的语义表示中读取该 token 的 Logit。它更快，而且不可能格式错误。

「这实际上是对 Jev 核心论点的直接证明：如果你只需要判断，不要生成文本。即使是非常小的模型（0.6B），直接读取 Logit 也能在结构化任务上给出有用的分布。」

5. 中文路线：zhihz/openjev

zhihz/openjev 是中文社区的直接回应。基于 Qwen3-4B-Instruct，用 MLX 在 Apple Silicon 上运行，支持中文和英文输入。

核心差异：

真正的双语：英文 + 简体中文，Prompt 和候选标签均支持
本地运行：Apple M3 + 16GB 内存即可
Web 界面：内置 UI 支持编辑示例、多问题并发、JSON 导出

但作者也诚实标注了当前的局限：

后端是 Qwen3-4B 的通用指令模型，不是专门训练的决策模型
问题目前是顺序执行的（共享上下文编码的并行化尚未实现）
没有宣称比直接调用 LLM 有精度或速度优势

这意味着 zhihz/openjev 更像一个工程演示——展示如何将 LLM 的输出约束为决策接口——而不是一个真正的「复刻」。

6. Benchmark 乱局：谁真的超越了 Jev？

OpenJev 生态里最热门的叙事是「Verdict 2.0 以 151M 参数超越 Jev」。但这个说法需要仔细拆解。

明面宣称	实际限制
Verdict 2.0 准确率 77.10% > Jev 72.70%	Benchmark 数据集 `LocalLLaMA/typed-decisions` 不是 Jev 的评估集
Verdict 2.0 ECE 1.44% « Jev 14.4%	Jev 的 ECE 来自其官方 jaggedness 文档，但 Jev 也在持续改进
Verdict 2.0 延迟 ~25ms < Jev ~140ms	Jev 的 140ms 包含网络传输，Verdict 的 25ms 仅是本地推理
Verdict 2.0 训练成本 $0（消费级 GPU 8.8 小时）	Jev 的 RLCD 训练成本未公开

TypeSafe AI 有一个明确的哲学立场：「不发布公开 Benchmark 成绩，也不鼓励社区用公开 Benchmark 对比。」 他们甚至写了一篇博客叫 Antibenchmaxxing，论述为什么以 Benchmark 为中心会扭曲研究。

所以「超越了 Jev」这个说法在工程上有趣，但在科学上几乎是不可验证的——除非有人拿到同一个私有评估集，或者 TypeSafe 开放他们的 Workflow Eval 集。

7. 三条路线的工程对比

维度	编码器路线（Verdict）	扩散路线（DiffusionGemma）	LLM 路线（SemIf/zhihz）
架构	纯编码器（非自回归）	扩散语言模型	自回归 LLM + Logit 读取
参数	149.6M	26B (A4B)	0.6B-4B
推理速度	~20-35ms	~150ms	~700ms-2s
GPU 需求	任意 GPU（6GB VRAM）	H100 80GB	RTX 3090 / M3
类型安全	数学保证	约束解码保证	约束解码保证
候选上限	~25	灵活	灵活
校准	专用双通道	未专门校准	原始 Logit 未校准
训练	需 RLCD 风格训练	无需（零样本）	无需（零样本）
语言	英文	英文	中英双语
可部署性	生产就绪	实验性	演示/教育

没有一条路线在所有维度上领先。选择取决于你的约束条件：

如果你要在生产环境中做高频率决策（>100 QPS）、GPU 有限、只需要英文 → Verdict 路线最务实
如果你需要零训练成本、最高判断质量、有 H100 资源 → DiffusionGemma 路线值得试
如果你要快速验证概念、做双语或教育演示 → SemIf/zhihz 路线最佳

8. 工程启示：为什么 OpenJev 生态会爆炸？

Jev 发布不到一周就出现 8 个复刻项目，这个速度本身就值得思考。

洞见一：「决策」是比「生成」更容易复制的接口

LLM 的「生成」能力依赖大规模预训练数据、RLHF 对齐、数万张 GPU。Jev 的核心创新是接口层面的——不是模型更强了，而是模型被迫输出的东西更少了。一旦理解了「单次 Logit 读取」这个 trick，任何 LLM 或编码器都可以装上这个接口。

SemIf 用 0.6B 模型证明了这一点。Verdict 用 151M 的编码器论证了「专用胜过通用」。

洞见二：TypeSafe 真正的护城河可能是 RLCD 训练数据

Verdict 2.0 的 Benchmark 成绩虽然惊艳，但它依赖的是 LocalLLaMA/typed-decisions——一个 2000 条的企业决策数据集。Jev 背后是 TypeSafe 自研的合成数据 pipeline，他们明确定义自己为「primarily a data research lab」。

数据，而不是架构，可能是这个领域真正的护城河。

洞见三：Agent 基础设施正在吃掉这些能力

OpenJev 生态快速膨胀的原因之一是 agent 开发者的直接需求。我在上一篇中提到 Jev 对路由层、护栏、验证的影响——OpenJev 项目正在把这些能力从 API 调用变成可部署的本地服务。

Verdict 2.0 明确列出了 MCP 工具选择、实时 Agent 护栏、高频率状态循环等场景。这不是巧合，这是 agent 基础设施在寻找自己的「条件判断函数」。

9. 总结：未来是属于 System One 的，但不会只有 Jev

Jev 的开创性贡献不是它的模型——而是它定义的接口。

这个接口——State + Questions → Typed Answers with Probabilities——可能会成为 AI 领域的 REST API：一个足够通用的契约，让不同技术栈在不同硬件上实现同一个承诺。

OpenJev 生态已经证明了三条独立的技术路线都可以收敛到这个接口上。未来 12 个月，我们很可能会看到：

编码器路线向更大上下文和更多候选发展（ModernBERT-large, 更长位置编码）
扩散路线通过更多去噪步获得更好的校准
LLM 路线作为「回退方案」——同一个模型同时提供 System One（Logit 读取）和 System 2（生成）能力
Agent 框架原生集成 System One 接口作为标准组件

这个领域正在发生的事情，不只是 Jev 被复刻——而是整个 AI 行业在重新思考：当模型不需要「说话」时，我们能省下多少成本、快多少？

答案可能是「两个数量级」。那个未来值得我们去建。

关于作者：万戈（Chengqi），AI Infra 工程师，前华为/万翼，现构建 MCPZERO（Agent 工具协议）、ClawGuard（Agent 行为安全）和 NanoRuntime（轻量级 Agent Runtime）。

OpenJev on AI博士 万戈