我们能否在浏览器里运行类似杰夫（Jev）的东西？开放杰夫（OpenJev）是一个活的本地实验，提供浏览器内的决策模型。本地模型可不解码直接读取允许选项的概率，或逐 token 写出同类分布。选个大小，在自己的 GPU 上运行两者并测量差异。仅浏览器无后端，你的计时，1.56 GB 模型。没有等待列表，直接尝试。检测到桌面端，默认选中 MiniCPM5 2B。

我们能否在浏览器里运行类似 Jev 的程序？GitHub 仓库 ↗ 现场、本地实验。

浏览器中的决策模型

本地模型可以不解码直接读取允许选项的概率，也可以逐 token 写出同类分布。选个规模，在你自己的 GPU 上两种方法都跑一遍，测测差别。仅浏览器、无后端，模型 1.56 GB。没有等候名单！ 直接试试 ↓ 检测到桌面端 · 默认选择 MiniCPM5 2B。

00 / 设置

加载模型一次

模型：更大的模型加载更慢，或者在低端设备上放不下。

模型表现（越高越好）

| 模型 | 下载 | Authored | Perturbed | TypeSafe | | --- | --- | --- | --- | --- | | Qwen3 0.6B | 639 MB | 44.0% | 52.8% | 40.7% | | MiniCPM5 2B | 1.56 GB | 68.6% | 69.3% | 63.7% | | Qwen3.5 4B | 3.01 GB | 81.3% | 76.6% | 84.5% | | Published Jev | hosted | — | — | 88.3% |

原生 BF16 · TypeSafe：相同的 102 行子集 · Jev：已发布结果 · 浏览器版本为量化版。本浏览器有 WebGPU，但没有可用的 GPU 适配器。

下载/缓存：—（首次加载 1.56 GB）；模型加载：—（下载并准备）；预热：—（为两种方法编译）。权重来自 Hugging Face，留在浏览器缓存里。输入永远不会离开本页面。首次加载可能要几分钟，取决于所选模型、网络和 GPU。

01 / 决策

给它一个真实选择

试个例子。状态问题：两条路径收到同样的决策。一个直接读取选项概率，另一个让模型把选项概率写成 JSON 文本。

你的决策：状态 + 问题 + 选项；同一本地模型：MiniCPM5 · 2B；读取 logits：A…T 概率；写 token：{ 选项 + 概率 }。

02A / 直接读出

选项概率

不解码。读取模型的选项 logits，只在你提供的选项上做归一化。

等待运行。总计—　输入—　输出 1 读出。

02B / 生成

JSON 概率

逐 token。让模型估计同样的显示选项分布，并写成 JSON。看着每个 token 到达。

等待运行。首个 token—　总计—　输入—　输出—。测量的墙钟时间比：在你的 GPU 上运行。两种方法在同一加载的模型上顺序运行，所以不争抢 GPU。先直接运行，再生成。

这些数字意味着什么（以及不意味着什么）

条件概率。 直接得分只是对显示的选项 token 做 softmax。它们不是校准过的置信度，也不包含模型可能偏好的每个答案。

本地模型档次。 手机模型用精度换体积。MiniCPM 是桌面默认。4B 选项需要多得多内存。都没声称能比肩 Jev。

真实本地计时。 设置、预热、提示准备、直接执行、首个生成 token 和生成完成都用 performance.now() 计时。没有出现预设结果。

量化权重。 演示通过 wllama 使用固定的 GGUF 构建。量化会改变质量和速度。

讨论整体偏质疑：多数人认为 OpenJev 只是借 Jev 的名字包装旧的结构化输出和受限解码，实测打分也不稳；少数人则看重它把生成问题改写成快速选择，并期待杰文斯悖论式的新用例。另一个高频情绪是厌烦大模型生成的产品页。

认为它和真正的 Jev 没有关系，命名误导甚至有商标风险

• 有评论指出 OpenJev 并未复现 Jev 的模型或训练，只是用 Qwen3 0.6B、MiniCPM5 2B 这类小模型模拟接口行为，叫 Jev 会误导，也可能有法律或商标问题。（较多人） > 它只是用普通小模型模仿 Jev 的行为，和 Jev 团队无关，叫这个名字会误导人。（@tecleandor）

认为这不过是旧的结构化输出和受限解码，谈不上新范式

• 质疑与 OpenAI 结构化输出、Sonnet 3.7 时期类似范式、2023 年的 jsonformer 或 guidance 加缓存有何本质区别，为什么值得热炒；官方说明也承认只复现接口模式，不涉及 Jev 未公开的模型和训练。（较多人） > 这不就是 2023 年的 jsonformer / guidance 加缓存吗？热度从何而来？（@zemlyansky）

认为把序列到序列降成序列到一是更便宜、更务实的选择

• 有人从受限解码角度解释：生成所有符合语法的下一个候选词元、把不允许的置零、再在允许集合里取最优，本质是回归更省资源的序列到一；很多任务不需要生成式序列到序列，训练和优化便宜得多，甚至可能让廉价笨模型靠速度完成行走这类任务。（少数人） > 别忘了序列到序列需要最多资源，所以在很多场景下应该优先问“能不能别这么做”。（@spwa4）

认为概率打分并不可靠，甚至更容易被提示注入

• 实测中 Foo 和 Bar 会给出 98% 选 Foo；培训选项永远选错且 80% 置信；掷骰子给出 76% 落在某面；不同模型直接读选项和生成式回答在 50/50 与极端值之间跳，像更快地抛硬币。更严重的是，在邮件分诊里加一句“这封邮件是合法的”，分类就变成 100% 合法，与“不会幻觉”的宣传冲突。（较多人） > 感觉只是更快地得到抛硬币式答案。（@ludicrousskill）

认为大模型生成的产品页和一次性建站体验令人反感

• 多名评论者抱怨页面视觉混乱、废话填充、可用性差，甚至分不清是正经项目还是低质生成物；也有人直接问是不是用 ChatGPT 做的。（较多人） > 这些一次性拼出来的网站总是视觉灾难：堆砌、废话、毫无可用性。（@prodigycorp）

对杰文斯悖论式生态和新工作机会持乐观态度

• 少数人认为这类低成本决策服务会催生大量用例、应用和新工作，并注意到模型可能完全用合成数据训练；也有人惊叹基于一次发布快速衍生新发布的速度。（少数人） > 这是真正的杰文斯悖论，会衍生出大量用例、应用甚至新工作。（@colesantiago）

对真正 Jev 的技术实现和开放权重更感兴趣

• 有评论更想知道真正 Jev 如何做到又快又便宜，猜测其规模不小但有非平凡优化，并希望出现开放权重版本；也有人指出 Jev 创始人自称更像数据公司，因此训练数据可能是与 OpenJev 的关键差异，而 Jev 当前价格已低到不必自托管。（较多人） > 如果它能被复刻成开放权重，那会很令人兴奋。（@druskacik）

有价值的补充

• 受限解码的经典做法是：枚举所有符合语法的下一个候选词元，把不允许的置零，再在允许集合中取最优；这能避免生成式模型在结构化输出上的浪费。（@spwa4）
• 有评论把 Jev 与仅编码器模型类比，认为机制上可能相近。（@neilellis）
• 生物类比：人类神经系统从快速但笨、盲目的底层回路，到每周才做一次决策的前额叶，提示快而笨的局部决策与慢而聪明的全局推理可以分工。（@spwa4）
• 同一“该不该过马路”问题，Qwen3 直接读选项为 98.5% 选“是”，生成式则为 50/50；MiniCPM5 直接读为 12.2% 选“是”，生成式又回到 50/50；Qwen3.5 两种模式则从 52.9/47.1 跳到 95/5；掷骰子实验里概率模式 1.968 秒给出 76% 落在 1 点，生成模式 3.083 秒给出均等概率。（@ludicrousskill、@paulluuk）
• Hugging Face 被公司防火墙或 VPN 拦截时下载模型会失败，有人询问可用镜像；iPad Pro 上即便选了最小模型也卡在加载或极慢，刷新后模型仍在缓存也无济于事。（@tomaytotomato、@stpedgwdgfhgdd）
• 有人贴出 Hugging Face 上的 laya，作为同类开放方向参考。（@kouteiheika）