AREX Feed Article
GitHub Next 公开 LocalJev：基于 oMLX 的本地 Jev 兼容实现，附 1,200 次请求的评测
9 月 19 日，GitHub 内部研究软件开发未来的团队 在 X 上：一个在本地运行、接口与 Jev 兼容的决策实现。它用 TypeScript 为 Bun 编写，跑在 Mac 的本地推理服务器 oMLX 上，默认由 DiffusionGemma 经 OpenAI 兼容的 Chat Completions 端点驱动，对外提供 Jev 兼容的 POST /v1/systemone 决策 API；代码、文档和一份在 M5 Max 上完成的 1,200 次请求评测都在 仓库里。这份评测把 Gemma 4 26B-A4B 与 Qwen3.6 列为小样本筛查里的最强候选。
Jev 是 TypeSafe AI 几天前发布的决策模型；按的说法，它用预定义的类型返回带概率的结构化决策、不生成文本，目前处于早期访问（early access）阶段，TypeSafe 正逐步放行等待名单上的开发者。在它发布之后，独立的本地实现也开始出现，比如 ：它在 vLLM 上复现了 Jev 的协议，靠一个尚未合并的 提供的结构化读取，直接从 DiffusionGemma 的概率里读出答案。LocalJev 也属于这类实现，但走法不同。
「不是所有人都有 Jev 权限」：一个上午搭出的本地替代
「团队里还不是所有人都有 Jev 的访问权限」，发帖者于是花了一个上午，在 oMLX 上拼出一个供本地使用的「穷人版 Jev」，并把 DiffusionGemma 和几种自回归模型（Qwen MoE、Gemma 4 MoE、Gemma 4 E4B/E2B）放进了评测。推文自述这是「100% 靠提示词写代码」的产物，但同时称「评测看起来还行」、M5 Max（64GB）本机的速度不错，而且 LocalJev 暴露的 API 可以直接配合常规的 Jev API 封装库使用。
接口层面，LocalJev 监听本机 8080 端口，提供 POST /v1/systemone，接受 state 与类型化问题（choice、score、noul 等）；把 TypeSafe SDK 的 TYPESAFE_BASE_URL 指向它、再填一个 API 密钥即可（默认接受任意值），SDK 默认的 jev-latest / jev-preview 模型名就能照常工作。默认上游是本地 oMLX 服务器（127.0.0.1:8000）上的 diffusiongemma-26B-A4B-it-4bit。
接口兼容，但概率由模型自己报出
仓库写明了「兼容」的边界：它接口层面兼容（wire-compatible），但与 OpenJev 的 logit 读取并不「数学等价」。OpenJev 直接读取模型对每个候选词元的原始打分（logits）；LocalJev 的概率则是由模型自己生成、自己报出来的。README 因此提醒：在依赖这些概率做后果重大的决策之前，先在自己的工作负载上评估它们的校准。
实现上，LocalJev 把 state 和类型化问题翻译成分类提示；要求 DiffusionGemma 返回 JSON 格式的概率标量或向量；校验完整结果，对格式错误重试；把向量归一化，计算 Jev 兼容的选项、期望分数和基于熵的置信度；最后按 Jev 的响应结构返回。
LocalJev 之所以选择「提示自报」（prompted / self-reported）路线，是因为普通 oMLX API 不提供 OpenJev 依赖的那些原语：带种子的画布、只读去噪、指定词元（token）的对数概率（logprobs）。README 还提到，截至 9 月 18 日，LM Studio 仍无法加载 DiffusionGemma（ 和 都还没有关闭），而 oMLX 能正常加载并运行它，是目前 Mac 上更合适的选择。README 为想要直接读取模型概率的路线列了两条：给 oMLX 的 DiffusionGemma 支持补上结构化读取原语，或者换到支持的 NVIDIA 机器上运行 OpenJev 打过补丁的 vLLM 后端。
五个本地模型的对比：三个较大的模型没有分出高下
评测直接运行 LocalJev 实际使用的 TypeScript 引擎，连接本地推理服务器；题目与标注答案来自公开数据集，没有使用合成标签或 LLM 裁判。9 月 18 日完成的覆盖 5 个 4-bit 模型、3 项任务（AG News 新闻分类、BoolQ 是非问答、SST-5 五级情感）和 2 种输入条件（不加背景，或加入 2,048 个背景词）；每项任务 40 个样本，合计 1,200 次请求（5 个模型 × 120 个样本 × 2 种条件），在 M5 Max（64GB）、oMLX 0.6.4 和 Bun 1.4.0 上约 23.5 分钟跑完；方法细则见。
短输入下，Qwen3.6-35B-A3B 的宏平均准确率（三项任务准确率的平均）最高，为 76.7%；Gemma 4 26B-A4B 为 75.0%；LocalJev 的默认后端 DiffusionGemma 26B-A4B 为 74.2%；两个小模型 E4B、E2B 分别为 63.3% 和 45.8%。中位耗时从 0.52 秒（E2B）到 1.21 秒（DiffusionGemma）不等；这组数字是完整决策的墙钟时间（单请求、单并发），不是首 token 时间。DiffusionGemma 没有速度优势，其较慢请求的耗时（p95，即 95 分位）约 1.9 秒；不过它的 BoolQ 准确率最高（87.5%，比紧随其后的模型多对一题）。在加入背景词的长输入条件下，所有模型的宏平均准确率都下降，Gemma 4 26B-A4B 与 Qwen3.6 打成平手（均为 69.2%），E4B 的 SST-5 准确率从 50% 跌到 12.5%。
报告列出了这些限制：每项任务 40 个样本只是筛选级样本，多答对或少答对一题，准确率就会变动 2.5 个百分点；三个较大的模型之间没有可靠的先后排序，差距相对抽样不确定性来说很小，不足以判定谁更好；公开基准可能存在污染；「不要把输出当成已校准的概率」。它建议用每项任务 200 个以上样本、再配一份真实工作流的标注数据重测，并指出 LocalJev 的默认服务配置并未改动。小模型还暴露了格式问题：E2B 在长输入下每 120 次请求有 21 次需要重试、3 次耗尽重试；报告强调，JSON 写对不等于语义正确。
「这不是一次严谨的评测」：没有与 Jev 的对照
这条推文已有约 1,100 次点赞和近 15 万次浏览。回复里的追问指向两件事：它离真正的 Jev 有多远，以及这次评测够不够扎实。
被问到哪个模型最接近 Jev 的表现时，GitHub Next 的是：「如果能拿到 Jev 的访问权限做并排对比，就不用做这个临时替代品了。」则写明，这次评测不是对 TypeSafe Jev 的基准测试，也不是对 OpenJev 后端的基准测试。
有人在回复里要求公布完整的评测契约（提示词、候选标签、温度、校准指标等）与分数；账号的更直接：「会看看，不过这不是一次严谨的评测。我实际测量的只有一件事：这些本来就不合适的模型，在这台机器上当作类 Jev 分类器用时表现如何。相互比较之下，我能得到『哪个模型对我最好用』的信号。」
另有回复者（）称自己也用 5 个模型跑了 1,200 多次调用，并建议给评测加一栏期望校准误差（ECE）：「准确率很容易追平，难的是校准，多数模型不管对错都报 0.9 以上。」
报告把数据来源、校验和与复现命令一并公开，可以增加样本量，或换成自己工作流的标注数据重跑一遍。提示自报的概率在实际负载上校准如何、与真正的 Jev 相差多少，报告都没有回答。