在当前软件系统与 AI Agent 的工程实践中，让大语言模型做分支路由、类别判定或布尔判断，几乎都遵循一套标准动作：让模型自回归逐字输出 JSON 字符串，再用校验器拦截格式错误。这套成熟流程虽然稳妥，却在每一次分支判断中浪费着大量的显存带宽与等待时间。
开源开发者 TheoLeeCJ 近日上线的实验平台 OpenJev，用一种极为克制的方式打破了这种惯性。该项目基于 WebGPU 和 wllama 3.6.1 框架，完全在用户的浏览器本地运行量化开源模型。它的核心改动只有一步：彻底抛弃逐字生成 JSON 的自回归循环，仅凭一次前向传播，直接读取预设选项 Token 的 Logits 并做归一化，将单次决策耗时缩短了 2.11 至 2.78 倍，在密集决策场景下的提速更达到 5.21 倍。这项实验证明了端侧决策无需沉重的后端推理集群，但也用硬核的测试数据，撕开了非校准模型在决策稳定性上的裂痕。
算力账本拆解：为什么让模型输出 JSON 是对显存带宽的空耗？
在传统的 Agent 工作流中，即便只是判断一封邮件属于投诉还是咨询，模型也要老老实实吐出二三十个 Token。大语言模型的自回归解码机制决定了，生成每一个 Token 都必须将几十亿参数从显存完整搬移到计算核心一次。这种受限于显存带宽的机械重复，构成了分支判断中最昂贵的延迟来源。
OpenJev 证明了这笔开销完全可以省掉。在分类与路由场景下，候选结果在提问前就已经收敛在固定选项内。项目在浏览器端挂载了三档量化 GGUF 模型：Qwen3-0.6B（Q8_0，639 MB）、MiniCPM5-2B（Q4_K_M，1.56 GB，桌面默认档）以及 Qwen3.5-4B（Q4_K_M，3.01 GB）。在 RTX 3090 与 Chrome 152 环境下的邮件分流实测中，传统自回归 JSON 与直接读取 Logits 的差距被清晰量化。
当决策密度进一步提升时，两者的性能分界更为剧烈。在原生 BF16 环境下执行 21 个共享上下文的连续二元判定测试中，Qwen3.5-4B 直接读取 Logits 仅耗时 1.023 秒且生成 0 个 Token；作为对比，自回归生成紧凑 JSON 数组耗时 5.332 秒，产生了 111 个 Token。直接读取方案跑出了 5.21 倍的物理提速，同时在这 21 项二元判断中，有 18 项给出了与逐字生成完全一致的最高概率选择。
客户端极简探针，与闭源 Jev 的本质分界
OpenJev 并非单纯的服务端脚本迁移，它的整套演示运行在极其干净的纯静态架构上。项目依靠 WebGPU、Web Workers 以及 wllama 3.6.1 跑在前端页面内，无后端服务器、无 API 请求调用、无数据库存储，也没有任何遥测代码收集用户输入，模型权重直接从 Hugging Face 静态缓存至本地。
这种架构的低成本部署让不少开发者感到兴奋，但其实现手法更像一个极巧的语法分类探针，而非底层张量级运算。浏览器端机制是调用 wllama 提供的单 Token 语法约束 Completion API，向模型请求前 20 个候选项的 Logprobs，同时对预设的 A 至 T 选项施加等额 Logit Bias，最后在选定选项之间执行一次 Softmax 归一化。
这也正是开源社区产生争议的技术分水岭。商业决策模型 TypeSafe Jev 由官方在 2026 年 9 月 15 日发文推出，宣称基于强化学习校准决策（RLCD）进行专项训练，锚定 GPT-6 Astra 与 Claude Fable 5.1 的共识概率作为基准。虽然 TypeSafe 迄今未公开模型权重，且在 4 个真实业务流中的平均一致率仅约 67.8%，但其核心卖点在于通过强化学习纠正了模型输出概率的系统性偏差。
省去自回归循环能带来数倍提速，但给通用模型套上分类探针并不等于掌握了决策校准。
OpenJev 显然不是开源版 Jev，它并未引入专有决策架构或 RLCD 训练管线，只是用开源通用模型外加语法约束，快速还原了类似的调用界面。两者的能力底色完全不同。
概率幻象与扰动陷阱：归一化数值并不等于可靠置信度
在 OpenJev 构建的 706 行主评估矩阵中（涵盖 144 个原创决策、256 个 WANLI 推理样本、102 个公开 TypeSafe 案例行及 204 个 Every 实验室工件），原生 BF16 模型在 TypeSafe 公开的 102 行子集上表现出与参数量高度正相关的表现：Qwen3-0.6B 一致率为 40.7%，MiniCPM5-2B 达到 63.7%，Qwen3.5-4B 则攀升至 84.5%，接近 TypeSafe 宣称的 88.3%。
但如果把这组跑分理解为模型拥有极高的决策把握，就会在落地时踩坑。OpenJev 团队在文档中直白承认，界面给出的概率只是限定在给定选项 Token 之间的条件概率，绝非统计意义上经过校准的置信度。模型只是在几个被圈定的标签之间做相对排序，根本不代表模型对这个答案的真实把握。
最扎眼的证据来自扰动鲁棒性测试。直接提取 Logits 的方案对提示词顺序极其脆弱：仅仅将给出的选项顺序颠倒，36 个测试用例中就有 10 个彻底改变了概率最高的预测选项；对判断准则进行同义改写，有 9 个用例改变了最高选项；甚至只是加入无关上下文，也有 4 个用例翻车。当模型对位置与细微措辞如此敏感时，界面上浮现的 90% 概率，在工业级流水线里就会演变成无法预测的生产事故。
除了算法层面的脆弱性，端侧环境的硬边界同样不容忽视。目前浏览器内运行的模型受到 2048 Token 的上下文截断限制，单次只支持最多 20 个选项分支；而在 WebGPU 跨引擎支持上，WebKit（Safari）的执行耗时实测比 Chrome 慢了近一倍，碎片化的硬件环境决定了它短期内更适合充当离线实验场。
- 提醒.直接读取 Logits 虽能规避解码开销，但顺序扰动翻车率接近 28%，在缺乏后验校准的前提下，绝不能直接将其作为高风险分支路由的置信依据。
OpenJev 的真正贡献，是为系统工程师卸掉了大模型决策必用 JSON 的思维枷锁。它清晰勾勒出一条演进路径：在云端，服务端推理框架如 vLLM 或 Ollama 完全有必要开放原生的单步 Logits 分支接口，取代沉重的结构化解码；而在边缘端，伴随轻量模型素质的提升，在前端零延迟完成确定性任务分流已非天方夜谭。但在开源社区真正拿出成熟的 RLCD 权重校准方案之前，这笔省下来的算力账单，仍需要开发者用严密的业务防线去谨慎对冲。